DEV Community: SwiftNodes

What Is EIP-7702? EOAs That Act Like Smart Accounts

SwiftNodes — Thu, 20 Aug 2026 06:52:12 +0000

Run this against Ethereum mainnet right now:

curl -X POST "https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getCode",
       "params":["0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045","latest"]}'

That's vitalik.eth — an externally owned account, a plain wallet address. For ten years the correct answer was 0x: EOAs have no code, contracts do. Today it returns something like:

0xef01005a7fc11397e9a8ad41bf10bf13f22b0a63f96f6d

Twenty-three bytes of code on an EOA. That's EIP-7702, live on mainnet since the Pectra upgrade in May 2025, and it quietly breaks one of the oldest assumptions in Ethereum tooling. This post explains what it is, what those bytes mean, and what changes for you as a developer reading and writing over RPC.

The problem: EOAs are stuck, and ERC-4337 asked you to move

Externally owned accounts have exactly one capability: a secp256k1 key signs transactions. No batching (approve + swap is always two transactions), no gas sponsorship (a new user with zero ETH can't do anything), no session keys, no spending limits, no recovery if the key leaks. Every one of those features requires logic, and EOAs can't hold logic.

ERC-4337 account abstraction solved this by putting your account in a smart contract — but that means a new account at a new address. Your assets, your token approvals, your history, your ENS name all live at the old EOA. Migration friction is exactly why most users never made the jump.

EIP-7702 takes the opposite approach: keep your address, keep your key, and let the EOA borrow a contract's code.

How it works: the delegation designator

Pectra added a new transaction type, 0x04 (the set-code transaction). Alongside the usual fields, it carries an authorizationList: one or more tuples of {chainId, address, nonce, yParity, r, s}, each signed by an EOA's key. Each authorization says: "set my account's code to delegate to this contract address."

When the transaction is processed, the protocol writes a delegation designator into the EOA's code slot:

0xef0100 || <20-byte delegate address>

That's what the eth_getCode call above returned: the 0xef0100 prefix, then the delegate contract. (The 0xef prefix is reserved by EIP-3541 — no regular deployed contract can start with it, so a designator can never be confused with real bytecode.)

From that point on, any call or transaction sent to the EOA executes the delegate contract's code in the EOA's own context — its storage, its balance, its address. The EOA effectively becomes an instance of the delegate contract, while the original private key keeps working for normal transactions too.

A few mechanics worth knowing:

Delegation is persistent. It's not per-transaction. It stays until replaced by a new authorization or cleared by authorizing the zero address, which resets the account to a plain EOA.
chainId can be 0, which makes the authorization valid on every chain — convenient for wallets, but it means one signature can take effect on chains you weren't thinking about.
The authorization embeds the account's nonce, so it can't be replayed after the account moves on. If you self-sponsor (the delegating EOA also sends the transaction), sign the authorization with nonce + 1, because the transaction consumes the current nonce first — the classic off-by-one that ties back to nonce management.
Each authorization costs gas (25,000 for a fresh account), paid by the transaction sender — which can be someone other than the delegating EOA. That's how a wallet with zero ETH gets upgraded: a sponsor submits the type-4 transaction carrying the user's signed authorization.

What it unlocks

Once an EOA delegates to a well-designed smart-account implementation, it gets the ERC-4337 feature set without moving addresses: batch an approve and a swap into a single atomic call, let a dApp or paymaster sponsor gas, hand a game a session key with a spend limit, set up recovery. Major wallets shipped exactly this — MetaMask's smart-account upgrade is a 7702 delegation under the hood, which is why tens of millions of EOAs now return code.

7702 and ERC-4337 are complements, not competitors. A delegated EOA can point at 4337-compatible account code and then ride the whole 4337 stack — UserOperations, bundlers, paymasters. 7702 fixes the migration problem; 4337 provides the infrastructure.

	ERC-4337	EIP-7702	Native AA (zkSync, Starknet)
Protocol change	None (contracts + alt mempool)	New tx type `0x04` (Pectra)	Built into the chain
Your address	New contract address	Same EOA address	Contract account from day one
Key still works	n/a	Yes — key retains full control	Depends on account code
Where it works	Any EVM chain with bundlers	Ethereum + L2s that shipped it	That chain only

What changes when you're building over RPC

1. "No code = EOA" is dead. Any classifier, indexer, or security check that calls eth_getCode and treats a non-empty result as "this is a contract" now misfires on millions of wallets. Check for the designator:

import { createPublicClient, http } from "viem";
import { mainnet } from "viem/chains";

const client = createPublicClient({
  chain: mainnet,
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY"),
});

const code = await client.getCode({ address: "0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045" });

if (!code || code === "0x") {
  // plain EOA
} else if (code.startsWith("0xef0100")) {
  const delegate = `0x${code.slice(8)}`; // the contract this EOA delegates to
} else {
  // regular deployed contract
}

2. Wallets can be callers and callees. A delegated EOA emits events, receives calls, and shows internal-call behavior like a contract, while still originating ordinary transactions with its key. If your indexer keys behavior on "sender must be an EOA" or "recipient with code must be a contract," revisit both branches, and confirm outcomes from the receipt, not from account shape.

3. Type 0x04 shows up in your feeds. eth_getTransactionByHash and block bodies now include set-code transactions with an authorizationList field. If you decode raw transactions yourself (the eth_sendRawTransaction path), handle the new type rather than dropping it on the floor.

4. The security model is sharp-edged. The delegate contract controls the account completely — a signature over a malicious delegation is total compromise, which is why "sign this one message" phishing got more dangerous and why wallets only delegate to a shortlist of audited implementations. And the original key always retains full control: 7702 adds capabilities, it does not remove the key. Nothing here changes consensus or the mempool — it's account behavior, visible through perfectly ordinary eth_* calls.

The takeaway

EIP-7702 is the quiet one of the big upgrades: no new namespace, no new mempool to integrate, just a 23-byte designator that upgrades the humble EOA in place. If your code touches eth_getCode, transaction types, or any EOA-versus-contract logic, it's already affected — the one-curl check at the top of this post is the fastest way to see it live.

You can run that check — and everything else in this post — on any Ethereum RPC endpoint from SwiftNodes: flat-rate, HTTP and WebSocket, no KYC. The free tier takes about 30 seconds to set up.

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.

Getting Bitcoin Data: Core RPC vs Blockbook vs Hosted Address APIs

SwiftNodes — Wed, 19 Aug 2026 06:21:01 +0000

Developers coming to Bitcoin from Ethereum hit the same wall within an hour. On Ethereum, eth_getBalance(address) just works. On Bitcoin, you spin up a node, start calling JSON-RPC, and then try to answer "what's the balance of this address?" — and discover that Bitcoin Core simply can't tell you. There's no getbalanceofaddress. This isn't a missing feature; it's a consequence of how Bitcoin is built, and it shapes every decision about how you source Bitcoin data. This post covers the gap and the three ways providers fill it.

Why Core RPC can't answer address questions

Bitcoin is a UTXO chain: there's no global map of address → balance. The ledger is a pile of unspent transaction outputs, and an "address balance" is just the sum of the UTXOs currently locked to that address — something nobody maintains as an index unless they choose to build one.

Bitcoin Core's wallet is also node-centric: getbalance reports the balance of the wallet the node manages, not any address you ask about. Even with -txindex enabled — which lets you fetch any transaction by hash with getrawtransaction — there's still no way to ask "give me every transaction touching this address" or "list this address's UTXOs." Core indexes transactions, not addresses. (The same is true for Litecoin and Dogecoin, which are Bitcoin forks — see the Litecoin RPC guide for the UTXO-specific version of this.)

So the moment your app needs to show a user their balance, list their coins to build a transaction, or display an address's history, raw Core RPC leaves you stranded. You need an address index layered on top.

The three ways to get the data

1. Raw Bitcoin Core JSON-RPC

What it's genuinely great at: everything that isn't an address query.

curl -s -X POST "https://rpc.swiftnodes.io/rpc/btc?key=YOUR_API_KEY" \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"getblockchaininfo","params":[]}'
# → { "chain":"main", "blocks":963140, "pruned":false, ... }

Blocks, transactions, mempool inspection, fee estimation, and — critically — broadcasting signed transactions all live here. If you're building a node-adjacent service, Core RPC is the foundation. It just can't do addresses.

2. Blockbook (the Trezor address indexer)

Blockbook runs alongside bitcoind, reads the chain, and builds the address index Core lacks. It exposes a REST (and WebSocket) API for exactly the queries you were missing:

curl -s "https://rpc.swiftnodes.io/blockbook/btc/api/v2/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX?details=basic&key=YOUR_API_KEY"
# → { "address":"12c6DSiU...", "balance":"5135273240", "txs":231, ... }   (balance in satoshis)

That's a balance (in satoshis — ~51.35 BTC here), transaction count, and with other endpoints: UTXO lists, full transaction history, and xpub queries that derive and scan an entire HD wallet from an extended public key. Blockbook is what SwiftNodes runs for BTC, LTC, and DOGE, so the same /blockbook/<chain>/api/v2/... shape works across all three.

3. Esplora / electrs (the Electrum-family indexers)

