Sonic RPC Guide: Endpoints, Methods, Fast-Block Infrastructure (2026)

Sonic is a high-performance EVM-compatible layer-1 blockchain targeting 10,000 transactions per second with sub-second finality. It is the upgraded successor to Fantom Opera, rebuilt from scratch with a new execution engine, new native token (S), a DeFi ecosystem that migrated from the original Fantom network. At 1-second block times, Sonic creates RPC infrastructure requirements that differ significantly from slower EVM chains, and understanding those differences is essential for building production applications.

This guide covers public Sonic RPC endpoints, multi-library connection examples, fast-block polling strategy, WebSocket subscriptions, the most common production issues developers encounter on Sonic.

For BoltRPC endpoint setup and MetaMask configuration, see the Sonic chain page.

What Makes Sonic Different from Other EVM Chains

Sonic is not simply a fork of another EVM chain with faster block times. The Fantom Foundation built a new EVM execution engine to achieve its performance targets. Key architectural decisions that affect your RPC usage:

1-second block times amplify RPC demand. An application that polls eth_blockNumber every block on Ethereum makes 5 calls per minute. The same application on Sonic makes 60 calls per minute. Any polling-based design that works on slower chains will hit rate limits or generate unexpected costs on Sonic if you do not account for this multiplier. WebSocket subscriptions to newHeads or newPendingTransactions eliminate this overhead.

Sub-second finality changes confirmation patterns. On Ethereum you wait 12-15 minutes for probabilistic finality or use finality tags (finalized, safe). On Sonic, transactions reach economic finality within a single block. Your confirmation logic can be simpler: one block confirmation is generally sufficient for most DeFi operations.

Fantom DeFi ecosystem is now Sonic. Protocols you may know from Fantom, including Beethoven X, SpookySwap, others, have migrated to Sonic. These are production protocols with real liquidity, not testnet deployments. Any application interacting with these protocols needs reliable production RPC.

FTM to S migration context. Fantom’s native token (FTM) migrated to S (Sonic). Chain ID 146 is the Sonic Mainnet identifier. If your application previously connected to Fantom Opera (Chain ID 250), you need a new endpoint with Chain ID 146.

Public Sonic RPC Endpoints

Use public endpoints for development and testing. For production applications, use a dedicated provider with guaranteed availability.

Provider	HTTP Endpoint	WSS Endpoint	Notes
Sonic Labs (official)	https://rpc.soniclabs.com	wss://ws.soniclabs.com	Official, rate limited
dRPC	https://sonic.drpc.org	wss://sonic.drpc.org	Public tier available
1RPC	https://1rpc.io/sonic	none	Privacy-focused
Ankr	https://rpc.ankr.com/sonic_mainnet	none	Public tier

Chain ID: 146 Native token: S Block explorer: https://sonicscan.org

For production, use BoltRPC: https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY

Connecting to Sonic

ethers.js

import { ethers } from "ethers";

// HTTP provider for single calls
const provider = new ethers.JsonRpcProvider(
  "https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY"
);

// WebSocket provider for subscriptions, recommended for Sonic's 1-second blocks
const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/sonic?auth=YOUR_KEY"
);

// Subscribe to new blocks (fires every ~1 second on Sonic)
wsProvider.on("block", (blockNumber) => {
  console.log("New Sonic block:", blockNumber);
});

// Read latest block
const blockNumber = await provider.getBlockNumber();
console.log("Current Sonic block:", blockNumber);

// Check finality: on Sonic, one block confirmation is generally sufficient
const tx = await provider.getTransactionReceipt(txHash);
if (tx && tx.status === 1) {
  console.log("Transaction confirmed on Sonic (block:", tx.blockNumber, ")");
}

Web3.py

from web3 import Web3

# HTTP connection
w3 = Web3(Web3.HTTPProvider(
    "https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY"
))

print("Connected:", w3.is_connected())
print("Chain ID:", w3.eth.chain_id)  # 146
print("Latest block:", w3.eth.block_number)

# Read gas price (Sonic fees are low by design)
gas_price = w3.eth.gas_price
print("Gas price (gwei):", Web3.from_wei(gas_price, "gwei"))

# Check balance
address = "0xYourAddressHere"
balance = w3.eth.get_balance(address)
print("Balance (S):", Web3.from_wei(balance, "ether"))

WebSocket subscription (Node.js)

import { ethers } from "ethers";

const wsProvider = new ethers.WebSocketProvider(
  "wss://eu.endpoints.matrixed.link/ws/sonic?auth=YOUR_KEY"
);

// Subscribe to contract events on Sonic
const contractAddress = "0xYourContractAddress";
const abi = ["event Transfer(address indexed from, address indexed to, uint256 value)"];
const contract = new ethers.Contract(contractAddress, abi, wsProvider);

contract.on("Transfer", (from, to, value, event) => {
  console.log("Transfer on Sonic:", {
    from,
    to,
    value: ethers.formatEther(value),
    block: event.log.blockNumber
  });
});

// Auto-reconnect pattern for 1-second block chains
wsProvider.on("error", async (error) => {
  console.error("WS error, reconnecting:", error.message);
  await wsProvider.destroy();
  // Reinitialize provider here
});

curl

# Check Sonic block number
curl https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

# Get gas price on Sonic
curl https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":1}'

# Call a contract on Sonic
curl https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "jsonrpc": "2.0",
    "method": "eth_call",
    "params": [{
      "to": "0xContractAddress",
      "data": "0x70a082310000000000000000000000000YourAddress"
    }, "latest"],
    "id": 1
  }'

Example Sonic RPC Methods

These are standard EVM JSON-RPC methods as implemented on Sonic. Code examples are for reference. Verify against the official Sonic documentation before production use.

Method	Purpose	Sonic Notes
`eth_blockNumber`	Get current block height	Returns a new value every ~1 second
`eth_getBlockByNumber`	Fetch block data	Use with `"latest"` for most recent
`eth_call`	Read contract state	No gas spent
`eth_estimateGas`	Estimate transaction cost	Low fees on Sonic
`eth_sendRawTransaction`	Broadcast signed transaction	Fast inclusion at 1-second blocks
`eth_getTransactionReceipt`	Confirm transaction	Available within 1 block
`eth_getLogs`	Fetch contract events by filter	Standard filter params apply
`eth_subscribe`	Subscribe via WebSocket	`newHeads`, `logs`, `newPendingTransactions`

Fast-Block Polling Strategy

At 1-second block times, the choice between HTTP polling and WebSocket subscriptions has a bigger performance impact than on slower chains.

HTTP polling every block: Your application makes one call per second minimum for block monitoring alone. On a typical DeFi bot that also calls eth_call to read prices and eth_getLogs to check events, you may be at 5-10 calls per second per contract. At scale, this saturates shared public endpoints quickly. Use a dedicated provider and design with rate budgets in mind.

WebSocket subscriptions: Subscribe once to newHeads and receive every block header as it arrives without polling. For event monitoring, subscribe to log filters using eth_subscribe with logs and your contract address. This reduces call count to one initial subscription request plus whatever direct calls you need.

// Subscribe to new block headers via WebSocket
wsProvider.on("block", async (blockNumber) => {
  // Only make additional calls when you actually have a new block
  const block = await wsProvider.getBlock(blockNumber);
  console.log("Block time:", block.timestamp, "Txs:", block.transactions.length);
});

// Subscribe to specific contract logs
const filter = {
  address: "0xYourDeFiContract",
  topics: [ethers.id("Swap(address,address,int256,int256,uint160,uint128,int24)")]
};

wsProvider.on(filter, (log) => {
  console.log("Swap event on Sonic:", log.transactionHash);
});

Batch calls for snapshot reads. If you need multiple values at the same block, batch them into a single call rather than sequential HTTP requests. Many JSON-RPC providers support JSON-RPC batching (send an array of requests in one HTTP call). This collapses your per-block overhead significantly.

Production Issues on Sonic

Rate limits on public endpoints. At 1-second blocks, you will exhaust public endpoint rate limits faster than on Ethereum. The official Sonic Labs public RPC has undocumented limits that can reject requests during high-traffic periods. Build retry logic with exponential backoff for any production application.

async function callWithRetry(provider, method, params, maxRetries = 3) {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await provider.send(method, params);
    } catch (err) {
      if (attempt === maxRetries - 1) throw err;
      const delay = Math.pow(2, attempt) * 100;
      await new Promise(r => setTimeout(r, delay));
    }
  }
}

WebSocket disconnection at high block frequency. At 1-second blocks, a persistent WebSocket connection receives events far more frequently than on Ethereum. Some client libraries have buffering issues under high event frequency. Monitor your WebSocket connection health and implement automatic reconnection. Libraries like ethers.js v6 include built-in reconnect behavior for WebSocketProvider with staticNetwork options.

Log range limits. eth_getLogs queries on Sonic use block number ranges. Public nodes typically cap ranges at 1,000-2,000 blocks. Because Sonic produces far more blocks per calendar hour than Ethereum (3,600 blocks per hour vs 300), a 1,000-block limit covers only about 17 minutes of history, not 3.5 hours as on Ethereum. Adjust your log scanning batch sizes accordingly.

FTM/S token confusion. Applications that previously supported Fantom Opera (chain ID 250, native token FTM) need explicit updates to use chain ID 146 and native token S. Display currency labels and decimal handling for S are identical to ETH (18 decimals), but never pass a Fantom endpoint URL to a Sonic application.

Sonic for DeFi Bots and Yield Automation

Sonic’s design specifically targets DeFi use cases. At 1-second blocks and low fees, the infrastructure model for trading bots is different from Ethereum:

On Ethereum: A bot monitors every 12-second block. Mempool monitoring with eth_subscribe to newPendingTransactions is useful for front-run detection. Gas optimization is critical because high fees on Ethereum make each transaction significant.

On Sonic: Blocks arrive every second. Mempool window is narrow. Priority shifts from gas optimization to execution speed and reliable endpoint availability. A bot that misses a block because its RPC endpoint is slow or rate-limited loses more opportunities per unit of time than on Ethereum.

For yield automation and auto-compounding on Sonic, the dominant RPC pattern is:

eth_call to read APY conditions across multiple protocols (1 call per protocol per check)
eth_estimateGas before submitting harvest transactions
eth_sendRawTransaction for execution
eth_getTransactionReceipt to confirm

At 1-second blocks, this cycle can run continuously at a rate that would be impractical on Ethereum. Flat-rate RPC pricing is important for this pattern because per-request billing compounds at Sonic’s frequency.

Choosing an RPC Provider for Sonic

Consideration	What to Look For
Rate limits	Generous burst limits: 1-second blocks hit limits 12x faster than Ethereum
WebSocket support	Required for efficient production on fast-block chains
Latency	Low latency matters more at 1-second blocks than at 12-second blocks
Pricing model	Flat rate preferred for high-frequency polling workloads
Reliability	SaaS shared infrastructure can bottleneck during Sonic DeFi activity spikes

For dedicated Sonic RPC infrastructure with flat pricing: BoltRPC Sonic endpoint.

Sonic RPC FAQ

What is the Sonic RPC endpoint? The public Sonic Mainnet RPC is https://rpc.soniclabs.com. For production use, BoltRPC provides a dedicated endpoint at https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY. Chain ID is 146.

Is Sonic the same as Fantom? Sonic is the successor network to Fantom Opera. The Fantom Foundation rebuilt the execution engine and launched Sonic (chain ID 146) as the upgraded replacement for Fantom Opera (chain ID 250). The DeFi ecosystem, including major protocols and liquidity, migrated from Fantom to Sonic. The native token changed from FTM to S.

Why use WebSocket instead of HTTP on Sonic? At 1-second block times, polling every block via HTTP generates 60 calls per minute for block number checks alone. WebSocket subscriptions deliver new block headers as they arrive without polling, eliminating this overhead. For event-driven applications on Sonic, WebSocket is strongly preferred over HTTP polling.

What is the Sonic chain ID? Sonic Mainnet chain ID is 146. This is different from Fantom Opera (chain ID 250). Always verify chain ID when connecting wallets or configuring applications.

How does Sonic finality work? Sonic achieves economic finality within one block (approximately 1 second). Unlike Ethereum, where you typically wait for multiple block confirmations or use finality tags like finalized, a single confirmed block on Sonic is generally sufficient for DeFi operations.

What are public Sonic RPC endpoints for testing? Public endpoints: https://rpc.soniclabs.com (Sonic Labs official), https://sonic.drpc.org (dRPC public). Both are rate-limited and not recommended for production workloads.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What is the Sonic RPC endpoint?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "The public Sonic Mainnet RPC is https://rpc.soniclabs.com. For production use, BoltRPC provides a dedicated endpoint at https://eu.endpoints.matrixed.link/rpc/sonic?auth=YOUR_KEY. Chain ID is 146."
      }
    },
    {
      "@type": "Question",
      "name": "Is Sonic the same as Fantom?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sonic is the successor to Fantom Opera. The Fantom Foundation rebuilt the execution engine and launched Sonic (chain ID 146) as the upgraded replacement for Fantom Opera (chain ID 250). The DeFi ecosystem migrated from Fantom to Sonic and the native token changed from FTM to S."
      }
    },
    {
      "@type": "Question",
      "name": "Why use WebSocket instead of HTTP on Sonic?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "At 1-second block times, polling every block via HTTP generates 60 calls per minute for block checks alone. WebSocket subscriptions deliver new block headers without polling, eliminating this overhead. For event-driven applications on Sonic, WebSocket is strongly preferred."
      }
    },
    {
      "@type": "Question",
      "name": "What is the Sonic chain ID?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sonic Mainnet chain ID is 146. This is different from Fantom Opera which had chain ID 250. Always verify chain ID when connecting wallets or configuring applications."
      }
    },
    {
      "@type": "Question",
      "name": "How does Sonic finality work?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Sonic achieves economic finality within one block (approximately 1 second). A single confirmed block on Sonic is generally sufficient for DeFi operations, unlike Ethereum where you wait for multiple confirmations."
      }
    }
  ]
}
</script>

Sonic RPC Guide: Endpoints, Methods, Code Examples 2026