Sidechain · settles to Solana
Sonic SVM ticker SONIC
Summary
Sonic runs its own chain on a modified Solana validator (a February 2026 upgrade moved mainnet from runtime v1.18.23 to v2.3.0), so blocks come in slots and forks are settled by stake-weighted validator votes. Sonic calls this chain a grid in its HyperGrid framework: a Cosmos-framework coordination network (HSSN) is meant to relay grid state and post settlement proofs to Solana, first with an optimistic challenge model and later with zero-knowledge proofs. This review found no live proof or state-root posting to Solana. Assets arrive from Solana through Hyperlane routes. The March 2024 whitepaper's design (validators staking SOL, SONIC holders delegating locked veSONIC, data on Celestia) differs from what current operator docs describe. 346911121321
Design
- System
- SidechainSonic's docs call it an atomic SVM chain that keeps atomic settlement with Solana, and describe its HyperGrid framework as a rollup framework. In practice it runs its own validator cluster on a modified Solana validator, and assets reach it through Hyperlane message routes. The documented proof and state-root posting to Solana was not found live, and the coordination network meant to carry it had stopped producing blocks at review time. It is filed as a sidechain bridged to Solana. The gas coin is labelled SOL; SONIC is a Solana token used for staking and governance programs.
- Settles to
- SolanaSonic describes itself as settling to Solana. SOL, SONIC, USDC and USDT enter from Solana through Hyperlane routes that hold assets on Solana and credit them on Sonic; exits depend on each route's security module. The docs describe state roots and proofs posted from HSSN to a verifier program on Solana, but no verifier program or posting record was found. The HSSN node that Sonic's mainnet validator guide lists as its peer, which also backs the HSSN explorer, reported no block after 31 August 2026 while the Sonic chain kept producing slots.
- Settlement family
- Solana / SVM
- Scarce resource
- Other
- State model
- Accounts
- Finality
- Other
- Who makes blocks
- Validators in Sonic's own cluster. Grid and RPC operators register by sending server details to the Sonic operators team, and HSSN validators are limited to selected ecosystem partners. Reads of the documented public mainnet RPC on 27 September 2026 showed one vote account holding all active stake (less than one whole native coin), one identity scheduled as leader for every slot of the epoch, and eight nodes visible; these are provider reports, not a published validator list.
- Fork choice
- Vote and lockout fork choice, from the modified Solana validator, among Sonic's own validators, not a work-weighted longest chain. With a single voting validator, that operator alone decides the canonical chain. The documented design would let proofs checked on Solana constrain grid state, but no such check was verified as live.
Qualifications
- System class · Contested. Sonic's docs call it an atomic SVM chain with atomic settlement with Solana, call HyperGrid a rollup framework with Sonic as a gaming grid that settles on Solana, and speak of layer 2 transactions on Sonic; its developer page groups it with gaming layer 1s; NorthStar's docs call Sonic's devnet the Sonic L1 surface; Trezor describes a framework for optimistic Solana rollups. It runs its own cluster and no Solana-checked settlement was found, so this profile uses sidechain.
- Scarce resource · Contested. The validator software weights leaders and votes by stake, but the reviewed mainnet had one voting validator whose whole stake was under one native coin, and joining is arranged with the Sonic team, so stake is not an open route to producing blocks.
- Finality · Partial. Blocks become final when Sonic's own validator stake votes, which at review time meant one validator. Solana finality does not cover Sonic transactions unless proof posting is live, which was not verified. Hyperlane's registry uses one confirmation and no reorg allowance for its relayers; that is a relayer setting, not a protocol guarantee.
- Solana settlement · Unknown. The docs describe an optimistic phase in which observer nodes challenge bad commitments and a later zero-knowledge phase; neither the Solana verifier program nor posting records were found.
- Coordination network · Unknown. HSSN, a Cosmos-framework chain, is documented as the consensus and communication hub between grids and Solana. Read on 27 September 2026, the HSSN node named as the peer in Sonic's mainnet validator guide listed two validators with equal voting power and a last block on 31 August 2026.
- Block time · Partial. Hyperlane's registry estimates 0.4-second blocks. Slot pace is not confirmation or finality time, and skipped slots produce no block.
- Tps · Contested. No observed throughput figure is recorded. The whitepaper and NorthStar figures are listed only as theoretical peaks.
- Consensus upgrade · Partial. Sonic's testnet notice announced an upgrade to Agave 3.0 on a March 4 with no year given, and lists Alpenglow consensus among its features. The testnet RPC reported version 3.0.0 on 27 September 2026, but whether Alpenglow voting is active there was not verified. Mainnet reported 2.3.0, and no mainnet consensus change was found.
- Data availability · Unknown. The whitepaper planned data on Celestia and an account store based on Kademlia; current docs do not describe live data availability for grid data.
Tradeoffs
- Emphasizes
- Scalability Contested
- Gives up
- Decentralized operation and trust-minimized settlement: one validator produced and voted on every block in a September 2026 RPC read, node and HSSN onboarding runs through the Sonic team, the documented proof posting to Solana was not found live, and bridged assets depend on the signers configured for each Hyperlane route.Sonic's docs say the chain keeps decentralization through its connection to Solana's security; this review could not verify that link, so the reading is marked contested. Scalability here means the design goal of giving each application its own grid, not a measured throughput.
- Full node at home
- Data-center class 101112Sonic's RPC node guide lists a low-end tier of a 64-core CPU, 512 GB RAM and 10 TB storage (mid-range: 128 cores, 1 TB RAM, 15 TB); the grid guide lists 64 cores, 128 GB RAM and a 5 TB SSD; HSSN validators need 64 cores, 128 GB RAM and 7 TB. Operators must send their server IP or node identity to the Sonic team, and the RPC guide is written for testnet. The rating reflects the listed hardware and the team-gated onboarding.
- Throughput claims
- Theoretical peak 1021Theoretical peak; not comparable across chains or with observed load.No figure recorded. The 2024 whitepaper calls throughput potentially infinite as grids are added, and says its engine handles millions of transactions per second.Grid and RPC operators are expected to meet Sonic's listed 64-core, 128-512 GB RAM, multi-terabyte hardware.Design-document aspiration with no method, window or hardware test; not comparable with any other chain's figure. Adding grids adds separate execution environments; it does not raise the capacity of any one grid, and cross-grid coordination depends on HSSN, which was not producing blocks at review time. Ignores propagation, state growth and vote traffic.
- Theoretical peak: 1,000,000 tx/s 2425Theoretical peak; not comparable across chains or with observed load.NorthStar session runtimes; the NorthStar product page says over a million transactions per second.Product-page figure with no method, hardware or measurement window. Applies to NorthStar's single-tenant session runtimes, which its docs say are live only on devnet, not to the Sonic mainnet chain. Ignores settlement, fraud-proof and propagation costs; NorthStar's fraud-proof checkpoints are specified but not yet built.
Scaling layers
- NorthStar ephemeral rollup sessions · Rollup, testnet 242526
Operator-run single-tenant session runtimes built by the Sonic team. Accounts are locked on Solana during a session and settled back when it closes. Fraud-proof checkpoints and bisection are specified but not built: the devnet runs with an honest sequencer. If the operator stops, the owner can force-undelegate once the session expires, accepting the last published checkpoint. Its docs say it is live on Sonic's devnet, anchored to Solana's devnet; it does not settle to the Sonic mainnet chain.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Built into the protocolLimited scope | Limited to exchanges on the Sonic chain itself. Sonic runs Solana's runtime, where a transaction can carry several signers and all its instructions succeed or all revert, so two parties can exchange on-chain assets in one transaction. A trust-minimized cross-chain swap with Solana was not established; bridges rely on route signers. 1339 |
| Authenticated data publication | Unknown | Not yet assessed under the current definitions; the reviewed source describes Sorada, Sonic's system for serving archival reads apart from transaction processing, not a way to publish data against a commitment the chain records. No other publication feature was found, and absence was not exhaustively verified. 20 |
| Light clients | Unknown | No light-client verification path for Sonic was found; RPC answers from Sonic endpoints are provider reports. |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Unknown | No payment or state channel layer anchored to Sonic was found. NorthStar sessions are ephemeral rollups, not channels. |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Sonic runs SVM programs, so assets can be held and moved under custom program rules; Sonic's guide deploys them with the Solana command-line tools and Anchor. Whether every Solana program behaves identically on Sonic was not checked. 18 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; no way for a sender to cancel or reclaim a payment, and no recovery path, was found. The multisig tool listed in Sonic's resources gives shared control through a multisig threshold, which the current definition does not count as recovery. 19 |
| Rollups | Unknown | No rollup anchored to the Sonic chain itself was found. The same team's NorthStar ephemeral rollups anchor to Solana and are on devnet. 25 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | ThinSEGA | SEGA's docs describe permissionless AMM pools on Sonic SVM, and Sonic's July 2025 campaign post points users to it to buy SONIC and to add SONIC and USDT liquidity. No other venue was reviewed and liquidity was not measured. 2235 |
| Issuer-native stablecoins | None found | Neither Circle's USDC address list nor Tether's supported-protocols page includes Sonic SVM; Circle's Sonic entry is an unrelated EVM chain. USDC and USDT on Sonic are Hyperlane-bridged tokens backed by tokens held on Solana. 30313637 |
| Algorithmic stablecoins | Unknown | Algorithmic or hybrid stablecoins on Sonic were not reviewed. |
| Bridges | First-partySonic Bridge (HyperGrid Bridge), Hyperlane Nexus, Superbridge, Orbiter Finance | Sonic's docs list these for moving funds from Solana. The Sonic Bridge front end's code carries the Hyperlane route addresses for SOL, SONIC, USDC and USDT between Solana and Sonic. Sonic also publishes a separate bridge validator service that signs bridge events and passes them to relayers. Risk: Bridged assets on Sonic are only as safe as each route's security module and signers, which Hyperlane lets the deployer choose (the default is a validator multisig). The modules, signers and upgrade keys for Sonic's routes were not reviewed, and no Solana-checked proof backs withdrawals. The gas coin's reported supply exceeds all SOL on Solana, so it is not fully backed by the SOL route. 1519232829313234 |
| Block explorers | First-partySonic Explorer, HSSN Explorer | Sonic's docs list its own explorer for the chain and a separate explorer for the coordination network. The chain explorer's page did not render for the review tools. Third-party explorers were not reviewed; explorer output is indexed data, not consensus proof. 121727 |
| Hardware wallets | Unknown | See custody rows: no Ledger page for Sonic was found, Trezor lists the SONIC token only on Solana, and no vendor page or verified wallet path covers signing on the Sonic chain itself. 38 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | UnknownSame as native: Unknown | Ledger coin pages tried for Sonic SVM returned 404; no Ledger support for the Sonic chain or the SONIC token was verified. |
| Trezor | UnknownSame as native: Unknown | Trezor's Sonic SVM page lists the SONIC token only on the Solana network, with Trezor Suite, Backpack or NuFi; the Sonic chain itself is not listed, and holding the token on Solana is not custody on the Sonic chain. Sonic's docs list Backpack and NuFi as Sonic-capable wallets, but whether either lets a Trezor sign Sonic-chain transactions was not verified. 1938 |
Public data
iKnow Blockchain has no public-data lookups for Sonic SVM yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Review overdue Reviewed Sep 27, 2026; next review was due Oct 7, 2026, 12:00 UTC.
Publication date · newest first
-
Sonic introduced NorthStar session runtimes
Sonic described NorthStar as a session-based scaling protocol that lets an app open a short-lived dedicated runtime for traffic peaks and close it afterwards.
- Implementation:devnet per project docs
- Release:Announced
- Activation:not on mainnet
Sources: Sonic SVM — Intro to NorthStar (external site) · Sonic SVM — NorthStar documentation (external site)
-
Sonic announced a mainnet move to runtime v2.3.0
Sonic said it would migrate mainnet to new hardware and upgrade the runtime from v1.18.23 to v2.3.0, with about three hours of planned downtime starting 4 February 2026 and no endpoint or code changes for developers.
- Implementation:migration scheduled by the operator
- Release:v2.3.0
- Activation:public RPC reported v2.3.0 on 2026-09-27
Source: Sonic SVM — Sonic Mainnet Infrastructure Upgrade Notice (external site)
-
Sonic proposed veSONIC staking and boosts for node holders
Sonic's first numbered proposal would let node holders stake any amount of veSONIC, unstake at any time, and use a boost that raises a node's effective production weight, shifting its share of a fixed daily reward pool.
- Proposal:proposal published
- Implementation:not independently observed
- Release:not stated
- Activation:not verified as active
Source: Sonic SVM — Proposal #01: Activation of veSONIC Staking and Boost Mechanism (external site)
Topics your AI can explain
Your AI can explain these topics for Sonic SVM through the connection, with sources.
Known gaps
What this profile's review did not establish:
- No Solana verifier program, state-root account or posting record for Sonic was found, so the documented settlement on Solana is unverified; that is why this profile files Sonic as a sidechain.
- The HSSN node named in Sonic's mainnet validator guide, which also backs the HSSN explorer, reported no block after 31 August 2026 when read on 27 September 2026; whether the coordination network is halted, replaced or served elsewhere was not established, and no notice about it was found in Sonic's docs or blog.
- Validator counts come from single public RPC reads (one voting validator on the chain, two on HSSN), which are provider reports, not a published validator list.
- The chain's gas coin is labelled SOL, but a public RPC read reported a native supply larger than all SOL on Solana, so it cannot all be backed by bridged SOL; how that supply was created and how the SOL route's reserve is funded were not documented.
- The security modules, signer sets and upgrade keys for the Hyperlane routes serving Sonic were not reviewed, nor was the design of Sonic's own bridge validator service.
- The whitepaper's design (validators staking SOL, SONIC delegation through veSONIC, observer-node slashing, data on Celestia, an emergency exit on Solana) could not be matched to anything live.
- What the nodes held by Sonic's node holders are (the veSONIC proposal gives one vote per node and a share of a daily reward pool), and whether they take any part in block production, was not established.
- The testnet upgrade notice listing Alpenglow consensus gives no year, and whether Alpenglow voting actually runs on Sonic's testnet was not verified.
- Ledger support was not found (coin pages returned 404); Trezor lists the SONIC token on Solana only, and no hardware-wallet signing path for the Sonic chain itself was verified.
- Current user activity, fees charged in practice and liquidity on SEGA were not measured.
- Third-party explorers, other DEXes, algorithmic stablecoins and light-client options were not reviewed.
- The explorer front end did not render for the review tools, so its contents were not checked.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Architecture overview (external site)
- Why Choose Sonic? (external site)
- Clusters (external site)
- HyperGrid architectural overview (external site)
- Grids (external site)
- HyperGrid Shared State Network (HSSN) (external site)
- HSSN Gas Fee Mechanism (external site)
- Interoperability with Solana (external site)
- Verifiable Compute and Zero-Knowledge Proofing on HyperGrid (external site)
- Deploying a Sonic RPC Node (external site)
- Deploying a New Grid (external site)
- Deploying an HSSN Validator (Mainnet) (external site)
- Sonic Mainnet Infrastructure Upgrade Notice (external site)
- Sonic SVM Testnet Upgrade Notice (external site)
- Bridging funds to Sonic (external site)
- Setting up your wallet (external site)
- Explorer (external site)
- Build and Deploy Your First Program (external site)
- Additional Resources (external site)
- Sorada introduction (external site)
- Sonic SVM: A HyperGrid Scaling Future of Solana (whitepaper, March 18, 2024) (external site)
- Sonic Summer Surge (external site)
- sonic-bridge-validator (external site)
- NorthStar (external site)
- NorthStar documentation (external site)
- NorthStar security model (external site)
- Hyperlane registry: sonicsvm chain metadata (external site)
- Hyperlane registry: SOL route between Solana and Sonic SVM (external site)
- Hyperlane registry: SONIC route between Solana and Sonic SVM (external site)
- Hyperlane registry: USDC route between Solana and Sonic SVM (external site)
- Hyperlane registry: USDT route between Solana and Sonic SVM (external site)
- Sonic Bridge (external site)
- HyperGrid Framework (external site)
- Interchain Security Modules (external site)
- SEGA documentation (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
- Sonic SVM wallet (external site)
- Transactions (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding