Blast RPC: The L2 Where Balances Grow on Their Own (and Why That Breaks Naive Indexers)

On almost every chain, an account's balance only changes when a transaction moves it — so indexers, accounting systems, and AMMs all lean on one assumption: balance changes come with a Transfer event. Blast breaks that assumption on purpose. It's an Ethereum Layer 2 (chain ID 81457) whose defining feature is native yield: bridged ETH earns staking yield and the USDB stablecoin earns T-bill yield, and both rebase directly into account balances with no action and no transfer. For users that's magic; for developers it's a design constraint you have to plan around. Blast is standard EVM underneath (ordinary eth_*, viem/ethers/foundry unchanged), but the yield primitive is the reason to read carefully before you build. Here's the map.

The essentials

Blast mainnet (live since February 29, 2024) is chain ID 81457, an optimistic rollup with:

• ETH as the gas token (18 decimals) — but auto-rebasing ETH, whose balance grows over time.
• ~2-second blocks — fast soft confirmation.
• Optimistic rollup finality with a notably long ~14-day challenge window for L1 withdrawals (longer than the typical 7-day OP Stack window — see finality below).
• Native yield on bridged ETH and on USDB (the yield-bearing stablecoin).
• EVM-compatible — Solidity, ABIs, and standard tooling deploy without changes.

Connecting is standard EVM:

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

const blast = defineChain({
  id: 81457,
  name: "Blast",
  nativeCurrency: { name: "Ether", symbol: "ETH", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/blast?key=YOUR_API_KEY"] } },
});

const client = createPublicClient({ chain: blast, transport: http() });
await client.getBlockNumber();   // just works

The headline: balances that grow by themselves

Blast's native yield means two things move without anyone sending a transaction:

• Bridged ETH earns staking yield — an account's ETH balance rebases upward over time.
• USDB earns T-bill yield — the stablecoin's balance rebases the same way.

There's no mint, no Transfer, no user action. The protocol simply grows balances. For a wallet or a "your money is working" product, that's the entire pitch. For anyone reading the chain programmatically, it's the thing to design around — because it violates the invariant most tooling assumes.

Gotcha #1: you can't derive balances from Transfer events

The standard way to track ERC-20 holdings — sum every Transfer in and out — silently under-counts on Blast, because rebasing yield increases balances without emitting a transfer. The same applies to native ETH: an address's ETH grows without any transaction touching it.

So on Blast, for anything yield-bearing:

• Snapshot balances, don't reconstruct them from events. Query eth_getBalance (for ETH) and balanceOf (for USDB / rebasing tokens) at the block you care about, rather than assuming starting_balance + transfers_in − transfers_out.
• If you maintain a running ledger, re-sync balances periodically against on-chain reads to absorb accrued yield, or your numbers drift.
• Event-driven indexing still works for movements — you just can't treat the absence of events as "balance unchanged." (The general event-indexing mechanics still apply; see eth_getLogs range caps and subscribing to logs.)

This is the single most common way teams get Blast accounting wrong: they build a normal transfer-summing indexer and wonder why balances don't match the explorer.

Gotcha #2: yield modes — contracts default to "Void"

Because auto-rebasing balances break a lot of contract logic (an AMM whose reserves silently change would mis-price; a vault tracking shares against a fixed balance would drift), Blast doesn't force yield on smart contracts. Instead, every account has a yield mode, configured through Blast's yield system contract:

• Automatic — balance rebases upward (the default for EOAs / user wallets).
• Void — no yield; balance stays put. This is the default for smart contracts, precisely so existing DeFi logic keeps working.
• Claimable — yield accrues separately and is claimed explicitly, leaving the principal balance stable.

The practical rule when you deploy on Blast: if your contract holds ETH or USDB and you want it to earn, you must opt in — and for most contracts the safe choice is Claimable, so your core balance stays invariant while yield accumulates on the side. Turning on Automatic for a contract that assumes a fixed balance is a foot-gun. This configuration is a Blast-specific step with no equivalent on a vanilla EVM chain, and it's the thing to get right before mainnet.

Finality: fast soft, but a long ~14-day withdrawal window

As an optimistic rollup, Blast gives fast soft confirmation (~2s) at the sequencer, but true L1 settlement — and any withdrawal back to Ethereum — waits out an extended ~14-day challenge window, roughly double the usual 7-day OP Stack period. If your app moves value L2→L1, design for that delay explicitly; the soft vs. hard finality breakdown covers the model, and it's the same optimistic-rollup shape as OP-aligned chains like Unichain — just with a longer window.

For indexing, treat the L2 head like any optimistic rollup: reasonably reliable but reorg-capable at the tip, so key your data on block hash and reconcile — see handling chain reorgs.

What carries over unchanged

Aside from native yield and yield modes, treat Blast 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.
• ETH is the 18-decimal gas token; fees follow EIP-1559 with an L1 data-fee component like any rollup (gas estimation basics); transaction receipts read the same way; WebSocket subscriptions work, and at ~2s blocks streaming beats tight polling.

The short version

Blast (chain ID 81457) is an optimistic-rollup L2 whose defining feature is native yield — bridged ETH and USDB rebase into balances automatically, with no transaction and no Transfer event. That breaks two common assumptions: (1) you can't reconstruct balances by summing transfers, so snapshot eth_getBalance / balanceOf at a block and re-sync for accrued yield; and (2) contracts have a yield mode (Automatic / Void / Claimable) — they default to Void, and if you want yield the safe pattern is usually Claimable so your core balance stays invariant. Everything else is standard EVM (ETH gas, viem/ethers/foundry unchanged), with fast ~2s soft confirmation but a long ~14-day L1 withdrawal window. Build it like an optimistic rollup; just respect the rebasing.

Building yield-bearing DeFi, USDB payment flows, or anything indexing Blast balances? A flat-rate Blast RPC endpoint gives you chain 81457 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/blast?key=YOUR_API_KEY

---

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.