Sonic is the highest-performing EVM L1, combining speed, incentives, and world-class infrastructure for DeFi. The chain provides 400,000 TPS and sub-second finality.

Developers and users on Sonic are supported by several incentive programs, including:

Sonic delivers exceptional performance, enabling developers to scale their applications without limits while ensuring smooth user experiences.

• 400,000 Transactions per Second

• Sub-Second Finality

• EVM Compatible

• Solidity/Vyper Support

The of Sonic is S, which is used for transaction fees, staking, running validators, and participating in governance.

Furthermore, the provides developers and users with seamless access to vast liquidity through a secure bridge connected to Ethereum. With a unique fail-safe mechanism, it ensures user assets are protected in all circumstances.

Sonic is the highest-performing EVM layer-1 blockchain, combining speed, incentives, and world-class infrastructure, powering the next generation of DeFi applications. The chain provides 400,000 TPS and sub-second finality.

By combining a novel consensus mechanism with full EVM compatibility, Sonic delivers unparalleled speed, security, and scalability. The is Sonic's native token, used for paying transaction fees, staking, running validators, and participating in governance.

Key Features:

• Sub-Second Finality Transactions are confirmed and irreversible in under a second.

• Full EVM Compatibility Deploy your existing Ethereum app on Sonic without changing your code.

The S token is the native token of Sonic. It has multiple roles within the network, such as paying for transaction fees, staking, running validators, and participating in governance.

— Staking — Supply and Tokenomics ‎‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎— Institutional Expansion ‎‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎— Airdrop ‎‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎— Ongoing Funding ‎‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎— Block Rewards ‎‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎— Token Burn — Validator Rewards — Ecosystem Vault

Staking

You can help secure the network and earn rewards by staking your S tokens.

1. Visit .

2. Connect your wallet.

3. Choose a reputable validator and delegate your stake.

Staking your S involves a 14-day waiting period if you choose to withdraw. When staking your S, choose a reputable validator carefully. If your validator is penalized for misconduct or errors in their setup, it could impact your delegated S stake as well.

Supply and Tokenomics

The current total supply of S is approximately 3.8 billion. As decided by multiple governance proposals, the following adjustments have been or will gradually be integrated into the tokenomics of S.

Institutional Expansion

A approved the issuance of $50M in S for the pursuit of an ETF, $100M in S for the pursuit of a Nasdaq DAT, and 150M S tokens for the newly established Sonic USA entity, as part of our institutional expansion into the U.S. capital markets.

The first issuance of 472,372,662.8 S . This covered the full allocation for our Nasdaq DAT and Sonic USA entity. An additional $50 million in S may also be issued to support our pursuit of an S ETF.

The following transactions provide transparency into how the issued funds have been used to date, mainly involving .

• to old SonicStrategy DAT Multisig

• to new SonicStrategy DAT Multisig for validator setup

• to new SonicStrategy DAT Multisig from the old SonicStrategy DAT Multisig

Importantly, if a Nasdaq DAT is not achieved during SonicStrategy’s pursuit, all funds will be returned to the Sonic Foundation to be leveraged for an alternative DAT or burned.

Airdrop

190.5 million S will be issued in phases exclusively used for the . The airdrop features an that rewards active participation and gradually reduces the total supply of S tokens.

The first issuance of 89,778,181.9 S occurred on and .

Ongoing Funding

To fund ongoing growth and expansion, the Sonic network could to:

• Increase S adoption and global presence

• Grow the team and scale operations to drive increased adoption

• Implement robust marketing initiatives and DeFi onboarding campaigns

To fund this program, 47,625,000 tokens will be issued annually for six years, starting six months after Sonic's mainnet launch. Issued tokens will be sent to . The first issuance of 47,625,000 S .

However, to guard against inflation, the network will burn newly issued tokens not used during the year, ensuring that 100% of all newly issued tokens from this initiative are allocated toward network growth rather than being held by the treasury for later use.

For example, if Sonic Labs uses only 5,000,000 tokens in the first year, the network will burn the remaining 42,625,000 tokens.

Block Rewards

were migrated Fantom Opera to Sonic. As validators and stakers moved to Sonic, Opera's block rewards were reduced to zero, and the saved funds are used to reward Sonic validators. The Sonic Foundation will maintain Opera validators for now.

To achieve a 3.5% APR for Sonic without causing further inflation in the first four years, we're reallocating the remaining block rewards from Opera to Sonic, comprising around 70 million tokens per year, which will be distributed as validator rewards over the first four years, avoiding the need to issue new S tokens during this period for block rewards.

As a result, Opera's APR dropped to zero upon Sonic's launch. To preserve value and avoid new inflationary rewards at Sonic's inception, we will not issue new tokens for block rewards during the initial four years, as stated. After that period, S block rewards will resume by issuing new tokens at a rate of 1.75% per year to reward validators.

Token Burn

We have two burn mechanisms in place that will decrease the emission of new S tokens.

Validator Rewards

To help secure the Sonic network by running a validator and staking a certain amount of S, you can earn block rewards as well as transaction fees paid by users on Sonic.

Block Rewards

The target reward rate for validators on Sonic is 3.5% when 50% of the network is staked. The network issues tokens each epoch to provide this, except during Sonic's first four years when rewards stem from block rewards migrated from Opera, .

The reward rate adjusts proportionally, e.g. if all S tokens are staked, the annual reward is 1.75%. Conversely, if only 25% of S tokens are staked, the annual reward is 7%.

