DEV Community: SwiftNodes

Starknet RPC: It's JSON-RPC, but Almost Nothing Else From Ethereum Transfers

SwiftNodes — Thu, 30 Jul 2026 06:41:24 +0000

Almost every chain we've covered is EVM, and the pitch is the same: point viem or ethers at the endpoint and your Ethereum knowledge carries over. Starknet is the one where that's not true. It's a validity (ZK) rollup on Ethereum, but the execution layer is Cairo, not the EVM — different VM, different contract language, different account model. The RPC is still JSON-RPC over HTTP, so at a glance it looks familiar, but it's the starknet_* namespace, not eth_* — which means your EVM toolchain won't connect and your mental model needs adjusting. If you're coming from Ethereum, this is the spotlight to read slowly. Here's the map.

The essentials

Starknet mainnet is chain SN_MAIN (starknet_chainId returns the felt-encoded string 0x534e5f4d41494e), a STARK validity rollup with:

Cairo VM, not EVM — contracts are written in Cairo and run on the Starknet OS; Solidity and EVM bytecode don't apply.
STRK as the fee/staking token (18 decimals), launched February 2024.
Validity-proof finality — every state update ships with a STARK proof verified on Ethereum L1, so once proven it's cryptographically final (no fraud-proof challenge window).
A versioned JSON-RPC spec — the endpoint above reports starknet_specVersion 0.10.2; the method set is a formal, versioned standard.
Its own toolchain — starknet.js / starknet.py, starkli, and scarb (Cairo build). Not foundry/hardhat/viem.

Connecting uses a Starknet library, not an EVM one:

import { RpcProvider } from "starknet";

const provider = new RpcProvider({
  nodeUrl: "https://rpc.swiftnodes.io/rpc/starknet?key=YOUR_API_KEY",
});

await provider.getBlockNumber();          // starknet_blockNumber under the hood
await provider.getSpecVersion();          // "0.10.2"

Point viem/ethers at the same URL and it fails — those speak eth_*, and Starknet doesn't answer to that namespace.

The method map: eth_* → starknet_*

The concepts you use daily mostly have an analogue — just under a different name and with different shapes:

You want to…	Ethereum (`eth_*`)	Starknet (`starknet_*`)
Latest block height	`eth_blockNumber`	`starknet_blockNumber`
Read a block	`eth_getBlockByNumber`	`starknet_getBlockWithTxs`
Call a view function	`eth_call`	`starknet_call`
Read storage	`eth_getStorageAt`	`starknet_getStorageAt`
Estimate cost	`eth_estimateGas`	`starknet_estimateFee`
Fetch a receipt	`eth_getTransactionReceipt`	`starknet_getTransactionReceipt`
Query events/logs	`eth_getLogs`	`starknet_getEvents` (continuation tokens)
Submit a transaction	`eth_sendRawTransaction`	`starknet_addInvokeTransaction`

Two things to notice immediately: there's no single "send raw transaction" — you submit INVOKE, DECLARE, or DEPLOY_ACCOUNT transactions depending on intent — and event querying uses continuation tokens for pagination rather than a fromBlock/toBlock range you scan yourself (a different rhythm from the eth_getLogs range-cap dance).

Big difference #1: every account is a contract (native AA, no EOAs)

This is the one that trips up Ethereum developers hardest. Starknet has no externally-owned accounts. There is no "private key = address." Every account is a deployed smart contract that holds its own signature-verification logic — account abstraction isn't a bolt-on standard like ERC-4337, it's the only account model.

Practical consequences from the RPC's perspective:

To send a transaction, you invoke through your account contract (an INVOKE), which the account validates with whatever scheme it implements.
A brand-new account must be deployed (DEPLOY_ACCOUNT) before it can transact — the "just receive funds and go" flow from Ethereum doesn't exist.
Multicall is native — an account can carry multiple calls in one transaction without a Multicall contract.
Signature formats are account-defined, so don't assume secp256k1/ECDSA (Starknet commonly uses the STARK-friendly curve).

If you liked the account-abstraction direction on zkSync Era, Starknet takes it all the way: there, AA is native but the chain is still EVM-compatible; here, AA is native and the VM is Cairo.

Big difference #2: Cairo and felts, not Solidity and uint256

Starknet's fundamental data type is the field element (felt252), not the EVM's 32-byte word. Addresses, storage keys, calldata, and return values are felts. When you call a contract, arguments and results are arrays of felts, and it's on you (or the library's ABI layer) to encode/decode Cairo types into and out of them. There are no Solidity ABIs — Cairo has its own ABI format, and starknet.js handles the marshalling if you feed it the contract's ABI.

The upshot: address handling and calldata encoding are different enough that you can't reuse EVM helpers. A Starknet address isn't a 20-byte hex string; contract calls aren't 4-byte selectors plus ABI-packed args. Lean on the Starknet library rather than hand-rolling.

Finality: STARK-proven, so no challenge window

Unlike the optimistic rollups we've covered (Blast, Unichain, Fraxtal) — where hard finality waits out a 7-to-14-day fraud-proof window — Starknet is a validity rollup. State transitions are accompanied by a STARK proof verified on Ethereum, so once that proof settles, the state is cryptographically final; there's nothing to challenge. The two tiers are:

Soft confirmation on Starknet within seconds to minutes (the sequencer has accepted and sequenced your transaction).
Hard finality once the STARK proof is verified on L1 — final by math, not by an elapsed dispute period.

That's a genuinely different finality story from optimistic L2s; the general model is in soft vs. hard finality, and like every rollup there's a sequencer ordering transactions before proofs settle.

What does NOT carry over

Be explicit with yourself before you start:

eth_* methods — not available; use starknet_*.
viem / ethers / web3.py / foundry / hardhat — they speak EVM JSON-RPC and Solidity; use starknet.js / starknet.py / starkli / scarb.
Solidity, EVM bytecode, 4-byte selectors, 20-byte addresses, uint256 words — replaced by Cairo, felts, and the Cairo ABI.
EOAs and raw eth_sendRawTransaction — replaced by account contracts and INVOKE/DECLARE/DEPLOY_ACCOUNT.

What does carry over is the shape of the work: it's still JSON-RPC over HTTP(S), you still read blocks/receipts/events and submit transactions, and reading a receipt to confirm success is conceptually the same check — just via starknet_getTransactionReceipt and Starknet's status fields.

The short version

Starknet (chain SN_MAIN) is a non-EVM STARK validity rollup: JSON-RPC over HTTP like Ethereum, but the starknet_* namespace, not eth_* — so viem/ethers/foundry don't connect and you use starknet.js/starkli instead. Contracts are Cairo, values are felts, and every account is a contract (native account abstraction, no EOAs — you send INVOKE transactions through your account, and new accounts must be deployed first). Most eth_* calls have a starknet_* analogue (with starknet_getEvents using continuation tokens), and finality is STARK-proven with no challenge window — cryptographic once the proof lands on L1. Treat it as its own platform that happens to share Ethereum's RPC transport, not as another EVM chain.

Building Cairo dApps, account-abstraction wallets, or indexers over Starknet? A flat-rate Starknet RPC endpoint gives you the full starknet_* JSON-RPC over HTTP alongside 75+ other chains under one key. Grab a free key and point your stack at:

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

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

SwiftNodes — Wed, 29 Jul 2026 06:28:20 +0000

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.

Fraxtal RPC: The OP Stack Chain That Doesn't Use ETH for Gas

SwiftNodes — Tue, 28 Jul 2026 05:06:26 +0000

