Sonic (S) sustainability report

Sonic (prev. FTM) is present on the following networks: Sonic.

Sonic is an independent layer one network that reaches agreement with Lachesis, a leaderless asynchronous Byzantine fault tolerant protocol operating over a proof of stake validator set. It inherits this design from the earlier chain whose community and token it succeeded, and it runs it on a rebuilt client. No validator is designated to propose for a given round. Each one bundles the transactions it has received into an event, references the latest events it has seen from its peers, signs the result and gossips it on, so every participant accumulates a directed acyclic graph of the same events. Ordering is then derived from the structure of that graph: once an event has been observed, directly or through the references of later events, by validators holding more than two thirds of the bonded native asset, it is settled, and the ordering procedure turns that portion of the graph into a sequential chain of blocks.

A 2025 revision of the consensus implementation restructured how these decisions are computed, running the elections that resolve successive positions in an overlapping fashion instead of one after another. The change did not alter the safety or finality properties; it cut the processing and memory a validator needs to seal an epoch, which lowers the hardware burden of participating. Execution is deliberately separated from consensus: an Ethereum compatible virtual machine tuned for fast contract execution sits behind a dedicated state storage layer, and the node software distinguishes validating nodes from archival ones that retain full history.

Finality is deterministic and typically reached about a second after submission, with no confirmation depth and no dispute window; agreement is reached by this network's own validators and is not deferred to, or settled on, any other chain. Bridges to other networks exist but sit outside consensus. Operators register through the staking contract with a substantial self bond, set high while the validator set was young and intended to fall over time, and delegated stake is capped at a fixed multiple of that self bond.

Sonic (prev. FTM) is present on the following networks: Sonic.

Validators are paid for sealing epochs and for the transactions they order. For the network's early years the reward pool is not fresh issuance but a carried forward allocation redirected from the predecessor chain, which the staking contract pays out per sealed epoch; the target rate is tied to how much of the supply is bonded, falling as more is staked and rising as less is, so the yield tracks the security actually being purchased rather than a fixed schedule. Rewards accumulate in the contract and are claimed rather than credited automatically.

Holders who do not run infrastructure delegate to an operator. Delegation adds to the operator's consensus weight and to its reward entitlement, and the delegator receives the corresponding share less a commission the operator keeps. Each operator can accept only a fixed multiple of its own self bond in delegations, which limits how much weight a single operator can gather. Unbonding a delegation is not immediate: withdrawals enter a waiting period of about two weeks before the balance is released, so stake cannot be pulled out ahead of a penalty.

Penalties act on the bond. An operator found to have acted maliciously, for instance by signing conflicting events, has its stake reduced by the staking contract, and the delegations behind it are reduced in proportion, which is paid out of what delegators receive when they withdraw. Persistent unavailability is not confiscatory but earns nothing for the periods missed.

The fee a user pays is gas metered in the native asset, priced by demand for block space, with contract calls charged in proportion to the work they cause and no recurring charge for data already stored. What happens to that fee is unusual. Applications may register their contracts to receive a share of the fees their own usage generates, which can reach the large majority of the fee, with a further share going to validators and the balance destroyed. The proportions are governance controlled and have been revised since launch, and the accounting attributes gas consumed in nested calls so that shares cannot be double counted.

Sonic (prev. FTM) is present on the following networks: Sonic.

The reported consumption is a modeled figure rather than a metered one, built from the population of machines that keep the network running. That population is estimated from network crawlers, peer discovery traffic and operator information published in public sources. Counting nodes is the right unit for this consensus family: in a stake weighted asynchronous Byzantine fault tolerant design, participating means receiving gossip, verifying signatures, executing transactions and maintaining state, which is conventional server work. Nothing in the protocol rewards spending more electricity than the next participant, so there is no mining hardware to infer and no hash rate to translate into equipment.

