Sonic Blockchain


TL;DR
Sonic Network Architecture
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:
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.

Lachesis Consensus Protocol
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.


Tokenomics of $S
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.

Transaction Fee Model
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.

Performance Characteristics
Transaction Throughput
Deterministic Sub-Second Finality
State Storage: Carmen DB
Holistic Performance Stack
Sonic Gateway
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.

Conclusion
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.
Resources
Frequently asked questions
Check out most commonly asked questions, addressed based on community needs. Can't find what you are looking for?
Contact us, our friendly support helps!
How does Sonic’s Lachesis consensus stay secure without a leader?
Lachesis uses a leaderless DAG where validators independently create and confirm events. Consensus is reached when two-thirds agree, ensuring fast, fork-free finality and strong security even during network issues.
What makes the Fantom Virtual Machine (FVM) better than Ethereum’s EVM?
FVM speeds up smart contract execution by combining common instructions into single operations, reducing gas costs and boosting transaction speed while staying compatible with Ethereum.
How does Sonic’s Fee Monetization benefit developers and users?
Sonic sends 90% of gas fees from participating dApps to developers, helping them earn revenue directly from network use, unlike most blockchains where fees go mainly to validators or are burned.