Almost every OP Stack L2 shares one assumption: ETH is the gas token. Fraxtal breaks it. It's Frax Finance's Layer 2 — built on the OP Stack, aligned with the Optimism Superchain — but it runs on FRAX as the native gas asset, and it layers on a blockspace-incentive system (Flox) that pays contract developers for the gas their users spend. Underneath it's a standard EVM (chain ID 252, ordinary eth_*, viem/ethers/foundry unchanged), so the tooling is familiar. The two Frax-specific twists are what you actually need to design around. Here's the map.

The essentials

Fraxtal mainnet (live since February 2024) is chain ID 252, an OP Stack L2 with:

FRAX as the native gas token (18 decimals) — not ETH, which is the headline difference from most OP Stack chains.
~2-second blocks — fast L2 confirmation.
Optimistic rollup finality — soft confirmation is immediate on the L2; withdrawals to Ethereum follow the usual ~7-day challenge window.
EVM-compatible — Solidity, ABIs, and standard tooling deploy without changes.

Connecting is standard EVM — the one thing to get right is the native currency:

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

const fraxtal = defineChain({
  id: 252,
  name: "Fraxtal",
  nativeCurrency: { name: "Frax", symbol: "FRAX", decimals: 18 },  // not ETH
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/fraxtal?key=YOUR_API_KEY"] } },
});

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

Twist #1: gas is FRAX, not ETH

The practical consequence lives in your fee handling. eth_estimateGas still returns gas units the same way it does everywhere (gas estimation basics), and EIP-1559 fields behave normally — but the value you multiply by, the balance a user needs to transact, and the token your relayer or funding wallet must hold are all FRAX, not ETH. Anywhere your code hard-codes "the native token is ETH" for display, funding, or balance checks, Fraxtal will surprise you.

If you've read the Celo fee-currency post, this is a cousin — Celo lets you pay gas in various fee currencies, while Fraxtal simply makes the native gas token FRAX end to end. Either way, the lesson is the same one that recurs across non-ETH chains: don't assume the gas asset. Read it from the chain config.

Twist #2: Flox — gas that pays developers back

This is the feature that has no equivalent on a vanilla OP Stack L2. Fraxtal runs Flox, a blockspace incentive system that distributes FXTL points based on gas activity — and crucially, it rewards both the user who spends the gas and the contract they interact with. In other words, if users transact against your deployed contract, you accrue FXTL for that usage.

For a developer choosing where to deploy, that flips the usual calculus. On most chains, the gas your users spend is pure cost that leaves the ecosystem; on Fraxtal, it partially cycles back to the builders driving the activity. It's conceptually adjacent to Astar's dApp Staking, where on-chain rewards flow to contracts by usage — but Flox ties it directly to gas spent, so the metric is raw blockspace consumption rather than a separate staking vote.

From the RPC's point of view, Flox is a protocol/accounting layer — it doesn't change how you call the chain. You deploy and interact with eth_sendRawTransaction / eth_call exactly as normal; the FXTL accrual happens off to the side based on the gas those transactions burn. It's a reason to build here, not an API you invoke. (Tokenomics around FRAX and the frxUSD stablecoin have evolved through Frax's later upgrades — check Frax's official docs for the current specifics before you design economics around FXTL.)

OP Stack mechanics carry over

Because Fraxtal is OP Stack, everything you know from other Superchain L2s applies — the same model we covered on Unichain and Zora:

A sequencer orders transactions and gives near-instant soft confirmation; transaction data is posted to Ethereum L1.
Two-tier finality: the L2 head is fast and practically reliable, but true settlement — and any withdrawal back to Ethereum — waits out the ~7-day optimistic challenge window. If your app moves value L2→L1, design for that delay; see soft vs. hard finality.
Fee structure includes an L1 data component on top of L2 execution, so total cost tracks Ethereum's calldata pricing — just denominated in FRAX here.

What carries over unchanged

Aside from the FRAX gas token and Flox, treat Fraxtal 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.
18-decimal native token; WebSocket subscriptions (newHeads, logs) work; at ~2s blocks, streaming beats tight polling.

The short version

Fraxtal (chain ID 252) is Frax Finance's OP Stack L2 with two departures from the standard Superchain playbook: gas is paid in FRAX, not ETH (so never assume the native asset — read it from the chain config), and its Flox system pays FXTL points to both users and the contracts they use, turning gas spend into a builder incentive. Everything else is standard OP Stack — fast sequencer soft-confirmation, an L1 data-fee component, and a ~7-day withdrawal challenge window — over an ordinary eth_* EVM that viem/ethers/foundry drive unchanged. Build it like any OP Stack chain; just get the gas token and the withdrawal delay right.

Building on Frax's ecosystem — frxUSD settlement, liquid staking, or Flox-incentivized dApps? A flat-rate Fraxtal RPC endpoint gives you chain 252 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/fraxtal?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.

ZetaChain RPC: One Contract That Touches Native Bitcoin

SwiftNodes — Mon, 27 Jul 2026 10:31:47 +0000

Most "cross-chain" really means "wrap the asset and trust a bridge." ZetaChain takes a different swing: a smart contract on ZetaChain can read from and write to other chains directly — including chains that have no smart contracts of their own, like Bitcoin — while controlling the native asset, no wrapped token in sight. You write one Solidity contract, and it orchestrates value across many chains. The contract layer (ZetaEVM, chain ID 7000) is standard eth_*, so viem/ethers/foundry work unchanged — but the omnichain machinery underneath is what makes it interesting. Here's the map.

The essentials

ZetaChain mainnet is chain ID 7000, an EVM (ZetaEVM) with an unusual foundation:

Cosmos-SDK L1 with CometBFT consensus — validators stake ZETA; ~5-second blocks with instant, non-reversible BFT finality.
ZETA as the gas token (18 decimals).
Omnichain by design — cross-chain interoperability is a protocol feature, managed by a distributed TSS (threshold signature scheme) validator set.
EVM-compatible — deploy Solidity with standard tooling.

Connecting to the ZetaEVM is boringly standard:

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