Hardware is inferred from what the client software requires. Published processor, memory and storage specifications are matched to commercially available server configurations capable of meeting them, and the power draw of those configurations is taken from laboratory measurement under load and at rest. This network's node software distinguishes validating nodes from archival nodes that retain the full history, and the two have appreciably different storage and memory footprints, so the estimated mix between them affects the result. The network total aggregates the modeled draw across the estimated set for the reporting period, including idle time, since a node that is synchronized but momentarily idle still consumes power.

The limits of the method should be read alongside the number. Both the node count and the hardware mix are inferences from public observation and from stated requirements, not an inventory, and operators running on shared or virtualized infrastructure are not distinguishable from those on dedicated machines. Where evidence is missing the assumptions used are the ones more likely to overstate consumption than to understate it, and estimates are revised as observation improves. A further complication here is that consensus and client efficiency have changed since launch, so a figure computed for an earlier period reflects a heavier per node profile than the software now demands.

Sonic (prev. FTM) is present on the following networks: Sonic.

The renewable proportion attached to this network is inferred rather than measured. It starts from where the machines appear to be: node locations are approximated from publicly observable network data, chiefly the addresses seen during peer discovery and in crawler output, resolved to country or regional level and not to individual facilities. That view is partial by construction. Many operators sit behind hosting providers or relays, cloud regions do not always correspond to the jurisdiction of the account holder, and a comparatively young validator set concentrated in a few data center regions can shift quickly. Where the distribution cannot be observed with enough confidence, the geographic spread of a structurally comparable network, one with a similar participation model and similar hardware demands, is substituted for the unobserved part.

Those locations are then weighted against published electricity statistics. The share of generation coming from renewable sources in each region is taken from Share of electricity generated by renewables, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy, and applied to the consumption attributed to that region. Summing across regions gives a weighted renewable share for the network. The underlying assumption is that a node draws from its local grid at the average mix for that grid; operators with dedicated renewable supply contracts or on site generation are not separately credited, because that arrangement is not visible in network data.

Energy intensity is expressed as the marginal energy associated with one additional transaction, not as annual consumption divided by annual transactions. The distinction is significant for a high throughput network whose equipment draws much the same power whether blocks are full or nearly empty: the incremental cost of ordering one more transaction is small and largely independent of how busy the chain happens to be, and a simple average would move with usage rather than with anything physical.

Sonic (prev. FTM) is present on the following networks: Sonic.

Emissions are derived, not observed. The estimate combines the modeled electricity consumption of the network with the carbon content of the electricity supplying the regions where its machines appear to run. Those regions come from the same inference used for the energy assessment: addresses seen in peer discovery and crawler output, resolved regionally, with the distribution of a structurally comparable network standing in wherever direct observation is too thin to rely on.

Each region is assigned a carbon intensity for its electricity, measured as emissions per unit generated, taken from Carbon intensity of electricity generation, compiled by Our World in Data from Ember and from the Energy Institute's Statistical Review of World Energy and published under the Creative Commons Attribution 4.0 license. Multiplying each region's intensity by the consumption attributed to it, then summing, produces the network figure.

The split between the two reported scopes follows from how the network operates. Scope one counts emissions from sources the operators control directly, which for server infrastructure means combustion on the operator's own premises; nothing in running a node produces this, and any backup generation is neither material nor observable, so the figure is reported at or close to zero. Scope two counts the emissions embedded in the purchased electricity that runs the machines, and effectively the whole footprint sits there. Because regional grid averages are used, an operator buying certified clean supply is not credited for it, and one drawing from a dirtier local mix than its region's average is not charged for it either.

Greenhouse gas intensity is reported as the marginal emissions attributable to one further transaction, mirroring the treatment of energy intensity. For a network built for high throughput this is the more honest presentation: the infrastructure emits at much the same rate whether it is processing a few transactions or many, so dividing a period total by a transaction count would produce a figure that swings with activity rather than with the emissions actually caused.