Blockstream's Esplora (and the electrs server behind it) are the other common address-index layer. They solve the same problem with a different API shape — Esplora has its own REST conventions, and the Electrum protocol underpins most light wallets. If you're already in the Electrum ecosystem, this is the natural fit; the trade-off is a different API to learn than Blockbook's.

What each actually gives you

Capability	Core JSON-RPC	Blockbook	Esplora/electrs
Blocks, txs, mempool	✅	partial	partial
Broadcast a signed tx	✅	✅	✅
Fee estimation	✅	—	—
Address balance	❌	✅	✅
Address UTXOs	❌	✅	✅
Address tx history	❌	✅	✅
xpub / HD-wallet scan	❌	✅	✅ (varies)

The pattern is clear: you want Core RPC for the node operations and an address indexer for everything address-shaped. Neither replaces the other.

The provider gotcha

Here's where choosing a provider gets tricky. Most RPC providers are EVM-first — Bitcoin is an afterthought, and "Bitcoin support" often means raw Core RPC only. You can broadcast and read blocks, but the instant you need an address balance you're on your own, because they never built the index.

So the real question to ask any Bitcoin RPC provider isn't "do you support Bitcoin?" — it's "do you offer an address / UTXO / xpub API, or just node RPC?" The providers that take UTXO seriously (SwiftNodes among them) pair Core JSON-RPC with an address indexer like Blockbook. The ones that don't will quietly leave you to run your own.

And running your own is not trivial. A full archival bitcoind plus a Blockbook index is well over 2 TB of fast storage per chain, and the index build is memory-hungry and slow — the kind of thing that's genuinely cheaper to rent than to operate, the same calculus as self-hosted node vs RPC provider, with the added twist that you're maintaining two systems (node + indexer) instead of one. Address queries also need unpruned history, so a pruned node won't do — see full node vs archive node.

What to check when picking a Bitcoin RPC provider

Core JSON-RPC for broadcasting, fees, blocks, and mempool.
An address API — balance, UTXOs, history, and ideally xpub. This is the piece most providers skip.
The UTXO chains you actually need. Many providers do BTC only; if you need Litecoin or Dogecoin too, confirm it. (SwiftNodes runs all three.)
Archive, not pruned — address history requires full chain data.
Predictable pricing — the same flat-rate-vs-metered question that applies to EVM RPC applies here.

The takeaway

Bitcoin Core RPC and an address indexer are two halves of a whole: Core handles blocks, mempool, fees, and broadcasting; Blockbook (or Esplora) handles anything keyed on an address. Raw node access alone can't show a user their balance — and that's the exact spot where a lot of "Bitcoin-supported" providers stop. Pick one that gives you both.

SwiftNodes serves both halves for BTC, LTC, and DOGE behind one key — Core JSON-RPC at /rpc/<chain> and the Blockbook address API at /blockbook/<chain>/api/v2/..., flat-rate with no per-request metering. Sign up for a free key and try an address query against https://rpc.swiftnodes.io/blockbook/btc/api/v2/address/<address>?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.

Sending a Raw Transaction: Why eth_sendTransaction Doesn't Work on a Provider

SwiftNodes — Tue, 18 Aug 2026 06:00:03 +0000

Reading from a chain is easy — eth_call, eth_getBalance, done. Writing is where developers get stuck, and it usually starts with the same confusing moment: you try eth_sendTransaction, and your provider rejects it. Here's what that looks like against a real endpoint:

# Ask the node to sign and send for us:
curl ... -d '{"method":"eth_sendTransaction","params":[{"from":"0x00..","to":"0x00..","value":"0x0"}]}'
# → {"error":{"code":-32000,"message":"unknown account"}}

# Ask which accounts the node controls:
curl ... -d '{"method":"eth_accounts","params":[]}'
# → {"result":[]}

The node controls no accounts, so it can't sign for you. That's not a bug — it's the whole security model. Understanding it is the key to the entire write path.

Two methods, and why only one works

There are two ways to submit a transaction, and they differ entirely in who signs:

eth_sendTransaction asks the node to sign the transaction using a private key in the node's own keystore, for an unlocked account. This only works if you're running your own node and have loaded your key into it. A shared RPC provider holds no keys — it can't and shouldn't sign on your behalf — so eth_accounts is empty and eth_sendTransaction fails with "unknown account."
eth_sendRawTransaction takes a transaction you've already signed yourself, as a blob of bytes, and broadcasts it. The node never sees your private key — only the signed result. This is how every application that uses a provider sends transactions.

So the rule is simple: you sign locally, then send the signed bytes. The node is a broadcaster, not a signer. If you send eth_sendRawTransaction a malformed payload, you get an RLP-decoding error — proof that it expects properly signed, encoded transaction bytes and nothing less.

Anatomy of a transaction

Before you can sign one, you assemble it. A modern (EIP-1559, "type 2") transaction has these fields:

Field	What it is
`nonce`	The sender's transaction count — strict per-account ordering
`to`	Recipient (or omitted for contract creation)
`value`	Wei to send
`data`	Calldata (empty for a plain transfer, or an encoded function call)
`gas`	Gas limit — the max units the tx may consume
`maxPriorityFeePerGas`	The tip to the validator
`maxFeePerGas`	The ceiling you'll pay per gas (base fee + tip)
`chainId`	Which chain this tx is valid on

Every one of these has to be correct before you sign, because the signature commits to all of them.

The build → sign → send flow

Five steps, each mapping to an RPC call or a local operation:

Get the nonce. eth_getTransactionCount(from, "pending") gives the next nonce. Under any real send rate this is the single trickiest field — see nonce management for high-throughput senders for why "pending" flaps and how to manage nonces locally.
Price it. Estimate the gas limit with eth_estimateGas, and set your fees from the current base fee (via eth_feeHistory or the latest block's baseFeePerGas) plus a priority tip. Getting this wrong gets your transaction stuck or overpaying — the mechanics are in estimating gas right.
Set the chain ID. eth_chainId, or a value you already know. This is mandatory (more below).
Sign locally. Your library signs the assembled fields with your private key and RLP-encodes the result into a 0x-prefixed byte string. This happens entirely in your process — the key never leaves it.
Broadcast. eth_sendRawTransaction(signedBytes) returns the transaction hash immediately. That hash means "accepted into the mempool," not "mined" — you still have to wait for a receipt.

Then poll eth_getTransactionReceipt(hash) until it's mined and check status — because a mined transaction can still have reverted.

Doing it from a library

Libraries wrap all five steps, but they're all doing the same thing under the hood: sign locally, then call eth_sendRawTransaction.

viem:

import { createWalletClient, http, parseEther } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { mainnet } from "viem/chains";

const account = privateKeyToAccount("0xYOUR_PRIVATE_KEY");
const wallet = createWalletClient({
  account,
  chain: mainnet,
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY"),
});

// Fills nonce/gas/fees, signs locally, and broadcasts via eth_sendRawTransaction:
const hash = await wallet.sendTransaction({ to: "0xRecipient", value: parseEther("0.01") });

ethers v6:

import { JsonRpcProvider, Wallet, parseEther } from "ethers";

const provider = new JsonRpcProvider("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY");
const wallet = new Wallet("0xYOUR_PRIVATE_KEY", provider);
const tx = await wallet.sendTransaction({ to: "0xRecipient", value: parseEther("0.01") });
await tx.wait(); // waits for the receipt

To see the raw path explicitly — sign, then broadcast the bytes yourself:

const signed = await wallet.signTransaction({
  to: "0xRecipient", value: parseEther("0.01"),
  nonce: await provider.getTransactionCount(wallet.address, "pending"),
  chainId: 1, gasLimit: 21000n,
  maxFeePerGas: 30_000_000_000n, maxPriorityFeePerGas: 1_000_000_000n,
});
const hash = await provider.send("eth_sendRawTransaction", [signed]); // the actual broadcast

web3.py:

signed = w3.eth.account.sign_transaction(tx_dict, private_key="0xYOUR_KEY")
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)  # calls eth_sendRawTransaction

Gotchas

chainId is not optional. Since EIP-155, the chain ID is baked into the signature for replay protection — a transaction signed for one chain is invalid on another. Omit it or get it wrong and the transaction is rejected. This is also why the same signed transaction can't be replayed across chains.
The returned hash isn't a confirmation. eth_sendRawTransaction returns as soon as the node accepts the transaction into its mempool. It might still be dropped, replaced, or reverted. Treat the hash as a receipt to track, not proof of success — the mempool explainer covers what happens between broadcast and mining.
Nonce gaps stall everything. Transactions execute in strict nonce order. A missing nonce blocks every higher one behind it until it's filled.
Never send your private key to the node. The entire point of eth_sendRawTransaction is that signing happens locally. If a tutorial ever has you putting a private key in an RPC request, stop.
Account abstraction changes the path. Smart-contract accounts don't originate transactions the EOA way — an ERC-4337 UserOperation goes to a bundler, not to eth_sendRawTransaction. See what is account abstraction for how that submission path differs.

The takeaway

On a provider you always sign locally and broadcast with eth_sendRawTransaction — the node is a relay, never a keyholder, which is exactly why eth_sendTransaction returns "unknown account." Assemble the fields, price it, set the chain ID, sign in your own process, send the bytes, then wait for a receipt and check its status. Your library does this for you, but knowing the five steps underneath is what lets you debug a stuck or rejected transaction.

