Index

General Information
Part A: Information about the offeror or the person seeking admission to trading
Part B: Information about the issuer, if different from the offeror or person seeking admission to trading
Part C: Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D: Information about the crypto-asset project
Part E: Information about the offer to the public of crypto-assets or their admission to trading
Part F: Information about the crypto-assets
Part G: Information on the rights and obligations attached to the crypto-assets
Part H: Information on the underlying technology
Part I: Information on the risks
Part J: Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts

2026-06-02

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union.
The operator of the trading platform of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

False

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

Warning
This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other documents pursuant to the applicable national law.
This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

S is the native crypto-asset of the Sonic network,an EVM-compatible layer-1 blockchain. The Sonic project provides blockchain infrastructure for users and developers of decentralised applications, including Sonic Gateway for transfers between Ethereum and Sonic.

Holders of S may use the crypto-asset to pay gas fees for transactions on Sonic, stake or delegate S in connection with network validation and security, and participate in governance where applicable.Staking and delegation are subject to the applicable network rules. Withdrawing staked S involves a 14-day waiting period and that holders should choose validators carefully, because validator penalties for misconduct or setup errors may affect delegated S. A person operating a validator must satisfy the validator requirements, including the applicable minimum self-stake.

S crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Sonic project. Holding S does not give rise to contractual claims or entitlements against any natural or legal person.

S is designed for functional use within the Sonic network. Any interaction with the token occurs through compatible wallets, Sonic network applications, the Sonic staking system, validator-node software, and governance processes, as applicable. Token-related parameters and network arrangements may be modified through Sonic’s governance and technical update processes.

Not applicable

The token has been admitted to trading to the trading platform operated by Bitstamp Europe S.A. on its own initiative.

TRUE

Sonic Operations Ltd. (“Sonic Labs”)

UE3G

Stuarts Corporate Services Ltd, P.O. Box 2510, Kensington House, 69 Dr Roy’s Drive, George Town

KY1-1101

Stuarts Corporate Services Ltd, P.O. Box 2510, Kensington House, 69 Dr Roy’s Drive, George Town

KY1-1101

2024-05-13

984500AC98A5B4936B57

Not applicable as LEI is provided in B.7.

Not applicable as LEI is provided in B.7.

Sonic Operations Ltd. (‘Sonic Labs’) facilitates the issuance of the S token and supports the development, operation and ecosystem growth of the Sonic blockchain, including protocol development, network infrastructure coordination, ecosystem support and related operational activities.

Not applicable

Bitstamp Europe S.A.

5GGB

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

40, avenue Monterey, L-2163, Grand Duchy of Luxembourg

LU-LU

2015-05-19

549300XIBGTJ0PLIEO72

Bitstamp Europe S.A. is registered with the Luxembourg Trade and Companies Register under the number B196856.

Robinhood Markets, Inc with its registered office at 85 Willow Road, Menlo Park, California 94025, USA.

Bitstamp Europe S.A., acting in its capacity as a crypto-asset service provider (CASP) and operator of a trading platform, has prepared this crypto-asset white paper to support the admission to trading of the crypto-asset on its platform and to provide users with the information required under Regulation (EU) 2023/1114 (MiCA).

Bitstamp Europe S.A. is a Crypto-Asset Service Provider authorised with the CSSF under the number N00000003 to provide the following crypto-asset services:

• providing custody and administration of crypto-assets on behalf of clients;
• operation of a trading platform for crypto-assets;
• exchange of crypto-assets for funds;
• exchange of crypto-assets for other crypto-assets;
• execution of orders for crypto-assets on behalf of clients;
• reception and transmission of orders for crypto-assets on behalf of clients; and
• providing transfer services for crypto-assets on behalf of clients.

Bitstamp Europe S.A. is a payment institution authorised by the CSSF under number Z00000012 to provide the following payment services:

3.a) execution of direct debits, including one-off direct debits,

3.b) execution of payment transactions through a payment card or a similar device,

3.c) execution of credit transfers, including standing orders and

6.) money remittance.

Bitstamp Europe S.A. has notified the cross-border provision of payment services and of crypto-asset services in all EU and EEA member states.

Bitstamp has admitted the asset to which this white paper relates to, to trading on its own initiative on its trading platform.

Robinhood Markets, Inc. is the parent holding company of the Robinhood group.

MiCA Crypto Alliance Limited

MiCA Crypto Alliance Limited was mandated to assist in the white paper preparation by Bitstamp Europe S.A. Bitstamp Europe S.A. retains the role of person seeking admission to trading.

Sonic

S

S

Sonic is an EVM-compatible layer-1 blockchain project designed to provide high-throughput and low-latency distributed-ledger infrastructure for decentralised finance applications and other decentralised applications. The network is designed to support up to 400,000 transactions per second with sub-second finality while maintaining compatibility with the Ethereum Virtual Machine (EVM) and support for Solidity and Vyper smart contracts.

The project includes validator and staking infrastructure, developer tooling, interoperability infrastructure and incentive programs intended to support network activity and application development. Its incentive programs include Fee Monetization, under which developers may receive a share of the network fees generated by their applications, the Innovator Fund intended to support projects building on Sonic, and the Sonic airdrop program intended to incentivise network users through a points-based system.

The native crypto-asset of the project is S, which is used for transaction fees, staking, validator participation and governance-related functions within the Sonic ecosystem.

The project also includes the Sonic Gateway, which is an interoperability mechanism connecting Ethereum and Sonic. Sonic Gateway is intended to facilitate transfers of supported assets between Ethereum and Sonic while incorporating a fail-safe recovery mechanism intended to protect user assets in the event of extended operational disruption.

FALSE

Not applicable

Past milestones

Sonic Labs announced the new Sonic chain in May 2024 as a Layer 1 network with a native Ethereum bridge, the introduction of the Sonic Foundation and Sonic Labs, and a 1:1 migration path from Fantom token (FTM) to S. The initial total supply of S at launch was 3,175,000,000, matching the total supply of FTM. Sonic Labs later stated that migration incentives were introduced in June 2024, the transition was publicly outlined in September 2024, and the Sonic network launched on 18 December 2024.

Sonic mainnet launched on 18 December 2024 as an EVM-compatible Layer 1 blockchain with Sonic Gateway, MySonic, staking access, FTM-to-S migration, Sonic Points, Sonic Gems and developer Fee Monetization. The FTM-to-S migration initially operated as a two-way conversion mechanism between FTM and S following Sonic’s launch. On 18 March 2025, the migration mechanism changed to a one-way conversion from FTM to S. Subsequently, following a governance-approved tokenomics update, the S supply began increasing from 19 June 2025., and 18 June 2025 was the date on which updated tokenomics took effect and the S supply began to increase. Sonic Labs also announced Sonic Airdrop season 2 beginning on 18 June 2025, with a revised rewards model focused on activity-based user points, loyalty-based participation and application-level Gems based on more sustainable ecosystem usage metrics. The initial issuance of 472,372,662.8 S took place on 4 September 2025 and was allocated to the Nasdaq Digital Asset Treasury initiative and the Sonic USA entity.

