Elysium mainnet RPC on Triport: JSON-RPC, sending, WebSocket and batch history

Triport's tenth network is Kinetiq's Arbitrum Orbit L2 on HyperEVM. It launches with the full read surface, transaction submission and live subscriptions, plus an index of every sequencer batch since genesis that answers questions plain RPC cannot.

Endpoint and plans: Elysium RPC endpoint.

Elysium mainnet launched on November 9, 2026, and it is live on Triport the same day as our tenth network. You get the same API key, the same plans and the same request format you already use for Ethereum, Base or Robinhood Chain, pointed at a new path: https://triport.io/r/<API_KEY>/elysium.

This post covers what the endpoint serves on day one, how to connect in a minute, where the limits are, and the one product on Elysium that has no direct equivalent on our other EVM networks: an index of sequencer batches that gives you address history from genesis without running an indexer.

What Elysium is, in one paragraph

Elysium is an Arbitrum Orbit L2 built by Kinetiq on the Nitro stack. It settles to HyperEVM and uses HYPE as its gas token. Mainnet is chain ID 99901, which eth_chainId returns as 0x1863d. Elysium testnet is 99801 and HyperEVM itself is 999; keep the three apart in your client configuration, because a connection to the parent chain reads a different network. Other projects have used the name "Elysium" on other chain IDs, so when you see the name elsewhere, check the chain ID before you assume it is this network.

Blocks are produced by a single sequencer at about ten per second (our measurement through the endpoint on 2026-11-08). Two practical consequences follow. The head moves between any two calls, so pass explicit heights when you need repeatable reads. And every block opens with an ArbOS system transaction of type 0x6a, so a block with two user transactions reports a count of three.

Connect in a minute

Create an API key in the Triport console and give it the elysium:rpc scope (keys with all-network access already include it). Then confirm the network:

curl --silent https://triport.io/rpc/elysium \
  -H "X-API-Key: $TRIPORT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

The result must be 0x1863d. Check it, not just the HTTP status: a 200 alone does not prove the client reached the chain you intended. The key can also travel in the path, which is the convenient form for libraries that take a single URL:

import { createPublicClient, http } from "viem";


const client = createPublicClient({
  transport: http(`https://triport.io/r/${process.env.TRIPORT_API_KEY}/elysium`),
});
if (await client.getChainId() !== 99901) throw new Error("not Elysium mainnet");
console.log(await client.getBlockNumber());

ethers v6 works the same way with new JsonRpcProvider(url); compare (await provider.getNetwork()).chainId with 99901n.

What the endpoint serves

Reads. 35 JSON-RPC methods, each with a measured request and response in the method reference: network identity, blocks and headers, transactions and receipts (including eth_getBlockReceipts), balances, code, storage, eth_call, eth_estimateGas, eth_getProof, eth_createAccessList, eth_simulateV1, gas price and fee history. History, including historical state, goes back to block 1, so an eth_call or eth_getBalance at an old height answers instead of failing on a pruned node.

Event logs. eth_getLogs covers up to 10,000 blocks per request, counting both ends. A wider range is rejected with -32602 and a message telling you to split it; nothing is silently truncated. Each response is capped at 8 MB, and an oversize result returns -32005. At ten blocks per second, 10,000 blocks is roughly sixteen minutes of chain time, so a backfill pages through many windows: filter by address or topics, store the last completed range, and treat an error as a signal to split rather than as an empty range.

Sending. eth_sendRawTransaction is live on every plan. An accepted submission returns the hash. If the outcome is unknown, the error carries the hash in error.data.txHash and the gateway does not resend automatically, so your code decides whether to rebroadcast. Poll eth_getTransactionReceipt: receipts usually appear within seconds, while the finalized tag follows batch posting on HyperEVM on a scale of minutes.

Subscriptions. wss://triport.io/ws/elysium/<API_KEY> accepts eth_subscribe for logs from Basic up, with an address or topics filter required, and newHeads from Pro up. The key needs the elysium:ws scope. There is no newPendingTransactions: Elysium has no public mempool to stream. Reorged logs are not re-sent, so after a reconnect reconcile the gap with eth_getLogs.

Batches of requests. JSON-RPC batches are accepted. Each element counts as one request against your plan's rate, and a batch larger than the plan's burst capacity is rejected whole with HTTP 429.