Need an endpoint to broadcast against? SwiftNodes serves eth_sendRawTransaction (and the rest of the write path) across 60-plus chains behind one key — sign up and point your wallet client at https://rpc.swiftnodes.io/rpc/eth?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.

How Do Blockchain Bridges Work? Lock-Mint, Burn-Mint, and Who You're Trusting

SwiftNodes — Mon, 17 Aug 2026 05:32:31 +0000

You've used a bridge every time you moved funds onto an L2, and probably several times since without thinking about it. But "bridge" is a single word covering several genuinely different mechanisms, and the differences matter — bridges have been the single largest source of losses in crypto, because the mechanism you pick decides who you're trusting. This post explains what a bridge actually does, the main designs, and the one question that determines whether a bridge is safe.

Why bridging is hard at all

A token on Ethereum can't "move" to another chain. Ethereum has no idea another chain exists, and vice versa — each chain only knows its own state. So an asset never physically travels. Instead, every bridge is some scheme for two things:

Prove that something happened on the source chain (you deposited or locked funds).
Act on the destination chain in response (release or mint funds to you).

The entire design space of bridges is different answers to "how do we prove step 1 to chain 2, and who do we trust to do it?" Everything else is detail.

The main mechanisms

Lock-and-mint

The most common third-party design. You lock the real asset in a contract on the source chain, and the bridge mints a wrapped representation on the destination chain. To come back, you burn the wrapped token and the original is unlocked.

The wrapped token is an IOU: USDC.e or a bridged WETH is only worth anything because collateral sits locked on the other side. This is powerful — you can represent any asset anywhere — but it means the wrapped token's value depends entirely on the bridge staying solvent and honest. If the lock contract is drained, every wrapped token it backed becomes worthless.

Burn-and-mint

Some assets are issued natively on multiple chains by the same issuer. Here there's no wrapping — you burn the token on the source chain and the issuer mints the equivalent native token on the destination. Circle's cross-chain transfer for USDC works this way, as do "omnichain" token standards. The result is one canonical asset everywhere instead of a patchwork of wrapped IOUs, which avoids the "which bridged USDC is this?" problem.

Liquidity-pool bridges

The "fast bridge" model (Across, Hop, Stargate, and similar). Instead of minting anything, the bridge keeps liquidity pools on both chains. You deposit on chain A, and a relayer immediately pays you out of the pool on chain B, then the pools rebalance in the background. You get near-instant transfers because nobody waits for a mint — you're just being paid from pre-positioned liquidity. The trade-off is that these bridges are limited by pool depth and charge a fee for the service.

Canonical (native) rollup bridges

Every rollup has an official bridge between it and its L1. Depositing from L1 to the L2 is usually fast. Withdrawing back is where the rollup's finality model shows up:

Optimistic rollups (Arbitrum, Base, Optimism) make you wait a challenge window — around 7 days — before a trustless withdrawal completes, because the system has to allow time for someone to dispute the state.
ZK rollups (Linea, Scroll, zkSync) settle via validity proofs, so there's nothing to dispute — withdrawals finalize as soon as the proof is verified on L1, no multi-day window.

That difference is the practical face of soft vs hard finality: the canonical bridge is exactly where "the sequencer said so" versus "Ethereum proved it" becomes real money you can or can't withdraw. (This is also why "fast bridges" exist — they front you the liquidity so you don't have to wait out the challenge window.)

The question that actually determines safety

Here's the part that matters. All of the above still rests on step 1 — proving to the destination chain that something happened on the source chain. How that proof is verified is where bridges live or die:

External validators (multisig / MPC). A set of off-chain signers watches the source chain and attests to the destination. Fast and flexible, but you're trusting that signer set. This is the design behind the largest bridge hacks in history — compromise enough keys and you can mint unbacked tokens or drain the lock contract. When you read that a bridge lost hundreds of millions, it was almost always this.
Light-client / native verification. The destination chain verifies a cryptographic proof of the source chain's state directly, trusting no external party — only the source chain's own consensus. This is the most secure design and the hardest to build. Some omnichain systems approximate it with a threshold-signature validator set that custodies assets on external chains (ZetaChain's approach to native Bitcoin is an example of pushing toward native verification of an external chain).
Optimistic verification. Assume the cross-chain message is valid, but allow a challenge window in which a watcher can prove fraud. Cheaper than full verification, at the cost of a delay.

So the useful question when you look at any bridge isn't "how fast is it?" — it's "who verifies the cross-chain message, and what happens if they're wrong or compromised?" Canonical rollup bridges and light-client bridges inherit the security of the chains themselves. External-validator bridges are only as safe as their signer set.

The developer's view

If you're building something that reacts to a bridge — crediting a deposit, triggering a downstream action — the mechanics come down to watching events and respecting finality:

Watch the bridge contract's events. Deposits and withdrawals emit logs; you track them with eth_getLogs or a subscription on the bridge contract, the same way you'd index any contract.
Never credit a deposit before source-chain finality. This is the cardinal rule. If you act on a deposit that later disappears in a reorg, you've paid out real value against nothing. Wait for the source chain's finalized tag (or enough confirmations), exactly as in handling chain reorgs. Reading the deposit's transaction receipt confirms it succeeded — but "mined" still isn't "final."
Canonical withdrawals need a proof step. Withdrawing from a rollup usually involves submitting a proof on L1 after the challenge/proof window; that's a second transaction on the destination chain, not an automatic credit.

None of this needs special RPC methods — it's standard eth_* against both chains, one endpoint per chain.

The takeaway

A bridge never moves an asset; it locks or burns on one side and mints or releases on the other, and the only thing standing between you and a loss is how the cross-chain message gets verified. Wrapped tokens are IOUs backed by locked collateral. Canonical rollup bridges inherit the L2's finality model — instant-ish on ZK, a challenge window on optimistic. And the security question is always the same: who attests that the source-chain event really happened? Answer that, and you understand the bridge.

Building across chains? SwiftNodes gives you the same endpoint format for 60-plus chains behind one key — sign up and point each client at https://rpc.swiftnodes.io/rpc/<chain>?key=YOUR_API_KEY, from Ethereum to every L2 you're bridging between.

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.

Linea RPC: The zkEVM Where Gas Estimation Works Differently

SwiftNodes — Sun, 16 Aug 2026 06:16:07 +0000

Linea is a zkEVM Layer 2 built by Consensys — the team behind MetaMask and Infura — which means two things for developers. First, it's EVM-equivalent, so your existing contracts and tooling connect with a URL change and nothing else. Second, because Consensys ships the wallet most of your users already have, Linea tends to show up as a default network in a lot of places. The RPC surface is standard eth_*, so the on-ramp is easy.

The parts worth actually reading about are the two places Linea diverges from a plain Ethereum node: gas estimation and finality. Get those right and everything else is business as usual.

Connecting

Linea mainnet is EVM chain ID 59144 (0xe708). Gas is paid in ETH — no separate native token — so funding, balances, and fee display work exactly like Ethereum. Point any standard client at a SwiftNodes endpoint:

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

viem, ethers, web3.py, Foundry, and Hardhat all work unchanged:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  transport: http("https://rpc.swiftnodes.io/rpc/linea?key=YOUR_API_KEY"),
});

console.log(await client.getChainId());   // 59144
console.log(await client.getBlockNumber()); // ~31,700,000 and climbing

What "zkEVM" means here

Linea is a zkEVM rollup: it executes standard EVM bytecode and proves that execution correct with zero-knowledge validity proofs posted to Ethereum. For a developer, the practical upshot is bytecode-level compatibility — Solidity compiles the same, opcodes behave the same, and audits carry over. The RPC is plain eth_*; there's no Cairo (like Starknet) or a modified VM to learn.

It's worth placing Linea against the other ZK L2s we've covered. zkSync Era is EVM-compatible but not equivalent — it has a different VM, custom account abstraction, and its own transaction type. Scroll targets bytecode-equivalence. Linea sits in the equivalent camp: standard EVM semantics, standard tooling, with the validity-proof machinery running underneath. In the rollup taxonomy, it's a ZK rollup — proofs plus data on Ethereum.

The gas estimation gotcha

Here's the first place a naive integration goes wrong. On Ethereum you reach for eth_gasPrice and eth_estimateGas and move on. On Linea, those don't capture the whole cost, because an L2's fee has a component that reflects the cost of proving and posting data to L1 — and Linea exposes a dedicated method to price it correctly: linea_estimateGas.

It returns a tuple rather than a single number:

curl -s -X POST "https://rpc.swiftnodes.io/rpc/linea?key=YOUR_API_KEY" \
  -H 'content-type: application/json' -d '{
    "jsonrpc":"2.0","id":1,"method":"linea_estimateGas",
    "params":[{"from":"0x...","to":"0x...","value":"0x0"}]}'

{ "gasLimit": "0x5208", "baseFeePerGas": "0x7", "priorityFeePerGas": "0x24137da" }