Sonic Labs announced the final stage of the season 1 and season 2 airdrop claim process. According to the announcement, approximately 32,690,000 S remained unclaimed across season 1 and season 2 allocations. Eligible holders may continue to claim remaining allocations, subject to the applicable unlock and penalty rules, until the final deadline. Season 1 claims become claimable without penalty from 18 April 2026 to 15 October 2026, and season 2 claims become claimable without penalty from 24 May 2026 to 15 October 2026. After 15 October 2026, any remaining unclaimed locked S may be permanently burned. Sonic Labs stated that the remaining incentive allocation continues to be reserved for future airdrops, incentives, or burn, with no additional airdrop minting planned.

Future milestones

Sonic Labs has stated that SonicCS is architecturally positioned for a future migration to post-quantum cryptography because its consensus design relies on per-event digital signatures and hash functions, rather than aggregate certificates or threshold-signature structures. According to Sonic Labs, this means that a future quantum-resistance upgrade would be expected to involve replacing the current signature scheme with a post-quantum signature scheme and updating hash parameters, while leaving the consensus logic, Directed Acyclic Graph (DAG) structure and liveness guarantees materially unchanged.

Through 2026, Sonic intends to focus on consistent execution across its infrastructure, ecosystem development and economic-alignment initiatives.

Sonic Labs is also pursuing a selective vertical-integration strategy around core financial infrastructure. This approach is intended to improve operational reliability and support mechanisms through which value generated by network activity may be reflected in the S token ecosystem, while continuing to support independent developers and applications building on Sonic.

Sonic Labs also intends to continue working with ecosystem teams to improve developer tooling, support high-quality applications, and refine mechanisms designed to strengthen the long-term sustainability of the network.

S does not have a fixed capped supply. Additional S tokens may be issued pursuant to governance-approved tokenomics measures to fund network growth and expansion, including initiatives intended to increase S adoption, expand operations, support marketing activities and facilitate DeFi onboarding. Accordingly, the total supply of S may increase over time.

A governance proposal approved the issuance of S tokens in support of Sonic’s institutional expansion into United States capital markets. This included an allocation equivalent to USD 50,000,000in S for the pursuit of an exchange-traded fund relating to S, an allocation equivalent to USD 100,000,000 in S for the pursuit of a Nasdaq Digital Asset Treasury arrangement, and an allocation of 150,000,000 S tokens for the Sonic USA entity. The first issuance of 472,372,662.8 S occurred on 4 September 2025 and covered the allocation for the Nasdaq Digital Asset Treasury initiative and the Sonic USA entity. Sonic further states that an additional USD 50,000,000 in S may be issued in support of the pursuit of an S exchange-traded fund.

The transparency regarding the use of issued S tokens has been provided through publicly identified transactions associated primarily with SonicStrategy multisignature wallets. According to Sonic, these transactions included a transfer of 126,622,348.845 S to the former SonicStrategy Digital Asset Treasury multisignature wallet, a transfer of 500,000 S to the new SonicStrategy Digital Asset Treasury multisignature wallet for validator setup purposes, and a subsequent transfer of 126,122,433.845 S from the former SonicStrategy Digital Asset Treasury multisignature wallet to the new SonicStrategy Digital Asset Treasury multisignature wallet.

Sonic states that the first issuance for the airdrop program, amounting to 89,778,181.9 S, occurred on 17 July 2025 and 31 July 2025.

The Sonic airdrop program minted 190,500,000 S tokens intended to incentivise participation within the Sonic ecosystem. Sonic states that these tokens were allocated through the Sonic Points, Sonic Gems and Game Gems programs. Sonic Points were intended to reward users deploying assets and liquidity across applications on Sonic, Sonic Gems were intended to reward decentralised-finance applications driving user engagement on the network, and Game Gems were intended to reward games promoting player engagement and retention within the ecosystem.

The airdrop program was distributed across two seasons. According to Sonic, Season 1 allocated approximately 89,500,000 S and concluded on 18 June 2025, while Season 2 allocated approximately 6,000,000 S and continued until 1 November 2025. Sonic further states that an additional Kaito campaign allocated approximately 2,800,000 S and operated concurrently with Season 2. The remaining approximately 92,200,000 S was retained in treasury reserves for future targeted ecosystem incentives and strategic initiatives.

The airdrop program also rewarded certain historical activities associated with the Fantom Opera ecosystem, participation in Sonic Arcade activities and holders or minters of the Shard NFT. According to Sonic, the remaining treasury allocation is intended to support sustainable network usage, liquidity participation, developer support and future ecosystem incentive initiatives, with no additional S tokens intended to be minted for these incentive programs.

For Season 1 of the airdrop, 25% of a participants’ allocation became immediately claimable, while the remaining 75% vested over a 270-day period through NFT positions tradable on the Airdrop Order Book operated by Paintswap.

Sonic Labs states that approximately 32,690,000 S remained unclaimed across Season 1 and Season 2 airdrop allocations as of the relevant update. Any of these tokens will be burned permanently, if not claimed before 15 October 2026, as the contract permits the remaining locked balance to be burned once the burn date is reached. Eligible Fungible NFTs (fNFT) holders may still unlock and claim the remaining S associated with their airdrop positions before the final cut-off. Claims made before the applicable full-unlock dates may remain subject to a penalty, while claims made after full unlock and before 15 October 2026 may be made without penalty. For season 1, penalty-bearing claims remain available until 18 April 2026, after which claims may be made without penalty until 15 October 2026. For season 2, penalty-bearing claims remain available until 24 May 2026, after which claims may be made without penalty until 15 October 2026.

47,625,000 S tokens may be issued annually for 6 years beginning 6 months after the Sonic mainnet launch, with the first issuance of 47,625,000 S occurring on 18 June 2025. Sonic further states that any tokens issued under this program but not used during the relevant year are intended to be burned in order to limit inflationary effects and ensure that issued tokens are used for ecosystem growth purposes rather than retained indefinitely in treasury reserves.

The validator block rewards from the Fantom Opera network were migrated to Sonic in connection with the transition from Opera to Sonic. According to Sonic, the remaining Opera block rewards are intended to support validator rewards on Sonic during the first 4 years following Sonic’s launch, thereby avoiding the issuance of new S tokens for validator rewards during that period. Sonic states that, after the initial 4-year period, validator rewards are intended to resume through issuance of new S tokens at a rate of 1.75% annually.

Target validator reward rate is 3.5% annually where approximately 50% of the network supply is staked, with the effective reward rate adjusting proportionally depending on the staking participation level across the network.

Not applicable

By admitting the S asset to trading, holders of the token will gain transparent price discovery and improved liquidity. This enables the project’s community and ecosystem participants to more easily enter and exit positions, supporting a dynamic and efficient market.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account. If a client wants to hold the token in their own wallet, they will need to (i) provide an external blockchain wallet address, where the crypto-assets will be sent if a withdrawal is initiated and (ii) satisfy all other requirements applicable to a withdrawal in line with the Regulation (EU) 2023/1113 of the European Parliament and of the Council of 31 May 2023 on information accompanying transfers of funds and certain crypto-assets.

