Sonic Blockchain

• Architecture: Sonic is a monolithic but modular high-performance L1 built by the Fantom team. It features validator and archive node separation, FVM for fast EVM execution, and Carmen DB for efficient state storage.
• Consensus: Lachesis is an asynchronous, leaderless, and DAG-based aBFT protocol with deterministic finality, enabling sub-second block confirmations and high throughput.
• Tokenomics: $S replaces $FTM with a fixed 3.175B supply at launch. Staking rewards are reserve-funded for 4 years, followed by modest 1.75% annual inflation. Governance and airdrops are handled via $S voting.
• Fees: The Fee Monetization model sends 90% of gas fees to developers of dApps, aligning economic incentives. Non-participating contracts follow a fee burn/distribution model.
• Performance: Sonic supports 10,000+ TPS with deterministic sub-second finality. Powered by Lachesis, FVM, and Carmen DB, it avoids sharding while achieving near-instant finality and fast state access.
• Bridge: The Sonic Gateway enables secure, validator-relayed bridging between Ethereum and Sonic using Merkle proofs. Features include Fast Lane transfers and a 14-day fallback to ensure asset recovery.

Sonic introduces a fundamentally reimagined architecture that builds upon the foundations of the Fantom Opera chain while incorporating breakthrough performance optimizations across every layer. The architecture is monolithic yet highly modular in its internal organization, enabling the chain to achieve scalability without sacrificing consistency or developer experience. At the heart of the Sonic architecture are two classes of nodes: validator nodes and archive nodes:

• Validator nodes are responsible for executing the consensus protocol, verifying transactions, creating new event blocks, and ultimately finalizing blocks into the main chain. Each validator must lock a minimum of 500,000 S tokens, establishing a high barrier to entry that ensures participants are economically committed to the network's integrity.
• Archive nodes, on the other hand, serve as the long-term memory of the network. They store historical state and block data, including all past transactions, event blocks, and finalized states. By offloading this responsibility from validators, archive nodes allow the consensus layer to remain lightweight and focused on the most recent state, facilitating the use of Sonic's real-time pruning engine.

The consensus layer operates over a Directed Acyclic Graph (DAG), which due to its importance in the Sonic architecture, we will discuss in full explanation in the next section. Execution on Sonic is powered by the Fantom Virtual Machine (FVM), a highly optimized, EVM-compatible execution environment designed to process smart contracts far more efficiently than standard Ethereum clients. FVM introduces several low-level optimizations that are particularly effective for gas-intensive workloads. For example, it replaces repetitive instruction sets with super-instructions that execute complex opcode sequences as a single atomic operation, significantly reducing overhead.

Beneath the execution layer, Sonic leverages Carmen DB, a purpose-built state management engine. Carmen diverges from Ethereum’s Merkle Patricia Trie (MPT) structure in favor of a flat state format that uses a cryptographically provable mapping of keys to values. Unlike MPT, which requires traversing multiple trie levels to resolve a key, Carmen accesses keys directly, reducing IO operations and latency. The state database is divided into two sections: LiveDB, which holds the active state needed by validators to process the next block, and ArchiveDB, which holds the historical states preserved by archive nodes. Validators maintain only the LiveDB and use Carmen’s live pruning functionality to discard old entries on the fly, significantly minimizing disk usage and improving node synchronization times.

Sonic’s consensus engine, Lachesis, is a significant evolution of asynchronous Byzantine Fault Tolerant protocols, designed specifically for high-speed, leaderless blockchains. It operates over a DAG-based communication topology, allowing consensus to emerge organically through the propagation and validation of event blocks among validators. This approach provides deterministic finality, parallel event processing, and resilience to partial network failures. Unlike traditional BFT protocols that require fixed round durations, leader elections, or synchronous communication, Lachesis permits validators to create and broadcast event blocks at any time. Each event contains a payload of transactions and references to prior events from the same or other validators. These references establish a causal order among events, and as the DAG grows, each validator independently computes the structure and determines the order of events that have been seen by a supermajority of peers. Once an event is confirmed by two-thirds of the total stake-weighted validators, it is designated as a root event. The ordering of root events in Lachesis is governed by deterministic algorithms, ensuring all honest validators reach the same finalized sequence. Once ordered, these events are assembled into blocks and appended to the chain. Because all validators operate from the same DAG and ruleset, forks and reorgs are eliminated—unlike probabilistic consensus in PoW or some PoS systems, where chain reversals can occur. Lachesis is fully asynchronous, allowing validators to progress without synchronized rounds or global timing. This is especially valuable under real-world conditions with variable latency or partial outages. As long as two-thirds of validators are honest and online, consensus advances reliably. Its leaderless design enhances decentralization and avoids bottlenecks or collusion risks. All validators can propose events concurrently and are rewarded based on staked S tokens and honest participation. The DAG structure supports parallel event generation, letting validators process transactions simultaneously during peak demand. Finality remains constant, as ordering depends on causal relationships and quorum acknowledgment, not sequential rounds. This enables Sonic to achieve sub-second finality and high throughput without relying on sharding or external sequencers. Together, asynchronous consensus, leaderless architecture, and deterministic finality make Lachesis the foundation of Sonic’s speed, scalability, and Byzantine fault tolerance.