const zeta = defineChain({
  id: 7000,
  name: "ZetaChain",
  nativeCurrency: { name: "ZETA", symbol: "ZETA", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/zetachain?key=YOUR_API_KEY"] } },
});

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

The headline: omnichain contracts over native assets

Here's what makes ZetaChain different from a bridge or a wrapped-asset chain. Its validator set collectively controls addresses on external chains via a threshold signature scheme — no single party holds the keys. That lets the chain itself hold and move native assets on Bitcoin, Ethereum, and other connected networks. So a contract on ZetaChain can:

React to a deposit on another chain (including a native BTC transfer) and run logic in response.
Move native assets on external chains as an outcome of that logic — without a centralized bridge operator and without minting a wrapped representation.

The concrete payoff developers point to: native Bitcoin DeFi. Instead of building on WBTC (a wrapped IOU with its own trust assumptions), a ZetaChain contract can work with actual BTC, because the TSS network can custody and release it. It's a genuinely different model from, say, Rootstock, which brings smart contracts to Bitcoin via merge-mining and a pegged BTC — ZetaChain instead reaches out to native Bitcoin (and other chains) from an omnichain hub.

How you actually use it from the RPC

For the developer, the good news is that this power is exposed through standard EVM calls. You interact with ZetaChain's cross-chain system contracts (its gateway and related protocol contracts) the same way you'd call any contract — eth_call to read, eth_sendRawTransaction to write. The omnichain behavior is what those system contracts do; the interface is ordinary EVM:

Deploy your omnichain contract with foundry/hardhat like any Solidity contract.
Read cross-chain state and balances with eth_call.
Trigger cross-chain actions by calling the gateway; the TSS network carries them out on the target chain.
Watch results with eth_getLogs / eth_subscribe on ZetaEVM, plus the connected-chain confirmations.

You don't need a special RPC namespace for the cross-chain part — it's all Solidity and eth_*, which is why standard tooling works. (Under the hood it's a Cosmos-SDK chain, like the "EVM cockpit over a Cosmos engine" pattern we covered on Kaia and Story; the native Cosmos layer is reachable via CometBFT RPC as in the Cosmos RPC explainer, but for EVM work you stay on chain 7000.)

Finality: instant, so index the head

CometBFT gives instant, single-slot BFT finality — a committed block is final, no reorgs. That matters doubly for an omnichain chain: a cross-chain action you observed as final won't be undone on the ZetaChain side. The whole class of reorg-handling defenses collapses to "confirm once" on ZetaEVM. (The connected chains keep their own finality characteristics — a native BTC leg still follows Bitcoin's probabilistic confirmations — so cross-chain flows are as final as their slowest chain, which is worth designing around.)

What carries over unchanged

On the ZetaEVM (chain 7000), 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.
ZETA is the gas token with 18 decimals; WebSocket subscriptions (newHeads, logs) work.

If your app spans native UTXO chains too (ZetaChain famously connects to Bitcoin), it's worth understanding the UTXO side as well — see the Litecoin/Blockbook spotlight for how non-account chains are queried.

The short version

ZetaChain (EVM chain ID 7000) is an omnichain L1: a single Solidity contract can read and write across connected chains — including native Bitcoin, with no wrapping and no centralized bridge — because a TSS validator set lets the chain custody and move native assets on external networks. The ZetaEVM is standard eth_* (viem/ethers/foundry unchanged) and you drive the cross-chain machinery through ordinary contract calls; underneath it's a Cosmos-SDK chain with instant BFT finality (confirm once on ZetaEVM). Build the EVM side like any EVM chain, and reach out to other chains through the omnichain gateway.

Building omnichain apps, native Bitcoin DeFi, or bridgeless cross-chain flows? A flat-rate ZetaChain RPC endpoint gives you chain 7000 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/zetachain?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.

Plasma RPC: The Chain Where Sending USDT Costs Nothing

SwiftNodes — Sun, 26 Jul 2026 06:36:26 +0000

Most chains treat stablecoins as just another ERC-20. Plasma treats them as the point. It's an EVM Layer 1 purpose-built for stablecoin payments, and its headline feature is one users feel immediately: basic USDT transfers are zero-fee, sponsored by a protocol-level paymaster — so a user can send USDT without holding the native token at all. For a developer building payments, that removes the single biggest friction on every other chain. Plasma is standard EVM underneath (chain ID 9745, ordinary eth_*, viem/ethers/foundry unchanged), but the stablecoin-first design is the reason to build here. Here's the map.

The essentials

Plasma mainnet (beta since September 2025) is chain ID 9745, an EVM Layer 1 with:

XPL as the native gas token (18 decimals) — but often not the token users actually pay with (see below).
Sub-second blocks and fast BFT finality via PlasmaBFT consensus.
Bitcoin anchoring — Plasma periodically anchors its state to Bitcoin for added security.
EVM-compatible — Solidity, ABIs, and standard tooling deploy without changes.

Connecting is standard EVM:

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

const plasma = defineChain({
  id: 9745,
  name: "Plasma",
  nativeCurrency: { name: "XPL", symbol: "XPL", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/plasma?key=YOUR_API_KEY"] } },
});

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

The headline: zero-fee USDT transfers

The feature that defines Plasma is a protocol paymaster that sponsors basic USDT transfers. In practice:

A user can send USDT with no gas fee and without holding XPL. The "you must acquire the native token before you can move anything" cliff — the one that kills onboarding on every other chain — simply isn't there for the most common action.
For a payments product, that's transformative: someone can receive USDT and immediately send it onward, with no prior funding step and no native-token balance to manage.

The developer implication is that your payment flows can assume gasless USDT movement for basic transfers. You're not integrating a third-party paymaster or building meta-transaction relayers — the sponsorship is a protocol feature of the chain. (If you've read the Celo fee-currency post, this is a close cousin — but where Celo lets you pay gas in a stablecoin, Plasma sponsors the basic transfer outright.)

Gas in stablecoins for everything else

Zero-fee covers basic USDT transfers; for more complex transactions, Plasma lets users pay gas in stablecoins rather than requiring XPL. So even a contract interaction doesn't force a user to hold the native token — they can settle fees in the stablecoin they already have.

For you, that means the same design consideration Celo introduced: gas isn't purely a native-token concern. Standard eth_estimateGas still returns the gas units (gas estimation basics); the stablecoin-fee layer sits on top, converting that to a charge in the chosen token. If you build with XPL as the fee token, everything behaves like a vanilla EVM chain — the stablecoin options are there when you want them.

Sub-second BFT finality: built for payments

PlasmaBFT gives sub-second block times and fast BFT finality — which matters enormously for a payments chain:

Payments confirm in well under a second and don't reverse. For a point-of-sale or remittance flow, "did it go through?" resolves instantly.
No reorgs to defend against. BFT finality means a confirmed block is final — the whole class of reorg-handling patterns reduces to "confirm once." Index at the head and trust it. It's the same fast-finality comfort as other BFT EVM chains like Kaia and Flare.

The Bitcoin anchoring adds a second layer to the security story — Plasma periodically commits its state to Bitcoin, borrowing Bitcoin's settlement assurances for long-range integrity. It's mostly invisible from the RPC, but it's part of why a stablecoin-settlement chain leans on it.

What carries over unchanged

Aside from the paymaster and stablecoin-fee model, treat Plasma 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.
XPL is the native gas token with 18 decimals; WebSocket subscriptions (newHeads, logs) work; at sub-second blocks, stream rather than poll.

Two practical notes: because it's a stablecoin-heavy chain, your indexing will be dominated by ERC-20 Transfer events (USDT movement) — filter on the transfer signature and the token address. And it's a young chain (mainnet beta since late 2025), so parameters can still evolve — check Plasma's official docs for the latest specifics before shipping.

The short version

Plasma (chain ID 9745) is a stablecoin-focused EVM L1 whose defining feature is a protocol paymaster that makes basic USDT transfers zero-fee — users send USDT with no gas and no native token — with gas payable in stablecoins for everything else. It's standard EVM (XPL native gas, viem/ethers/foundry unchanged), with sub-second PlasmaBFT finality (confirm once, no reorgs) and Bitcoin anchoring for added security. Build it like any EVM chain, and lean on the gasless-stablecoin model for payment UX.

Building stablecoin payments, remittances, or cross-border settlement? A flat-rate Plasma RPC endpoint gives you chain 9745 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/plasma?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.

Astar RPC: One Chain, Two VMs, Polkadot Security

SwiftNodes — Sat, 25 Jul 2026 06:31:14 +0000

Most chains give you one virtual machine. Astar gives you two: a full EVM environment and WebAssembly (Wasm) contracts, on the same Polkadot parachain. If you're building with Solidity, you use the EVM side — chain ID 592, ordinary eth_*, viem/ethers/foundry unchanged — and you may never touch the Wasm layer. But it's worth knowing what's underneath, because Astar is a Substrate-based Polkadot parachain, and that gives it a security and finality model different from a standalone L1 or a rollup. Here's the map.

The essentials

Astar's EVM is chain ID 592, with:

ASTR as the gas token (18 decimals) — also used for staking and dApp Staking.
~12-second blocks with deterministic finality via Polkadot's GRANDPA finality gadget.
Polkadot parachain — inherits shared security from the Polkadot relay chain via nominated proof-of-stake.
Dual VM — EVM (Solidity) and Wasm (ink!) contracts coexist on the network.

For Solidity work, connecting is completely standard:

import { createPublicClient, http } from "viem";
import { astar } from "viem/chains";   // chain ID 592

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

One clarification up front: chain 592 is the Polkadot-based Astar EVM. Astar has separately operated a zkEVM deployment on different infrastructure — that's a distinct network. When you point tooling at chain 592, you're on the parachain EVM.

The dual-VM model: EVM and Wasm

Astar's defining trait is that it runs two smart-contract environments side by side:

EVM — standard Solidity, deployed and called exactly as on Ethereum. This is what chain 592's RPC serves.
Wasm (ink!) — Rust-based WebAssembly contracts, native to the Substrate/Polkadot world.

For an RPC consumer, the practical takeaway is simple: the EVM side is a normal eth_* endpoint, so your Solidity contracts, ABIs, and tooling work with zero changes. The Wasm side lives in the Substrate layer and is reached through Polkadot's own RPC (Substrate JSON-RPC / Polkadot.js), not eth_*. If you're doing pure Solidity, you stay entirely in the EVM RPC and the Wasm layer is just... there, an option for teams that want it. The two can interoperate, but that's an advanced path — most EVM developers use chain 592 like any other EVM chain.

The parachain model: what changes underneath

Astar isn't a standalone L1 and isn't a rollup — it's a parachain, which shapes two things worth understanding:

Shared security from Polkadot. Rather than bootstrapping its own validator economy, Astar inherits security from the Polkadot relay chain's validator set (nominated PoS). Its safety rides on Polkadot's.
Deterministic finality via GRANDPA. Polkadot's finality gadget provides deterministic finality — once a block is finalized, it's irreversible. That means no reorgs to defend against once finality is reached. The whole class of reorg-handling patterns — waiting many confirmations, tolerating tip rollbacks — reduces to tracking the finalized head. It's the same "confirm once" comfort you get on other deterministic-finality EVM chains like Kaia and Flare, just delivered by Polkadot's consensus rather than a chain-specific one.

There's also a conceptual parallel worth drawing: like the Cosmos chains where an EVM sits atop a non-EVM native layer, Astar's EVM (via the Frontier compatibility layer) sits atop Substrate. You mostly won't see it from the eth_* RPC, but it's why the underlying architecture differs from a from-scratch EVM chain. (If you've read the Cosmos RPC explainer, it's a similar "EVM cockpit over a different engine" idea — and different again from a non-EVM chain like Sui with its own object model.)

dApp Staking: an ecosystem quirk worth knowing

Astar has a distinctive dApp Staking program: ASTR stakers can direct rewards to the projects building on the network, so dApps earn ongoing support based on the stake backing them. It doesn't change your RPC integration, but it's part of why teams choose to build here — worth a mention if you're evaluating the chain, not just querying it.

What carries over unchanged

On the EVM side (chain 592), treat Astar 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.
ASTR is the gas token with 18 decimals; WebSocket subscriptions (newHeads, logs) work; if you're pulling lots of reads, batch them.

The short version

Astar (EVM chain ID 592) is a Polkadot parachain that runs both EVM and Wasm contracts. For Solidity, it's a standard eth_* endpoint — viem/ethers/foundry unchanged — while the Wasm (ink!) side lives in the Substrate layer reached via Polkadot's RPC. The parachain model gives it shared security from Polkadot and deterministic GRANDPA finality (no reorgs once finalized, so index the finalized head and confirm once). Build the EVM side like any EVM chain; know that the Wasm option and Substrate underpinnings are there.

Deploying Solidity on Astar, or building across its EVM and Wasm environments? A flat-rate Astar RPC endpoint gives you chain 592 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/astar?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.

Flare RPC: The L1 With Oracles Built Into the Protocol

SwiftNodes — Fri, 24 Jul 2026 04:40:48 +0000

On most chains, getting external data into a smart contract means integrating a third-party oracle — deploy against Chainlink, wire up feeds, manage the dependency. Flare inverts that: the oracle is part of the chain. Decentralized price feeds (FTSO) and cross-chain/Web2 data verification (FDC) are enshrined protocol primitives — contracts read them natively, with no external oracle to deploy or pay. For a developer, Flare is a standard EVM L1 on the surface (chain ID 14, ordinary eth_*, viem/ethers/foundry unchanged) — but its native data layers are the reason to build here, and they're all reachable over the same RPC. Here's the map.

The essentials

Flare mainnet is chain ID 14, an EVM Layer 1 with:

FLR as the gas token (18 decimals).
~1.8-second blocks with near-instant finality — once a block is accepted, it's final.
Snowman++ / Federated Byzantine Agreement consensus (Avalanche-derived) — fast, BFT-style finality.
EVM-compatible — Solidity, ABIs, and standard tooling work directly.

Connecting is boringly standard EVM:

import { createPublicClient, http } from "viem";
import { flare } from "viem/chains";   // chain ID 14

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

What makes Flare different: enshrined data protocols

Flare's reason to exist is bringing trustworthy external data on-chain natively. Two protocols are built into the base layer:

FTSO (Flare Time Series Oracle) — decentralized price and time-series feeds, sourced from a set of independent data providers and delivered on-chain. Instead of integrating an external price oracle, a Flare contract reads FTSO feeds directly.
FDC (Flare Data Connector) — lets contracts verify state from other blockchains and Web2 sources. It's the "is this true on chain X / at URL Y?" primitive, enshrined so contracts can trust attested external data.

The key point for RPC consumers: you access these the same way you access any contract — with eth_call. FTSO and FDC are exposed through on-chain system contracts, so reading a price feed or a verified data attestation is a normal EVM read against a known address. There's no separate oracle API and no special RPC namespace — the "oracle" is just more state your standard eth_call can reach.

// FTSO feeds and FDC attestations are read like any contract — standard eth_call.
const price = await client.readContract({
  address: ftsoRegistryOrFeedAddress,   // Flare's enshrined FTSO system contract
  abi: ftsoAbi,
  functionName: "getFeedById",          // exact method depends on the FTSO version/interface
  args: [feedId],
});

The developer implication is that a DeFi app needing prices, or a cross-chain app needing to verify a deposit on another network, does that with native reads rather than a third-party oracle integration. If you're pulling several feeds at once, batch the calls to cut round-trips — it's the same JSON-RPC batching you'd use anywhere.

Finality: near-instant, so drop the reorg defenses

Flare's FBA/Snowman++ consensus gives near-immediate finality — once a block is accepted, it doesn't roll back. Practically:

No reorgs to defend against. The whole class of reorg-handling patterns — waiting N confirmations, keying on (txHash, logIndex), tolerating tip rollbacks — collapses to "confirm once." Index at the head and trust it.
This matters doubly for oracle-consuming apps: a price read or a cross-chain attestation you acted on won't be undone by a reorg. That's the kind of guarantee you want when a feed drives liquidations or a bridge.

It's the same fast-finality profile as other BFT-style EVM L1s we've covered, like Kaia and Sei — code written to wait 12 confirmations is just adding latency here.

What carries over unchanged

Aside from the native data layers, treat Flare as a standard EVM chain:

eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally — including reading receipts for your own transactions.
Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
FLR is the gas token with 18 decimals; WebSocket subscriptions (newHeads, logs) work; at ~1.8s blocks, stream rather than poll.

The short version

Flare (chain ID 14) is an EVM L1 with oracles enshrined in the protocol: FTSO delivers decentralized price/time-series feeds and FDC verifies cross-chain and Web2 data, both read through on-chain system contracts with ordinary eth_call — no third-party oracle to deploy or pay. It's standard EVM otherwise (FLR gas, ~1.8s blocks, viem/ethers/foundry unchanged), with near-instant finality so you can drop confirmation-counting and reorg defenses. Build it like any EVM chain, and lean on the native data layers instead of bolting on an external oracle.

Building DeFi that needs price feeds, or cross-chain apps that verify external state? A flat-rate Flare RPC endpoint gives you chain 14 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/flare?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.

Cosmos RPC Explained: Tendermint RPC vs REST vs gRPC

SwiftNodes — Thu, 23 Jul 2026 06:40:51 +0000

If you come to the Cosmos ecosystem from Ethereum, the first thing that trips you up isn't the SDK or the tokens — it's the word "RPC." On Ethereum, the RPC is a single JSON-RPC endpoint, and eth_* methods do everything. On a Cosmos chain, "RPC" can mean three different interfaces, each running on its own port, each answering a different kind of question. Point CosmJS at the wrong one and nothing works. This post clears that up: what the three interfaces are, when to use each, and the one mental shift — you query modules, not contracts — that makes the whole thing click. It applies to every Cosmos-SDK chain, including the ones we've spotlighted: Celestia, Osmosis, and Injective.

First, the mental shift: modules, not contracts

On Ethereum, state lives inside smart contracts, and you read it by eth_call-ing a contract function. On a Cosmos chain, the base functionality — balances, staking, governance, and app-specific logic — lives in modules compiled into the chain binary (bank, staking, gov, plus app modules like Osmosis's poolmanager). You don't call a contract's balanceOf; you query the bank module for an address's balance.

So there's no eth_getBalance, no eth_getLogs, no eth_call. Instead, every interface below is a different way to reach the same module queries and the underlying consensus data. Keep that in mind and the three endpoints stop being confusing — they're three doors into the same house.

The three interfaces

1. Tendermint / CometBFT RPC — the consensus layer (port 26657)

This is what people usually mean by "the Cosmos RPC," and it's what an integration points CosmJS at. It's a JSON-RPC (and URI) interface to the consensus engine — CometBFT (formerly Tendermint) — exposing:

Chain/consensus data: status, block, block_results, commit, validators.
Transactions: tx, tx_search, and broadcasting via broadcast_tx_sync / _async / _commit.
Generic state access: abci_query — the escape hatch that lets you query any module's state by path.

It's the lowest-level, most universal interface: block data, transaction submission, and (via abci_query) all module state. If you're tailing the chain, broadcasting transactions, or building with CosmJS, this is your endpoint.

import { StargateClient } from "@cosmjs/stargate";

// CosmJS talks to the Tendermint/CometBFT RPC
const client = await StargateClient.connect(
  "https://rpc.swiftnodes.io/rpc/osmosis?key=YOUR_API_KEY"
);
console.log(await client.getHeight());             // current block height
console.log(await client.getAllBalances(address)); // bank module, under the hood

2. REST / LCD — the HTTP gateway (port 1317)

The LCD ("Light Client Daemon," now just the REST API) is a RESTful gateway that maps plain HTTP GET paths to the same module queries. It's generated from the modules' protobuf definitions via gRPC-gateway, so every query has a URL:

GET /cosmos/bank/v1beta1/balances/{address}
GET /cosmos/staking/v1beta1/validators
GET /osmosis/poolmanager/v1beta1/pools

REST is the convenient choice for browsers, quick scripts, and reading module state without any protobuf tooling — paste a URL, get JSON. It's a read-and-broadcast gateway, not a consensus interface: you won't tail blocks here, but you'll happily fetch balances, positions, and app-module state.

3. gRPC — the typed interface (port 9090)

Under the hood, Cosmos modules define their queries in protobuf, and gRPC is the native, strongly-typed way to call them. With generated clients you get type safety, efficient binary encoding, and streaming — the right choice for production backends that want typed queries rather than hand-built URLs or JSON. REST is literally a gateway in front of gRPC, so anything REST can do, gRPC can do with types.

Which one do I use?

Task	Interface
Tail blocks, get consensus/tx data	Tendermint RPC
Broadcast a signed transaction	Tendermint RPC (`broadcast_tx_*`)
Quick reads, browser apps, no tooling	REST / LCD
Typed queries in a production backend	gRPC
Generic "query any module state"	Tendermint RPC `abci_query`

For most integrations — wallets, indexers, dApps built with CosmJS — you'll live in the Tendermint RPC, because it covers block data, transaction submission, and (via abci_query) all module state. That's the endpoint SwiftNodes serves at /rpc/<chain> for Cosmos chains.

Broadcasting transactions: messages, not calldata

Cosmos transactions aren't EVM calldata — they're Cosmos SDK messages (Msg types: MsgSend, MsgDelegate, Osmosis's MsgSwapExactAmountIn, etc.). You build and sign them with CosmJS, then broadcast over the Tendermint RPC:

import { SigningStargateClient } from "@cosmjs/stargate";

const client = await SigningStargateClient.connectWithSigner(
  "https://rpc.swiftnodes.io/rpc/osmosis?key=YOUR_API_KEY", wallet
);
await client.sendTokens(from, to, [{ denom: "uosmo", amount: "1000000" }], "auto");

Two Cosmos gotchas worth flagging, both covered in the Osmosis spotlight: amounts are in micro-denominations (uosmo, uatom — 1 token = 1,000,000 base units), and cross-chain assets show up as ibc/<HASH> denoms you resolve via the denom trace.

Finality: single-block, no reorgs

One genuinely nice thing after Ethereum: CometBFT gives single-block BFT finality. When a block commits, it's final — there are no reorgs, no confirmation counting, no "wait 12 blocks." Index at the tip and trust it. (Contrast with the reorg defenses probabilistic chains force on you — none of that here.)

How this maps to the Cosmos chains you'll use

Every Cosmos-SDK chain follows this same three-interface pattern; only the app modules differ:

Celestia — a modular data-availability layer; its core consensus RPC is standard CometBFT, with blob submission living in a separate node API.
Osmosis — a DEX where the AMM is a native module (poolmanager/gamm), queried through exactly these interfaces rather than a smart contract.
Injective — a finance-focused chain whose order-book and exchange logic are likewise native modules (Injective RPC).

Learn the pattern once and every Cosmos chain is approachable — the modules change, the three doors don't. And since the Tendermint RPC is plain JSON-RPC, standard conveniences like request batching still apply when you're making many reads. (It's a different world from the non-Cosmos non-EVM chains like Sui, which has its own object-model API entirely.)

The short version

"Cosmos RPC" isn't one thing — it's three interfaces to the same chain: Tendermint/CometBFT RPC (consensus + tx broadcast + generic abci_query, port 26657, what CosmJS uses), REST/LCD (HTTP gateway to module queries, port 1317, browser-friendly), and gRPC (typed protobuf queries, port 9090, for backends). The unifying idea is that you query modules, not contracts — no eth_*, no balanceOf; you ask the bank module for a balance and the app module for app state. Transactions are signed Msg types broadcast over the Tendermint RPC, and finality is single-block (no reorgs).

Building on the Cosmos ecosystem? A flat-rate Cosmos RPC endpoint gives you CometBFT RPC across Celestia, Osmosis, Injective, the Cosmos Hub and more — all under one key. Grab a free key and connect CosmJS to:

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

Celo RPC: The L2 Where You Pay Gas in Stablecoins

SwiftNodes — Wed, 22 Jul 2026 06:59:18 +0000

Celo has a feature most EVM chains don't: you can pay gas in stablecoins. A user with only cUSD in their wallet can transact without ever holding the native token — the fee is charged in the ERC-20 they already have. For a mobile-first payments network, that's the whole point, and it's the thing that most changes how you build here. Celo is also unusual in another way: it migrated from a standalone Layer 1 to an Ethereum L2 in 2025, keeping the same chain ID through the transition. It's standard EVM either way — chain ID 42220, ordinary eth_*, viem/ethers unchanged — but two Celo-specific facts shape the work. Here's the map.

The essentials

Celo mainnet is chain ID 42220, and as of March 2025 it's an OP Stack Layer 2 on Ethereum:

CELO is the native gas token (18 decimals) — but not the only fee token (see below).
~1-second blocks — down from ~5s on the old L1, after the L2 migration.
OP Stack + EigenDA — Celo runs Optimism's stack but posts data to EigenDA for data availability rather than Ethereum blobs.
EVM-compatible — Solidity, ABIs, and standard tooling work directly.

Connecting is standard EVM:

import { createPublicClient, http } from "viem";
import { celo } from "viem/chains";   // chain ID 42220

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

The standout feature: fee currencies (gas in stablecoins)

On almost every chain, gas is paid in the native token — you must hold ETH, or CELO, or whatever, to move anything. Celo breaks that assumption with fee abstraction: a transaction can specify a feeCurrency — a whitelisted ERC-20 (like cUSD or cEUR) — and the protocol charges the fee in that token instead of CELO.

Why it matters:

Onboarding. A user funded with only a stablecoin can transact immediately — no "go acquire the gas token first" step. For payments and emerging-market use cases, that removes the single biggest UX cliff.
Predictable fees. Denominating fees in a stablecoin means the cost of a transaction doesn't swing with the native token's price.

The developer implication is that gas isn't purely a native-token concern here. If you're building wallet or payment flows, you deal with an extra field: transactions can carry a feeCurrency, and estimating cost means knowing which token the fee is in. Standard eth_estimateGas still returns the gas units (gas estimation basics); the fee-currency layer sits on top, converting that to a charge in the chosen ERC-20. If you use CELO as the fee token, everything behaves like a normal EVM chain — the abstraction is opt-in.

Design fact #2: it's now an OP Stack L2 (with EigenDA)

Celo launched as its own L1 in 2020 and completed its transition to an Ethereum L2 on March 26, 2025 (at block 31,056,500), rebuilt on the OP Stack. Two consequences:

OP Stack mechanics now apply. A sequencer orders transactions, gas has an L1 data-fee component, and withdrawals to Ethereum pass through the standard optimistic challenge window — the same model we covered on Unichain, Zora, and (as a contrast) the based-rollup Taiko. Finality is L2-soft/L1-hard; see soft vs hard finality.
Data availability is EigenDA, not Ethereum blobs. Rather than posting rollup data to Ethereum as blobs, Celo uses EigenDA — an external DA layer (conceptually similar to the modular-DA role Celestia plays). It's a cost/scaling choice and mostly invisible from the RPC, but it's why Celo's data-availability story differs from a vanilla OP Stack chain.

The nice part for existing integrations: the chain ID stayed 42220 through the migration, so your RPC endpoint config and chain references didn't need to change — only the underlying architecture did.

One more quirk: CELO token duality

CELO is the native gas token, but it also has an ERC-20 representation — "token duality." You can interact with CELO both as native value (like ETH) and via a standard ERC-20 interface at a well-known address. Most of the time you won't think about it, but if a contract expects an ERC-20 and you're dealing with the native token, that's the mechanism that bridges the two.

What carries over unchanged

Aside from fee currencies and the DA layer, treat Celo as a standard OP Stack EVM chain:

eth_call, eth_getLogs, eth_getBalance, eth_getTransactionReceipt, eth_sendRawTransaction, eth_subscribe all behave normally.
Solidity contracts, ABIs, and the viem/ethers/foundry toolchain deploy and run as-is.
WebSocket subscriptions (newHeads, logs) work; at ~1s blocks, stream rather than poll.

The short version

Celo (chain ID 42220) is now an OP Stack L2 (migrated from L1 in March 2025, using EigenDA for data availability), with ~1-second blocks and standard eth_* — viem/ethers work unchanged. Its two distinctive traits: fee currencies let users pay gas in stablecoins like cUSD instead of CELO (a mobile-first onboarding superpower, and an extra feeCurrency field in payment flows), and it's a rare chain that kept its chain ID through an L1→L2 migration. Build it like an OP Stack chain, and lean on fee abstraction if you're doing payments.

Building mobile payments, stablecoin apps, or ReFi on Celo? A flat-rate Celo RPC endpoint gives you chain 42220 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/celo?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.

WEMIX RPC: Building on a Gaming-First EVM Chain

SwiftNodes — Tue, 21 Jul 2026 07:06:04 +0000

WEMIX3.0 is the Layer 1 built by Wemade — a Korean game company, not a crypto-native team — and that origin shows in the design. It's tuned for games: fast blocks, high throughput, and a validator model that gives you immediate confirmation, which matters a lot when a player just minted an item or completed a trade. For a developer the good news is that it's standard EVM — chain ID 1111, ordinary eth_*, Solidity and viem/ethers unchanged. What's worth understanding is why it behaves the way it does, because two design choices shape how you build and index on it. Here's the map.

The essentials

WEMIX3.0 mainnet is chain ID 1111, an EVM Layer 1 with:

WEMIX as the gas token (18 decimals) — also used for staking.
~1-second blocks — short block times suited to game transaction volume.
Stake-based Proof-of-Authority — blocks are produced and the network governed by a council of up to 40 Node Council Partners, with a path toward a fuller staked-PoS model.
EVM-compatible — Solidity contracts and standard Ethereum tooling apply directly.

Connecting is boringly standard:

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

const wemix = defineChain({
  id: 1111,
  name: "WEMIX3.0",
  nativeCurrency: { name: "WEMIX", symbol: "WEMIX", decimals: 18 },
  rpcUrls: { default: { http: ["https://rpc.swiftnodes.io/rpc/wemix?key=YOUR_API_KEY"] } },
});

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

WEMIX shares its heritage with another Korean EVM chain we've covered: Wemade originally ran its tokens and games on Ethereum and Klaytn before migrating to its own chain in 2022. If you've built on Kaia (the Klaytn–Finschia merger), the ecosystem and tooling conventions will feel familiar.

Design choice #1: PoA council → instant finality, no reorgs

WEMIX doesn't use permissionless proof-of-stake or proof-of-work — it uses a stake-based Proof-of-Authority council of known validators. That's a genuine trade-off to be honest about (a curated validator set is more centralized than a permissionless one), but it buys a property developers care about: fast, deterministic finality.

The practical payoff for you:

No reorgs to defend against. With a known council producing blocks under BFT-style finality, a confirmed block stays confirmed. The whole class of reorg-handling defenses — waiting N confirmations, keying on (txHash, logIndex), tolerating tip rollbacks — mostly collapses to "confirm once." You can index at the head and trust it.
Immediate UX confirmation. For a game, "did my item mint land?" resolves in about a second and won't reverse. You don't have to build the "pending → maybe-reorged" state machine that probabilistic chains force on you.

Code written for Ethereum that waits 12 confirmations before treating a transaction as final is just adding a dozen seconds of pointless latency here.

Design choice #2: it's a gaming chain, so plan for game-shaped traffic

WEMIX's reason to exist is its game ecosystem — WEMIX PLAY (the game platform), NILE (DeFi and NFTs), WEMIX Pay (payments), and a stablecoin product. The consequence for an RPC consumer is a traffic profile dominated by high-frequency, asset-centric transactions: item mints, in-game economy transfers, NFT activity — often in bursts around game events or drops.

That shapes your indexing more than your write path (much like the mint-heavy pattern we covered on Zora):

Filter for asset events. Game items and rewards are ERC-721/1155 mints and transfers. Filter eth_getLogs on the event signature (topics[0]) plus from = 0x0 to isolate mints from ordinary transfers.
Page dense blocks. At ~1s blocks with burst traffic, a wide block range can return a lot of logs — page by block range and respect the endpoint's log/range limits.
Stream over WebSocket. For live game state, subscribe to logs/newHeads over wss:// rather than tight polling; at one-second blocks, polling lags fast.

// Stream ERC-721 item mints (Transfer from the zero address) live
const ws = new WebSocket("wss://rpc.swiftnodes.io/ws/wemix?key=YOUR_API_KEY");
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "eth_subscribe",
  params: ["logs", {
    topics: [
      "0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef", // Transfer
      "0x0000000000000000000000000000000000000000000000000000000000000000", // from 0x0 = mint
    ],
  }],
}));

What carries over unchanged

Past those two considerations, WEMIX is standard EVM:

eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave normally — see reading receipts and gas estimation.
Solidity contracts, ABIs, and the viem/ethers/hardhat/foundry toolchain deploy and run as-is.
WEMIX is the gas token with 18 decimals — no exotic fee handling.

The short version

WEMIX3.0 (chain ID 1111) is a gaming-first EVM L1 from Wemade: WEMIX gas, ~1-second blocks, and a stake-based PoA council of up to 40 validators. viem/ethers/foundry work unchanged. The two things that shape building on it: the PoA council gives deterministic finality with no reorgs (drop the confirmation-counting and reorg defenses — confirm once), and the game-heavy traffic means your indexing should be tuned for bursty ERC-721/1155 mint and transfer activity, streamed over WebSocket.

Building a game, a marketplace, or a WEMIX PLAY integration? A flat-rate WEMIX RPC endpoint gives you chain 1111 with WebSocket support alongside 75+ other chains under one key. Grab a free key and point your stack at:

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

Sui RPC: Where Everything You Own Is an Object

SwiftNodes — Mon, 20 Jul 2026 04:22:10 +0000

Most "alt-L1" chains still think in accounts and balances — Sui doesn't. On Sui, everything you own is a first-class object with its own ID and owner, and that single design decision changes the entire RPC surface. There's no eth_getBalance, no eth_call, no eth_getLogs. If you're arriving from Ethereum, the tooling is unfamiliar but the mental model is actually simpler once it clicks: you don't ask a contract what it thinks you own — you ask the chain which objects belong to your address. Here's the map.

The essentials

Sui is a non-EVM Layer 1 from Mysten Labs, mainnet since May 2023:

Move language (Sui Move) — resource-oriented, assets are safe by construction.
Object-centric model — assets are objects with owners, not entries in a contract's storage mapping.
Parallel execution — transactions touching disjoint objects don't contend and run concurrently.
Sub-second finality for owned-object transactions; a few seconds via consensus for shared objects.
SUI is the gas token, with 9 decimals (the base unit is MIST; 1 SUI = 1e9 MIST).
No fixed block time — the chain advances in checkpoints, not numbered blocks.

The RPC is JSON-RPC, but the method namespace is sui_* / suix_*, not eth_*. Use the official SDK:

import { SuiClient, getFullnodeUrl } from "@mysten/sui/client";

const client = new SuiClient({
  url: "https://rpc.swiftnodes.io/rpc/sui?key=YOUR_API_KEY",
});
await client.getLatestCheckpointSequenceNumber();   // the chain tip

The mental shift: query objects, not contract storage

On Ethereum, "what NFTs does this wallet hold?" means calling a contract's balanceOf/ownerOf or indexing Transfer events — you're reconstructing ownership from a contract's internal bookkeeping. On Sui, ownership is native to the protocol: every object records its owner, so you query it directly.

// Everything an address owns — coins, NFTs, arbitrary Move objects
const owned = await client.getOwnedObjects({ owner: address });

// A specific object by ID, with its Move type and fields
const obj = await client.getObject({
  id: objectId,
  options: { showType: true, showContent: true, showOwner: true },
});

// All coin balances for an address (SUI + any other coin type)
const balances = await client.getAllBalances({ owner: address });

That's the core reframe. getOwnedObjects is the query you'll reach for constantly — it's the "what does this address actually have?" primitive that Ethereum never gave you at the protocol level.

Owned vs shared objects: the finality fast path

Sui's speed comes from a distinction with no EVM equivalent, and it's worth understanding because it affects latency:

Owned objects (e.g., your coins, your NFT) have a single owner. A transaction touching only owned objects can skip full consensus and finalize in sub-second time — because nothing else can be mutating your object concurrently.
Shared objects (e.g., a DEX pool everyone trades against) can be touched by anyone, so those transactions go through the Mysticeti consensus path — still fast (a few seconds), but not the owned-object fast path.

For a developer this means: simple transfers and single-owner updates are extremely fast, while contended DeFi state settles through consensus. Design latency expectations around which kind of object a transaction touches.

Reading transactions and events (indexing)

There's no eth_getLogs, so the range-cap headaches don't apply — but you index differently:

// A transaction by digest, with effects, events, and object changes
const tx = await client.getTransactionBlock({
  digest,
  options: { showEffects: true, showEvents: true, showObjectChanges: true },
});

// Query events by type, module, or sender
const events = await client.queryEvents({
  query: { MoveModule: { package: pkgId, module: "my_module" } },
});

The chain tip is a checkpoint sequence number, not a block height — poll getLatestCheckpointSequenceNumber (or subscribe over WebSocket) and read checkpoints to tail the chain. objectChanges on a transaction tells you exactly which objects were created, mutated, or transferred — the object-model equivalent of parsing logs.

Standard JSON-RPC conveniences still apply — if you're making many independent reads, batch them to cut round-trips.

What's different from the other non-EVM chains

If you've built on the Cosmos chains we've covered — Celestia, Osmosis — note that Sui is not CometBFT/Tendermint either; it has its own sui_* API and consensus (Mysticeti). And unlike UTXO chains like Litecoin, Sui's objects are rich, typed, and programmable, not just unspent outputs. Sui is genuinely its own model — the closest intuition is "typed, owned objects" rather than accounts, UTXOs, or Cosmos modules.

The short version

Sui is a non-EVM Move L1 with an object-centric model: assets are first-class objects with owners, so you query ownership natively (getOwnedObjects, getObject, getAllBalances) instead of reconstructing it from contract storage. The API is sui_*/suix_* via the @mysten/sui SDK, not eth_*. SUI has 9 decimals (base unit MIST), the chain advances in checkpoints (no fixed blocks), and owned-object transactions finalize sub-second by skipping consensus while shared-object transactions settle through Mysticeti in a few seconds.

Building consumer-scale apps, on-chain games, or low-latency DeFi on Sui? A flat-rate Sui RPC endpoint gives you a full node's sui_* API alongside 75+ other chains under one key. Grab a free key and point the SDK at:

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

Taiko RPC: The L2 With No Sequencer

SwiftNodes — Sun, 19 Jul 2026 06:17:28 +0000

Every OP Stack chain we've covered — Base, Unichain, Zora — has a sequencer: one privileged party that orders transactions, and the thing you're implicitly trusting for liveness and fair ordering. Taiko doesn't have one. It's a based rollup: Ethereum's own validators propose Taiko's blocks as part of normal L1 block production. That single architectural choice cascades into everything a developer cares about — liveness, finality, MEV, and reliability. And because Taiko is also a Type-1 zkEVM, your Ethereum tooling works with zero changes. Here's the map for chain ID 167000.

The essentials

Taiko mainnet (Alethia) is chain ID 167000, an EVM Layer 2 with:

ETH as the gas token (18 decimals) — no separate gas token to source.
~12-second blocks, aligned with Ethereum's slot times — because block proposing rides on L1, the cadence follows L1.
Type-1 zkEVM equivalence — the most Ethereum-equivalent zkEVM design. Contracts deploy bit-identically; opcode behavior is exact.

Connecting is completely standard EVM:

import { createPublicClient, http } from "viem";
import { taiko } from "viem/chains";   // chain ID 167000

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

What "based" changes: no sequencer to trust — or to fail

On a typical rollup, a sequencer receives your transactions, orders them, and produces L2 blocks (what a sequencer does). It's efficient, but it's also a single point of trust and a single point of failure — sequencer outages have taken major L2s offline for hours. A "based" rollup removes it entirely:

Block proposing happens on Ethereum L1. Taiko blocks are proposed via L1 transactions, so Ethereum's proposers include them as part of normal block production. There is no separate Taiko sequencer.
Liveness = Ethereum's liveness. As long as Ethereum is producing blocks, Taiko is producing blocks. There is no "the sequencer is down" failure mode.
Censorship resistance = Ethereum's. Because anyone can propose via L1, ordering isn't controlled by one operator. This also reshapes MEV — there's no single sequencer with exclusive ordering rights to extract it.

For you as a builder, the practical upshot is reliability inherited from L1. The chain's uptime story is Ethereum's uptime story, not a startup's sequencer infrastructure.

What "Type-1 zkEVM" changes: your tooling doesn't know the difference

zkEVMs trade off equivalence for proving speed. Type-1 sits at the far equivalence end: exact Ethereum behavior, no bytecode-level compromises. In practice:

Solidity contracts, ABIs, and deployment bytecode are identical to L1 — deploy with foundry/hardhat unchanged, and addresses/behavior match.
eth_call, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction, eth_subscribe all behave exactly as on Ethereum.
Tooling that assumes precise Ethereum semantics (debuggers, tracers, gas profilers) works without special-casing.

If a chain is going to be "just Ethereum but cheaper," Type-1 is the version where that's literally true at the opcode level.

Finality: validity proofs, not a 7-day wait

This is where Taiko diverges sharply from the optimistic rollups (OP Stack, Arbitrum). Taiko is a zk-rollup — it proves state transitions with validity proofs instead of assuming-honest-then-challenging:

Soft confirmation at the ~12s block, like any L2 (see soft vs hard finality).
Hard finality once the zk proof is submitted to L1 — minutes, not the ~7-day optimistic challenge window that optimistic rollups impose on withdrawals. A validity proof mathematically establishes correctness, so there's nothing to challenge.

For anything touching L1 settlement or bridging, that's a materially faster and cleaner finality model. The trade-off Taiko accepts is slower proof generation (Type-1 equivalence makes proofs heavier) — but that's the prover's problem, not your app's.

What carries over unchanged (basically everything)

Because it's a Type-1 zkEVM, treat Taiko as Ethereum for development:

Data is posted to L1 (as blobs — see what are blobs), so the L1 data-fee component of gas applies, as on any rollup.
Indexing is standard: eth_getLogs by topic/address, WebSocket logs/newHeads subscriptions. At ~12s blocks, reorg risk at the tip is Ethereum-like — the usual reorg-handling patterns apply.
No exotic namespaces, no gas-token quirks, no sequencer-specific endpoints.

The one mental adjustment: block cadence is ~12s (L1-aligned), not the ~2s of an OP Stack chain like Unichain or Zora — size your polling and confirmation logic accordingly.

The short version

Taiko (chain ID 167000) is a based zk-rollup: Ethereum's validators propose its blocks, so there's no sequencer to trust or to go down — liveness and censorship-resistance are inherited from L1. It's a Type-1 zkEVM, so Solidity, ABIs, and every eth_* method behave bit-identically to Ethereum (viem/ethers/foundry work with zero changes). ETH gas, ~12s L1-aligned blocks, and zk validity-proof finality in minutes rather than the ~7-day withdrawal window of optimistic rollups.

Building on a rollup where uptime is Ethereum's uptime and your tooling doesn't need a single tweak? A flat-rate Taiko RPC endpoint gives you chain 167000 alongside 75+ others under one key. Grab a free key and point your stack at:

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

Starknet RPC: It's JSON-RPC, but Almost Nothing Else From Ethereum Transfers

The essentials

The method map: eth_* → starknet_*

Big difference #1: every account is a contract (native AA, no EOAs)

Big difference #2: Cairo and felts, not Solidity and uint256

Finality: STARK-proven, so no challenge window

What does NOT carry over

The short version

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

The essentials

The headline: balances that grow by themselves

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

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

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

What carries over unchanged

The short version

Fraxtal RPC: The OP Stack Chain That Doesn't Use ETH for Gas

The essentials

Twist #1: gas is FRAX, not ETH

Twist #2: Flox — gas that pays developers back

OP Stack mechanics carry over

What carries over unchanged

The short version

ZetaChain RPC: One Contract That Touches Native Bitcoin

The essentials

The headline: omnichain contracts over native assets

How you actually use it from the RPC

Finality: instant, so index the head

What carries over unchanged

The short version

Plasma RPC: The Chain Where Sending USDT Costs Nothing

The essentials

The headline: zero-fee USDT transfers

Gas in stablecoins for everything else

Sub-second BFT finality: built for payments

What carries over unchanged

The short version

Astar RPC: One Chain, Two VMs, Polkadot Security

The essentials

The dual-VM model: EVM and Wasm

The parachain model: what changes underneath

dApp Staking: an ecosystem quirk worth knowing

What carries over unchanged

The short version

Flare RPC: The L1 With Oracles Built Into the Protocol

The essentials

What makes Flare different: enshrined data protocols

Finality: near-instant, so drop the reorg defenses

What carries over unchanged

The short version

Cosmos RPC Explained: Tendermint RPC vs REST vs gRPC

First, the mental shift: modules, not contracts

The three interfaces

1. Tendermint / CometBFT RPC — the consensus layer (port 26657)

2. REST / LCD — the HTTP gateway (port 1317)

3. gRPC — the typed interface (port 9090)

Which one do I use?

Broadcasting transactions: messages, not calldata

Finality: single-block, no reorgs

How this maps to the Cosmos chains you'll use

The short version

Celo RPC: The L2 Where You Pay Gas in Stablecoins

The essentials

The standout feature: fee currencies (gas in stablecoins)

Design fact #2: it's now an OP Stack L2 (with EigenDA)

One more quirk: CELO token duality

What carries over unchanged

The short version

WEMIX RPC: Building on a Gaming-First EVM Chain

The essentials

Design choice #1: PoA council → instant finality, no reorgs

Design choice #2: it's a gaming chain, so plan for game-shaped traffic

What carries over unchanged

The short version

Sui RPC: Where Everything You Own Is an Object

The essentials

The mental shift: query objects, not contract storage

Owned vs shared objects: the finality fast path

Reading transactions and events (indexing)

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