Rootstock RPC: An EVM Chain Where Gas Is Bitcoin

Rootstock (RSK) is the oldest attempt to give Bitcoin smart contracts — a live EVM sidechain since January 2018, secured by Bitcoin's own hashpower through merge-mining. For a developer it's the best of both worlds and a couple of sharp edges: your Ethereum tooling connects in one line because RSK runs the EVM, but two things behave differently enough to break naive code — gas is Bitcoin, and addresses use a different checksum. Get those two right and everything else is just Solidity. Here's the map for chain ID 30.

The essentials

Rootstock mainnet is chain ID 30, an EVM-compatible sidechain with:

• RBTC as the gas token, pegged 1:1 to BTC via the PowPeg two-way peg. There's no separate inflationary token — you pay fees in Bitcoin, and RBTC shares Bitcoin's 21M cap. RBTC uses 18 decimals like ETH (so amounts are in wei-style units), but the value is BTC.
• ~30-second blocks — much slower than Ethereum's ~12s or an L2's ~2s. Fees are tiny, but your polling cadence and confirmation logic should assume half-minute blocks.
• Merge-mining security — Bitcoin miners secure RSK with the same proof-of-work, no extra energy. That makes it a PoW sidechain, not a rollup: there's no sequencer and no L1 challenge window; finality is probabilistic, like Bitcoin (wait for confirmations), not a fast-soft/slow-hard rollup model.

Because it's EVM, connecting is boringly standard:

import { createPublicClient, http } from "viem";
import { rootstock } from "viem/chains";   // chain ID 30

const client = createPublicClient({
  chain: rootstock,
  transport: http("https://rpc.swiftnodes.io/rpc/rootstock?key=YOUR_API_KEY"),
});
await client.getBlockNumber();   // just works

Gotcha #1: gas is Bitcoin, and the min gas price lives on-chain

On Ethereum you reason about gas in gwei and lean on EIP-1559 base-fee mechanics. Rootstock is pre-1559 in spirit: it uses a legacy gas-price model with a minimum gas price that miners set on-chain (it appears as minimumGasPrice in the block header). eth_gasPrice returns a value denominated in RBTC — i.e., in Bitcoin — so the numbers look absurdly small compared to Ethereum. The upside: transactions cost fractions of a cent. The trap: don't hard-code Ethereum-style gwei assumptions or an EIP-1559 maxFeePerGas path expecting base-fee behavior — read the current gas price and the block's minimum. Our gas-estimation guide covers eth_estimateGas; on RSK, pair it with the on-chain minimum rather than a 1559 fee market.

Gotcha #2: the EIP-1191 checksum — why your address looks "wrong"

This is the one that quietly breaks integrations. Ethereum addresses use the EIP-55 mixed-case checksum (capitalization derived from the address hash). Rootstock uses EIP-1191, which folds the chain ID into the checksum. The consequence: the same 20-byte address has different capitalization on Rootstock (chain 30) than on Ethereum (chain 1).

That means:

• A wallet or library that validates addresses with strict EIP-55 may reject a correctly-checksummed RSK address as "invalid."
• An RSK address checksummed for Ethereum will fail RSK's own EIP-1191 validation.
• The underlying bytes are identical — it's purely a display/validation convention — but strict validators disagree.

The safe pattern for cross-chain code: normalize to lowercase when comparing, storing, or transmitting addresses, and only apply a checksum for display using the chain-aware (EIP-1191) routine when you're specifically targeting RSK. Don't let an EIP-55-only checksum validator gate your RSK transactions. This single mismatch is behind most "my address is valid on Etherscan but the RSK tool rejects it" support tickets.

What carries over unchanged

Past those two, RSK is standard EVM:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_sendRawTransaction, eth_subscribe all behave normally.
• Solidity contracts, ABIs, events, and the whole viem/ethers/hardhat/foundry toolchain deploy and run as-is (RSK's RVM tracks EVM opcodes).
• Reading logs and receipts works like any EVM chain (see reading receipts).

Finality: think Bitcoin, not rollup

Because RSK is merge-mined, its security rides on the share of Bitcoin hashpower that opts into merge-mining — strong, but a fraction of total BTC hashrate. Practically, treat finality the way you treat Bitcoin: wait for confirmations before considering a transaction settled, and build your indexer to tolerate short reorgs at the tip. The reorg-handling patterns — key on (txHash, logIndex), confirm against a depth buffer rather than trusting the head — apply directly. This is the opposite of the instant BFT finality on a Cosmos chain and different again from an optimistic rollup's challenge window; RSK is genuinely PoW.

The Bitcoin connection

RBTC enters and exits through the PowPeg, Rootstock's two-way peg: lock BTC on Bitcoin, receive RBTC on Rootstock, and reverse to redeem. That's what lets Bitcoin holders use BTC-denominated DeFi with full Solidity programmability — the reason RSK exists. If you already run Bitcoin-adjacent infrastructure (we've covered the UTXO side in the Litecoin/Blockbook spotlight), Rootstock is the smart-contract layer that pairs with it: BTC value, EVM tooling.

The short version

Rootstock (chain ID 30) is a Bitcoin-merge-mined EVM sidechain: RBTC gas pegged 1:1 to BTC, ~30-second blocks, PoW probabilistic finality (wait for confirmations, tolerate tip reorgs — not a rollup). viem/ethers/hardhat all connect unchanged. The two things that break naive Ethereum code: gas is denominated in Bitcoin with an on-chain minimum gas price (don't assume gwei/EIP-1559), and addresses use the EIP-1191 chain-aware checksum, so normalize to lowercase for comparison and only checksum for RSK-specific display.

Building BTC-denominated DeFi or bridging Bitcoin into EVM apps? A flat-rate Rootstock RPC endpoint gives you chain 30 alongside dozens of others under one key. Grab a free key and point your tooling at:

https://rpc.swiftnodes.io/rpc/rootstock?key=YOUR_API_KEY