When a client purchases a token on the Bitstamp Europe S.A.'s trading platform, the crypto-asset will be credited to their Bitstamp account and a client does not need to fulfill any other technical requirement to hold the crypto-assets on their Bitstamp account, apart from have either a computer or phone with an internet connection and appropriate software in order to interact with the Bitstamp services.

Bitstamp Europe S.A.

BESA

Investors can access the trading platform through https://www.bitstamp.net or via the Bitstamp applications.

There are no costs involved in creating an account on the trading platform, however trading fees and other costs apply in accordance with the fee schedule available at https://www.bitstamp.net/fee-schedule.

Not applicable

There are no conflicts of interest arising at the moment of writing the white paper in relation to the offer or admission to trading. Bitstamp Group has a strict Code of Conduct and Trading Policy in place. They both mitigate the possibility of conflicts of interest.

In accordance with the Code of Conduct all officers, directors, employees, agents, representatives, contractors and consultants (and other persons, regardless of job or position), are required to report any situation where there is the potential for conflict of interest between their interests and interests of Bitstamp. The Trading Policy that is in place within the Bitstamp Group prohibits all forms of market manipulation and has been designed to prevent insider trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Not applicable, as this point pertains to an 'offer to the public', whereas this white paper relates to admission to trading.

Crypto-assets other than asset-referenced tokens or e-money tokens

S is used within the Sonic network to pay transaction fees, to stake, to operate validators, and to participate in governance. Sonic supports Ethereum-compatible smart contracts, including contracts written in Solidity and Vyper, meaning that S functions as the native gas asset for the execution of transactions and smart-contract activity on the network.

S also supports the proof-of-stake security model of the Sonic network. Validators are required to lock S in order to participate in transaction validation and block production, and users may delegate S to validators through the staking system. Validators may lose staked tokens if they act maliciously, and that staking operations are managed through the Special Fee Contract.

S is also used in connection with Sonic’s economic-incentive mechanisms. Under Sonic’s Fee Monetization program, network fees generated by applications may be allocated to developers, with rewards calculated by reference to gas consumption within transactions. This links the use of S for network fees with incentives for application development and ecosystem activity.

The broader functionality of S is connected with Sonic’s interoperability infrastructure. Sonic Gateway is Sonic’s native bridge between Ethereum and Sonic is designed to facilitate the transfer of supported assets between the two networks. The Gateway includes a fail-safe mechanism allowing users to retrieve bridged assets on Ethereum if the Gateway or Sonic chain is unavailable for 14 consecutive days.

Not applicable

S is the native crypto-asset of the Sonic network,an EVM-compatible layer-1 blockchain. The Sonic project provides blockchain infrastructure for users and developers of decentralised applications, including Sonic Gateway for transfers between Ethereum and Sonic.

Holders of S may use the crypto-asset to pay gas fees for transactions on Sonic, stake or delegate S in connection with network validation and security, and participate in governance where applicable.

Staking and delegation are subject to the applicable network rules. Withdrawing staked S involves a 14-day waiting period and that holders should choose validators carefully, because validator penalties for misconduct or setup errors may affect delegated S. A person operating a validator must satisfy the validator requirements, including the applicable minimum self-stake.

S crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Sonic project. Holding S does not give rise to contractual claims or entitlements against any natural or legal person.

S is designed for functional use within the Sonic network. Any interaction with the token occurs through compatible wallets, Sonic network applications, the Sonic staking system, validator-node software, and governance processes, as applicable. Token-related parameters and network arrangements may be modified through Sonic’s governance and technical update processes.

N/A as DTI is provided in F.13

https://www.soniclabs.com/

2026-07-03

2026-07-02

Not applicable

English

JN8QMR9XS

7JBMLCWCR

FALSE

TRUE

TRUE

Not applicable as the S crypto-asset holders do not acquire any ownership, equity, profit participation, repayment, or redemption rights against any natural or legal person associated with the Sonic project. Holding S does not give rise to contractual claims or entitlements against any natural or legal person.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable as the asset confers no ownership or financial claims and does not impose any legal obligations.

Not applicable

FALSE

Not applicable

Not applicable

TRUE

Not applicable

Not applicable

FALSE

Not applicable

FALSE

Not applicable

FALSE

Not applicable

There is no written legal agreement between the issuer and the crypto asset-holder that sets out the laws that govern the legal relationship between those two parties. In the absence of such an agreement, the laws that govern that relationship will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

There is no written legal agreement between the issuer and the crypto asset-holder that sets out which jurisdiction's courts will have authority to deal with a dispute between the crypto asset-holder and the issuer. In the absence of such an agreement, the laws of the competent court will depend on the location of the issuer and the given crypto asset-holder and characteristic performance of the legal relationship, and any agreed intention of the issuer and crypto asset-holder.

Not applicable as DTI is provided in F.13

Sonic is a public, permissionless EVM Layer 1 blockchain. S is its native token, used to pay transaction fees, stake, operate validators, and participate in governance. S is not implemented through a separate token contract and does not conform to any contract-level token standard such as ERC-20; its behaviour is defined entirely at the protocol level. The network uses chain ID 146, with the native currency symbol S, and exposes a public RPC endpoint at https://rpc.soniclabs.com and a block explorer at https://sonicscan.org.

Networking, transport and session

The public mainnet RPC endpoint and block explorer provide the primary access interfaces for wallets, developers, and applications. Archive nodes may additionally expose HTTP and WebSocket RPC services: HTTP supports request-and-response queries, while WebSocket enables persistent connections for event subscriptions. Validator node operation requires inbound TCP and UDP traffic on the default consensus port for participation in the Lachesis consensus protocol.

Serialisation

Any smart contract that runs on Ethereum can be deployed on Sonic without modification. Supported smart contract languages are Solidity and Vyper. Sonic also confirms compatibility with Geth 1.4. The network supports Ethereum's Cancun hard fork features, including the PUSH0 opcode (EIP-3855), with the exception of EIP-4844 data blobs. EIP-155 is enforced for all transactions, binding each signed transaction to chain ID 146 and preventing replay on other networks.

Release 2.1 introduced full ERC-4337 account abstraction compatibility, enabling smart contract wallets with programmable authorisation logic. The model operates through UserOperations, an alternative mempool, bundlers that collect and simulate UserOperations before packaging them into a single transaction submitted to an EntryPoint contract, and optional paymasters that sponsor gas on behalf of users. This operates at the application layer and does not alter the underlying Layer 1 consensus mechanism.

Cryptography and key formats

As a fully EVM-compatible chain, Sonic uses standard Ethereum cryptographic primitives for externally owned accounts: elliptic-curve digital signatures over secp256k1, with account addresses derived by applying Keccak-256 to the uncompressed public key. Validator nodes additionally use a dedicated signing key to authorise consensus messages. State data is committed via Carmen's cryptographic structures, which support an Ethereum-compatible state-commitment schema using an incremental prefix algorithm rather than indirect key-value storage.

Ledger and state

