Whitepaper

Abstract

Hyburn is a contract on HyperEVM that opens a round every 999 seconds. Anyone may burn HYPE into the open round. When it ends, the HYBURN issued for that round is divided among the burners in proportion to what each burned. Issuance per round is fixed in advance and halves every 86,400 non-empty rounds, 43 times, until exactly 999,000,000 HYBURN exist. Burned HYPE goes to a vault that cannot be opened. There is no premine, no team allocation, no administrator, no upgrade path, no randomness and no way to change any parameter after deployment.

1. Rounds

Time is divided into rounds of 999 seconds starting at a genesis timestamp fixed at deployment: round r covers [genesis + 999r, genesis + 999(r+1)). Genesis is the deployment block timestamp plus 999 seconds (16 minutes, 39 seconds). Burns are rejected before genesis; round 0 opens at genesis.

A round that receives no burn issues nothing and does not advance the issuance schedule. Each round that receives at least one burn is assigned the next mining sequence number at its first burn. Issuance depends only on that number.

2. Burning

A burn is a call to burn(expectedRoundId) carrying HYPE as value, at least 0.000999 HYPE, with no upper bound. The HYPE is forwarded in the same transaction to a vault contract whose only function is to receive; nothing can withdraw from it. The contract records the amount against the sender for that round. Several burns by the same account in the same round accumulate.

The caller names the round the burn is intended for. If the transaction is included after that round has ended, the call reverts and the HYPE is returned. A burn therefore never lands in a round the burner did not choose.

This is an economic burn on HyperEVM. It removes the HYPE from circulation permanently; it is not a reduction of HYPE's protocol-level supply on HyperCore.

3. Issuance

reward(seq) = 5,781.25 HYBURN >> floor(seq / 86,400)
reward(3,715,199) += 0.0012096 HYBURN   (arithmetic remainder, last sequence)

The sum over all 3,715,200 sequences is exactly 999,000,000. If every round is non-empty, one era lasts 999 days and the schedule ends after about 117.6 years. Economically meaningful issuance ends much earlier: from era 13 a round issues less than one HYBURN. After the last sequence, burning is rejected.

4. Distribution

For an account that burned b wei into a round whose total is T wei, the payout is reward × b / T with integer division. The rounding loss is below one base unit (0.000000001 HYBURN) per account per round and is never minted, so the minted supply is at most the scheduled supply.

Timing within the round does not change the payout. Splitting a burn across wallets does not change the payout. Burning more is the only way to receive more.

5. Claiming

Payouts are pulled, not pushed. After a round ends, claim(round, account) mints the account's share to the account. Anyone may call it for anyone; the tokens only ever go to the burner. There is no deadline. claimMany claims several rounds in one transaction, and a burn into a new round claims the caller's finished rounds in the same transaction.

6. Cost of a round

There is no difficulty parameter. The total burned in a round is the difficulty: the more HYPE in the round, the fewer HYBURN each HYPE receives. It adjusts every round with no retarget rule. Rounds with low participation pay more per HYPE.

7. Properties

• No one received anything before the first burn. The deployer has no privileges; the deploying key can do nothing the public cannot.
• The supply cap, the schedule, the round length and the minimum burn are constants in the bytecode. There is no function that changes them, pauses the contract, upgrades it or withdraws from the vault.
• Nothing is drawn. Payouts are a deterministic function of the burns in a round. No validator, proposer, bot or operator can change who receives what.
• The burn record (every round, every account, every amount) is public on chain and sufficient to reconstruct every balance.

8. Trust assumptions and limits

• HyperBFT. Hyburn runs on HyperEVM and inherits its consensus entirely. The burn secures nothing; the chain does. If Hyperliquid stops, Hyburn stops.
• The last block of a round. The validator producing it can leave a transaction out. The excluded burner misses the round and keeps the HYPE; the remaining burners' shares rise proportionally. This is the entire extent of the influence and it is avoided by not burning in the final second.
• Price. The contract guarantees the rules, the supply and that burning is the only source of HYBURN. It does not guarantee a price. HYBURN has no function inside the contract.
• Liquidity. There is no treasury, so no one is obliged to provide a market.

9. Contracts

Three contracts, deployed by one transaction, none upgradeable. The Miner holds no funds at any time.

Building the source at that commit with the compiler settings recorded in the repository must reproduce the deployed bytecode exactly. The comparison command and the test suite are in the repository README.

10. Parameters

11. Mining software

Four miner implementations (Python, Rust, Go, Node.js) share one command set and pass the same scripted scenario. See Mine. Both actions are also plain contract calls from any explorer.