Sonic is an app-fee L1 with a discretionary treasury layer

Sonic is not trying to win by “ultra sound money” branding. It is trying to win by routing economic value to applications by default, at the base layer. In the current docs, 90% of transaction fees flow to a developer-oriented Fee Monetization treasury and 10% flow to validators, and Sonic explicitly notes that the base fee is not burned.

That single design choice shapes everything else about S. Value accrual is not “fee burn first.” It is “builder revenue first,” with security paid as a slice of fees plus staking emissions. Sonic is also a continuation of Fantom via an FTM→S upgrade path, which matters because it imports legacy distribution, legacy power centers, and a governance culture that has already shown willingness to rewrite issuance assumptions when the foundation’s operating constraints become painful.

What S does in-product

S is the native asset for gas, staking, validator operations, and governance participation, as described on the token utility page.

The migration framing is straightforward. Sonic launched on December 18, 2024, and FTM holders can upgrade to S at 1:1. The migration timeline in official docs calls out a two-way swap period for the first 90 days, followed by one-way swaps (FTM→S only) after that.

The launch post makes the timeline more operational. It specifies the network parameters (Chain ID 146, currency symbol S), and it pins a key tokenomics milestone: June 18, 2025 as the date when “S supply begins to increase as the updated tokenomics take effect.”

On the staking side, the token docs state a 14-day waiting period if you choose to withdraw staked S.

Validator economics, in practice, are gated by parameters that meaningfully influence decentralization. The validator deployment docs specify a minimum self-stake of 500,000 S and a maximum validator size of 15× self-stake, and they also note that the minimum self-stake is set high “during the network’s early months,” with plans to reduce it over time.

Supply, issuance, and where new S can come from

Supply on Sonic is a mix of legacy-migrated balances and governance-authorized expansion. The official token page gives a coarse snapshot, stating that the “current total supply” is approximately 3.8 billion S.

CoinGecko provides a more precise market-facing view. It lists circulating supply 3,784,775,845 S and total supply 3,885,497,663 S, and it explicitly tracks 100,721,818 S as “Airdrop (Unminted).” It also lists max supply as ∞ (which should be read as “no hard-coded cap surfaced here,” not as a proof of unlimited issuance in protocol code).

From a mechanism perspective, Sonic’s own docs describe several issuance channels and schedules. These are not hypothetical. They include dated issuances already executed on-chain and an explicit future inflation regime for validator rewards.

Fee flows, burns, and the fiscal reality of S

Sonic’s fee model is opinionated and unusually explicit in official docs. Gas pricing is described as “Base Fee + Priority Fee” similar to EIP-1559, with a key deviation: the base fee is not burned. Instead, the gas pricing docs say fee distribution is 90% to a FeeM treasury for developers and 10% to validators.

Fee Monetization (FeeM) then refines how that developer-oriented share is attributed. The Fee Monetization docs describe the user paying gas in S and the network allocating 10% of the fee to validators, while builders earn 90% of the network fees their apps generate.

This “apps get paid” policy is not just narrative. It comes with contract-level plumbing and an oracle-like accounting system that traces gas usage across sub-operations, then attributes rewards.

Now the part that should make any Operator Discretion Skeptic sit up. Sonic’s docs introduce a FeeM Vault that is explicitly a multisig operated by Sonic Labs. It accumulates fee revenue (described as 90% of transaction fees) generated by “core token contracts” like wS and bridged stables, then plans to deploy those funds for liquidity incentives and integrations.

That is a structural trade-off. Sonic can iterate quickly and steer liquidity toward strategic assets. At the same time, a meaningful portion of chain-level revenue is not governed by immutable rules alone. It is governed by a multisig’s operational decisions. For a contrast in value routing, our Basic Attention review is a useful comparison.

On burns, Sonic’s current S-token docs focus on two burn mechanisms that reduce effective emissions, not fee burns. They are: (1) an airdrop burn if users do not wait out the full maturation period for the vested portion, and (2) an ongoing funding burn where unused annually-issued growth tokens are burned.

There is also a documentation-level ambiguity worth flagging. Some earlier ecosystem materials described fee burning for non-FeeM activity, but the current gas pricing doc is unambiguous that base fees are not burned and that fees are routed 90/10 to developer treasury and validators. If you are modeling long-run value accrual, you should privilege the latest primary technical docs over older explainers.

Governance and operator control surfaces

The official S-token page repeatedly grounds tokenomics changes in “governance proposals,” including institutional expansion issuance, ongoing funding issuance, and the block-reward migration plan.

We do not have great primary documentation, in one place, describing governance as a fully specified constitution. What we do have is strong evidence that governance is active, that it approves large monetary changes, and that it is executed through a mix of on-chain transactions and off-chain signaling (Snapshot is explicitly referenced in the token docs).