Sonic records account balances, smart contract bytecode, and contract storage in a world state managed by Carmen, the network's purpose-built storage engine (also referred to as SonicDB). Carmen splits this state across two database types. LiveDB contains the world state of the current block only and is used exclusively by validator nodes. ArchiveDB stores the world states of all historical blocks and is held by archive nodes alongside LiveDB to serve historical RPC queries. Carmen uses a native disk format rather than storing state indirectly through general key-value stores such as LevelDB or PebbleDB. Chain parameters, including DAG-related network rules, are accessible programmatically through the eth_getRules RPC method.

Execution

Sonic's execution environment is powered by SonicVM, a high-performance internal translation layer that dynamically translates EVM bytecode into an optimised internal representation. SonicVM uses super-instructions for frequently occurring code patterns, increasing execution efficiency without compromising compatibility. SonicVM is fully compatible with all standard Solidity and Vyper compiled contracts and preserves deterministic execution semantics identical to those of the standard EVM.

External APIs

The public mainnet RPC endpoint is available at https://rpc.soniclabs.com and the block explorer at https://sonicscan.org. Network parameters are queryable through eth_getRules. Staking integrations use functions exposed by the Special Fee Contract. Bridge integrations use the Gateway contracts, with programmatic access documented in the Sonic developer documentation. .

Implementation and architecture

The Sonic node software is implemented in Go and requires a C compiler to build from source. It supports two operational modes: archive node and validator node. Archive nodes retain the complete chain history and serve historical RPC queries. Validator nodes participate in consensus and block production using LiveDB only, without retaining full historical state. This separation allows operators to match their infrastructure to their use case without the overhead of full historical storage.

The consensus engine is Lachesis, a leader-based proof-of-stake protocol that implements asynchronous Byzantine fault-tolerant consensus using directed acyclic graphs, described in H.4. Staking operations for validators and delegators are managed on-chain by the Special Fee Contract (SFC), which records delegations, undelegations, withdrawals, and reward accumulation. To operate as a validator, an operator registers through the SFC, obtains a signing key for consensus messages, and runs the node software in validator mode. The validator wallet handles account-level actions while the signing key handles consensus message authorisation separately.

Carmen provides the LiveDB and ArchiveDB storage layers. The consensus repository contains the protocol interfaces and modules for the Lachesis consensus mechanism. The sonic-SFC repository contains the Special Fee Contract source and logic. All four primary repositories, sonic client, Carmen, consensus, and sonic-sfc, are published as open-source repositories under the 0xsoniclabs GitHub organisation.

Sonic Gateway

The Sonic Gateway is the native bridge facilitating ERC-20 token transfers between Ethereum and Sonic. Transfers from Ethereum to Sonic are processed in batches called heartbeats at approximately 10-minute intervals; transfers from Sonic to Ethereum are processed at approximately 1-hour intervals. Users may pay for a Fast-Lane transaction to trigger an immediate heartbeat outside the standard schedule, making bridged funds available at once rather than waiting for the next scheduled batch.

The Gateway transmits each chain's Merkle root and block height in each heartbeat. If the heartbeat ceases for 14 consecutive days, a built-in fail-safe activates, allowing users to recover their original deposit on Ethereum. This 14-day period is immutable and cannot be altered by Sonic Labs or any third party after deployment. The Gateway uses Circle's CCTP V2 for USDC transfers specifically.

Runtime and build parameters

Node recovery procedures are published for operators encountering failed or corrupted states, covering log inspection, removal of corrupted data, backup restoration, and resynchronisation.

Dependencies

The principal software components are: the Sonic client (EVM execution and Lachesis consensus); the Carmen storage engine (LiveDB and ArchiveDB); the consensus repository (ABFT protocol interfaces and modules); and the sonic-sfc repository (validator and delegator management via the Special Fee Contract). All four are published under the 0xsoniclabs GitHub organisation.

Native Layer 1 finality and absence of Layer 2 dependencies

Sonic is a Layer 1 blockchain. True finality is achieved in a single block with no longest-chain rule and no requirement to write data back to Ethereum. It does not inherit settlement finality from a separate base layer and is not subject to fraud proof challenge windows or validity proof verification requirements. The Sonic Gateway participates in the Ethereum ecosystem for asset transfer purposes but does not convert Sonic into a Layer 2 rollup. L2-style proof submission, external data availability committees, and challenge periods are not part of the Sonic core protocol.

Sonic uses a leader-based, asynchronous Byzantine fault-tolerant (ABFT) consensus mechanism derived from the Lachesis protocol, combined with directed acyclic graphs. Byzantine fault tolerance ensures the network continues to reach agreement even when some participants behave incorrectly or maliciously. The asynchronous property means consensus does not depend on all validators receiving messages simultaneously. In the DAG structure, each event produced by a validator references one or more earlier events without forming cycles, enabling concurrent transaction ordering across validators before block output. Unlike classical BFT systems that require sequential majority agreement for each block, this design avoids sequential dependency and achieves sub-second, single-block finality with no rollback risk.

Sybil resistance is achieved through proof of stake. Validators must lock at least 500,000 S to participate. A validator that acts maliciously loses their locked tokens, providing a direct economic disincentive for incorrect behaviour. Delegators may assign S to validators through the SFC to participate in staking economics without running a node; delegated stake is equally exposed to any penalty applied to the chosen validator. Consensus weight is proportional to staked amounts.

Transaction fees

Sonic uses a fee model composed of a base fee and a priority fee, analogous to Ethereum's EIP-1559. The base fee has a configured minimum of 50 Gwei and does not adjust dynamically under normal conditions because the network's gas capacity is not saturated under typical load. Unlike Ethereum, the base fee is not burned at the protocol level; instead it is distributed according to the fee allocation rules below.

Gas price values returned by eth_gasPrice and eth_feeHistory include a 10% buffer above the block base fee, accounting for Sonic's asynchronous multi-block resolution process and preventing transaction rejection due to minor base fee movement between estimation and execution. Each validator holds a gas power budget that refills over time in proportion to their stake, limiting any single validator's throughput per period and linking transaction inclusion capacity to staked participation.

Fee allocation (updated September 2025)

A governance proposal approved on 31 August 2025 with 99.99% support updated the fee distribution mechanism. The updated allocation, which increases deflationary pressure on S supply, distinguishes between transactions that interact with FeeM-registered contracts and those that do not.

For FeeM transactions; those involving contracts registered under the Fee Monetization program ; 90% of the transaction fee is distributed to the registered developer, 5% is allocated to validators, and 5% is burned. For non-Fee Monetization transactions; those not involving any registered contract; 50% of the transaction fee is burned and 50% is distributed to validators.

Fee Monetization

The Fee Monetization (FeeM) program allows registered developers to earn 90% of the network fees generated by their applications. Off-chain oracle servers monitor every on-chain transaction and trace gas consumption per registered contract including all internal sub-calls, accurately attributing fees between multiple projects that share a single transaction without double-counting. When an application claims rewards, a quorum of oracles confirms the gas attribution on-chain before the FeeM contract releases accumulated rewards to the developer.

Validator rewards