You get the gas limit, the base fee, and a recommended priority fee in one call. The priority fee it returns is not the near-zero tip you'd assume from mainnet habits — it's computed for Linea's fee market, and using a hand-picked or eth_gasPrice-derived value instead is the classic way to get transactions that either overpay or sit unmined. If you're building a wallet or a bot on Linea, prefer linea_estimateGas and use the values it hands back. (It's a Linea-specific method, so this is knowledge that lives with the chain, not with any one provider — the standard eth_estimateGas mechanics still apply for the EVM side.)

Finality: the `finalized` tag means something specific

The second divergence is finality, and it's a good divergence. Linea produces blocks quickly at the sequencer, but a block is only truly final once its validity proof is verified on Ethereum. That gives Linea two useful properties compared to optimistic rollups:

No multi-day challenge window. An optimistic rollup like Arbitrum or Base makes you wait ~7 days for a trustless L1 withdrawal because someone might dispute the state. A validity proof has nothing to dispute — once it's verified, the state is settled. This is the core ZK-vs-optimistic distinction from soft vs hard finality.
The finalized block tag is your anchor. When you need certainty — bridging value, crediting a deposit, settling something irreversible — read against the finalized tag rather than latest, and you're reading L1-proven state.

One caveat that trips people up: the finalized tag only reflects true L1 finalization on a Linea-aware node. Some generic endpoints alias finalized to the chain head, which quietly defeats the purpose. If your withdrawal logic depends on real finality, confirm your endpoint reports a finalized height that lags latest — that gap is the proof-verification pipeline, and it's supposed to be there.

Indexing and events

Nothing exotic here — eth_getLogs and log subscriptions work as on any EVM chain. Two habits carry over: respect getLogs range caps when backfilling, and key your indexed records on (txHash, logIndex) rather than block number so a reorg near the sequencer head can't corrupt your data. The mechanics are the same as handling chain reorgs, and for certainty-sensitive reads, anchor to finalized as above.

The Consensys distribution angle

Linea's quieter advantage is reach. Because Consensys builds MetaMask, Linea is frequently a first-class network in the wallet flows your users already run, which lowers the friction of getting them onto your L2. It doesn't change how you build — the RPC is standard — but it's a real reason Linea shows up in a lot of consumer-facing apps.

The short version

Linea is an easy chain to build on and a slightly nuanced one to build well on. It's an EVM-equivalent zkEVM, so eth_* and your tooling just work. Two things deserve attention: use linea_estimateGas for pricing instead of assuming mainnet gas habits, and treat the finalized tag as your finality anchor — validity proofs mean no 7-day exit window, but only a Linea-aware endpoint reflects real L1 finalization.

Get a Linea endpoint — and 60-plus other chains behind one consistent URL format — on the SwiftNodes Linea RPC page. There's a free tier to start; sign up and point your client at https://rpc.swiftnodes.io/rpc/linea?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.

eth_call State Overrides: Simulate Against State That Doesn't Exist

SwiftNodes — Sat, 15 Aug 2026 05:40:41 +0000

Most developers use eth_call to ask "what does this function return against current state?" But eth_call has a rarely-used third parameter that answers a much more powerful question: "what would this return if the chain looked different?" You can hand the node a set of state overrides — fake balances, fake contract code, fake storage slots — and it will run your call against that hypothetical world without touching anything on-chain.

This is one of the most useful RPC features almost nobody reaches for. It turns a read-only call into a simulator: preview a transaction that would revert today, test a contract patch without deploying it, or read what a contract would return if an account held tokens it doesn't. This post covers the mechanics, a reproducible example, and the cases where it earns its keep.

The third parameter

The full signature is:

eth_call([ txObject, blockParameter, stateOverrideSet ])

The stateOverrideSet is an object keyed by address, where each entry can override:

Field	Effect
`balance`	Set the account's ETH balance (hex wei)
`nonce`	Set the account's nonce
`code`	Replace the account's bytecode with your own
`state`	Replace the account's entire storage (all other slots read as zero)
`stateDiff`	Patch specific storage slots, leaving the rest untouched

Nothing is persisted — the override exists only for the duration of that single call. The node builds a temporary view of state, runs your call against it, and throws the view away.

A reproducible example

Here's the smallest demonstration. We call an empty address, but override its code with runtime bytecode that always returns the number 42 (0x2a). The bytecode 0x602a60005260206000f3 is just: push 0x2a, store it in memory, return 32 bytes.

curl -s -X POST "https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY" \
  -H 'content-type: application/json' -d '{
    "jsonrpc":"2.0","id":1,"method":"eth_call","params":[
      {"to":"0x0000000000000000000000000000000000000abc","data":"0x"},
      "latest",
      {"0x0000000000000000000000000000000000000abc":{"code":"0x602a60005260206000f3"}}
    ]}'

Result:

0x000000000000000000000000000000000000000000000000000000000000002a

Run the same call without the override and you get 0x — an empty account with no code returns nothing. The override materialized a contract that never existed on-chain, ran your call against it, and returned 42.

Where this is actually useful

Simulate a transaction for an account that can't afford it yet. Testing a swap or a contract interaction usually fails if the caller doesn't hold the tokens or ETH. Override the caller's balance and you can preview whether the call would succeed with funds, before the user has deposited anything. This pairs naturally with gas estimation — eth_estimateGas accepts the same override set, so you can estimate gas for a transaction that would revert against real state (see estimating gas right).

Preview a token operation without an approval. ERC-20 transfers through a router need an allowance, which is a real on-chain transaction. With a stateDiff, you can set the allowance storage slot to a large value and simulate the whole swap as if the approval already happened — useful for quoting an exact-output trade before asking the user to sign anything.

Test a contract change without deploying it. Override the code at an existing contract's address with a patched version and call it. You get to see how the new logic behaves against live storage and live surrounding contracts, with zero deployment cost. This is how a lot of "what if we fixed this bug" analysis gets done.

Read a contract under hypothetical storage. Override a storage slot with stateDiff to flip a boolean (say, a paused flag) or change an owner, then call a function gated on it. You're asking "what would this return if the contract were in that state?" without waiting for it to actually get there.

state vs stateDiff — use stateDiff

The difference between state and stateDiff trips people up and matters a lot:

state replaces the account's entire storage. Every slot you didn't specify reads back as zero. If the contract depends on any other storage (almost all do), it will misbehave.
stateDiff patches only the slots you list and leaves everything else intact.

In practice you almost always want stateDiff. Reach for state only when you genuinely want a blank-slate storage.

Finding the right slot is the hard part. For a mapping like mapping(address => uint256) balances declared at slot p, the slot for key k is keccak256(abi.encode(k, p)). Fixed variables occupy sequential slots from 0. Getting the layout right is the main friction of storage overrides — tooling like Foundry's storage layout output helps, and the reading balances post covers why you should read storage rather than reconstruct it.

Doing it from a library

viem has first-class support via stateOverride:

const result = await client.call({
  to: "0x0000000000000000000000000000000000000abc",
  data: "0x",
  stateOverride: [
    { address: "0x0000000000000000000000000000000000000abc", code: "0x602a60005260206000f3" },
  ],
});

web3.py takes a state_override argument:

result = w3.eth.call(
    {"to": "0x0000000000000000000000000000000000000abc", "data": "0x"},
    "latest",
    state_override={"0x0000000000000000000000000000000000000abc": {"code": "0x602a60005260206000f3"}},
)

ethers v6 doesn't expose overrides on provider.call, so send the raw request — the third array element is the override set:

const result = await provider.send("eth_call", [
  { to: "0x0000000000000000000000000000000000000abc", data: "0x" },
  "latest",
  { "0x0000000000000000000000000000000000000abc": { code: "0x602a60005260206000f3" } },
]);

Gotchas

Not every endpoint supports it. State overrides are a client feature (Geth, Erigon, Reth, Nethermind implement them), but many shared public endpoints strip the third parameter or reject it. If your override seems ignored — the call returns the un-overridden result — you're likely on an endpoint that dropped it. SwiftNodes passes the override through to a supporting node; the example above runs against our Ethereum endpoint as-is.
It's a simulation, full stop. Nothing is written. Two calls with different overrides don't interact.
Combine with a historical block. The block parameter still applies, so you can override state and pin to an old block — "what would this have returned at block N if the account had held tokens?" — which requires an archive node (archive access via &archive=1, and see reading historical state).
Tracing accepts overrides too. debug_traceCall takes the same override set, so you can get a full execution trace of your simulated call, not just its return value.

The takeaway

eth_call isn't only a way to read the chain as it is — with the third parameter it's a way to read the chain as it might be. Override a balance to preview a funded transaction, override code to test a fix, override a storage slot to explore a hypothetical, and estimate gas for calls that would revert today. It's a simulator hiding inside a method you already use.

Want a node that actually honors the third parameter? SwiftNodes forwards eth_call overrides straight through to a supporting Ethereum node — sign up for a free key and point your client at https://rpc.swiftnodes.io/rpc/eth?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.

Ankr Alternative: Public Endpoints, API Credits, and the Flat-Rate Option

SwiftNodes — Fri, 14 Aug 2026 05:43:30 +0000