Secondary reporting adds color on participation concentration. CoinDesk’s expansion vote details report that the U.S. expansion issuance vote received 99.99% support, with 860.6 million votes in favor, and references a 700 million token quorum threshold.

On the smart contract side, FeeM also introduces explicit administrative surfaces. The application docs list a “Dispute Resolver” contract and other FeeM contracts that projects must interact with, and it discusses practical handling for upgradeable (proxy) contracts during registration.

Finally, there is a broader “who holds keys” question around institutional allocations. Sonic’s own “Sonic in 2026 and Beyond” post discloses a real multisig configuration related to strategic allocations, stating that a wallet is secured via a 4-of-6 multisignature with three signers designated by Sonic Labs, and it claims binding legal restrictions on selling or rehypothecating that allocation.

Risk register (Operator Discretion Skeptic view)

Sonic’s token design is coherent. It pays apps. It funds growth. It avoids early security inflation by reallocating legacy rewards.

The cost is governance and operator discretion that is both monetary and operational. S is not just “a staking token.” It is the unit of account for a set of programmable budget lines that can be expanded, re-aimed, and executed through multisigs and admin-driven programs.

Dominant risk: Monetary policy is governance-mutable, and governance is plausibly concentrated. For another L1 case study, our Berachain tokenomics review is a useful comparison.

The biggest structural risk is not “inflation exists.” It is that the magnitude, timing, and recipients of inflation have already been changed via governance, including a large institutional expansion issuance whose first tranche is explicitly dated and sized.

Mechanically, Sonic has multiple issuance spigots: ongoing funding (47.625M per year for six years), institutional expansion (hundreds of millions issued in a single event, with the possibility of additional ETF-linked issuance), and future validator inflation (1.75% per year after the initial four years).

Even when a program has a burn backstop, the system still depends on credible operational enforcement. The ongoing funding promise is “unused gets burned.” That is directionally good. It still leaves discretion on what qualifies as “used,” who receives it, and how quickly it is deployed, all of which can shift net sell pressure and perceived fairness without changing a line of protocol code.

Then there is the governance participation reality. If quorum is high but actual participation is narrow, you can get outcomes that look decentralized on paper while behaving like stakeholder capture in practice. CoinDesk’s reporting on the U.S. expansion vote gives the key datapoints to watch: token-weighted participation near 860.6M and a 700M quorum threshold.

For S holders, the practical takeaway is simple. Your long-run exposure is not just to chain adoption. You are also exposed to governance willingness to “refinance” the ecosystem using your unit of account. The project has shown it will do this when it believes strategic constraints are binding.

  1. Governance-driven dilution shocks. Trigger: new proposals that authorize large issuances (for institutional initiatives, “ongoing funding,” or any future program). Mechanism: token-weighted voting approves minting or reallocation, followed by on-chain issuance events that step-function supply upward. Who bears it: liquid holders and stakers, via dilution and potential sell pressure; also app treasuries that hold S as working capital. Indicators: circulating and total supply deltas, “Airdrop (Unminted)” changes, and discrete issuance events like the documented 472,372,662.8 S mint on September 4, 2025.

  2. Admin and multisig execution risk in fee treasuries. Trigger: signer compromise, signer rotation, rushed treasury deployments, or governance ambiguity on how fee treasuries should be spent. Mechanism: the FeeM Vault is described as a Sonic Labs-operated multisig accumulating fee revenue, and it can deploy capital into liquidity incentives and integrations. Who bears it: everyone relying on “neutral” fee flows, especially builders not favored by vault allocations and holders whose value accrual assumptions include disciplined treasury policy. Indicators: published vault addresses and on-chain outflows, changes in stated deployment policy, and any public disclosures about signer sets or thresholds.

  3. Validator-set centralization pressure from staking thresholds. Trigger: sustained high minimum self-stake requirements or slow follow-through on the stated plan to reduce them. Mechanism: a 500,000 S minimum self-stake and a 15× validator size cap shape who can run infrastructure and how delegation concentrates. Who bears it: users and apps if censorship resistance weakens, and delegators if validator quality becomes more correlated with a small operator set. Indicators: number of active validators, stake concentration by top operators, and any parameter changes to minimum self-stake or max multiplier.

If you are evaluating or designing around Sonic’s token economy, treat “who can change the rules” as a first-class variable. If you want support pressure-testing these assumptions, our tokenomics design services are built for this kind of work.

This is the kind of system where tokenomics consulting work tends to focus less on emissions math and more on authority boundaries, upgrade processes, and treasury controls. Our token economy components guide is a helpful framework for that analysis.

The cleanest way to summarize S is that it is a productive asset inside an L1 that pays applications, funds growth with explicit issuance, and accepts a higher level of operator discretion to move fast. The open question is not whether that trade-off can work. It is whether Sonic can keep discretion legible, constrained, and credibly governed as the stakes rise. For more writing in this vein, see our crypto research reports.



This article is part of our Tokenomics Deep Dive series.