Validators earn income from their share of transaction fees and from block rewards. During Sonic's first 4 years of operation, block rewards are drawn from approximately 70,000,000 S per year reallocated from the Fantom Opera validator reward pool, which is already included in the initial supply of 3,175,000,000 S. No new tokens are minted for block rewards during this period.The effective reward rate adjusts proportionally with staking participation: 7% when 25% of the total supply is staked, 3.5% when 50% is staked, and 1.75% when 100% is staked. After the initial 4-year period, new S tokens are minted at a rate of 1.75% per year to fund continuing validator rewards.

Staked S is subject to a 14-day undelegation period after which a 7-day withdrawal window opens. Positions not withdrawn within the withdrawal window must re-initiate the undelegation process.

Liquid staking

The 14-day undelegation period and 7-day withdrawal window create a predictable framework for building a liquid staking token market, enabling stakers to access liquidity through LST protocols without compromising their staking position or the network's security model.

Token supply and burn

The initial total supply of S at launch was 3,175,000,000, matching the total supply of FTM. Two active burn mechanisms offset new issuance. Airdrop recipients who choose not to wait for the full 270-day maturation period for the remaining 75% of their airdrop allocation, distributed as ERC-1155 NFT positions, forfeit a portion of those tokens, which are permanently burned. From the 47,625,000 S minted annually for 6 years to fund network growth, any tokens not deployed during the year are burned at year-end, ensuring the entire growth allocation is actively used.

A governance-approved institutional expansion separately issued 472,372,662.8 S on 4 September 2025 to fund the pursuit of a Nasdaq digital asset token and to capitalise the Sonic USA entity, with tokens allocated to the DAT vehicle subject to a minimum 3-year lock-up. Should the Nasdaq program not be achieved, undeployed funds are to be returned to the Sonic Foundation for an alternative purpose or burned. In addition, the updated fee mechanism introduced in the same September 2025 governance vote — burning 5% of FeeM transaction fees and 50% of non-FeeM transaction fees — creates ongoing, protocol-level deflationary pressure on circulating supply.

Governance

S holders participate in on-chain governance. Governance proposals have amended tokenomics, including the September 2025 institutional expansion issuance and the updated fee mechanism. Governance outcomes are binding once quorum and majority thresholds are met. Economic parameters within the SFC, including undelegation and withdrawal periods and reward-related constants, are exposed through a constant manager function and may be subject to future governance adjustment.

FALSE

TRUE

OpenZeppelin | December 2024 — Sonic Gateway

• Object: The Fantom Foundation Bridge repository at commit 558465d, covering Go relay and voter components and Solidity contracts including Bridge, TokenDeposit, TokenPairs, StateOracle, UpdateManager, ValidatorsRegistry, and MPTProofVerifier.
• Results: 25 total findings: 0 critical, 1 high, 3 medium, 8 low, 13 informational.
• Actions: The high-severity finding was resolved. One medium-severity finding was resolved. Remaining items were addressed or documented per their individual status.

Certora | November 2024 — Sonic Gateway (Security Assessment and Formal Verification)

• Object: Sonic Bridge project Solidity contracts at the referenced commit and fix commit, examined through the Certora Prover for formal verification and manual code review. Verification properties covered bridge solvency, prevention of duplicate claims or withdrawals, resistance to front-running of claims or deposits, and uniqueness of token pairs.
• Results: 13 total findings: 0 critical, 0 high, 5 medium, 4 low, 4 informational. Seven findings were fixed in total.
• Actions: Four of five medium-severity findings were fixed. Three of four informational findings were fixed. Low-severity findings were not fixed.

Quantstamp | 2024 — Sonic Gateway

• Object: All Solidity files in the Gateway contracts directory. Methodology included specification review, manual source code review, comparison to specification, symbolic execution, automated analysis with Slither, test suite review, and best practices review.
• Results: Findings included a high-severity issue and a medium-severity finding (SONIC-9) concerning potential stuck funds where no exit administrator had been assigned. Quantstamp additionally documented an emergency failsafe behaviour: if the bridge is not updated for more than 5 consecutive days, the validator quorum requirement begins declining from 66.67%, falling to 55% over 2 days, remaining there until day 182, then declining further to 25% between days 182 and 189, and remaining at 25% until day 200, after which the bridge enters an inoperable state. Quantstamp also noted that trust in the Sonic Bridge team is required for token unregistration and for funds moving through the bridge.
• Actions: The high-severity finding was fixed. SONIC-9 was subsequently addressed. All tests confirmed passing after fix review. Fix review recorded more robust management for situations where participating validators fall below the quorum required for state oracle updates.

OpenZeppelin | December 2024 — FTM-to-S Bridge (Sonic Opera Native Token Bridge)

• Object: The Opera Bridge repository at commit 730e10b3, covering the OperaBridge contract, error definitions, and deployment modules. The OperaBridge contract manages two-way bridging of native tokens between the Fantom Opera and Sonic networks exclusively.
• Results: 14 total findings, all resolved: 0 critical, 0 high, 2 medium, 3 low, 9 informational.
• Actions: All findings were resolved through pull requests, covering withdrawal handling, total withdrawal sum verification, fee change handling, documentation, variable naming, gas efficiency, removal of unused error definitions, and addition of event emissions for state changes. OpenZeppelin additionally recommended adopting a pull pattern for base token transfers rather than the push pattern in use, reducing reliance on the validator role for deposit accounting, and improving transparency and decentralisation over time. These architectural observations remain relevant to the trust assumptions of the bridge design.

Quantstamp | 2024 — Special Fee Contract

• Object: The Special Fee Contract managing validator registration, delegation, undelegation, withdrawal, and reward distribution on Sonic.
• Results: The detailed findings, severity breakdown, and remediation status from the Quantstamp Special Fee Contract review are not available in fully readable form through the current Quantstamp certificate portal linked in the official Sonic audit index.
• Actions: Not determinable from available public sources.

Market volatility and liquidity

S may experience material price fluctuations and liquidity may vary across venues, pairs and market conditions. Thin order-book depth, rapid order flow, or large trades can widen spreads and increase slippage for purchasers or holders seeking to acquire or dispose of S.

Irreversibility of transactions

Sonic transactions are final once accepted by the network and cannot be reversed at protocol level. Mistaken transfers, incorrect addresses, malicious approvals or loss of wallet access can result in permanent loss of control over S.

Key custody and operational security

Control over S depends on secure handling of wallet credentials, private keys and signing devices. Sonic Labs does not provide custodial services, and compromise or loss of credentials can lead to unauthorised transfers or unrecoverable loss.

Distribution and vesting event risk

S supply and market conditions can be affected by active distribution mechanisms, including airdrop vesting positions maturing over a 270-day schedule, the ongoing funding program issuing up to 47,625,000 S annually for 6 years, and the institutional expansion issuance approved through the September 2025 governance vote. Early-claim burn penalties and the structure of vested ERC-1155 positions can create secondary-market activity and shifts in circulating supply across maturity dates.

Bridge access and execution timing

Sonic Gateway transfers involve bridge steps, heartbeat timing, proof generation and claim operations. Users may experience waiting periods, claim delays, Fast-Lane fee decisions, or loss of recoverability where bridged assets are spent, swapped or not routed through the Sonic Gateway.