Network Fees

Network fees are generated when users pay gas to interact with the network. Validators earn a percentage of these fees, which are distributed equally among all staked S tokens. For a detailed breakdown of how much a validator earns from gas fees, .

Sonic offers developers robust infrastructure with 400,000 transactions per second and sub-second finality, ensuring your apps are both fast and scalable.

With full EVM compatibility and support for Solidity and Vyper, Sonic seamlessly integrates with common developer tools such as Chainlink, Safe, Pyth, Alchemy, and more. Additionally, Sonic provides the incentives, such as Fee Monetization, necessary to innovate and thrive in the ecosystem.

Test your contracts on the Sonic testnet first, then deploy to the mainnet when ready. Dive in and explore how you can leverage Sonic's powerful features to bring your ideas to life.

The Sonic chain is secured using a proof-of-stake (PoS) mechanism.

In PoS on Sonic, validators must lock their S (Sonic's native token); if they act maliciously in the network, they lose their tokens. Validators are incentivized to act in the network's best interest as their own funds are at stake. Since validators do not need to perform computations, this approach is a much more energy-efficient alternative to proof-of-work for achieving resistance to Sybil attacks.

A Sybil attack is an attack where a malicious actor runs a large number of validators to allow them an unsafe amount of influence over the network. PoS makes it costly to set up these validators and allows the network to punish validators for malicious behavior, increasing the costs of attacks.

Sonic requires nodes to lock up at least 500,000 S to validate transactions and produce blocks.

The Sonic chain provides developers with exceptional scalability and storage capabilities while delivering a fast and seamless user experience.

Sonic achieves 10,000 transactions per second with sub-second finality for immediate, irreversible transactions. There is zero risk of rollbacks or reorganizations, making every transaction final and tamper-proof. Sonic's cutting-edge storage system ensures efficient data management.

Learn more about the Sonic technology stack:

• Consensus

• Database Storage

If a contract is already registered under a different app in Fee Monetization, your registration attempt will fail with ContractAlreadyRegistered(contract, projectID).

If you believe the contract rightfully belongs to you, file a dispute using the steps below.

1. Visit the Fee Monetization dashboard and connect your admin wallet

2. Click My FeeM in the menu and then Create Dispute

3. Enter your dispute contact email address and the contracts you wish to dispute

4. Click Submit and pay the 50 S fee, which will be refunded if the dispute is accepted

Once submitted, we will process your dispute as quickly as possible and notify you via email. If resolved in your favor, the dispute fee is refunded and the disputed contracts are moved to your app.

Claims for the airdrop's first season are now live. Users earned S through Sonic Points and Sonic Gems.

Earned directly by users holding and using whitelisted assets across apps on Sonic.

Earned by apps that drove user activity, based on their performance across key metrics.

Sonic Points

Nodes are interconnected devices, usually software run on servers, that maintain the Sonic network by storing a full or partial copy of the chain, validating transactions, and ensuring consensus to keep the system secure and decentralized.

Visit the pages below to learn how to deploy archive and validator nodes on Sonic.

At the software level, deploying to Sonic is the same as deploying to any other EVM network.

The only difference is which network you connect to. Use as the connection endpoint for the Sonic testnet or for the mainnet.

For the Sonic testnet, you can use the to obtain an initial amount of S to execute transactions on the testnet.

Here are example configurations for Hardhat to deploy on the Sonic mainnet or testnet:

To deploy, execute npx hardhat run scripts/deploy.js --network sonic.

Objective

Fee subsidies enable users to interact with an app without paying gas fees themselves. Users do not need to hold any native tokens to execute transactions with the app’s contracts. Instead, gas costs are covered by a third party, typically the app’s developers.

Solution

Sonic offers developers two distinct networks to build and deploy their apps. First, the serves as a dedicated environment where you can rigorously test your smart contract code and deployments, ensuring everything functions correctly using faucet tokens.

Once your contracts are thoroughly vetted on the testnet, you can confidently deploy your live apps to the Sonic mainnet, the production environment where end users will interact with your apps.

The following are the network details:

Objective

Alternative fee payments enable users to interact with an app without holding the network’s primary token (S) to cover gas fees. Instead, gas costs are paid using an alternative method, such as ERC-20 tokens (e.g. stablecoins) or even off-chain settlement. This removes the requirement for users to maintain a balance of the native token.

Sonic uses database storage to store its world state, which includes account information, virtual machine bytecode, smart contract storage, etc. This database has a feature called live pruning, which removes historical data automatically, reducing storage needs for validators as the blockchain grows.

Previously, pruning required validator nodes to go offline, risking financial and operational issues for them. Now, validators can use live pruning without going offline, ensuring continuous operation and saving on disk space and costs by discarding historical data in real-time.

Live pruning works by splitting the database into two types: LiveDB and ArchiveDB. The LiveDB contains the world state of the current block only, whereas the ArchiveDB contains the world states of all historical blocks. Validators use only LiveDB, while have both LiveDB and ArchiveDB to handle historical data requests through the RPC interface.

Sonic's database storage uses efficient tree-like or hierarchical structures, which simplifies data retrieval. Importantly, it still provides cryptographic signatures for a world state and archive capabilities using an incremental version of a prefix algorithm. Additionally, it utilizes a native disk format instead of storing the world state indirectly through key-value stores like LevelDB or PebbleDB.

You can build apps on top of Sonic's staking system, such as liquid staking tokens or vaults. All staking operations are managed by the SFC (Special Fee Contract).

• SFC Address: 0xFC00FACE00000000000000000000000000000000

• Key Functions:

Sonic is fully compatible with the Ethereum Virtual Machine (EVM). Any smart contract that runs on Ethereum can be deployed on Sonic without modification.

• Supported Languages Solidity and Vyper

• Supported EIPs Sonic supports Ethereum's Cancun hard fork features, including PUSH0 opcode (EIP-3855), with the exception of EIP-4844 data blobs. All transactions must have a Chain ID (EIP-155 is enforced).

With the Ethereum Pectra upgrade supported in Sonic release 2.1, the network gains full compatibility with ERC-4337, a transformative framework originally introduced on Ethereum.

ERC-4337 replaces traditional externally owned accounts (EOAs) with smart contract wallets that have programmable authorization logic. This enables advanced features such as:

• Social Recovery Restore access with help from trusted guardians.

• Multi-Signature Security Require multiple approvals before executing transactions.

• Spending Limits Enforce daily/weekly caps on outgoing funds.

• Token-Based Gas Payments Pay fees in ERC-20 tokens instead of the native token.

Unlike protocol-level changes, ERC-4337 operates entirely on top of the blockchain. No network hard fork is required, making it immediately compatible with Sonic post-Pectra. It works through a specialized flow involving UserOperations, an alternative mempool, bundlers, and optional paymasters for gas fee handling.

This upgrade fundamentally improves the Sonic user experience, unlocking customizable, secure, and user-friendly wallets without sacrificing decentralization or performance.

Core Concepts

Smart Wallet An ERC-4337 smart wallet extends the functionality of a standard EOA by delegating control to a smart contract. This enables transaction batching, gas sponsorship, and custom permission logic while still functioning like a traditional wallet.

EntryPoint The EntryPoint contract is the core of ERC-4337. It validates signatures, nonces, and logical rules defined by each wallet. It can also enforce custom conditions such as balance checks, restricted contract calls, or app-specific rules.

UserOperation A UserOperation is a generalized transaction format for ERC-4337. It contains standard fields like sender, recipient, calldata, maxFeePerGas, maxPriorityFeePerGas, signature, and nonce, along with additional fields such as callGasLimit, verificationGasLimit, and paymasterAndData to support advanced execution logic.

Bundler A bundler collects UserOperations from the alternative mempool, simulates them for validity, and packages them into a single transaction sent to the EntryPoint. Bundlers may also forward standard transactions to a full node for normal blockchain processing.

Paymaster A paymaster is a smart contract that sponsors gas fees on behalf of users, allowing them to transact without holding the network’s native token. During validation, the paymaster checks if the operation qualifies for sponsorship and covers the gas cost. To prevent abuse, paymasters stake collateral with the EntryPoint and must maintain a sufficient deposit.

Related Topics

• Customize transaction authorization logic with smart contract wallets.

• Let users interact with an app without paying gas themselves.

• Monetize app usage via increased gas consumption.

• Accept ERC-20 tokens or off-chain settlement for gas fees.

Sonic Labs has partnered with HackQuest to offer a learning track for anyone who is eager to learn Solidity on Sonic, whether they are a beginner or advanced. Start learning now.

Upon completing the course outlined below, graduates will receive a Sonic Developer Certificate.

Objective

Account abstraction enables users to customize how transactions from their account are authorized. This flexibility supports alternative signing methods, multi-signature requirements, and account recovery mechanisms. Examples include:

• Alternative Signing Methods Passkey, YubiKey, or TouchID to sign transactions directly in the browser without extensions like MetaMask.

• Multi-Signature Wallets Requiring multiple signatures before a transaction can be executed.

• Social Recovery Allowing a group of trusted contacts to override or replace the account’s controlling key.

Solution

ERC-4337 introduces a framework where user wallets are implemented as smart contracts. This allows the wallet’s transaction authorization logic to be fully customizable. Transactions are sent as UserOperations and processed according to the smart account’s rules.

EIP-7702 extends this flexibility by allowing a regular externally owned account (EOA) with a standard ECDSA private key to deploy a smart contract directly into its account. Once a smart account implementation is deployed, the user can send transactions in two ways:

1. Regular Transactions Signed with their private key.

2. UserOperations Authorized according to the custom logic defined in their smart account.

Example Authorization Logic Options

1. Passkey / YubiKey / TouchID []

   • Signs UserOperations directly in the browser, without extensions like MetaMask.

   • Currently a research project—experimental and not recommended for production.

2. Google OAuth JWT signing []

The FeeM Vault is a multisig operated by Sonic Labs. It accumulates 90% of transaction fees generated by core token contracts on Sonic:

• wS

• USDC

• USDT

• EURC

• WETH

• WBTC

Funds in the FeeM Vault will be strategically deployed to strengthen the Sonic ecosystem, provide targeted support where apps need it most, and enhance asset incentives.

The tokens that generate the revenue for the FeeM Vault will also shape how it is spent. Apps that integrate and optimize for the tokens above will be first in line to benefit.

Key areas of deployment include:

FeeM Vault Flywheel

The FeeM Vault is designed to compound growth across Sonic apps. As activity around key tokens increases, the Vault fills, and a self-reinforcing flywheel begins to spin:

1. More usage of key tokens increases the transaction fees redirected to the FeeM Vault.

2. More revenue in the FeeM Vault means more funding available for apps on Sonic.

3. More funding for apps leads to more integrations and incentives involving key tokens, attracting more users.

4. More users drive more activity and usage of those same tokens.

Check out the most frequently asked questions about Sonic and its S token.

S Token

Sonic Chain

Sonic Gateway

The Sonic Gateway is our native bridge between Ethereum and Sonic.

• OpenZeppelin

FTM to S Bridge

The FTM to S bridge enables users to upgrade their FTM on Fantom Opera to S on Sonic.

Special Fee Contract (SFC)

The SFC manages staking and validator operations on Sonic.

Sonic supports a range of popular wallets, both for users and institutions. Use the network information below to add Sonic to your wallet.

• Network name: Sonic

• RPC URL: https://rpc.soniclabs.com

• Explorer URL: https://sonicscan.org

• Chain ID: 146

• Currency symbol: S

User Wallets

Institutional Wallets

The Sonic Labs Innovator Fund offers up to 200,000,000 S from the Sonic Foundation treasury to expedite the immediate adoption of apps to the Sonic chain and support new innovative ventures.

Allocations

Funding from the Innovator Fund is being used to secure the best infrastructure and applications for Sonic, ensuring builders have the tools and capabilities to thrive within today’s ever-challenging marketplace.

We’re actively engaging with dozens of apps across the industry and top-tier infrastructure providers across on-chain tooling, compliance, native assets, cross-chain technology, wallets, indexes, strategic Web2 partnerships, and more.

To do so, we’ll work closely with strategic angel investors such as (Curve), (Aave), (Compound), (Gauntlet), and (FRAX), as well as our venture partners , , and .

The Sonic & Sodas program empowers our community to host developer-focused networking events around the world, funded by Sonic Labs.

Think of Sonic & Sodas events as grassroots gatherings where collaboration, networking, and innovation thrive, all within the Sonic ecosystem. You host the event, and we provide the funding. Our aim is to cultivate local communities, particularly in tech hubs and around major conferences.

How It Works

The process for organizing a Sonic & Sodas event is detailed below.

The active network parameter set can be obtained directly from an RPC interface:

Game Gems mark the beginning of a new chapter on Sonic, where blockchain games are not just part of the ecosystem, but central to its growth.

Just like DeFi apps earn , eligible games on Sonic earn Game Gems, unlocking a share of the S token airdrop. Similar to the existing Sonic Gems, these allocations are designed to be distributed to players, helping bootstrap in-game activity and drive lasting engagement.

Consensus in a decentralized system is not just a process but a cornerstone of the system. Its mechanism guarantees a consistent and secure blockchain among all participants and ensures the system's integrity and reliability. Consensus ensures that transactions are consistently and securely validated and added to the blockchain.

It's a critical element for effectively thwarting attempts by malicious actors to manipulate the network or its data. Sonic uses Asynchronous Byzantine Fault Tolerance in combination with directed acyclic graphs to achieve consensus.

Practical Byzantine Fault Tolerance

Practical Byzantine Fault Tolerance (PBFT) is a consensus mechanism designed to enable decentralized systems to function correctly in the presence of malicious or faulty nodes. It is named after the Byzantine generals’ problem, which is an idea that illustrates the difficulties of achieving consensus in a decentralized system when some of the participants may be acting in bad faith.

In a PBFT system, nodes in a network communicate with each other to reach a consensus on the system's state, even when malicious actors are involved. To achieve this, they send messages back and forth that contain information about the system's state and the actions they propose.

Each node verifies the message it receives, and if it determines the message is valid, it sends a message to all the other nodes to indicate its agreement. In the context of cryptocurrencies, the message with which all nodes must agree is the blockchain, a ledger that stores a history of transactions.

Before the invention of cryptocurrencies, the major flaw with PBFT systems was their susceptibility to Sybil attacks. If an attacker controlled a sufficient number of nodes, they could control the entire system; there needed to be a deterrent to launch many nodes. Bitcoin first solved this problem with proof-of-work, forcing nodes to invest considerable energy to partake in the consensus.

Since then, many new solutions have been developed, such as , which forces nodes to deposit tokens with monetary value, which Sonic uses.

Hence, Practical Byzantine Fault Tolerance (PBFT) is a mechanism to achieve consensus. It forms a functioning decentralized system when coupled with proof-of-work or proof-of-stake to deter participants from messing with the network. However, Sonic has decided to innovate on this mechanism by using Asynchronous Byzantine Fault Tolerance.

Asynchronous Byzantine Fault Tolerance

With Asynchronous Byzantine Fault Tolerance (ABFT), nodes can reach consensus independently and are not required to exchange final blocks sequentially to confirm transactions. At the same time, they exchange blocks, which is required to achieve consensus, and this is done asynchronously. Each node verifies transactions independently and is not required to incorporate blocks created by other miners or validators in sequential order.

This is opposed to PBFT systems, such as Bitcoin, in which the majority of nodes must agree to a block before it becomes final, which they must then sequentially order into their blockchain record. This slows down the network during high traffic; more on this in the consensus mechanism section further below.

Now that we have a basic understanding of Byzantine fault tolerance, let’s delve into the second part of Sonic’s consensus mechanism, directed acyclic graphs.

Directed Acyclic Graphs

A graph is a non-linear data structure used to represent objects, called vertices, and the connections between them, called edges. A directed graph dictates that all its edges, the connections between objects, only flow in a certain direction. An acyclic graph does not contain any cycles, which makes it impossible to follow a sequence of edges and return to the starting point. As such, a directed acyclic graph (DAG) only flows in a certain direction and never repeats or cycles.

The diagram below is an example of a directed acyclic graph. Each oval is a vertex, and the lines connecting them are edges. The vertices only connect in one direction, downwards, and never repeat.

In our consensus algorithm, an event containing transactions is represented by a vertex in a DAG, and edges represent the relationships between the events. The edges may represent the dependencies between events indicating the order in which they were added to the DAG.

Events can be created and added to the DAG concurrently. The blocks do not need to be added in a specific order, which enables the system to achieve faster transaction times. It is not limited by the requirement to incorporate blocks sequentially, as is the case with many of the biggest blockchains currently available.

Sonic's Consensus Mechanism

Sonic uses a proof-of-stake, DAG-based, ABFT consensus mechanism. In this mechanism, each validator has its own local block DAG and batches incoming transactions into event blocks, which they add to their DAG as vertices — each event block is a vertex in the validator’s DAG that is full of transactions.

Before creating a new event block, a validator must first validate all transactions in its current event block and part of the ones it has received from other nodes; these are the event blocks it has received during the asynchronous exchange of event blocks explained in the section above. The new event block then is communicated with other nodes through the same asynchronous event communication.

During this communication, nodes share their own event blocks, and the ones they received from other nodes, with other validators that incorporate them in their own local DAGs. Consequently, this spreads all information through the network. The process is asynchronous as the event blocks shared between validators are not required to be sequential.

Unlike most blockchains, this DAG-based approach does not force validators to work on the current block that is being produced, which places restrictions on transaction speed and finality. Validators are free to create their own event blocks that contain transactions and share these with other validators on the network asynchronously, creating a non-linear record of transactions. This increases transaction speed and efficiency.

As an event block is sent and propagated across validators, it becomes a root event block once the majority of validators have received and agreed upon it. This root event block will eventually be ordered and included in the main chain, which is a blockchain that contains the final consensus among all event blocks that have become root event blocks.

Every validator stores and updates a copy of the main chain, which provides quick access to previous transaction history to process new event blocks more efficiently. As such, Sonic's consensus mechanism combines a DAG-based approach that allows validators to confirm transactions asynchronously, which greatly increases speed, with a final blockchain that orders and stores all final transactions immutably and indefinitely.

Currently, the process of submitting a transaction and having it added to the Sonic main chain through the consensus mechanism takes approximately 1-2 seconds. This involves the following steps:

1. A user submits a transaction

2. A validator node batches the transaction into a new event block

3. The event block becomes a root event block once the majority of nodes have received it

4. The root event block is ordered and finalized into the main chain as a block

When a user explores Sonic through a , they view the final blocks on the Sonic main chain. Event block generation and exchange in validators' DAGs is an internal process only and is not visible to end users.

To better understand the technical aspects of Sonic's consensus mechanism, review the paper on Fantom Opera's consensus mechanism, as Sonic's design is a continuation of it:

.

Verifying your smart contract makes its source code publicly visible and auditable on the block explorer, creating transparency and trust. Here are the recommended methods to verify contracts on the and the .

— — — — —

Method 1. Hardhat Verification (Recommended)

The most streamlined way to verify contracts is using Hardhat with hardhat-toolbox:

Gas and Fees

• Fee Model Sonic uses a Base Fee + Priority Fee model similar to Ethereum's EIP-1559.

• Fee Distribution Unlike Ethereum, the Base Fee is not burned

This guide describes the steps for upgrading a Sonic mainnet node to the latest 2.1.2 version, which introduces the to the Sonic network.

Once upgraded, your nodes will continue to operate on the current mainnet until the full transition. The upgrade is backward compatible, meaning you can upgrade now without any interruption.

The guide covers the following steps:

The following version history documents the Sonic client (the node software that powers the Sonic mainnet) including its virtual machine, database storage, and consensus mechanism.

The S airdrop will distribute 190,500,000 S tokens to incentivize users of Sonic. The airdrop will be distributed using Sonic Points, Sonic Gems, and Game Gems.

The S airdrop spans multiple seasons, with an undisclosed amount of the total airdrop allocated to each season. The first season ended on June 18, 2025, and the second season began immediately after.

Visit the to track your points.

For historical information about previous seasons of the airdrop, find the relevant pages here:

Distribution

For season 1 of the airdrop, 25% of your allocation is immediately available, while the remaining 75% vests over 270 days as NFT positions that are tradable on the by Paintswap.

A linear decay mechanism applies to the vested portion, allowing you to claim early at the cost of a penalty that burns a portion of your tokens. This approach prevents sudden surges in circulating supply by burning tokens from users who choose to claim early. It also incentivizes recipients to stay active on-chain while waiting for an optimal time to claim the remainder of their allocation.

The chart below illustrates how many tokens will be burned based on when users choose to claim their vested airdrop allocation.

Burn Amount and Examples

Data Collection

We are working with and to manage and oversee our points and airdrop designs through data-backed decision-making.

OpenBlock’s data-driven incentive modeling platform powers over $2B in annual incentive spend and has been a leading provider of rewards design and efficacy analysis for leading protocols in the space including EigenLayer, Lido, Linea, Mode, Arbitrum, Solana, Sui, and many others. To initiate and sustain its ecosystem, Sonic will utilize OpenBlock’s incentive modeling frameworks, ensuring continuous and balanced growth for all actors in the system.

Sentio is an industry-leading indexing service that aids in streamlining continuous point tracking, helping retrieve historical states of all user positions to update user points upon every interaction. With its high-performance database infrastructure, engineered to handle queries at unprecedented speeds, Sentio enables the onboarding of tens of thousands of new users easily and efficiently.

Legal Provisions

As part of the Sonic Foundation’s research and commitment to this airdrop, we have sought legal opinions to ensure its success.

The program will likely need to exclude any sanctioned country or person including all those who are citizens or residents of or residing in (the “Restricted Countries”): Belarus, Burundi, Central African Republic, Congo, Cuba, DPRK (North Korea), Guinea, Guinea-Bissau, Iran, Iraq, Lebanon, Libya, Mali, Myanmar (Burma), Republic of South Sudan, Russia, Somalia, Sudan, Syria, Ukraine, the Crimea, Donetsk, and Luhansk regions of Ukraine, Venezuela, Yemen, or Zimbabwe.

These potential provisions may include:

• Geoblocking: Implementing geo-blocking measures for all restricted countries

• Self-declaration: Requiring participants to say they are not from one of the restricted countries

• Discretionary exclusion: The Sonic Foundation reserves the right to exclude any wallet address at its sole discretion

There will be a comprehensive set of terms and conditions provided at the program’s launch.

Explore the tooling and infrastructure platforms currently available on Sonic below. This list is regularly updated as new projects integrate the Sonic chain.

— Quick Overview — Introduction — Fail-Safe Mechanism — Fast Lane — Looking Into the Future — Frequently Asked Questions

Quick Overview

The Sonic Gateway is our native bridge that facilitates token transfers between Ethereum and Sonic. The bridging process consists of three steps:

1. Deposit Deposit your assets into the bridge, which takes ~15 minutes on Ethereum to achieve finalization and only ~1 second on Sonic.

2. Heartbeat After your deposit is confirmed, your assets will be bridged at the next heartbeat, which are intervals that bridge user assets in batches to ensure gas efficiency. A heartbeat occurs every ~10 minutes from Ethereum to Sonic and ~1 hour the other way. You can pay a Fast Lane fee to trigger an immediate heartbeat.

3. Claim Claim your bridged assets on the destination chain. That’s it! You’re now free to explore the Sonic ecosystem with your new assets.

Introduction

In today’s evolving blockchain landscape, a native, secure bridge is critical for ecosystem health, ensuring true interoperability and preventing network isolation. Yet, many current solutions on both layer 1S and layer 2S compromise security and speed —resulting in over to bridge hacks.

The Sonic Gateway is a revolutionary, secure bridge between Ethereum and Sonic that offers:

• Security: The Gateway includes a fail-safe mechanism that safeguards user assets. If the Gateway experiences prolonged failure (14 consecutive days), users can recover their bridged funds on Ethereum.

• Speed: Asset bridging is processed in intervals called "heartbeats" to ensure gas efficiency — every 10 minutes from Ethereum to Sonic and hourly in reverse.

Additionally, the Gateway makes Sonic an active participant on Ethereum as it spends ETH through its contracts.

Fail-Safe Mechanism

The Sonic Gateway includes a fail-safe mechanism that allows users to retrieve bridged assets on the original chain if the Gateway experiences a failure. In the highly unlikely event that the Gateway or the Sonic chain is down for 14 consecutive days, users are able to reclaim their bridged assets on Ethereum.

The 14-day period is immutable and cannot be altered by Sonic Labs or any third party after deployment. Importantly, this period is not intended as a contest period but rather as an essential feature that ensures users retain custody of their bridged funds on the originating chain.

Fast Lane

Assets bridged through the Sonic Gateway are processed in intervals called "heartbeats", ensuring gas efficiency by bundling bridging transactions together. For assets moving from Ethereum to Sonic, these heartbeats occur every 10 minutes, while Sonic to Ethereum heartbeats occur every hour.

During each interval, all queued transactions are processed simultaneously. While this system reduces costs, it may introduce waiting periods for users needing their assets bridged immediately. To address this, Fast Lane allows users to bypass the wait for a small fee and have their bridge transaction processed instantly.

Fast Lane works by adding an additional heartbeat to the Gateway. This means all other queued assets waiting to be bridged are also processed immediately, effectively accelerating the entire network. By using Fast Lane, users not only avoid delays and seize timely opportunities but also contribute to the broader ecosystem's efficiency, ensuring faster bridging for everyone involved.

Looking Into the Future

By enabling canonical access to native assets from other layer-1 platforms, the Gateway fosters a secure and thriving economy on the Sonic network.

Users can directly access these canonical assets on Sonic while maintaining asset security. The Sonic Gateway thus provides safe access to high-demand assets that natively exist outside the Sonic network.

Frequently Asked Questions

Troubleshooting

• Transaction Stuck in Heartbeat The relay service that processes heartbeats may occasionally experience downtime. If your transaction appears stuck for more than an hour, please check our official channels for status updates. The service is monitored and will be brought back online promptly.

• Claiming From a Multisig While possible, it requires careful proof generation. For the smoothest experience, we recommend using a standard EOA wallet with our Gateway UI.

Fee Monetization (FeeM) on Sonic lets builders earn 90% of the network fees their apps generate — creating a sustainable revenue stream without relying on fundraising. Inspired by Web2 models like YouTube, FeeM rewards developers for the traffic they drive.

FeeM also challenges the extractive "app chain" model by allowing builders to earn 90% of their app's network fees without the need to launch a separate chain. This approach removes the high costs, infrastructure overhead, and interoperability challenges typically associated with app chains.

By integrating monetization directly into the network layer, FeeM simplifies revenue capture and supports scalable, efficient app development within a unified, developer-friendly ecosystem.

Flow of Fees

Double-Spend Dilemma

In Fee Monetization, double counting is prevented by accurately tracking gas consumption within the virtual machine. The system traces all internal calls in a transaction and splits the reward based on the gas each sub-operation consumes.

This ensures that the sum of rewards across different projects never exceeds the total transaction fee. An example is given below.

• A trade consumes 100,000 units of gas with a total FeeM reward of 0.017 S.

• Inside this transaction, there are operations related to two projects: Project A and Project B.

• Project A, the DEX aggregator, is responsible for consuming 37,000 units of gas, while Project B, the liquidity pool on the DEX with which the aggregator interacts, uses 63,000 units of gas.

• The total reward is split based on the gas consumption:

The chart below illustrates how the FeeM oracle infrastructure traces each sub-operation and distributes the transaction fee spent on the calls based on gas consumed.

Frequently Asked Questions

Sonic Points are user-focused airdrop points that can be earned as part of the ~200 million S airdrop. Designed to boost liquidity on Sonic and strengthen its ecosystem, our points program positions Sonic as a premier hub for DeFi enthusiasts and users seeking to maximize the potential of their assets.

To earn Sonic Points, deploy whitelisted assets across various DeFi apps. These points will be distributed over multiple seasons as NFT positions, ensuring long-term sustainability and preventing sudden supply shifts.

— How To Earn Points — User Points — App Gems — Loyalty Multiplier — Whitelisted Assets — Airdrop Points Dashboard — Terms and Conditions

How To Earn Points

1. User Points — Deploy Assets on Apps

By deploying as liquidity on participating apps, users will earn points. A list of is available on the points dashboard.

To earn points for providing liquidity (LPs), both tokens in the pair must be whitelisted. If only one or neither token is whitelisted, no points will be earned. Points are calculated as the average of the two asset multipliers. For example, an S/USDC LP would earn 10x points (average of 12x and 8x).

2. App Gems — Earn Further Allocation

The S airdrop includes a developer-focused portion, where apps compete for an airdrop allocation known as . Apps can redeem these Gems for S tokens, which they can then distribute to their users however they want.

To decide how these S tokens are distributed to their users, each app will run its own independent points program, entirely at its discretion. The app may consider various things, such as the amount of liquidity a user has deployed, the duration of deployment, and the specific pools to which a user has added liquidity.

As a user, you will be earning points regardless if you've deployed your assets on an app. Your goal is to identify which app has the points program that will offer the highest return for your liquidity. The challenge lies in maximizing your overall rewards by combining the yield earned from providing liquidity with the points earned from the app's points program.

Loyalty Multiplier

To encourage consistency and prevent farming or drop-off cycles, a loyalty multiplier is in place.

Your season 1 performance sets your initial multiplier (from 1.0–2.0x), and your ongoing activity in season 2 can increase or decrease that value, up to a maximum of 3.0x and a minimum of 1.0x.

The multiplier applies to EOAs only (for now) and updates automatically based on your activity. It will be visible in MySonic once available (not immediately at launch). This loyalty program will carry forward into future seasons.

Whitelisted Assets

To qualify for the S airdrop, you must deploy the whitelisted assets listed in the table below as liquidity on participating apps. The multipliers are applied to the points you earn.

The multipliers for each asset above are decided by which category the fall under in the table below.

Sonic reserves the right to determine the appropriate category for any app.

Whitelisted assets and their multipliers are subject to change. S tokens staked through MySonic are not eligible for points. Users who wish to stake can instead use liquid staking tokens.

Airdrop Points Dashboard

The is a comprehensive platform where users can:

• Check earned points

• Check the list of participating apps

• Get whitelisted assets through a simple interface

• Generate a referral code and share with friends to earn extra points

Terms and Conditions

View the for the Sonic points program.

Archive nodes store the entire history of the Sonic chain, including all historical states, transactions, and blocks since the genesis block.

These nodes handle historical data requests, useful for chain explorers or apps that require historical chain information. However, they do not validate transactions or create new blocks, which is the role of validator nodes.

To run an archive node on the Sonic mainnet or testnet, follow the steps below.

1. Build Sonic Client and Tooling

The minimal configuration for a Sonic archive node is a Linux server with 4 vCPU, 32 GB of RAM, and local SSD storage. We recommend at least 8 vCPU and 64 GB of RAM, but 128GB of RAM is generally preferable for high-demand nodes.

You will need ≈1TB of free local SSD space to achieve good performance and speed. The configuration details depend on your specific use case.

The IOPS throughput and random access latency of the state DB persistent storage determine the performance of Sonic. For a smooth installation and fast response time, we recommend a local NVMe or a local SSD drive.

A remote block device, e.g. AWS Elastic Block Store (EBS), does not provide the required latency and IOPS performance.

Building the Sonic binary requires the essential software compilation tools and the language version 1.22 or newer to be available. Please refer to your Linux distribution manuals to obtain the development tools installed on your system.

Build Sonic Client

Download the Sonic source code from the following GitHub repository.

Switch to the most recent .

Build the Sonic binary using the provided configuration.

Transfer the new binaries to the bin folder for system-wide access (optional).

2. Prime Sonic State DB

Download the most recent network archive genesis file for the .

The genesis file will be used to prime your local state database and will allow you to join the network and synchronize with it. Please check the downloaded genesis file using the provided checksum.

The expected output is sonic.g: OK.

Prime Sonic Database

Use the sonictool app (created during the building process as build/sonictool) to prime a validated archive state database for the Sonic client. Start the genesis expansion.

The last step of the genesis processing is the state validation. Please double-check that the output log contains the following messages with details about the verified state:

3. Synchronize Sonic Node With Network

With the Sonic app created and the database primed in the previous step, you are ready to start the node and synchronize its state with the network.

• Use the node database path (<datadir>) from the previous step.

• Use ≈90% of the RAM as the GOMEMLIMIT value.

• Use ≈12 GiB of the RAM as the --cache value.

Additional starting flags may need to be added to start Web3 RPC and WebSocket interfaces on the node. Add the following flags to enable the Web3 HTTP interface. Adjust your listening IP address, port, CORS, and list of enabled APIs for your specific needs.

Add the following flags to enable the WebSockets interface. Adjust your listening IP address, port, origin, and list of enabled APIs for your specific needs.

Now, start your node with the sonicd application.

All apps on Sonic are eligible to participate in Fee Monetization. To apply, visit the and click Apply for FeeM.

The application process consists of registering your app to participate in FeeM, followed by registering your app's associated contracts to verify ownership.

Step 1 — App Registration

Visit the , connect your admin wallet, and click Apply for FeeM. The registration form will request several details from you.

Below is a list of all important contract addresses relevant to the Sonic network.

Sonic Gems are developer-focused airdrop points designed to reward apps for driving user engagement and innovation. These Gems can be redeemed for S tokens, which apps can then distribute as rewards to their users.

This system helps apps grow by driving consistent user activity and maintaining long-term engagement.

— What are Sonic Gems? ‎‎‎‏— Distribution of Gems — Gems Revocation Policy

What are Sonic Gems?

Sonic Gems are airdrop points exclusively designed for apps. Each season, a fixed supply of Gems is allocated to apps based on performance metrics. Apps can track their progress through the .

To distribute the S tokens earned through Gems to their users, apps must manage the process independently. For example, an app could:

• Run their own internal points programs

• Claim Gems and distribute S to users in season 3

• Join on Telegram for further support

While there’s no strict requirement for apps to share a specific percentage of their claimed S tokens with their users, the design of Gems incentivizes generosity. Apps that share a larger portion of their claimed S with their communities are rewarded more favorably compared to those that do not.

Tokenizing Gems is strictly prohibited. Any app that does so will be instantly disqualified from the entire season.

Distribution of Gems

Sonic Gems are distributed by considering factors such as category type, Sonic exclusivity, revenue generation, and effective reward distribution, promoting fairness and incentivizing active participation.

The competitive PvP nature and fixed supply of Gems mean that an app's Gem balance may fluctuate daily, influenced by the performance of other apps on the platform.

Below are the key criteria that will determine an app's share of Gems in season 1.

Final Gems Calculation

Apps will receive a pro-rata share of Sonic Gems based on their final weights, determined by the calculations below.

Gems Revocation Policy

The following actions by the app can cause their Sonic Gems to be revoked.

1. Incentivizing Project Tokens or NFTs with Gems Allocating Gems as rewards for activities like holding, staking, or providing liquidity (LPing) for a project’s token or NFT. For apps that have a voting mechanism to direct emissions, Gems can be used as vote incentives for any pool other than those that contain the project's token.

2. Suspicious Distribution Practices Distributing large quantities of Gems non-transparently, such as allocating them disproportionately to insiders or KOLs without clear disclosure.

3. Misrepresenting Gem Redistribution Providing false information about the amount of claimed S being distributed to users during any season.

Sonic nodes are generally stable and can run for extended periods without operator intervention. However, in rare cases, the software may encounter failures.

This page outlines the most common causes of such failures, suggests configuration adjustments to prevent them, and provides recovery steps to help you get your node back online as quickly as possible.

1. Recognizing a Failed Node

Regardless of the reason, the outcome of a failure is always the same. The node uses a database to track the state of all accounts, smart contracts, transactions, and the consensus data.

Parts of the database is kept in memory during normal operation. Pre-calculated and updated data is eventually pushed into the persistent storage. If the update cannot finish properly, the persistent copy of the database is in an inconsistent state and can be corrupted.

Sonic Bridge: Programmatic Usage Guide

Contract Addresses

Validator nodes are critical to the Sonic chain, responsible for validating transactions and creating new blocks in accordance with the . These nodes ensure the integrity and security of the network by verifying data, participating in block creation, and maintaining the chain’s state.

Unlike , validator nodes focus on real-time operations rather than storing extensive historical data or responding to general API requests.

To run a validator node on the Sonic mainnet or testnet, follow the steps below.

Steps to Run a Validator

Quick-Start Guide

Overview

USDC by Circle enables the seamless transfer of digital dollars on Sonic using a smart contract. This guide walks you through building a simple React app that lets users connect their wallet and send USDC on the .