Project Elysium whitepaper

01Overview

Overview

Project Elysium is a token launchpad on Elysium, Kinetiq's L2 on HyperEVM (an Arbitrum Orbit chain that settles on HyperEVM). Elysium is chain 99901 and its gas token is HYPE.

Every token launched here trades in a Uniswap v4 pool whose hook is our contract, ElysiumPad. The hook charges one fee model on every swap, whatever router or aggregator sends it, and it is the only party allowed to add liquidity to its pools. There is no bonding-curve contract to graduate from: a token is tradable in its v4 pool from the transaction that creates it.

$ELYSIUM is the ecosystem token. It is always the first token the pad registers, and the protocol share of every other pool's fees is used to buy it back and burn it.

There are three ways a token enters a pad pool:

02Architecture

Architecture

The router and the burner are deployed by the pad's constructor. All pools use the canonical Uniswap v4 PoolManager on Elysium, 0x06C63714fBf1F5753017123E2FcfdEde4540B2c4. Every pool key is {pair, token, fee 0, tickSpacing 200, hooks = ElysiumPad}; the v4 LP fee is zero and all fees come from the hook.

Straight into a v4 pool

createToken deploys the token, registers it on the pad, initializes its pool at the start price and adds the entire supply as one single-sided position, all in one transaction. For a HYPE pair the range runs from tick 166800 to the minimum tick, so the position holds only tokens at launch and HYPE accumulates in it as people buy. Any token dust left in the launcher is sent to 0x…dEaD. An optional first buy by the creator happens in the same transaction.

Price curve

A single-sided full-supply range behaves like a constant-product pool, x · y = k, with a virtual HYPE reserve that does not exist and cannot be withdrawn. Tick 166800 is about 1.75 × 10⁷ tokens per HYPE, which makes the virtual reserve 57.06 HYPE and the start FDV 57.06 HYPE.

With V = 57.06 HYPE and a share f of supply sold, the HYPE paid in is V · f / (1 − f) and the price is 1 / (1 − f)² times the start price. Before fees:

The start tick is a per-pair setting (pairs(asset)). An ERC-20 pair, if one is enabled, has its own start tick and therefore a different start price. A swap that would push the price outside the position's range reverts (OutOfRange).

Liquidity gating

beforeInitialize only lets the launcher create a pool, and only for a token it has registered. beforeAddLiquidity rejects every caller except the launcher. The launcher's position is therefore the only liquidity a pad pool can ever contain: no third-party LPs and no just-in-time liquidity. This also matters for burns, because the per-burn cap is measured against that one position.

03Fees

Fees

For every curve and ZERO token, the normal fee on each swap is:

So the pad takes up to 1% per swap: 0.7% to the creator and up to 0.3% to the $ELYSIUM burn. A creator can add up to 9% of their own on top. Buy and sell tax are set separately. The protocol rate is one global setting; the owner can lower it or raise it back to the 0.30% ceiling, and the change applies to all pools at once. The 0.70% base and each token's tax cannot be changed by anyone.

$ELYSIUM's own pool is different: no protocol fee and no base, only its 3% tax, covered in section 9.

How the fee is taken

Fees are always taken in the pair asset (HYPE for HYPE pairs), on all four swap kinds, through any router. When the pair asset is the side the trader specified, the hook takes the fee in beforeSwap through a BeforeSwapDelta; otherwise it takes it in afterSwap through the return delta. Exact-output amounts are grossed up as net · 10000 / (10000 − bps), rounded up, so exact-output trades pay the nominal rate too. The hook mints the fee to itself as PoolManager ERC-6909 claims of the pair asset and books it into three counters: protocolFees[pair], the token's creatorFees and its burnBucket. The counters always add up to the claims minted.

Swaps sent by the burner (buybacks) are fee-exempt. No other sender is.

Claims