Absence of statutory investor protection

S is not covered by EU deposit guarantee or investor compensation schemes. Holders are responsible for assessing suitability, transaction risk and the consequences of acquiring, holding or transferring S. Loss of all invested capital is possible.

Delisting Risks

Bitstamp Europe S.A. might remove the token from trading in line with Bitstamp Markets Trading Rules.

Issuer and organisational dependency

Sonic Operations Ltd. facilitates the issuance of S and supports development of the Sonic blockchain. Disruption to Sonic Operations Ltd.'s development, development, compliance, ecosystem-growth or operational functions could affect delivery, disclosure quality, treasury coordination and network-support activities.

Treasury and funding resilience

Sonic's growth initiatives rely in part on treasury resources, additional S issuance and ecosystem funding programs. Reduced treasury value, inefficient allocation, or weak demand for funded initiatives could constrain development, partnerships, infrastructure acquisition and ecosystem support.

Governance and tokenomics change risk

Governance processes have approved changes affecting issuance, validator rewards, burns, fee allocation and migration arrangements. Future governance outcomes can alter economic parameters and tokenomics, affecting holders' expectations regarding supply, rewards and fee distribution. The September 2025 governance vote, approved with 99.99% support, materially updated the fee mechanism, institutional issuance and burn rules.

Privileged bridge and operational control risk

Bridge contracts and operational arrangements contain privileged roles, multisig processes, validator roles and administrator-controlled settings operated by or connected to Sonic Labs. The REGISTER_ROLE in the Gateway TokenPairs contract can unregister supported tokens; the Quantstamp Gateway audit found that trust in the Sonic Bridge team is required for funds in transit and for token unregistration decisions. Misuse or compromise of these roles could affect bridge parameters, token support or reserve handling.

Regulatory, jurisdictional and access restriction risk

Sonic-related entities and site access operate across multiple jurisdictions and may be affected by sanctions, age restrictions, licensing, regulatory treatment and access limitations. Changes in law or compliance posture may affect website access, program participation, disclosures, exchange access or operational processes.

Conflicts of interest

Sonic Operations Ltd facilitates S issuance and supports network development, ecosystem growth and compliance. This overlap can create actual or perceived conflicts between token promotion, treasury allocation, infrastructure decisions, governance positioning and holder interests.

Environmental representation risk

The Sonic environmental impact assessment published by the issuer is based on estimates derived from validator hardware, hosting provider and energy mix assumptions that are not centrally observable or verifiable by the issuer. The decentralised composition of the validator set means the issuer cannot independently confirm that the published figures reflect actual consumption. Published estimates may therefore differ materially from actual environmental impact, creating disclosure accuracy risk for the issuer under applicable sustainability reporting obligations.

Data handling and privacy risk

Sonic collects contact, device, usage and location data through its website and related services, and may share data with vendors, affiliates, business partners and service providers. International transfers and third-party processing can expose users to privacy, data-security and cross-border compliance risk.

Utility and demand dependency

S is used for transaction fees, staking, validator operation and governance, and its long-term demand depends on usage of the Sonic network and applications. Lower developer activity, user adoption, fee generation or staking participation may weaken demand for S.

Supply mechanics and emissions

S supply changes through airdrop issuance, institutional expansion issuance, ongoing funding issuance, validator rewards and burns. The September 2025 governance vote introduced permanent burns of 5% of FeeM transaction fees and 50% of non-FeeM transaction fees, creating ongoing protocol-level deflationary pressure alongside new issuance. These mechanisms can alter circulating supply, perceived scarcity and market expectations.

Airdrop vesting and burn mechanics

Airdrop allocations include immediately claimable tokens (25% on the first day), vested ERC-1155 NFT positions (75% over 270 days), early-claim burn penalties scaling with time remaining, and a deadline after which a permissionless burn process applies. These mechanics create timing incentives, secondary markets for vested positions and potential supply shifts around maturity or claim deadlines.

Staking and delegation risk

S holders can stake to validators, but validator misconduct, double-signing, downtime or setup errors can affect delegated stake or rewards. A MisbehaviourProofGas mechanism is defined at the network parameter level, confirming that misbehaviour proofs are processable on-chain. Delegators rely on validator performance and must account for withdrawal periods and validator-selection risk.

Large-holder concentration

The largest SonicScan-listed balances include the Special Fee Contract, exchange hot wallets, the null address, wrapped-token contracts and bridge-related accounts. Concentrated holdings can affect liquidity, staking distribution, exchange flows and market execution conditions.

Rights and claim limitations

S does not represent ownership, equity, debt, revenue-sharing, dividend rights, or a claim on Sonic Labs' assets, profits or revenues. Holding or using S does not create a debtor-creditor relationship with Sonic Labs or its affiliates.

Legacy network transition residual risk

FTM-to-S migration is substantially complete, with the conversion contract now operating on a one-way, indefinite basis. Residual risks include app tokens not yet migrated on Fantom Opera, exchange coordination for remaining FTM balances, and user-error risk in one-way conversion operations. The Sonic Foundation continues to maintain Opera validators on an ongoing basis.

Ecosystem incentive dependency

Sonic's growth strategy relies on incentives including Fee Monetization, Sonic Points, Sonic Gems, airdrop reserves and the Innovator Fund, which holds up to 200,000,000 S from the Sonic Foundation treasury. If those programs underperform, are misallocated, are revoked, or fail to retain users and developers, network activity and demand for S may be weaker than intended. Gems may be revoked for suspicious distribution, misrepresentation, or failure to maintain required integrations.

Development and release risk

Sonic depends on ongoing client, contract, database and consensus development. Releases and upgrades can introduce regressions, RPC inconsistencies, state-handling issues or integration problems requiring later remediation. Version history records that prior releases addressed VM, archive, gas and dependency issues across successive upgrades.

Validator operations and resource dependency

Validator operation requires a minimum self-stake of 500,000 S, at least 4 vCPUs, 32 GB RAM, 1 TB local NVMe storage and 1 Gbps redundant connectivity. Misconfiguration, resource exhaustion, hardware failure, double-signing or extended downtime can reduce rewards, suspend validators or trigger slashing through the on-chain misbehaviour proof mechanism.

Third-party infrastructure dependency

Sonic uses or integrates with external wallets, exchanges, infrastructure providers, data providers, RPC services, explorers, analytics providers and bridge tooling. Outages, policy changes, inaccurate data, or service degradation by these providers can affect user access, incentive accounting, liquidity, application operation and state visibility.

Treasury and operational movement risk

Post-migration operational changes include multisig refinement, wallet rotations, treasury movements, exchange coordination, bridge accounts and burn transactions. Large on-chain movements can be misinterpreted by the market or create temporary uncertainty even where they do not change user balances, circulating supply or token ownership.

Consensus and network-layer risk

Sonic uses a proof-of-stake, DAG-based, asynchronous Byzantine fault-tolerant consensus design. Validator collusion, network disruption, misconfiguration, signing-key misuse, or validator concentration can affect transaction inclusion, reward distribution, liveness or network confidence.

Operational continuity and status risk

Validator nodes and public RPC endpoints are operated by independent third parties. The official status monitor records validators at 100.00% uptime while RPC services ran at 94.81% uptime over the monitored period, demonstrating that endpoint availability can differ from consensus availability. RPC degradation affects user access to balances, transactions and application state without affecting the validity of finalised chain state, but can impair user decisions and application operation in real time.

Node, database and recovery risk

Sonic nodes rely on local state databases, correct genesis processing, adequate storage, clean shutdowns and resource configuration. Database corruption after an incomplete persistent-storage update, an interrupted genesis import, high RPC load, insufficient storage or forced shutdowns can prevent node startup or require recovery actions.

Smart-contract and protocol logic defects

Sonic infrastructure includes bridge contracts, staking contracts, Fee Monetization contracts and other on-chain components. Defects in access control, state verification, accounting, token-pair registration or proof handling can cause reverts, frozen funds, denial of service, incorrect reward allocation or loss of funds. Independent audits identified an account-abstraction address mismatch in the Gateway that could have caused permanent fund loss, and a stuck-funds scenario where no exit administrator was assigned.

Bridge and interoperability risk

The Quantstamp Gateway audit documented that validator quorum requirements begin declining after five consecutive days without a bridge update, falling progressively from 66.67%, with the bridge entering an inoperable state after 200 days. A separate user-level fail-safe activates after 14 consecutive days of failed heartbeats, enabling recovery of eligible Gateway-routed assets on Ethereum.

Oracle and off-chain data dependency

Fee Monetization relies on off-chain oracle servers to monitor transactions, attribute gas usage and confirm rewards through quorum. Under the September 2025 governance-approved fee mechanism, FeeM transaction fees are split 90% to registered developers, 5% to validators and 5% burned, while non-FeeM transaction fees are split 50% burned and 50% to validators. Oracle failure or misattribution would affect the accuracy of this distribution. Airdrop and points infrastructure also relies on data providers including OpenBlock and Sentio for modelling, state retrieval and point tracking.

Upgradeable contracts and administrator settings

Sonic-side Gateway infrastructure includes proxy and implementation addresses. Audits identified administrator-controlled bridge settings, the REGISTER_ROLE for token-pair management and storage-layout assumptions in DirectExitAdministrator. Incorrect upgrades, storage-layout conflicts, parameter changes, or role compromise could affect bridge behaviour and token support.

RPC, explorer and indexer visibility risk

Users and applications rely on RPC endpoints, SonicScan, archive nodes and indexing services to observe balances, transactions, gas, blocks, validators and contract data. RPC outages, archive limitations, explorer parsing issues or delayed status updates can impair user decisions even where final chain state remains valid.

Account abstraction and wallet-integration risk

Sonic supports ERC-4337 account abstraction from release 2.1, including smart wallets, UserOperations, bundlers, paymasters and an EntryPoint contract. Incorrect wallet integration, address mismatch, paymaster failure, broad approvals or unsupported signing flows can expose users to failed transactions, unexpected permissions or loss of funds.

Gas, execution and congestion risk

Sonic transactions require S-denominated gas. The network base fee has a configured minimum of 50 Gwei (50,000,000,000 wei as confirmed by network parameters), with eth_gasPrice and eth_feeHistory returning values with a 10% buffer. High utilisation, pending queues, RPC load or gas-pricing changes can delay execution, increase costs or cause transactions to fail or revert.

Quantum computing and cryptographic vulnerability risk

Sonic uses secp256k1 elliptic-curve cryptography for externally owned account signing, consistent with full EVM compatibility. The secp256k1 curve is vulnerable to Shor's algorithm: a sufficiently capable fault-tolerant quantum computer could derive a private key from a known public key, enabling unauthorised transaction signing. Public keys are exposed upon first transaction broadcast, meaning accounts that have signed at least one transaction carry greater exposure than unused accounts. Validator signing keys face equivalent exposure. No post-quantum cryptographic migration pathway has been formally announced for the Sonic protocol as of May 2026. Large-scale fault-tolerant quantum computers capable of executing this attack do not currently exist, but the timeline for their development is uncertain and cannot be predicted with confidence.

Offer-Related Risks

• Market volatility and liquidity: Defined tokenomic rules; including annual issuance caps, mandatory year-end burns of unused growth allocations, graduated airdrop burn penalties, and the on-chain fee burn mechanism (5% of FeeM fees and 50% of non-FeeM fees permanently destroyed); provide transparent, governance-bound constraints on supply expansion. Top account balances and total supply are publicly verifiable via SonicScan in real time.
• Irreversibility of transactions: The single-block, no-rollback ABFT finality model eliminates post-inclusion reversal windows and chain reorganisation risk at the protocol level. Sonic Labs holds no user private keys or custodial balances. Credential security rests entirely with the holder.
• Key custody and operational security: A range of non-custodial hardware and software wallets with official Sonic network configuration is supported. Sonic Labs holds no user credentials and provides no custodial service. Private key management and wallet access control are the holder's sole responsibility.
• Bridge access and execution timing: The Sonic Gateway implements heartbeat batching (approximately ten minutes inbound, 1 hour outbound), Merkle-proof-based claim verification, an optional Fast-Lane payment to trigger an immediate heartbeat, and an immutable 14-day fail-safe that activates after consecutive heartbeat failure, enabling recovery of eligible Gateway-routed assets on Ethereum.

Issuer-Related Risks

• Treasury and funding resilience: The ongoing funding program incorporates a mandatory year-end burn of all issued growth tokens not deployed during the year, eliminating passive treasury accumulation from this allocation. On-chain issuance and burn transactions are publicly traceable via SonicScan.
• Governance and tokenomics change risk: All governance votes affecting tokenomics, including fee allocation, issuance and burn rules, are conducted on-chain through Snapshot and are publicly verifiable with timestamped outcomes. Burn events are recorded in real time on the S Burn Tracker at https://burn.soniclabs.com.
• Privileged bridge and operational control risk: The Sonic Gateway, Opera bridge and Special Fee Contract have been reviewed by OpenZeppelin, Quantstamp and Certora. Reported findings, severity levels, remediation status and residual trust assumptions; including the REGISTER_ROLE token unregistration authority and the trust dependency on the Sonic Bridge team for funds in transit; are disclosed in published audit reports. No critical findings were left unresolved across reviewed scopes.
• Regulatory, jurisdictional and access restriction risk: Sanctions screening representations, an 18-plus age eligibility requirement and explicit jurisdiction-based access restrictions are enforced at the website and program layer. The issuer retains the right to deny, suspend or terminate access.
• Data handling and privacy risk: Standard contractual clauses are applied to international data transfers. Defined retention limits, user rights mechanisms and explicit data category disclosures are established in the privacy policy and enforceable under applicable data protection law.

Crypto-Assets-Related Risks