You have probably used Ankr without deciding to. https://rpc.ankr.com/eth is pasted into more MetaMask networks, tutorials, and quick scripts than almost any other endpoint, because it's free, needs no API key, and covers 80-plus chains. As a way to get a read call working in thirty seconds, it's genuinely excellent.

The trouble starts when a prototype becomes a product. The free public endpoint is deliberately limited, and the paid path replaces those limits with a metered API-credit model that brings back the exact budgeting problem developers move to flat-rate providers to escape. This post walks through both walls and where an alternative like SwiftNodes fits.

Wall one: the public endpoint is capped by design

Ankr's public endpoints are anonymous and free, which means they have to be defended against abuse. In practice that means three restrictions that are invisible in development and painful in production:

A global, IP-level rate throttle. There's no per-key budget you can reason about — you share a throttle with everyone else hitting that public URL from your network. Under real traffic you get intermittent rate-limit errors you can't predict or raise.
A restricted method set. The public tier doesn't serve archive queries, debug_*/trace methods, or wide eth_getLogs ranges. Those are exactly the calls that indexers, analytics, and anything reading historical state depend on.
No private endpoint. You can't get a stable, isolated endpoint with its own limits without moving to a paid plan.

The first time this usually bites is indexing. You write a backfill that pages eth_getLogs, it works against a small range in dev, and then it fails in production because the public endpoint caps the range — the same class of problem covered in how eth_getLogs range caps bite you. The second time is when you need a historical eth_call or a debug_traceTransaction for accounting, and discover the public tier simply doesn't answer those (see full node vs archive node for why archive access is a separate capability, not a setting).

None of this is a knock on Ankr — free anonymous infrastructure has to be limited. It just means the public endpoint is a starting line, not a finish line.

Wall two: paid means API credits, priced per method

When you outgrow public, Ankr's paid path is pay-as-you-go API credits. The headline number is simple — roughly $0.10 per 1M credits (starting around $10 per 100M) — but the catch is that different methods cost different amounts of credits. An eth_call runs about 200 credits; heavier methods cost more. So your real cost per request depends entirely on your method mix.

Work an example. If your workload is mostly eth_call at ~200 credits each:

1,000,000 eth_call  ×  200 credits  =  200,000,000 credits
200,000,000 credits  ×  $0.10 / 1,000,000  =  $20

That looks cheap until you remember two things. First, real apps aren't one method — they mix getLogs, getBlockByNumber, traces, and receipts, each at a different credit weight, so you can't predict the bill without modeling the whole distribution. Second, that distribution changes the moment you ship a new feature or traffic spikes. This is the same metered-compute trap we've written about for Alchemy's compute units and QuickNode's credits: the pricing unit isn't a request, it's a synthetic cost that you have to translate back into requests every time you want to answer "what will this cost me next month?"

Ankr's Freemium tier softens the entry — a monthly allotment of free credits — but it still runs under the public rate limits, so it's a bigger evaluation bucket, not a production lane.

What flat-rate changes

The alternative model is to pay one number per month and stop counting. That's what SwiftNodes does, and the difference isn't philosophical — it removes concrete work:

No method-weight modeling. A request is a request. An eth_call, an eth_getLogs, and a debug_traceTransaction all draw from the same flat plan, so you never build a spreadsheet to predict a bill. For trace-heavy or log-heavy workloads — the ones Ankr's credit weights punish hardest — this is the biggest saving.
Archive and full methods on paid plans. The methods the public tier withholds — archive state, debug_*/trace, wide getLogs — are available, so you're not forced onto pay-as-you-go just to read history.
One URL format across every chain. https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY (and /ws/eth for WebSocket). The slug is the only thing that changes between chains — see the Ethereum RPC page for a live example.

Here's the shape of the trade-off:

	Ankr Public	Ankr Premium (credits)	SwiftNodes (flat-rate)
API key	none	yes	yes
Rate limit	shared IP throttle	high, per plan	fixed req/s per plan
Cost model	free	credits, per-method weight	flat monthly
Predict next month's bill	n/a	model your method mix	it's the plan price
Archive / debug / wide getLogs	no	yes	yes (paid plans)
Chains	80+ public	80+	60+ behind one key

For the broader "free public RPC vs a paid endpoint" decision — latency, reliability, and where the line actually is — public RPC vs paid RPC goes deeper, and if you're weighing running your own node instead, self-hosted node vs RPC provider has the cost math.

When Ankr is the right call

Flat-rate isn't automatically the answer, and it's worth being honest about where Ankr wins:

Prototyping and low-volume read apps. If you never leave read-only, low-traffic territory, the public endpoints are free and cover more chains anonymously than anyone. That's hard to beat for a hackathon or a hobby project.
You want anonymous, no-signup access. No key, no account — paste and go.
You're already in the Ankr ecosystem — its staking, RaaS (rollup-as-a-service), or enterprise node products. Keeping RPC in the same account has real convenience value.
Your method mix is genuinely cheap and stable. If you're overwhelmingly light eth_call traffic and you've actually modeled it, pay-as-you-go credits can come out inexpensive.

The point isn't that credits are bad — it's that credits are work. If you'd rather not re-model your bill every time your traffic changes, flat-rate is the trade you want.

Migration is a URL swap

Because both speak standard JSON-RPC, moving is mechanical. Point your client at the new endpoint and nothing else changes:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  transport: http("https://rpc.swiftnodes.io/rpc/eth?key=YOUR_API_KEY"),
});

Same eth_* methods, same responses — you're just trading a shared public throttle (or a per-method credit meter) for a single predictable monthly number, with archive and trace access included on paid plans.

If Ankr's public endpoints have gotten you this far and you're starting to hit the walls above, that's the signal you've outgrown the starting line. SwiftNodes has a free tier to test with — sign up, point your client at /rpc/<chain>?key=YOUR_API_KEY, and see whether flat-rate fits your workload better than counting credits.

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.

Robinhood Chain RPC: Tokenized Stocks on an Arbitrum Orbit L2

SwiftNodes — Thu, 13 Aug 2026 07:37:05 +0000

Robinhood Chain went live on mainnet on July 1, 2026, and it arrived with a specific job: settle tokenized real-world assets — most visibly Robinhood's tokenized stock tokens. That framing scares off some developers who assume an "RWA chain" needs a specialized SDK and a compliance degree. It doesn't. Under the hood, Robinhood Chain is an Arbitrum Orbit rollup running the same Nitro stack as Arbitrum One, which means the RPC surface is plain, boring, wonderful eth_*. Your existing tooling connects with a URL change and nothing else.

The interesting part isn't the transport — it's what those tokens do when you touch them. This post covers connecting, what carries over unchanged from Ethereum, and the one place a tokenized-asset chain will bite you if you treat its tokens like any other ERC-20.

Connecting

Robinhood Chain is EVM chain ID 4663 (0x1237). Point any standard client at a SwiftNodes endpoint:

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

Because it's a Nitro chain, viem, ethers, web3.py, Foundry, and Hardhat all work with zero changes:

import { createPublicClient, http } from "viem";

const client = createPublicClient({
  transport: http("https://rpc.swiftnodes.io/rpc/robinhood?key=YOUR_API_KEY"),
});

console.log(await client.getChainId());   // 4663
console.log(await client.getBlockNumber()); // ~35,190,000 and climbing

Gas is paid in ETH — there is no separate native "Robinhood" gas token, which is a deliberate choice that keeps funding, balance-reads, and fee display identical to Ethereum. Fees run in fractions of a gwei, as you'd expect from an Orbit L2. If you've integrated Arbitrum before, you already know how to integrate this chain.

What "Arbitrum Orbit" buys you

Orbit is Arbitrum's framework for launching an L2/L3 on the Nitro codebase. For a developer, three things follow from that:

EVM equivalence. Contracts, opcodes, and the JSON-RPC method set match Ethereum. There's no custom namespace to learn (contrast that with Starknet's starknet_* or Cosmos-based chains, where eth_* doesn't exist at all).
A settlement path. Robinhood Chain doesn't finalize on its own island. Like other rollups, it produces fast soft confirmations from its sequencer, then settles batches down the Arbitrum/Ethereum path. If you're fuzzy on why "the sequencer confirmed it" and "it's final" are different claims, the soft vs hard finality post is the one to read, along with what a sequencer actually is.
Ethereum-grade tooling. Block explorers, indexers, and wallets that speak generic EVM will work here without special cases.

Practically: build against Robinhood Chain the way you'd build against Arbitrum or any other Orbit chain. For confirmation semantics, treat soft confirmations as "probably done, good enough for UX" and wait for settlement when you're moving value that can't be reversed.

The one thing that isn't standard: the assets themselves

Here's the part specific to a tokenized-asset chain. The chain is standard EVM. The tokens representing stocks and real-world assets frequently are not plain ERC-20s, and that gap is where naive integrations break.

A vanilla ERC-20 lets anyone hold and anyone transfer. A tokenized equity can't work that way — the issuer has regulatory obligations about who is allowed to hold the asset and under what conditions it can move. So RWA and security tokens commonly layer compliance logic on top of the ERC-20 interface: allowlists (only KYC'd/whitelisted addresses can receive), transfer restrictions (blackout windows, jurisdiction checks), forced-transfer or freeze hooks for the issuer, and sometimes a partitioned-balance model in the style of ERC-1400. From the RPC's point of view all of this is invisible — you still call balanceOf and transfer — but the behavior differs.

The failure mode is concrete: a transfer that a wallet UI happily builds can revert on-chain because the recipient isn't eligible, or the transfer window is closed, or a compliance module said no. If your code assumes a transfer that lands in a block succeeded, you'll report success on a transaction that actually reverted. It won't. Two habits protect you:

Check the receipt status, don't assume. A mined transaction can still have status: 0x0 (reverted) while consuming gas. Read the receipt and branch on status — this is exactly the mined ≠ succeeded trap, and it matters far more on a compliance-gated token than on a plain one.

const receipt = await client.waitForTransactionReceipt({ hash });
if (receipt.status !== "success") {
  // transfer reverted — likely a compliance/eligibility check, not a gas issue
}

Simulate before you send. Use eth_call (or client.simulateContract) against the token to see whether the transfer would revert before you spend gas and show the user a spinner. Many compliance tokens also expose a "can this address receive?" view function — call it and gate your UI on the answer rather than discovering the rule after the fact.

None of this requires a special RPC. It requires treating "is this an ERC-20?" as a question with a nuanced answer on an RWA chain, and reading contract state instead of assuming the standard interface implies standard behavior.

Reading balances and prices correctly

Two more habits carry over from general EVM work but are worth repeating because RWA tokens make the stakes higher:

Don't assume 18 decimals. Read decimals() per token and cache it. Tokenized assets may use their own precision, and a display bug on a stock token is more embarrassing than a display bug on a memecoin. The full set of balance traps — decimals, snapshotting at a block, not reconstructing balances from Transfer events — is in reading balances right.
Pin reads to a block. When you show a portfolio, read every balance at the same blockNumber so the snapshot is internally consistent. Historical reads (what did this address hold last Tuesday?) need archive state — see the availability note below.

Indexing and event streams

Robinhood Chain produces blocks quickly, so if you're tracking token transfers or issuance events, prefer streaming over tight polling where you can. Standard eth_getLogs and log subscriptions apply; filter on the token's Transfer topic and key your records on (txHash, logIndex) rather than block number so a reorg near the tip doesn't corrupt your index. That reorg-safe indexing pattern is covered in handling chain reorgs, and the mechanics of decoding those logs (topics, signatures, indexed params) are in decoding event logs.

Honest notes on a young chain

Robinhood Chain launched in mid-2026, so calibrate expectations accordingly:

Archive state and WebSockets are still maturing. Deep historical queries (eth_getBalance/eth_call at old blocks, traces over history) depend on archive nodes being available, and not every endpoint on a new chain exposes them yet. If you need guaranteed archive access, request it explicitly — on SwiftNodes that's the &archive=1 flag, which routes only to archive-capable upstreams and returns a clear error rather than silently serving you a pruned node.
The ecosystem is early. A growing DeFi footprint (Arcus, Uniswap, Lighter) is forming around the chain, but tooling coverage will lag more established L2s for a while. Test against the live chain rather than trusting third-party assumptions.
Verify contract behavior per asset. As above — the compliance model can differ from token to token. Read the contract, don't generalize.

The short version

Robinhood Chain is easy to integrate and easy to get subtly wrong. It's an Arbitrum Orbit L2, so connecting is a one-line URL change and every eth_* method you know works. The nuance lives in the assets: tokenized stocks and RWAs carry compliance logic that can make a well-formed transfer revert, so check receipts, simulate first, and read contract state instead of assuming the plain ERC-20 contract implies plain ERC-20 behavior.

Get a Robinhood Chain endpoint — and 60-plus other chains behind one consistent URL format — on the SwiftNodes Robinhood Chain page. There's a free tier to start; sign up and point your client at https://rpc.swiftnodes.io/rpc/robinhood?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.

Scroll RPC: The zkEVM That Runs Ethereum Bytecode Unchanged

SwiftNodes — Wed, 12 Aug 2026 05:07:09 +0000

"zkEVM" covers a wide spectrum, and where a chain sits on it decides how much of your Ethereum knowledge transfers. Scroll is at the far end: it's a bytecode-equivalent zkEVM (chain ID 534352), meaning it targets opcode-level equality with the EVM. Your existing contracts deploy with no changes, the same audits still apply, the same tooling works, and the RPC is plain eth_* — while ZK validity proofs give it ~1-hour hard finality instead of an optimistic rollup's 7-day withdrawal window. If you've read our zkSync Era spotlight, Scroll is the interesting contrast: where zkSync is EVM-compatible (Solidity works, but it's a different VM under the hood), Scroll aims to be EVM-equivalent. Here's the map.

The essentials

Scroll mainnet (live since October 2023) is chain ID 534352, a ZK rollup with:

ETH as the gas token (18 decimals) — no separate token to hold.
~3-second blocks — fast soft confirmation from the sequencer.
Bytecode-equivalent zkEVM — full opcode equivalence with the EVM; existing Ethereum contracts run identically.
ZK validity proofs — every state transition is proven and verified on Ethereum, giving hard finality in ~1 hour (no fraud-proof challenge window).
A true rollup — transaction data is posted to Ethereum (via blobs), so data availability is Ethereum-grade (see rollup vs validium).

Connecting is completely standard EVM:

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

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

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

The headline: "equivalent," not just "compatible"

This distinction sounds like marketing until it bites you, so it's worth being precise. A compatible EVM (like zkSync Era) runs your Solidity, but through a different compiler and VM — which means some low-level things differ (custom deploy semantics, non-standard CREATE2 behavior, its own account-abstraction model, occasional edge cases in bytecode-level tricks). An equivalent EVM like Scroll targets identical opcode behavior, so:

Your existing bytecode runs as-is. Contracts compiled for Ethereum mainnet behave the same on Scroll — no recompilation for a different VM, no dialect.
Your audits still count. Because the execution semantics match, a contract audited for mainnet doesn't acquire new behavior on Scroll.
Tooling is unchanged. Foundry, Hardhat, ethers, viem, and standard debuggers work without special plugins, because there's nothing non-standard to accommodate.

The practical upshot: if you want a zkEVM where "it just works, exactly like mainnet" is the design goal, Scroll is built for that. The ZK part is invisible to your code — it's the proving system underneath, not something you interact with through the RPC.

Finality: fast, and actually final in ~1 hour

Here's where Scroll's ZK nature pays off versus the optimistic rollups we've covered (Blast, Unichain, Base):

Soft confirmation (~3s) at the sequencer — fast, and what your users feel.
Hard finality in ~1 hour — once the validity proof is generated and verified on Ethereum, the state is cryptographically final. There's no 7-day fraud-proof window, because there's nothing to dispute: the proof is the guarantee.

For anything moving value L2→L1 — bridges, withdrawals, cross-rollup flows — that's a big practical difference: hours, not a week. The two-tier model is still worth understanding (soft vs. hard finality): the sequencer head is fast but reorg-capable until the proof lands, so key your indexer on block hash and reconcile (handling chain reorgs). But the hard side resolves far quicker than optimistic chains.

Contrast the other ZK approaches: Starknet also uses STARK validity proofs but is non-EVM (Cairo, starknet_*), and zkSync Era is a compatible-but-not-equivalent zkEVM. Scroll's pitch is validity proofs with full EVM equivalence — ZK security, zero relearning.

What carries over unchanged (essentially everything)

Because Scroll is bytecode-equivalent, treat it as Ethereum-with-cheaper-gas:

eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally.
Solidity contracts, ABIs, bytecode, and the full viem/ethers/hardhat/foundry toolchain deploy and run without modification.
ETH is the 18-decimal gas token; fees include an L1 data-fee component like any rollup (gas estimation basics); WebSocket subscriptions work; at ~3s blocks, stream rather than tight-poll.

The short version

Scroll (chain ID 534352) is a bytecode-equivalent zkEVM — it targets opcode-level equality with Ethereum, so existing contracts, audits, and tooling work with zero changes, and the RPC is plain eth_* (viem/ethers/foundry unchanged). As a ZK rollup it posts data to Ethereum (blobs, so Ethereum-grade DA) and reaches hard finality in ~1 hour via validity proofs — no 7-day optimistic window. The key distinction to know: Scroll aims for EVM equivalence, versus zkSync Era's EVM compatibility (different VM) and Starknet's non-EVM Cairo. If you want ZK security without relearning anything, this is the zkEVM that behaves like mainnet — just cheaper and provably correct.

Building on Scroll — DeFi that needs fast L1 finality, cross-rollup apps, or on-chain games? A flat-rate Scroll RPC endpoint gives you chain 534352 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/scroll?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.

Rollup vs Validium vs Optimium: Where Your L2's Data Actually Lives

SwiftNodes — Tue, 11 Aug 2026 05:37:05 +0000

You keep seeing the words — rollup, validium, optimium, "modular DA," "settles to Ethereum." They sound like marketing, but they describe a real, consequential choice every L2 makes about where your transaction data lives and how the chain proves it did the right thing. Those two decisions determine how cheap the chain is, how strong its security is, and — the part that actually matters when things go wrong — whether you could recover your funds if the operator vanished. Here's the taxonomy without the jargon, and why a developer should care.

Two independent questions