• claimCreatorFees(token): anyone can call it; it pays the creator's whole balance to the creator. If the payment fails (for example a contract creator that rejects HYPE), the balance stays and ClaimFailed is emitted.
• claimTo(token, to): creator only, pays to any address.
• transferCreator then acceptCreator: two-step handover of the creator role.
• renounceCreator: pays what is pending, then all future creator fees on that token go to its own burn bucket.

04Sniper protection

Sniper protection

Each launch picks a sniper mode at creation. It cannot be changed later. While it is active, the fee on a swap is:

charged = max(normal, sniper)

Protocol and base keep their normal amounts and the custom tax keeps its normal split. Everything above the normal rate is the sniper excess. On curve and ZERO launches the excess goes entirely to the token's own burn bucket and is bought back and burned; the creator never receives it. The rate applies to buys and sells and to every sender, including the creator's own first buy in the launch transaction. A creator who picks Standard and makes a first buy therefore pays 90% on that buy, and the excess is burned.

There is no max-buy or max-wallet limit. A sniper is not blocked; they pay the tax. feeBps(token) returns the effective buy and sell rate right now, and currentSniperBps(token) the sniper part.

05ZERO launches

ZERO launches

ZERO is a fair launch run as a lottery over L2 blocks before the pool exists. The token has the same 1B supply. 500M is distributed to round winners; the other 500M and the HYPE raised open the pool.

Setup and limits

Tickets and fees

5% of each ticket purchase is a fee: 1.5% to the protocol bucket for the $ELYSIUM burn and 3.5% to the creator. The other 95% goes to the pot. Each round that sold tickets has exactly one winner, chosen with probability proportional to tickets held in that round. Whoever calls draw for a round earns a bounty of 1% of that round's ticket sales, paid out of the creator's 3.5% and claimable with claimBounty after finalization.

Randomness

1. A closed round is anchored to the first L2 block, strictly after the close, in which any transaction touches the launch.
2. In a later block the winner is drawn from ArbSys.arbBlockHash(anchor).
3. That hash is only available for 256 L2 blocks. If nobody draws in time there is no re-roll: the round is drawn once from a fallback seed, keccak(token, roundId, totalTickets, arbBlockHash(anchor − 1)). The salt is stored at anchoring, so a ticket count chosen before the close cannot steer it.

Trust assumption. Elysium has a single sequencer, run by its operator. The sequencer orders transactions and produces the block hashes these draws use, so it could bias a draw. ZERO does not remove that trust; it removes the ability of ordinary traders to pick winners. A second, smaller residual: the account that anchors a round can see the fallback salt and could anchor only when the fallback would favour it. That only pays if nobody draws for 256 L2 blocks afterwards, which the draw bounty and the site's auto-draw work against.

Finalization

A launch can be finalized once the wins target is reached, or the deadline has passed and every round is drawn. Winner supply that was never won is burned. The launcher then opens a two-sided full-range pool with the remaining 500M and the pot, at price pot / 500M, with the creator's tax and sniper mode. That position is locked like every other non-$ELYSIUM position. Winners collect with claim.

Refunds

refund opens 7 days after the deadline, and only after every round is drawn (StillDrawing until then). It always tries to finalize first: if finalization succeeds, the launch is finalized and nothing is refunded. Only if finalization itself reverts does the launch enter refund mode, in which each buyer gets back their gross ticket spend and the creator also gets the commit back. A refund call with less than 3,000,000 gas left, or whose finalize attempt fails with empty revert data (out of gas), reverts with LowGas, so a gas limit cannot push a finalizable launch into refunds.

createZero only works once the ZERO contract is wired to the launcher and $ELYSIUM exists (NotWired otherwise), and not while new launches are paused.

06Seeded launches

Seeded launches

You pick the supply and add HYPE. All of the supply and all of the seed go into one full-range v4 position, priced at supply ÷ seed, and that position is locked forever: the launcher has no remove function and the hook's beforeRemoveLiquidity always reverts.

