Porting a HyperEVM app or bot to Elysium: what changes and what stays

If you already run contracts or a bot on HyperEVM, Elysium is the closest new chain you will ever port to. It is Kinetiq's Arbitrum Orbit L2, it settles on HyperEVM, and it pays gas in HYPE, bridged 1:1. Kinetiq's documentation states that Solidity, Foundry, Hardhat, viem and ethers work as on any Orbit chain, and in our checks they do.

What changes is the execution environment around your code. HyperEVM is part of Hyperliquid's L1; Elysium is a rollup with its own sequencer, its own block rhythm and Arbitrum's system contracts. This post walks through the differences that matter to a working app or bot, in the order you will meet them. Values were read from Elysium mainnet and HyperEVM on 9 November 2026; the endpoint itself is covered in our Elysium launch post.

Identity: chain ID, currency, presets

Elysium mainnet is chain ID 99901, which eth_chainId returns as 0x1863d; net_version returns "99901". Its testnet is 99801. HyperEVM, the parent, stays 999. HYPE has 18 decimals on both chains.

Three practical points:

• Two configs, not one. A bot that bridges or settles keeps a HyperEVM client and an Elysium client side by side. Name them explicitly in config so a deposit is never signed for the wrong chain.
• Define the chain yourself. At launch the public chain registry had no entry for 99901, and viem's built-in elysiumTestnet is Vulcan Forged's chain 1338, not Kinetiq's. A hand-written defineChain with id 99901 is the safe form. The chain ID explainer lists every ID you will meet around Elysium.
• Check on connect. Compare eth_chainId with 0x1863d when a client starts. A misrouted URL that reaches HyperEVM returns 0x3e7 and otherwise looks healthy.

Wallet and framework snippets for MetaMask, viem, ethers, Hardhat and Foundry are in the network config tools, on the Elysium page.

Blocks and block.number

HyperEVM produces a small block every second and a large block every minute. Elysium produces blocks as its sequencer receives messages: over the 100,000 blocks before 9 November 2026 00:12 UTC the average was 10.6 blocks per second, over the last million 6.5. Code that counts blocks to measure time breaks twice on this chain: the rate is high and it is not constant.

Inside a contract, block.number on an Arbitrum chain does not return the L2 block number. It returns an estimate of the parent chain's block number. On Elysium the parent is HyperEVM, and we observed this directly: block 2,808,056 on Elysium carried l1BlockNumber 50,758,422, while HyperEVM's head at that moment was 50,758,456. If a HyperEVM contract uses block.number for a cooldown or a per-block limit, the same code on Elysium will count HyperEVM blocks. For L2 block numbers call ArbSys(0x64).arbBlockNumber(), and for durations use block.timestamp.

Off chain, every Elysium block starts with an ArbOS system transaction of type 0x6a, sent from the zero address. A block with two user transactions reports three. Filter by type when you count or decode transactions, and skip type 0x6a when you look for user activity.

Gas, fees and limits

The base fee sat at its 0.1 gwei floor throughout our readings on 8 and 9 November, and eth_gasPrice returned 0xbebc200, which is 0.2 gwei. Kinetiq describes the fee environment as tuned so that a market maker can refresh quotes several times per second cheaply, and orders transactions by priority fee with no privileged lanes. In practice:

• set maxFeePerGas with headroom above the base fee and keep maxPriorityFeePerGas meaningful if ordering inside a block matters to you;
• estimate with eth_estimateGas on Elysium itself; Arbitrum's gas accounting includes a parent-chain data component, so a HyperEVM estimate does not transfer;
• read eth_feeHistory for recent priority fees before you pick a value.

The block gas limit is reported as a very large number, as on other Nitro chains. Do not read it as an execution budget; the sequencer's own throughput target, which Kinetiq gives as 300 Mgas/s, is the real ceiling.

Sending transactions without a mempool

HyperEVM bots often watch pending activity. On Elysium there is nothing to watch: there is no public mempool, txpool_* methods are not available on mainnet nodes, and WebSocket newPendingTransactions does not exist. The sequencer orders what it receives.

eth_sendRawTransaction works on every plan through our endpoint, and three rules keep a sender correct:

1. A hash is a hand-off, not an inclusion. Poll eth_getTransactionReceipt until it returns a receipt; on Elysium receipts usually appear within seconds.
2. Unknown outcomes carry the hash. If our gateway cannot tell whether the network accepted the transaction, the error includes the transaction hash in error.data.txHash and nothing is resent automatically. Look the hash up before you rebroadcast.
3. Resend the same bytes. Rebroadcasting an already mined transaction returns its hash again. A new transaction with the same nonce is a replacement, not a retry.

The eth_sendRawTransaction reference has the request shapes and error codes.

Finality, bridging and the way back

Elysium's finalized tag follows batch posting on HyperEVM. On 9 November at 00:12 UTC it trailed latest by 21,977 blocks, about 47 minutes. For a trading bot, a receipt is usually enough to move on; for accounting, credit deposits or settle payouts at finalized.

Gas arrives by bridge. The canonical native deposit is a payable depositEth() call to the rollup's Inbox on HyperEVM, which credits HYPE at the same address on Elysium for a regular wallet; ERC-20s use the canonical token bridge with a gateway router. Withdrawals start on Elysium and are claimed on HyperEVM after the rollup's confirmation period, which the Rollup contract sets at 483,840 HyperEVM blocks, about five and a half days at the parent's recent pace. Plan inventory with that asymmetry in mind: moving HYPE in is quick, moving it out is not. The bridge guide lists each contract to check in the wallet prompt.

What is not there yet: HyperCore from contracts

On HyperEVM, contracts can read some HyperCore state and send actions through Hyperliquid's own system contracts. Elysium's equivalents are a market-data precompile and a trading predeploy, and Kinetiq schedules both for an ArbOS network upgrade about four weeks after mainnet. Until that upgrade activates, an Elysium contract cannot read HyperCore order books or route orders directly. A bot that needs both should keep its HyperCore logic off chain or on HyperEVM for now, and check the activation block before it switches.

When this is the wrong approach

• Your strategy depends on reading pending transactions. Elysium has no public mempool to read, so a mempool-driven HyperEVM bot has nothing equivalent to port to.
• Your contracts need HyperCore precompiles on day one. They arrive with a later ArbOS upgrade; stay on HyperEVM for that logic until then.
• You need traces. debug_* and trace_* are not exposed by Elysium mainnet nodes. If your tooling relies on call traces, plan an event-based or receipt-based alternative.
• You need to exit quickly. The canonical withdrawal waits the rollup's confirmation period on HyperEVM. Keep working capital on the chain where you need it.

For background on the chain, read what Kinetiq Elysium is. Endpoints, plans and the keyless public URL for first tests are on the Elysium RPC page.

Sources

• Chain ID, net_version, block timestamps, l1BlockNumber, the finalized tag, eth_gasPrice and block transaction types: read from Elysium mainnet through triport.io and from HyperEVM's public RPC, 2026-11-09 00:12 UTC.
• Rollup confirmPeriodBlocks (483,840) and HyperEVM block timestamps over that span: read from HyperEVM, 2026-11-09 00:06 UTC.
• Elysium architecture, fee and ordering design, HyperCore upgrade timing: Kinetiq docs, what is Elysium and blocks, fees and ordering, read 2026-11-08.
• HyperEVM chain ID and block structure: Hyperliquid docs, HyperEVM, read 2026-11-09.
• Send behaviour and unsupported methods: Elysium reference and unsupported methods, checked 2026-11-09.