Shibarium RPC: A Developer's Guide (Chain ID 109)
Shibarium is the Shiba Inu ecosystem's own chain, live since August 2023. If you have built on Polygon PoS, you already know most of it: Shibarium runs the same two-layer design, with Bor producing blocks and executing the EVM, and Heimdall validators writing checkpoints to Ethereum. That inheritance explains almost every quirk you will hit over RPC, including a native token that is also a contract and a safe block tag that doesn't answer.
This guide covers what we measured through our Shibarium endpoint on 2026-09-28.
The essentials
| Shibarium mainnet | |
|---|---|
| Chain ID | 109 (0x6d) |
| Gas token | BONE, 18 decimals |
| First block | 2023-08-05 |
| Block time | about 7 s (6.97 s averaged over the last 10,000 blocks) |
| Gas limit | 20,000,000 per block |
eth_gasPrice |
0.40 gwei (in BONE) |
finalized head |
13 to 17 blocks (65 to 85 s) behind latest |
safe head |
returned an error on every attempt |
eth_getLogs range |
a 1,000,000-block range was accepted |
| Historical state | full archive, back to block 1 |
| Tracing | debug_traceBlockByNumber yes; trace_* no |
It is EVM-compatible: Foundry, Hardhat, viem and ethers work with the chain ID set to 109. The differences are in what Bor adds on top.
BONE is gas, and also a contract
Fees are paid in BONE, the native token. As on Polygon PoS, the native token is also exposed as an ERC-20-style contract at a fixed system address:
cast call 0x0000000000000000000000000000000000001010 "symbol()(string)" \
--rpc-url "https://rpc.swiftnodes.io/rpc/shibarium?key=YOUR_API_KEY"
# "BONE"
The contract at 0x…1010 returns name "Bone Token", symbol "BONE" and 18 decimals. Two practical consequences:
- A wallet's BONE balance is
eth_getBalance.balanceOfon0x…1010returns the same number (we compared them), because the contract mirrors native balances rather than holding separate ones. An indexer that adds the two together, or treats0x…1010as just another ERC-20, will double-count. - Native transfers emit logs from
0x…1010. A plain BONE transfer we checked produced two logs from that address:LogTransfer(topic0xe6497e3e…) for the value andLogFeeTransfer(topic0x4dfe1bbb…) for the gas fee. Filtereth_getLogsonLogTransferand you can follow native BONE movements without traces. That is by design on Bor chains.
Don't confuse the gas token with the Ethereum-side tokens. SHIB, LEASH and BONE on Ethereum are ordinary ERC-20s; on Shibarium, only BONE is native.
Finality: use finalized, not safe
Bor finalizes blocks through milestones agreed by Heimdall validators. In our samples, finalized trailed the newest block by 13 to 17 blocks, a bit over a minute. That is the tag to wait for before you treat a deposit as settled:
import { createPublicClient, http, defineChain } from "viem";
const shibarium = defineChain({
id: 109,
name: "Shibarium",
nativeCurrency: { name: "Bone", symbol: "BONE", decimals: 18 },
rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/shibarium?key=YOUR_API_KEY"] } },
});
const client = createPublicClient({ chain: shibarium, transport: http() });
const finalized = await client.getBlock({ blockTag: "finalized" });
The safe tag is a different story: every request for it failed through our endpoint. Code written for Ethereum or OP Stack chains often asks for safe as a middle ground; on Shibarium, drop straight to finalized. The general model behind these tags is in L2 finality: soft vs hard.
Finality on Shibarium is not the same as settlement on Ethereum. Heimdall checkpoints batches of blocks to Ethereum, and bridge withdrawals wait for them: the Shib team put bridge withdrawals at about 45 minutes after a May 2024 upgrade (Shib Daily), down from up to seven days for BONE.
Logs, history and tracing
Three things are easier on Shibarium than on most chains:
eth_getLogsover big ranges. Our endpoint accepted a single address-filtered query over 1,000,000 blocks, about 80 days of chain. That still isn't a reason to skip pagination: a busy contract over that range can return more logs than you want in one response. The trade-offs are in eth_getLogs range caps.- Full history.
eth_getBalanceanswered at 128, 10,000 and 1,000,000 blocks back, and at block 1, so historical state queries work without a separate archive endpoint. See full node vs archive node for what that buys you. debug_*tracing.debug_traceBlockByNumberwithcallTracerworks.
One gap: the Parity-style trace_* methods (trace_block, trace_filter) are not available. Tools that depend on trace_filter for internal transactions need to switch to debug_traceTransaction with callTracer, one transaction at a time. What that costs is covered in the real cost of debug_traceTransaction.
Bor-specific methods are there as well. bor_getAuthor returns a block's producer, and bor_getCurrentValidators returned three validators for the current span when we checked. That is a small active producer set, worth knowing if your application's security assumptions depend on the chain's decentralisation.
Security history you should know
In September 2025 an attacker used a large BONE stake to push three fraudulent checkpoints into the Ethereum contracts that secure the Shibarium bridge, and drained about 224.57 ETH and 92.6 billion SHIB, around $2.4 million at the time. Heimdall halted the chain when its state no longer matched the checkpoints on Ethereum, and the network was later restored with new safeguards, including blacklisting on the Plasma bridge (MEXC News, TradingView).
For RPC users, the lesson is practical: a chain can halt. A health check that only asks whether the RPC answers will not notice: a halted chain's endpoints keep answering, with the same block. Compare the latest block's timestamp with the clock instead. At a 7-second block time, a head that hasn't moved in a minute is worth an alert.
If you're coming from Polygon PoS
Most of what you know transfers directly: the 0x…1010 native-token contract, bor_* methods, milestone finality and checkpoint-based withdrawals all work the same way. The differences are the gas token (BONE, not POL), the chain ID, a slower block time than Polygon's 2 seconds, and a much smaller validator set. Our Polygon RPC guide covers the shared architecture from the Polygon side.
The short version
- Chain ID 109, BONE for gas, Bor and Heimdall under the hood.
- Native BONE is also a contract at
0x…1010: useeth_getBalancefor balances, and expect native-transfer logs from that address. - Use
finalized(about a minute behind);safedoesn't answer. - Wide
eth_getLogsranges, full archive,debug_*tracing; notrace_*. - Watch block timestamps, not just block numbers.
Shibarium HTTP and WebSocket endpoints, with the live block height, are on our Shibarium RPC page. The same key covers 83 chains, and SwiftNodes has a free tier to try it.
John Sullivan covers RPC infrastructure, node operations, and multi-chain development at SwiftNodes — what it actually takes to keep endpoints fast, fresh, and reliable across EVM and non-EVM networks.
Related posts
- Ronin RPC After the Move to Ethereum L2: A Developer's Guide (Chain ID 2020)
Ronin became an OP Stack layer 2 in May 2026. Measured: 2 s blocks, a fixed 20 gwei base fee, a 200-block getLogs cap, ~23 min to finalized, and no pre-migration history.
- Kava RPC: A Developer's Guide (Chain ID 2222)
Kava runs an EVM beside a Cosmos SDK chain. Measured: 5.7 s blocks, instant finality, a 10,000-block getLogs cap, ~100 blocks of state, archive routing.
- Aurora RPC: A Developer's Guide (EVM on NEAR)
Aurora is an EVM running as a contract on NEAR. Measured: 0.6 s blocks, instant finality, a 2^53 gas limit, zero cumulativeGasUsed, NEAR receipt hashes.