Every L2 answers two separate questions. People conflate them, but they're orthogonal:

How does it prove its state is correct?
- Validity proofs (ZK): every state update ships with a cryptographic proof that it's correct. Ethereum verifies the proof; if it's valid, the state is final. No waiting.
- Fraud proofs (optimistic): state updates are assumed correct, and there's a challenge window during which anyone can submit a proof that they're wrong. If no one challenges, it's accepted.
Where does the data availability (DA) live?
- On Ethereum: the transaction data is posted to Ethereum (as calldata or, since Dencun, blobs). Anyone can reconstruct the full L2 state from Ethereum alone.
- Off Ethereum: the data is posted somewhere else — a separate DA layer like Celestia, EigenDA, or a committee — and Ethereum only sees a commitment to it.

The DA question is the one that names the category. DA is the thing that lets anyone rebuild the chain and exit their funds without the operator's cooperation. That's why "where the data lives" is the load-bearing decision.

The four combinations

Cross those two axes and you get the taxonomy:

	DA on Ethereum	DA off Ethereum
Validity (ZK) proofs	ZK Rollup	Validium
Fraud (optimistic) proofs	Optimistic Rollup	Optimium

ZK Rollup — proofs and data on Ethereum. The strongest security profile: correctness is proven, and data is recoverable from L1. (e.g. zkSync Era, Scroll, Linea, Starknet.)
Optimistic Rollup — data on Ethereum, correctness enforced by a fraud-proof challenge window. Cheaper historically, at the cost of a ~7-day withdrawal delay. (e.g. Arbitrum, Base, Optimism, Blast.)
Validium — validity proofs, but data kept off Ethereum. Very cheap, and still cryptographically proven correct — but data availability now depends on the external layer, not Ethereum. (e.g. Manta Pacific posts DA to Celestia.)
Optimium — fraud proofs and off-chain data. The cheapest, and the weakest guarantees: you're trusting both an honest challenger and an external DA layer.

The word "rollup" specifically means data is on Ethereum. The moment a chain moves DA off Ethereum, it's technically a validium or optimium — not a rollup — no matter how it markets itself.

Why the DA choice is the one that bites

Here's the scenario that makes it concrete. Suppose the L2's sequencer/operator goes offline permanently or turns malicious. Can you still get your money out?

On a rollup (data on Ethereum): yes. Because the full data is on L1, anyone can reconstruct the latest L2 state and you can force a withdrawal directly through the L1 contracts. Your funds don't depend on the operator being alive.
On a validium/optimium (data off Ethereum): only if the external DA layer still has the data and will serve it. If that data becomes unavailable, the L1 contract knows a commitment to your balance but not the balance itself — and you may be unable to prove what you're owed. That's the data withholding risk, and it's the fundamental trade-off you accept for lower fees.

This isn't hypothetical hand-wringing — it's the exact reason the community draws a hard line between "rollup" (Ethereum-grade DA) and "validium" (borrowed DA). Modern DA layers like Celestia are designed specifically to make off-chain DA trustworthy, so a validium is a reasonable, deliberate engineering choice — but it is a different security assumption than a rollup, and you should know which one you're building on.

What it means for you as a developer

From the RPC, all four types look nearly identical — standard eth_*, viem/ethers work — so the differences are in how you reason, not what you call:

Finality timing. ZK types can reach hard finality fast (proof verified); optimistic types make you wait out the challenge window for L1 settlement. If you move value L2→L1, this delay is real — see soft vs. hard finality.
Reorg behavior at the head. All of them still have a sequencer ordering transactions, and the L2 head can reorg before settlement — so key your indexer on block hash regardless (handling chain reorgs).
Long-range trust. For anything custodial or high-value, know your chain's DA model. A rollup gives you Ethereum-grade data recoverability; a validium/optimium ties that to an external layer. It doesn't change your code, but it changes your risk model — the same way public vs. paid RPC changes your reliability model without changing your calls.

The short version

L2s vary on two independent axes: proof system (validity/ZK proofs = proven correct + fast finality; fraud/optimistic proofs = assumed correct + challenge window) and data availability (on Ethereum = recoverable from L1; off Ethereum = depends on an external DA layer). Cross them and you get ZK rollup, optimistic rollup, validium (ZK + off-chain DA), and optimium (optimistic + off-chain DA). "Rollup" specifically means data-on-Ethereum; move DA off-chain and it's a validium/optimium, with lower fees bought at the cost of data-withholding risk — whether you could still exit your funds if the operator disappears. It's transparent from the RPC, but it's the difference between Ethereum-grade recoverability and borrowed data availability. Know which one you're on.

Building across L2s of every flavor? A flat-rate Ethereum RPC endpoint plus rollups, validiums, and 75+ other chains under one key — HTTP and WebSocket, no per-call metering. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/eth?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.

Is Your RPC Node Actually at the Chain Tip? How to Catch a Stale Endpoint

SwiftNodes — Mon, 10 Aug 2026 06:20:43 +0000

Here's a failure mode that's quietly common and genuinely nasty: an RPC endpoint that responds perfectly — 200 OK, valid JSON, every call works — but is serving data from hours or days ago because the node behind it fell behind the chain and never caught up. Your app reads "confirmed" balances that are stale, submits transactions against an old nonce, and shows users numbers that don't match the explorer. Nothing errors. This bites both people running their own node ("is it synced yet?") and people consuming a provider ("is this endpoint at the tip, or lagging?"). The tools to check are simple — but the most obvious one has a trap. Here's how to actually know.

The trap: `eth_syncing` returns `false` for two opposite states

The instinct is to call eth_syncing. When a node is actively catching up, it returns a rich object:

{ "startingBlock": "0x...", "currentBlock": "0x1878b4e", "highestBlock": "0x1878cea" }

When a node is fully synced, it returns:

{ "jsonrpc": "2.0", "id": 1, "result": false }

So far so good — false means "done syncing," right? Not exactly. eth_syncing returns false in two opposite situations:

The node is fully synced and at the tip. ✅
The node isn't syncing at all — freshly started, stalled, or waiting on its consensus client — so it has nothing to report. ❌

A node that's stuck at a block from last week, with its execution head frozen, can happily return eth_syncing: false. If you treat false as "healthy," you'll trust a stale node. eth_syncing tells you whether a sync is in progress — not whether you're at the tip. You need a second, independent check.

The real check: compare block height to a reference

The reliable signal is: does this node's latest block match where the chain actually is right now? You can't know "where the chain is" from the node you're suspicious of, so compare against something independent.

Option A — compare to a reference endpoint. Ask your node for its head and ask a known-good endpoint (a public node, a block explorer API, another provider) for theirs, and diff them:

const [mine, ref] = await Promise.all([
  myClient.getBlockNumber(),
  refClient.getBlockNumber(),
]);
const lag = Number(ref - mine);
if (lag > 5) console.warn(`node is ${lag} blocks behind the reference`);

A healthy node is within a block or two of the reference (accounting for propagation). Tens or thousands of blocks behind means it's lagging or stuck.

Option B — check the latest block's timestamp against wall-clock. This needs no second endpoint, which makes it great for a self-contained health check. Every block carries a timestamp; if the newest block is much older than "now," the node isn't keeping up:

const block = await client.getBlock();               // latest
const ageSeconds = Math.floor(Date.now() / 1000) - Number(block.timestamp);
if (ageSeconds > 60) console.warn(`newest block is ${ageSeconds}s old — node is behind`);

Pick a threshold a few multiples of the chain's block time (≈60s on Ethereum's ~12s blocks; tighter on fast chains). This is the single most useful "is it at the tip?" check because it catches the frozen-but-responsive node that eth_syncing: false hides. It's exactly how you'd catch a provider quietly serving stale data.

Why "it responds" is not "it's synced"

This is the core lesson, and it's worth stating plainly: a liveness check is not a freshness check. Health checks that only confirm the endpoint answers (eth_blockNumber returned something, HTTP 200) will keep a stalled node in rotation, because a stalled node still answers — it just answers with an old number. If you run any kind of failover or load balancing across endpoints, your health check has to assert the head is advancing and recent, not merely that a response came back. The cheap version: poll eth_blockNumber twice a few seconds apart and confirm it moved.

const a = await client.getBlockNumber();
await sleep(4000);
const b = await client.getBlockNumber();
if (b <= a) console.warn("head not advancing — node may be stuck");

Sanity-check finality too, not just height

Being at the tip isn't the whole story on chains with a separate finality signal. A node can be at the head block yet that block isn't final (and could be reorged), or — on some setups — the head advances while finalization stalls. Where it matters (exchanges, settlement), also read the finalized block tag and confirm it's recent and progressing:

const finalized = await client.getBlock({ blockTag: "finalized" });

If the head is moving but finalized is stuck far behind, something is wrong with the consensus side even though eth_syncing and block height look fine. See soft vs. hard finality for why the two can diverge, and handling chain reorgs for keying data safely on the head.

The Solana equivalents

Non-EVM chains have their own versions of the same idea. On Solana:

