Token bridging on Elysium

A developer overview of how tokens move between Elysium, HyperEVM, and HyperCore, and how the three bridge legs compose. This includes the full lifecycle available to a token: launch on Elysium, mirror to HyperEVM, and graduate to a HyperCore spot orderbook. Each leg also stands alone: tokens can start in any of the three environments and bridge wherever they are needed.

This page is the overview; each leg has its own guide with runnable code: Bridging HyperEVM tokens to Elysium, Bridging Elysium tokens to HyperEVM, and HyperCore bridging via deposit wallets. For the contract-level system map (architecture diagrams, the CREATE2 derivation mechanics, and the trust model), see Token bridging architecture.

Elysium is pre-launch: contract addresses — including the deposit-wallet family — the chain ID, and RPC endpoints arrive at launch, and details may be refined before mainnet. HyperCore's native linkage mechanism itself is live Hyperliquid protocol behavior today.

1. The three environments

• Elysium: a high-throughput EVM chain (100–200 ms blocks) with HYPE as native gas, built for high-frequency DeFi.
• HyperEVM: Hyperliquid's EVM (chain ID 999). Elysium settles to HyperEVM, and HyperEVM is the hop between Elysium and HyperCore.
• HyperCore: Hyperliquid's L1, with spot and perp orderbooks at ≈100 ms cadence. The destination for tokens that graduate to a spot orderbook.

2. The bridging map

Token assumptions (both EVM legs): standard ERC-20s whose transfers move the exact requested amount. Fee-on-transfer and rebasing tokens are not currently supported, since escrow and minted supply must match 1:1. The mirror bridge additionally requires IERC20Metadata (tokens without it are not currently mirrorable) and works best with immutable metadata; see the 1:1 guarantee for what metadata changes do.

3. Native HYPE

HYPE is Elysium's gas token. Deposit HYPE on HyperEVM and receive native gas on Elysium 1:1; burn native and withdraw HYPE 1:1. There is no wrapper asset and no token contract in this path. HYPE moves through the bridge as native value (msg.value) end to end, and all bridge fees below are paid the same way.

4. HyperEVM-native tokens: The canonical bridge

Any ERC-20 that lives on HyperEVM bridges to Elysium permissionlessly: the token locks in the standard bridge escrow on HyperEVM and a 1:1 representation is minted on Elysium. The representation contract is auto-deployed by the first-ever deposit at a deterministic address, with no registration, issuer involvement, or permission required. Burning the representation on Elysium releases the escrow on HyperEVM after the challenge period.

This is the stock canonical token bridge of the Arbitrum Orbit rollup stack Elysium runs on, unchanged — it is bridging infrastructure between Elysium and HyperEVM, and is unrelated to any bridge on the Arbitrum network. Full flow with code: Bridging HyperEVM tokens to Elysium.

5. Elysium-native tokens: The mirror bridge

The exact reverse of the canonical leg: an Elysium-native token locks on Elysium and a 1:1 mirror is minted on HyperEVM. The native token needs zero bridge code: no special interfaces, no mint authority granted to anything, no wrapping. Existing tokens bridge identically to purpose-built ones, and holders on Elysium always hold the original asset.

Setup is one-time and permissionless, with one transaction on each chain (either order): deploy the escrow wallet on Elysium, then deploy and register the mirror on HyperEVM. Full flow with code: Bridging Elysium tokens to HyperEVM.

6. The 1:1 guarantee

Every Elysium token maps to exactly one live mirror, enforced on-chain:

• A mirror's identity is keyed by the token plus its exact metadata (name, symbol, decimals).
• The Elysium factory derives the one pairable mirror from the token's live on-chain metadata and will only ever deploy the escrow wallet for that pair. The wallet's address commits to the factory's identity, so no other party can ever place code there.
• A mirror created with any other metadata can exist, but its wallet can never be deployed. Since mirror supply is only ever minted against wallet escrow, a wrong-metadata mirror's supply is zero forever. It is an inert contract, not a competing token.

Resolving the canonical mirror:

• On Elysium: query the factory. expectedL1Mirror(token) returns the one mirror address derived from the token's current metadata.
• On HyperEVM: check factory provenance (elysiumTokenOf(mirror) is set) and totalSupply() > 0. Nonzero supply proves the wallet exists, which proves the metadata matched the real token when the pair was created.

Tokens with owner-mutable metadata get one pair per metadata snapshot, and the pair matching the current metadata is canonical. Tokens that don't implement IERC20Metadata (name()/symbol()/decimals()) cannot currently be mirrored.

Full derivation mechanics (salts, deployer commitments, and public verification) are in Token bridging architecture.

7. Token lifecycle: Elysium → HyperEVM → HyperCore

The three legs compose into the full lifecycle without leaving the ecosystem:

A mirrored token on HyperEVM is an ordinary ERC-20, so it graduates to HyperCore the same way any HyperEVM token does: a deposit wallet escrows it and HyperCore credits and debits Core spot balances against that escrow, with the invariant escrowed balance == circulating Core supply. The linkage mechanism is HyperCore's own, live on Hyperliquid today; the deposit-wallet contracts ship at launch. See HyperCore bridging via deposit wallets for the worked example, and HyperCore spot deployment for the issuer ceremony that gets there — ticker auction, genesis, linking, and the spot orderbook listing.

8. Amounts & decimals

• Both EVM legs preserve decimals exactly. A canonical representation has the same decimals as its HyperEVM original, and a mirror has the same decimals as its Elysium original (the mirror bridge enforces this, since metadata is part of the pairing). All EVM calls take base units.
• The Core linkage scales between the EVM token's decimals and the Core token's weiDecimals. Alignment rules and the sendAsset human-readable amount format are covered in HyperCore bridging: Amounts & decimals.
• Bridge fees on the EVM legs are paid in native HYPE (msg.value) on the chain where the transaction starts. There are no fee-token approvals anywhere.