Contracts: SeededPad 0xa718d05cC1da4982c619CEBDf10364CB53E9eAcC, SeededLauncher 0xf4112a6d2dcC0EB976f758A89e5bc9F8f5458969, router 0xb7CDC18eD5943A60A6C296c17355C8C0E370b2DE, burner 0x03B3C10B814feF4003Fc0EC5195456784c40cb24.

07Mintpad launches

Mintpad launches

Every Mintpad token has 1B supply. A linear curve sells 720M for HYPE, from a start price p0 to 6 × p0. When the curve sells out, its HYPE is locked in one shared reserve, padUSD worth 2/3 of that HYPE is minted, and it goes into one full-range v4 pool with the other 280M tokens. The pool opens at the curve's last price and is locked forever: the launcher has no remove function and the hook's beforeRemoveLiquidity always reverts.

Contracts: MintpadPad 0xe730F78cb2a88273b64A638fE97F0889E87aEacC, MintpadLauncher 0x656ba9286B859cB25D1355E5e501dffd1803BB46, MintpadReserve 0x35E336E9722Bf592c4553776EcA97156Ac980180, padUSD 0xE9Bf8b99D3C284fb83c98E16cc534c78e9e22BfD, MintpadOracle 0x85c7a94203423e12B47Aa52B52FC520C68ee3015, router 0x590D146b6F87f48ebD6486603c9B213bA69C031D, burner 0xf83B472C98fF68F16F5BBe8e34Bb6837aEd2fD9F.

08Burns

Burns

Two kinds of bucket feed the burner:

• Protocol bucket, one per pair asset. burnElysium spends the HYPE bucket buying $ELYSIUM in its own v4 pool. ERC-20 pair buckets are first converted to HYPE by convertPairFees; that HYPE is spent first by the next burnElysium.
• Burn bucket, one per token: the burn share of its custom tax, its sniper excess, and all creator fees once the creator renounces. burnToken(token) buys that token in its own pool.

Bought tokens are sent to 0x…dEaD. The same checks apply to every caller, keepers and owner included:

The burner only accepts HYPE from the PoolManager and WHYPE. HYPE fees never pass through v3; v3 is used only to convert ERC-20 pair fees, and an ERC-20 pair cannot be enabled until a route exists for it.

09$ELYSIUM

$ELYSIUM

launchElysium is a single owner-only transaction that can run once, and only while the pad has no tokens. It:

1. Deploys the 1B PadToken.
2. Sends 1% (10M) to each of seven allocation wallets.
3. Puts the remaining 930M plus all HYPE sent into one full-range two-sided position at price HYPE / 930M. The planned seed is 23.183433118693380096 HYPE (pad/launch.env), which gives a start FDV of about 24.9 HYPE. That figure is recomputed on launch day.
4. Registers the token as tokens(0) with the team wallet as creator, and sets pad.elysium().

Fees on the $ELYSIUM pool

3% on buys and 3% on sells, with no protocol fee and no base. All of it is creator fees for the team wallet 0xCdDE12Ec24a012cc2Ea0ec12e1eFD336d445143E, which is also the deployer and pad owner. The tax rate is a constant in the launcher and cannot be changed.

The sniper curve is [(0, 95%), (3, 95%), (3, 70%), (10, 70%), (30, 3%)]: 95% for the first 3 seconds, 70% from 3 to 10 seconds, a linear fall from 70% toward 3% between 10 and 30 seconds, then the normal 3%. The launch passes sniperToTeam = true, so on this pool the sniper excess above 3% is paid to the team wallet instead of the burn bucket. That flag is set once at launch, has no setter, applies only to $ELYSIUM, and is readable as info(ELYSIUM).sniperToTeam.

Liquidity: locked

$ELYSIUM's position was locked on Nov 3 2026 with the one-way lockElysiumLiquidity(). elysiumLpLocked() on the launcher returns true; the position can never be withdrawn and never was.

$ELYSIUM liquidity

pending

Position liquidity (launcher)

pending

Source