getHealth — returns "ok" when the node is within a small slot distance of the cluster tip; returns an error (with how many slots behind) when it's lagging. This is a real freshness check, unlike eth_syncing.
getSlot vs a reference — compare your node's current slot to a known-good endpoint's, same as the block-height diff above.
solana catchup --our-localhost — from the CLI, tells you exactly how far behind the cluster your node is and whether it's closing the gap.

The principle carries across every chain: confirm the head is recent and advancing against an independent reference — don't trust a single "healthy" boolean.

The short version

eth_syncing returning false does not prove a node is at the tip — it returns false both when fully synced and when not syncing at all (stalled/stuck). To really know: compare the node's latest block to an independent reference (another endpoint or explorer), and/or check the newest block's timestamp against wall-clock (a block much older than "now" = the node is behind). Remember that a liveness check is not a freshness check — a stalled node still answers eth_blockNumber, so any health check driving failover must assert the head is advancing and recent. Sanity-check the finalized tag where finality matters, and use getHealth / catchup as the Solana equivalents. This is how you catch both a self-hosted node that quietly fell behind and a provider serving stale data.

Want endpoints that are actually at the tip — health-checked and load-balanced so a lagging node gets pulled from rotation? A flat-rate Ethereum RPC endpoint, Solana RPC, and 75+ other chains under one key, over HTTP and WebSocket. Grab a free key and point your stack at:

https://rpc.swiftnodes.io/rpc/eth?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.

Berachain RPC: Standard EVM, but the Token You Earn Can't Be Transferred

SwiftNodes — Sun, 09 Aug 2026 06:43:45 +0000

Berachain is one of the rare chains where the RPC is completely ordinary and the economics are the thing you have to understand. It's an EVM-identical Layer 1 (chain ID 80094) — your Solidity, ABIs, viem/ethers/foundry, and eth_* calls all work with zero changes. What's different is underneath: a Proof-of-Liquidity consensus and a three-token model where one of the tokens, BGT, is something you earn but cannot transfer. Treat BGT like a normal ERC-20 and your integration will fail in a way the RPC won't warn you about. Here's the map — mostly "everything works," with the two things that genuinely differ.

The essentials

Berachain mainnet (live since February 2025) is chain ID 80094, an EVM-identical L1 with:

Three tokens, each with a job: BERA (native gas token, 18 decimals), HONEY (a native stablecoin), and BGT (governance/emissions token — non-transferable, earned by providing liquidity).
Proof-of-Liquidity (PoL) consensus — validator rewards are tied to liquidity provided to the ecosystem, not raw staking.
BeaconKit on CometBFT — ~2-second blocks with single-slot deterministic finality (an "EVM cockpit over a CometBFT engine," like Kaia, Sei, and Story).
EVM-identical — Solidity, ABIs, and the full Ethereum toolchain deploy unchanged.

Connecting is completely standard EVM:

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

const berachain = defineChain({
  id: 80094,
  name: "Berachain",
  nativeCurrency: { name: "Bera", symbol: "BERA", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/berachain?key=YOUR_API_KEY"] } },
});

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

The gotcha: BGT is earned, not transferred

This is the one that catches integrations. In a normal ERC-20 world, if you hold a token you can send it — transfer, transferFrom, approve a spender, done. BGT breaks that assumption on purpose. BGT is a non-transferable (soulbound-style) governance token: you earn it by providing liquidity under Proof-of-Liquidity, and you can delegate it to validators, use it to vote, or burn/redeem it for BERA — but you cannot send it to another address like a normal token.

What that means when you build:

Don't expose a "send BGT" flow. A wallet or app that renders BGT as a transferable balance and offers a transfer button will produce transactions that revert. The RPC will happily accept the call and the transaction will fail on-chain — a confusing bug if you assumed ERC-20 semantics.
Model it as position + redemption, not spendable balance. You read a BGT balance with balanceOf like any token (reading balances right), but the actions available are delegate / vote / redeem-for-BERA, not transfer. Design your UI and accounting around that.
BERA and HONEY are normal. BERA (gas) and HONEY (stablecoin) behave like ordinary tokens/native coin — it's specifically BGT that has the transfer restriction. Don't over-apply the rule.

If you take one thing from this post: check which of the three tokens you're touching, and remember BGT is the non-transferable one.

Proof-of-Liquidity, briefly (and why it barely touches the RPC)

Proof-of-Liquidity is the reason BGT exists. Instead of paying block rewards purely to stakers, Berachain routes emissions (as BGT) to liquidity providers and the protocols they support, aiming to keep liquidity — and therefore security — on-chain. It drove a large pre-launch ecosystem of DeFi protocols designed around BGT incentives.

For a developer, PoL is mostly an economic/protocol layer, not an RPC one. You interact with the reward and liquidity contracts the same way you'd call any contract (eth_call to read, eth_sendRawTransaction to act); there's no special namespace. The one place it does surface is the BGT rule above — that's PoL's design showing through into token behavior.

Finality: single-slot, so confirm once

BeaconKit on CometBFT gives single-slot deterministic finality — a committed block is final, no reorgs. Practically:

Skip the reorg machinery. The reorg-handling patterns collapse to "confirm once" — no deep confirmation counts, no block-hash reconciliation for probabilistic reorgs.
~2-second blocks — fast enough that WebSocket subscriptions (newHeads, logs) beat tight polling for live data.

It's the same fast-finality comfort as the other CometBFT-EVM and BFT-EVM chains we've covered — Kaia, Sei, Monad — where "final means final" once you see the block.

What carries over unchanged (almost everything)

Because Berachain is EVM-identical, treat it 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.
BERA is the 18-decimal gas token; gas follows standard EVM mechanics (gas estimation basics); WebSocket subscriptions work.

The short version

Berachain (chain ID 80094) is an EVM-identical L1 — standard eth_*, viem/ethers/foundry unchanged — built on Proof-of-Liquidity consensus with a tri-token model: BERA (gas), HONEY (native stablecoin), and BGT (governance, earned via liquidity). The one thing that will bite you is that BGT is non-transferable — you earn, delegate, vote, or redeem it for BERA, but you cannot transfer it, so any flow that treats it like a normal ERC-20 will revert. PoL is otherwise an economic layer that barely touches the RPC, and single-slot CometBFT finality means you confirm once (no reorgs). Build it like any EVM chain — just get the BGT rule right.

Building liquidity-incentivized DeFi, HONEY stablecoin apps, or anything indexing Berachain? A flat-rate Berachain RPC endpoint gives you chain 80094 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/berachain?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.

DEV Community: SwiftNodes

What Is EIP-7702? EOAs That Act Like Smart Accounts

The problem: EOAs are stuck, and ERC-4337 asked you to move

How it works: the delegation designator

What it unlocks

What changes when you're building over RPC

The takeaway

Getting Bitcoin Data: Core RPC vs Blockbook vs Hosted Address APIs

Why Core RPC can't answer address questions

The three ways to get the data

1. Raw Bitcoin Core JSON-RPC

2. Blockbook (the Trezor address indexer)

3. Esplora / electrs (the Electrum-family indexers)

What each actually gives you

The provider gotcha

What to check when picking a Bitcoin RPC provider

The takeaway

Sending a Raw Transaction: Why eth_sendTransaction Doesn't Work on a Provider

Two methods, and why only one works

Anatomy of a transaction

The build → sign → send flow

Doing it from a library

Gotchas

The takeaway

How Do Blockchain Bridges Work? Lock-Mint, Burn-Mint, and Who You're Trusting

Why bridging is hard at all

The main mechanisms

Lock-and-mint

Burn-and-mint

Liquidity-pool bridges

Canonical (native) rollup bridges

The question that actually determines safety

The developer's view

The takeaway

Linea RPC: The zkEVM Where Gas Estimation Works Differently

Connecting

What "zkEVM" means here

The gas estimation gotcha

Finality: the finalized tag means something specific

Indexing and events

The Consensys distribution angle

The short version

eth_call State Overrides: Simulate Against State That Doesn't Exist

The third parameter

A reproducible example

Where this is actually useful

state vs stateDiff — use stateDiff

Doing it from a library

Gotchas

The takeaway

Ankr Alternative: Public Endpoints, API Credits, and the Flat-Rate Option

Wall one: the public endpoint is capped by design

Wall two: paid means API credits, priced per method

What flat-rate changes

When Ankr is the right call

Migration is a URL swap

Robinhood Chain RPC: Tokenized Stocks on an Arbitrum Orbit L2

Connecting

What "Arbitrum Orbit" buys you

The one thing that isn't standard: the assets themselves

Reading balances and prices correctly

Indexing and event streams

Honest notes on a young chain

The short version

Scroll RPC: The zkEVM That Runs Ethereum Bytecode Unchanged

The essentials

The headline: "equivalent," not just "compatible"

Finality: fast, and actually final in ~1 hour

What carries over unchanged (essentially everything)

The short version

Rollup vs Validium vs Optimium: Where Your L2's Data Actually Lives

Two independent questions

The four combinations

Why the DA choice is the one that bites

What it means for you as a developer

The short version

Is Your RPC Node Actually at the Chain Tip? How to Catch a Stale Endpoint

The trap: eth_syncing returns false for two opposite states

The real check: compare block height to a reference

Why "it responds" is not "it's synced"

Finality: the `finalized` tag means something specific

The trap: `eth_syncing` returns `false` for two opposite states