Sei RPC: Parallel EVM, Dual Addresses, and Instant Finality

Sei is a high-performance Layer 1 built for trading, and its EVM execution layer (chain ID 1329) is fully bytecode-compatible — point viem or ethers at it and eth_call, eth_getLogs, and eth_sendRawTransaction behave exactly as you'd expect. But Sei isn't "Ethereum with a faster block time." Three things about it change how you build: it runs a parallelized EVM, it lives in a dual Cosmos/EVM address world, and it has instant single-block finality. Here's the map.

It's EVM-compatible — reads just work

Sei's EVM (shipped with Sei v2) runs Geth-based execution behind a parallel engine, with ~400 ms block times and BFT finality from its Twin Turbo Consensus (derived from CometBFT/Tendermint). For standard reads and writes, nothing is unusual:

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

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

The native asset is SEI (18 decimals on the EVM), which pays for gas. Existing Solidity contracts, ABIs, and tooling deploy and run unchanged. So far, so familiar. Now the parts that differ.

1. The EVM is parallelized

On Ethereum, transactions in a block execute strictly one after another. Sei executes independent transactions in parallel, using optimistic concurrency control: it runs transactions concurrently, tracks which state slots each one touches, and re-runs any that actually conflicted. Non-overlapping transactions (say, two swaps on different pools) never wait on each other.

For an RPC developer this is mostly transparent — you still submit one transaction at a time and read state the same way. What it changes is throughput and latency: the chain sustains far more transactions per second at sub-second block times. The practical implication isn't a new API, it's a design posture: build for a fast chain (see finality and block-time notes below), and don't assume execution order matches submission order across unrelated transactions.

2. Two address worlds: EVM and Cosmos

This is the big one, and the source of most Sei confusion. Sei is a Cosmos chain with an EVM bolted on as a first-class execution environment, so every participant can have two addresses:

• an EVM address — the usual 0x… hex (what MetaMask and viem use)
• a Cosmos address — a bech32 sei1… string (what Cosmos wallets and the Cosmos SDK use)

These are derived from different key formats and are not interchangeable by string manipulation. They're linked through an on-chain address association (a one-time transaction, or automatic on first EVM send from a funded account). Until an account is associated, its EVM and Cosmos sides are effectively separate — a frequent "where are my funds?" gotcha.

Pointer contracts are how a token that lives on the Cosmos side (a native or CW20 token) becomes usable from the EVM as a standard ERC-20, and vice versa. If you're integrating a Sei asset and its ERC-20 balance looks wrong or missing, check whether you're pointing at the pointer contract or the native denom. Precompiles at fixed addresses let EVM contracts reach Cosmos functionality — including looking up the association between an 0x and a sei1… address.

The takeaway: for pure EVM DeFi you can ignore the Cosmos side, but the moment you touch bridged assets, native SEI accounting, or cross-environment users, you need to know which address world you're in.

3. Instant finality — no reorgs

On Ethereum you wait for confirmations because a freshly mined block can be reorged out. Sei uses BFT consensus with single-block finality: once a block is committed by the validator set, it is final immediately and cannot be reverted. There is no probabilistic settling, and in normal operation no reorgs.

For RPC consumers this is a real simplification:

• The latest block is effectively already final — the finalized and latest tags don't diverge the way they do on Ethereum (contrast soft vs hard finality on L2s, a different model entirely).
• You generally don't need deep confirmation waits before crediting a deposit or acting on an event. One block is settlement.
• Indexers can largely skip reorg handling — no parent-hash break detection, no rollback logic. Key on block number with far less anxiety than on an L1 with probabilistic finality.

This is arguably Sei's most developer-friendly property: the fast, final block removes an entire category of edge cases.

Building for ~400 ms blocks

Sub-second blocks change your polling math. A loop that polls eth_blockNumber every few seconds will lag many blocks behind; tight polling wastes requests. Prefer WebSocket subscriptions for heads and logs:

const ws = new WebSocket("wss://rpc.swiftnodes.io/ws/sei?key=YOUR_API_KEY");
ws.onopen = () => ws.send(JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "eth_subscribe", params: ["newHeads"],
}));

And if you're a high-frequency sender, fast blocks mean nonces advance quickly — manage them explicitly rather than round-tripping eth_getTransactionCount("pending") before every send (a dedicated post on nonce management is coming).

What carries over unchanged

Don't over-correct — the EVM surface is standard:

• eth_call, eth_getBalance, eth_getLogs, eth_getTransactionReceipt, eth_estimateGas, eth_sendRawTransaction all behave normally. (Reading a receipt and estimating gas are exactly as on Ethereum.)
• Solidity contracts, ABIs, events, and standard tooling work without changes.
• WebSocket subscriptions (eth_subscribe) for newHeads and logs work.

The rule of thumb: treat Sei as standard EVM for contracts and reads; treat it as Sei-specific when you touch addresses, native/bridged assets, or finality assumptions. Like zkSync, it's compatible where it counts and different exactly where the chain's architecture shows through — just in different places (Sei's differences are addresses and finality; zkSync's are account abstraction and gas).

The short version

Sei's EVM (chain ID 1329) gives you the familiar eth_* surface — viem and ethers just work — then differs in three architecture-driven ways: a parallelized EVM (mostly transparent, but don't assume cross-transaction ordering), a dual Cosmos/EVM address world (0x vs sei1…, linked by association, with pointer contracts and precompiles for cross-environment assets), and instant single-block finality (no reorgs — skip deep confirmation waits and most rollback logic). Build for ~400 ms blocks with WebSocket subscriptions, and mind which address world you're in the moment you touch assets.

Fast, final blocks are only an advantage if your endpoint keeps up with them. A flat-rate Sei RPC endpoint gives you the full eth_* surface plus WebSocket subscriptions across dozens of chains under one key. Grab a free key and point your app at:

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