launcher.elysiumLpLocked(), read in your browser

10Owner powers

Owner powers

One owner, pad.owner(), controls the pad, and the launcher and burner check the same address. Ownership moves in two steps (transferOwnership, then acceptOwnership). ElysiumZero, PadRouter and PadToken have no owner.

Status: renouncing ownership is planned for later. It has not happened and has no date. Until it does, every power in the left column is live. Renouncing also ends the burns' owner shortcut (the 24-hour public rule and any keepers remain) and fixes the protocol fee where it stands.

11Transactions before public mainnet

Transactions before public mainnet

Elysium has no public sequencer RPC yet. The Elysium RPCs that exist today are third-party relays; this site reads state from them but never sends a transaction through them. Writes use the chain's delayed inbox on HyperEVM instead:

1. Your wallet signs a normal transaction for chain 99901.
2. The signed bytes are posted to the Elysium Inbox on HyperEVM (chain 999), 0xce59f8B65ad41C9DAE4c07A0571a39824bD92cff, as sendL2Message(0x04 ++ signedTx). Several can go in one batch message (0x03).
3. ArbOS recovers the sender from the signature, so on Elysium the transaction comes from your own address, not an alias.

Wallets that cannot sign without sending can add Elysium with our capture RPC, projectelysium.xyz/api/l2rpc. It stores the signed transaction the wallet submits and does not relay it; the page then posts it through the Inbox for you to approve on HyperEVM. Every other method on that RPC is a read forwarded to the Elysium read RPCs.

You need a little HYPE on HyperEVM for the Inbox call and enough HYPE on Elysium for the L2 transaction. A delayed transaction with the wrong nonce or too little L2 HYPE is dropped with no receipt, so the site checks both before you sign.

Latency. In the round-4 review, recent Inbox messages were matched to their L2 receipts: every one landed on Elysium in the same second as its HyperEVM block. An earlier measurement found 0 to 16 seconds. SequencerInbox.totalDelayedMessagesRead lags by hours because it tracks batch posting, not inclusion, and is not used as a signal.

Status: once a public sequencer RPC is announced it can be added as a direct route. None is configured today.

12Security

Security

The contracts went through four internal adversarial review rounds (pad/AUDIT-REVIEW.md). These were internal reviews, not a third-party audit. Round 1 found one High (atomic sandwich of permissionless burns), two Mediums (per-swap anti-snipe bypass, exact-output fee underpayment) and four Lows. Rounds 2 and 3 found and fixed JIT-liquidity cap inflation, a fail-open TWAP floor, a ZERO re-roll, raffle capture, a stranded ERC-20 route, and creator recapture of the sniper tax. The round-4 verdict: no High or Medium open.

The test suite has 78 Foundry tests across unit, audit-regression and Elysium fork suites (fork tests run against block 293500), with ArbSys mocked locally.

Known residual risks

• Sequencer trust. Elysium's single sequencer orders transactions and produces block hashes; it could bias ZERO draws and reorder trades.
• Fallback salt (R4-L2, accepted). The anchoring transaction can see the fallback salt. It only matters if nobody draws for 256 L2 blocks.
• Same-second griefing (R3-L1, accepted). A dust swap blocks burns in that pool for that one second. Keepers retry the next second.
• Sybils in ZERO. The 5% win cap is per address; many addresses are not detected.
• $ELYSIUM sniper excess to team (accepted design choice). On $ELYSIUM only, early-block tax goes to the team wallet, not the burn.
• Owner powers. Everything in section 10 stays live until ownership is renounced.

Contracts and runtime hashes

Each row is read from Elysium in your browser: code at the address, its runtime keccak256 (immutable slots zeroed) against our build, deploy block, owner and fee settings. The same table is on /proofs.

13Roadmap status

Roadmap status

The roadmap on the home page lists what runs at launch, what waits for the public mainnet and what is still only planned. Contract rows there read Live only when the address has code on Elysium.

Open the roadmap