DEV Community

SwiftNodes
SwiftNodes

Posted on • Originally published at swiftnodes.io

Sonic RPC: What Fantom Became — New Chain ID, Sub-Second Finality

#ethereum #blockchain #tutorial #web3

If you built on Fantom, Sonic is where that chain went. Sonic is the rebranded, re-engineered successor to Fantom Opera — a high-performance EVM Layer 1 launched in late 2024 with a new execution engine, sub-second finality, and an aggressive model that returns most gas fees to developers. It's standard EVM underneath (chain ID 146, ordinary eth_*, viem/ethers/foundry unchanged), so the tooling is familiar. But the first thing to get right — and the thing that quietly breaks Fantom-era code — is that Sonic is a different chain ID with a different native token. Here's the map.

The essentials

Sonic mainnet (live since December 2024) is chain ID 146, an EVM Layer 1 with:

  • S as the native gas token (18 decimals) — migrated 1:1 from FTM.
  • Sub-second finality (~1s) via Sonic's BFT-style consensus (heir to Fantom's Lachesis) — an L1, not a rollup.
  • A custom high-performance execution layer (the "Sonic" engine) that keeps Solidity bytecode compatibility while targeting far higher throughput than typical EVM chains.
  • FeeM (fee monetization) — up to 90% of the gas fees generated by a dApp are returned to that dApp's developers.
  • EVM-compatible — Solidity, ABIs, Hardhat, Foundry, ethers, and viem all apply directly.

Connecting is standard EVM — the values that matter are the chain ID and the token:

import { createPublicClient, http, defineChain } from "viem";

const sonic = defineChain({
  id: 146,                                            // NOT 250 (that was Fantom)
  name: "Sonic",
  nativeCurrency: { name: "Sonic", symbol: "S", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/sonic?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: sonic, transport: http() });
await client.getBlockNumber();   // just works
Enter fullscreen mode Exit fullscreen mode

Migrating from Fantom: the chain ID is the trap

This is the one that catches people. Fantom Opera was chain ID 250; Sonic is chain ID 146. They are not the same network, and reusing Fantom configuration on Sonic fails in ways that can be confusing:

  • Chain ID mismatch — a transaction signed for 250 is invalid on 146 (EIP-155 binds the chain ID into the signature). Hard-coded 250 anywhere — signer config, defineChain, wallet network entries — must become 146.
  • Native token — it's S, not FTM. Anything displaying "FTM" or assuming the old symbol needs updating (the migration is 1:1, but the ticker and identity changed).
  • Endpoints and explorers — Fantom RPC URLs and FTMScan point at the old network; Sonic has its own endpoints and explorer.

If you're porting a Fantom dApp, treat it as deploying to a new chain, not flipping a URL: new chain ID, new native symbol, new endpoints. Once those are right, your Solidity and tooling carry over unchanged.

Sub-second finality: it's an L1, so confirm once

Sonic isn't a rollup — it's a Layer 1 with BFT-style consensus and sub-second (~1s) finality. That means a confirmed block is final: no sequencer, no optimistic challenge window, no reorgs to defend against. Practically:

  • Skip the reorg machinery. The whole class of reorg-handling patterns collapses to "confirm once" — you don't need deep confirmation counts or block-hash reconciliation the way you do on probabilistic chains.
  • No two-tier finality. Unlike the optimistic L2s we've covered (Blast, Metis, Manta), there's no fast-soft / slow-hard split and no ~7-day withdrawal window — see soft vs. hard finality for the contrast. On Sonic, final is final in about a second.
  • Stream, don't poll. At ~1s blocks, use WebSocket subscriptions (newHeads, logs) rather than tight polling.

This puts Sonic in the same family as other fast-finality EVM L1s we've spotlighted — Kaia, Sei, and Flare — where instant BFT finality is the defining developer comfort.

FeeM: fees flow back to builders

Sonic's headline incentive is FeeM — up to 90% of the gas fees generated by interactions with a dApp are returned to that dApp's developers. It's conceptually similar to Fraxtal's Flox (rewarding builders for the gas their users spend), but Sonic's version is a direct, high-percentage fee rebate to the contract's owner rather than a points system.

From the RPC's perspective, FeeM is a protocol/accounting layer — it doesn't change how you call the chain. You deploy and interact with eth_sendRawTransaction / eth_call exactly as normal; the fee return is handled by the network based on the gas your dApp's transactions consume. It's a reason to build on Sonic, not an API you invoke (registration/claiming specifics live in Sonic's own docs).

What carries over unchanged

Aside from the chain ID/token change and FeeM, treat Sonic as a standard EVM chain:

  • eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally.
  • Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
  • S is the 18-decimal gas token; fees follow standard EVM gas mechanics (gas estimation basics); WebSocket subscriptions work.

The short version

Sonic (chain ID 146) is the high-performance L1 successor to Fantom Opera — a custom EVM execution engine with sub-second (~1s) BFT finality (an L1, so confirm once: no sequencer, no challenge window, no reorgs) and FeeM, which returns up to 90% of a dApp's gas fees to its developers. It's standard EVM (viem/ethers/foundry unchanged), but if you're coming from Fantom the migration traps are the essentials: chain ID is 146, not 250, and the native token is S, not FTM — reuse the old values and your signed transactions won't be valid. Get the chain ID and token right, lean on the fast finality, and build it like any EVM chain.

Building high-frequency DeFi, GameFi, or FeeM-incentivized dApps on Sonic? A flat-rate Sonic RPC endpoint gives you chain 146 over HTTP and WebSocket alongside 75+ other chains under one key. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/sonic?key=YOUR_API_KEY
Enter fullscreen mode Exit fullscreen mode

Originally published on the SwiftNodes blog. SwiftNodes provides flat-rate multi-chain RPC endpoints — HTTP + WebSocket, 75+ chains, no per-request metering. Grab a free key.

Top comments (0)