Not served. debug_*, trace_*, txpool_*, net_listening and net_peerCount are rejected with HTTP 403 method_unknown, and a batch that contains one of them is rejected entirely. The unsupported-methods page lists them.

Batch history: address activity since genesis

Ordinary RPC answers questions about state and about blocks you name. It does not answer "what has this address done since the chain started" without an indexer that walks every block. On Elysium we built that index from a different source: the sequencer batches that the chain posts to HyperEVM through its data availability layer. Each batch is a group of sequencer messages with its own sequence number; we check every payload against its posted data hash and index the signed transactions in it, starting from batch 1.

The product has its own scope, elysium:das, and five surfaces, all documented under Elysium batch history:

SurfacePath
Address history, newest firstGET /v1/elysium/wallet/{address}/history
Batch listGET /v1/elysium/batches
One batch with its transactionsGET /v1/elysium/batches/{seq}?full=1
Coverage and freshnessGET /v1/elysium/das/status
Batch streamwss://triport.io/v1/elysium/batches/stream
curl "https://triport.io/v1/elysium/wallet/0xYourAddress/history?limit=25" \
  -H "X-API-Key: $TRIPORT_API_KEY"

Each item gives the hash, batch sequence and position, L2 block, sender, recipient, a contract address for a creating transaction, nonce, value and the input selector, plus the role the address played. Pages are cursor-based: pass next_before back as before.

The limits are deliberately higher than RPC, because one history page replaces what would otherwise be thousands of block reads. Snapshot of 2026-11-08, requests per second per key:

CategoryTrialBasicProBusinessEnterprise
History, batch list, status102560120120
One batch (the heavy request)2481515
Batch stream, new connections per second——125
For comparison: ordinary RPC reads510254040

That is two to three times the read rate of the same plan. The stream starts at Pro; on the trial and Basic the upgrade is refused with HTTP 403 tier_insufficient.

When this is the wrong approach

Batch history is not real-time and not complete account activity, and it says so in every response through a coverage object with complete: false.

  • Freshness follows batch cadence. A transaction enters the index when its batch is posted to HyperEVM and indexed, which is minutes after the sequencer accepted it, not seconds. A new receipt can be on RPC well before its batch reaches the index. For the current head, use eth_blockNumber, WebSocket newHeads, or receipt polling.
  • Deposits are not indexed per address. Messages from the parent chain, including deposits, are counted per batch but not attributed to addresses.
  • No internal calls. Value moved or contracts created inside contract execution do not appear; only top-level creating transactions do.
  • No execution results. Every item has execution_status: "not_available". Success, revert, gas used and logs come from eth_getTransactionReceipt.

So an empty history page is a valid answer within that coverage, not proof that an address never received funds. The empty address history explainer covers the same trap on other chains. If you need balances, use eth_getBalance; if you need every event a contract emitted, use eth_getLogs or a logs subscription.

Plans and limits

Elysium is on every Triport plan: the 7-day trial, Basic at $20 per month, Pro at $249, Business at $499 and Enterprise from $999 with a 365-day minimum term. Access is governed by plan and request-rate category, not by a call meter: there is no monthly call count to run out of, only a per-second rate with a 2× burst buffer.

CategoryTrialBasicProBusinessEnterprise
Ordinary reads510254040
eth_getLogs1251010
eth_sendRawTransaction35308080

Two different 429 answers exist, and your client should handle both: the plain rate_limited body means your plan limit, while a JSON-RPC -32005 means the node pool is at capacity even below your limit. Back off and honor Retry-After in both cases. The full set is on Elysium limits and Triport pricing; for how Triport compares with other providers on the networks they share, see the comparison hub.

Start with the chain ID check, add one block read, then the calls and subscriptions your application needs. The Elysium RPC page collects the endpoints, and the API reference documents every method with a measured example.

Sources

  • Elysium network identity (chain ID 99901, 0x1863d), block rate and method behaviour: measured through Triport production, 2026-11-08.
  • eth_getLogs range and response-size limits, batch accounting, unsupported methods: Elysium limits and unsupported methods, checked 2026-11-08.
  • Batch history coverage, paths and rate categories: Elysium batch history, production tariff headers checked 2026-11-08.
  • WebSocket subscriptions: live check of logs and newHeads through triport.io, 2026-11-08.
  • Plan prices: Triport pricing, 2026-11-09.