Shibarium RPC: A Developer's Guide (Chain ID 109)

By John Sullivan · September 28, 2026 · 5 min read · #shibarium #shibarium rpc #bone #polygon pos #developer guide

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. balanceOf on 0x…1010 returns 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 treats 0x…1010 as 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 (topic 0xe6497e3e…) for the value and LogFeeTransfer (topic 0x4dfe1bbb…) for the gas fee. Filter eth_getLogs on LogTransfer and 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_getLogs over 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_getBalance answered 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_traceBlockByNumber with callTracer works.

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: use eth_getBalance for balances, and expect native-transfer logs from that address.
  • Use finalized (about a minute behind); safe doesn't answer.
  • Wide eth_getLogs ranges, full archive, debug_* tracing; no trace_*.
  • 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.

J
John Sullivan
Infrastructure Writer, SwiftNodes

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

Try SwiftNodes free — multi-chain RPC across 83 networks, flat-rate pricing, pay by card or crypto, no KYC. Get an API key in 30 seconds →