NexFlow › Library › Sei RPC endpoint guide

Sei RPC endpoint: reading Sei through its EVM interface

Sei began as a Cosmos chain, added a full EVM, and is now moving its users onto the EVM side for good. For anyone reading Sei over Ethereum JSON-RPC that is good news — the EVM interface is the one with a future — but it comes with dual addresses, a migration you should understand, and finality so fast that the usual block tags collapse into one. Here is a tested endpoint and what we found.

7 min read · updated 2026-09-27 · infra guide, not financial advice

The endpoint is https://nexflowscan.com/api/rpc/sei. It serves Sei's EVM JSON-RPC — the eth_ namespace your Ethereum libraries already speak — over HTTPS POST with no key needed for baseline reads. Calls go to a pool of keyless upstreams that includes the public evm-rpc.sei-apis.com endpoint; if one errors or trails the tip, the relay tries the next.

What it does not serve is Sei's Cosmos-side interfaces: Tendermint RPC, the Cosmos REST API, or Sei's custom sei_ JSON-RPC methods. If your code queries sei1… balances through a Cosmos SDK client, this is not the endpoint for it — and, as the migration section explains, that kind of query has a limited future anyway.

Chain ID and block height, live

Run these before anything else. The first confirms you reached Sei mainnet's EVM, not a testnet; the second confirms the node is keeping up.

curl -s -X POST https://nexflowscan.com/api/rpc/sei \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
# {"jsonrpc":"2.0","result":"0x531","id":1}

curl -s -X POST https://nexflowscan.com/api/rpc/sei \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'
# {"jsonrpc":"2.0","result":"0xdf9a196","id":1}

0x531 is 1329, the EVM chain ID for Sei mainnet (the Cosmos side identifies itself with a string chain ID instead, which is one more reason not to mix the two stacks). 0xdf9a196 is block 234,463,638 — a high number for a chain of Sei's age, and a clue to the next section.

Sub-second blocks, and one tag for everything

Sei's documentation describes its EVM as combining sub-second finality with parallel transaction execution. Our reads agreed on the timing: over the last 1,000 blocks the timestamps averaged 0.464 seconds apart, and over the last 10,000, 0.472 seconds. That is roughly two blocks a second, around 127 a minute.

The finality claim is visible in the block tags. When we asked for latest, safe and finalized in a single pass, all three returned the same block, 234,463,357. A later spot check had finalized at 234,464,644 against a latest height of 234,464,645 — a one-block difference that is simply the time between two requests.

For application code, this simplifies confirmation logic considerably: once a transaction receipt exists, the block containing it is final. A deposit flow can credit on receipt. Keep asking for the finalized tag anyway if your code is multi-chain — on Sei it costs nothing, and on the next chain you add it will matter.

The fast cadence has the usual cost: polling one block at a time burns requests quickly. At about two blocks a second, a per-block loop eats roughly 127 items a minute of rate budget before doing any real work. Read ranges with eth_getLogs instead.

0x and sei1: two addresses, one account

Sei's Accounts documentation explains that the same underlying account can be represented both as an EVM 0x… address and as a Cosmos Bech32 sei1… address, and that the two are linked through a one-time on-chain association. Before association, the two sides can behave as separate addresses for the same key; after it, balances and state line up. The docs list several ways to associate: broadcasting a transaction, using the private key directly, signing a message, or supplying the public key.

Through an EVM endpoint, only the 0x form exists. We passed a sei1… string to eth_getBalance and got a -32602 parameter error — the node could not parse it as an Ethereum address. Sei does expose helper methods to translate between the two forms, but they live in the sei_ namespace, and our relay refused sei_getSeiAddress with -32601, "Method not allowed on this relay". If your product has users who think of themselves by their sei1 address, resolve the mapping with Sei's own tooling and store the 0x address for RPC work.

SIP-03: why the EVM side is the one to build on

Sei's SIP-03 migration guide sets out a transition toward an EVM-only chain. Its instructions for users of Cosmos-style wallets are to move assets from a native sei1… address to an EVM-compatible 0x… address. It warns that after the Cosmos interface is deprecated, addresses can no longer be associated and sei1… transfers can no longer be broadcast, so association has to happen first. It also records that IBC transfers out of Sei were disabled by a governance proposal passed July 31, 2026, so IBC assets can no longer leave Sei.

The same guide notes that native USDC and Circle's CCTP V2 are now supported on Sei, and that USDC bridged from Noble (USDC.n) is deprecated. For an RPC consumer, that means token lists and balance checks should key on the native USDC contract; a portfolio that still reads only the older asset will show users balances they are being asked to migrate away from.

The practical takeaway: if you are starting a Sei integration today, build it entirely on the EVM interface — addresses, balances, events and contracts. An endpoint like this one covers that surface fully for reads.

Gas and fee reads on Sei

Sei's gas documentation points EVM developers to the familiar methods: eth_gasPrice, eth_maxPriorityFeePerGas and eth_feeHistory. On 2026-09-27, the latest block's base fee was 50,000,000,000 wei (50 gwei), eth_gasPrice returned 55,000,000,000 wei, and eth_maxPriorityFeePerGas returned 1,000,000,000 wei. These are dated single readings denominated in SEI, the chain's native token, not an average. The block header reported a gas limit of 12,500,000.

Sei is not a rollup, so there is no L1 data fee to add and no oracle to read — the fee you estimate is the fee you pay. eth_blobBaseFee is on our allowlist, but the upstream that answered it replied that the method is not whitelisted on its side; blob fees do not apply on Sei, so there is nothing to lose by skipping it.

What passes and what doesn't

The relay forwards Sei's standard EVM reads: eth_getBalance, eth_call, eth_getLogs, blocks and receipts, eth_estimateGas, eth_feeHistory, filters and identity methods. It refuses signing, node internals and non-eth_ namespaces: eth_sign and txpool_content came back -32601 like the sei_ call above, and the Sei lane page states that sends and signs are refused on the public lane. Sign in your wallet or backend and broadcast through a provider you control.

Our relay, as of 2026-09-27, offers Sei in three lanes over the same upstreams:

We checked that last row directly: a request to the Sei x402 URL without an X-PAYMENT header came back HTTP 402 with a machine-readable payment challenge. The x402 RPC page walks through paying it. For a service that follows every Sei block, a key bought via the integration flow is the steadier choice; once the free window runs out, the free lane itself answers 402.

Frequently asked