Sonic’s native token, $S, is designed to secure the network, incentivize developers, and support decentralized governance. Replacing the original $FTM token from Fantom Opera, it introduces a streamlined economic model focused on low inflation, sustainable rewards, and long-term stakeholder alignment. At launch, $S had a total supply of 3.175 billion tokens, mirroring $FTM’s. Around 2.88 billion entered circulation immediately, while 295 million were reserved for staking rewards—covering the unissued portion from $FTM without inflating supply. This allowed Sonic to reward validators while keeping early inflation near zero. Staking is central to both consensus and governance. Validators lock $S to secure the network, while token holders can delegate to earn a share of rewards. For the first four years, staking rewards are drawn entirely from the reserve, targeting a 3.5% APR under typical participation. No new tokens are minted during this period. After four years, Sonic introduces a modest annual inflation of 1.75%, distributed to validators and delegators. This maintains rewards sustainably, with higher effective APRs for early or low-saturation staking. The design ensures economic security without excessive dilution. Governance is fully token-driven. $S holders can propose and vote on key parameters, protocol upgrades, and treasury allocations. Early votes included the airdrop structure and ecosystem fund deployment. The airdrop, scheduled six months post-launch, distributes 6% of the total supply (~190.5M $S) to early Sonic users and Fantom builders. Only 25% is immediately claimable; the rest vests over 270 days. Early claims trigger burns, discouraging premature selling and encouraging long-term participation. To support growth, Sonic also mints up to 1.5% of supply annually for six years, funding development, infrastructure, and marketing. Unused funds are burned at year-end, enforcing efficiency and preventing treasury bloat.

Sonic introduces an innovative approach to on-chain fee distribution through its Fee Monetization (FeeM) system. Unlike traditional Layer-1 networks where transaction fees primarily go to validators or are burned (as in Ethereum’s EIP-1559), Sonic redirects the majority of gas fees to developers, positioning itself as a network fundamentally aligned with builder incentives. This structure turns transaction activity into a revenue stream for smart contract developers, reducing the need for project-specific tokens or external funding.

The Sonic Gateway is a purpose-built, decentralized cross-chain bridge that connects the Sonic network to Ethereum and, in the future, other prominent Layer-1 and Layer-2 ecosystems. It plays a foundational role in the network’s interoperability strategy and user acquisition model, serving as both the conduit for token migration and the mechanism for general asset bridging across chains. The architecture of Sonic Gateway is composed of three core components: bridge contracts deployed on each connected chain, a StateOracle contract that stores verified state roots, and an off-chain validator relay system responsible for state updates. Together, these components allow for trust-minimized message and asset passing between chains without reliance on centralized custodians or third-party intermediaries. When a user deposits assets on Ethereum, the bridge contract logs the transaction and emits an event. Sonic validators monitor these events, build a Merkle tree of pending deposits, and submit its root to the StateOracle on Sonic. The user then provides a Merkle proof to the Sonic bridge, which verifies it and mints the corresponding tokens. Withdrawals follow the reverse flow: users burn tokens on Sonic, validators record the event, and update the Ethereum-side StateOracle. After confirmation, the user submits a Merkle proof on Ethereum to unlock the original asset. Transfers are processed in batches to optimize gas: Ethereum-to-Sonic every 10 minutes, Sonic-to-Ethereum every 60. A Fast Lane is available for urgent transactions, offering quicker processing for an added fee—similar to fast bridges but without custodial risk. The bridge’s security is anchored by Sonic’s validator set, not third-party relayers. Validators who secure consensus also maintain the bridge, aligning economic incentives and reducing attack surfaces. Validators are bonded and slashable, ensuring decentralization and accountability. Sonic Gateway also includes a fail-safe (withdrawWhileDead) that lets users reclaim assets on Ethereum if the bridge is inactive for 14 days. While highly unlikely, this fallback guarantees user funds remain recoverable even in worst-case scenarios.

Sonic represents a fundamental redesign of high-performance Layer-1 blockchain architecture, marrying deep protocol engineering with economic alignment. Its modular yet monolithic stack—anchored by Lachesis consensus, FVM execution, and Carmen DB storage—delivers scalability without compromising on decentralization, security, or developer experience. Through innovations like deterministic sub-second finality and validator-secured bridging, Sonic removes the common bottlenecks seen in traditional EVM chains. Beyond performance, Sonic introduces a developer-first economic model with Fee Monetization, transforming transaction volume into protocol-native revenue. With robust tokenomics, governance mechanisms, and a forward-looking interoperability stack, Sonic positions itself not just as an upgrade to Fantom Opera, but as a foundational platform for the next era of decentralized applications.

• soniclabs-consensus
• soniclabs-database-storage
• soniclabs-fee-monetization
• arxiv