• Supply mechanics and emissions: Total supply parameters, scheduled issuance caps, burn conditions and the governance-approved fee burn mechanism are defined by on-chain rules. All burn transactions are publicly recorded on the S Burn Tracker and SonicScan, providing verifiable supply transparency.
• Airdrop vesting and burn mechanics: Airdrop allocations use staged vesting (25% immediately liquid; 75% as ERC-1155 NFT positions over 270 days), graduated early-claim burn penalties and a defined claim deadline after which a permissionless burn process applies. These mechanics are on-chain, transparent and disclosed in advance.
• Staking and delegation risk: The proof-of-stake model requires a minimum validator self-stake of 500,000 S. Double-signing and malicious behaviour are subject to on-chain misbehaviour proof processing with defined MisbehaviourProofGas, resulting in loss of locked stake. Official node operation guidance covers monitoring, graceful shutdown, signing-key security and recovery procedures.
• Large-holder concentration: Top account balances, their percentage of total supply and transaction history are publicly observable via SonicScan at https://sonicscan.org/accounts, providing on-chain transparency into structural concentration.

Project Implementation-Related Risks

• Legacy network transition residual risk: The FTM-to-S conversion contract, official migration timeline, validator migration steps and a MySonic interface function are available for the ongoing one-way conversion process. Migration documentation covers exchange coordination, app-token migration options and validator transition steps.
• Ecosystem incentive dependency: The Gems revocation policy requires mandatory disclosure of the percentage of claimed S distributed to users, and revocation applies for suspicious distribution practices, misrepresentation or failure to maintain required integrations. OpenBlock and Sentio provide independent data support for incentive attribution and tracking.
• Development and release risk: All primary client repositories are open-source under the 0xsoniclabs GitHub organisation. Upgrade procedures require version checks, source integrity verification via official tagged releases, state validation and graceful restart, reducing regression risk from informal update processes.
• Validator operations and resource dependency: Published hardware and network specifications (minimum 4 vCPUs, 32 GB RAM, 1 TB local NVMe, 1 Gbps connectivity) and node recovery guidance covering database corruption, resource exhaustion, GOMEMLIMIT configuration, hardware failure and graceful shutdown procedures are provided for validator operators.
• Third-party infrastructure dependency: An official wallet configuration list, real-time status monitoring covering validators and RPC endpoints, and node recovery guidance; including middleware and load-balanced RPC backend recommendations for handling public traffic; are published. These reduce single-point dependency but do not govern third-party service decisions.

Technology-Related Risks

• Consensus and network-layer risk: The ABFT DAG-based consensus requires validators to lock S as self-stake and face on-chain misbehaviour proof processing with stake loss for malicious behaviour. The asynchronous model maintains liveness without synchrony assumptions and achieves single-block, no-rollback finality.
• Operational continuity and status risk: A public status monitor at https://uptime.soniclabs.com provides real-time tracking of validator and RPC endpoint health derived from on-chain block data and live endpoint checks. Archive node deployment and middleware-based RPC load balancing are documented as resilience measures.
• Node, database and recovery risk: Node recovery procedures, address database corruption, resource exhaustion, hardware failure, GOMEMLIMIT misconfiguration, cache sizing, graceful shutdown requirements and redundant storage recommendations, covering the identified failure modes and supporting restoration after known failure types.
• Smart-contract and protocol logic defects: Independent security assessments of the Sonic Gateway (OpenZeppelin, Quantstamp, Certora), the Opera bridge (OpenZeppelin) and the Special Fee Contract (Quantstamp) have been completed, with reported issue counts, severity distributions and remediation status publicly disclosed. The account-abstraction address mismatch and stuck-funds findings were resolved prior to publication of their respective audit reports.
• Bridge and interoperability risk: The Sonic Gateway uses Merkle-proof claim verification, StateOracle-based state updates, heartbeat batching, an optional Fast-Lane mechanism and an immutable 14-day fail-safe for eligible bridged assets. Certora's formal verification confirmed bridge solvency and duplicate-claim prevention properties. Quantstamp's fix review confirmed more robust management of validator quorum decline scenarios.
• Oracle and off-chain data dependency: FeeM rewards are released only upon on-chain confirmation by a quorum of independent oracle servers. Gas attribution is traced at the virtual machine level, including internal sub-calls, preventing double-counting across registered contracts. The September 2025 governance-approved fee mechanism; applied on-chain with defined burn and distribution rules; reduces discretionary off-chain attribution decisions for the fee-split calculation.
• Upgradeable contracts and administrator settings: Gateway proxy and implementation contract addresses are published in official developer documentation. Audit reports from Quantstamp and OpenZeppelin identifying privileged roles, storage-layout assumptions and administrator-sensitive settings are publicly available, providing verifiable disclosure of residual trust assumptions.
• RPC, explorer and indexer visibility risk: SonicScan provides public access to transaction, block, validator, contract and token data. Archive node documentation covers deployment for full historical state access. The public status monitor provides real-time RPC health tracking.
• Account abstraction and wallet-integration risk: ERC-4337 account abstraction is supported from release 2.1 with documented smart wallet, UserOperation, bundler, EntryPoint and paymaster flows. The OpenZeppelin Gateway audit identified and resolved an account-abstraction address mismatch that could have caused permanent fund loss for affected accounts.
• Gas, execution and congestion risk: The SonicScan gas tracker at https://sonicscan.org/gastracker provides current base fee, confirmation timing, pending queue depth and network utilisation data. Gas pricing documentation specifies the 10% RPC buffer included in eth_gasPrice and eth_feeHistory responses and the recommended fee calculation approach for Type 1 and Type 2 transactions.

Bitstamp Europe S.A.

549300XIBGTJ0PLIEO72

S

Sonic uses a leader-based, asynchronous Byzantine fault-tolerant (ABFT) consensus mechanism derived from the Lachesis protocol, combined with directed acyclic graphs. Byzantine fault tolerance ensures the network continues to reach agreement even when some participants behave incorrectly or maliciously. The asynchronous property means consensus does not depend on all validators receiving messages simultaneously. In the DAG structure, each event produced by a validator references one or more earlier events without forming cycles, enabling concurrent transaction ordering across validators before block output. Unlike classical BFT systems that require sequential majority agreement for each block, this design avoids sequential dependency and achieves sub-second, single-block finality with no rollback risk.

Sybil resistance is achieved through proof of stake. Validators must lock at least 500,000 S to participate. A validator that acts maliciously loses their locked tokens, providing a direct economic disincentive for incorrect behaviour. Delegators may assign S to validators through the SFC to participate in staking economics without running a node; delegated stake is equally exposed to any penalty applied to the chosen validator. Consensus weight is proportional to staked amounts.

See H.5

2026-01-01

2026-05-19

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at : www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Land use: 796.41387 m²

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5).
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Estimates on individual node weight, hazardous components and depreciation rate are used.
Full methodology available at: www.micacryptoalliance.com/methodologies

Data provided by the MiCA Crypto Alliance as a third party, with no deviations from the calculation guidance of Commission Delegated Regulation (EU) 2025/422, Article 6(5). Usage of natural resources is approximated through land use metrics. Land use, water use and water recycling are calculated based on energy mix-specific estimates of purchased electricity land intensity, purchased electricity water intensity, and water recycling rates. Full methodology available at: www.micacryptoalliance.com/methodologies