How the HYPE burn total is calculated
HYPE leaves the supply for good in four ways, and the total on this page adds them up: HYPE bought by the Assistance Fund, HYPE destroyed by HyperCore itself, HYPE sent to HyperCore’s zero and dead addresses, and gas burned on HyperEVM.
Hyperliquid runs two connected chains. HyperCore is where trading happens, and HyperEVM runs smart contracts. HyperCore records HYPE with 8 decimals and HyperEVM with 18, so every amount is converted to HYPE before the four are added. None of the four overlaps another, so no HYPE is counted twice.
Which HYPE burns are counted
Protocol Assistance Fund buybacks
The Assistance Fund is a Hyperliquid system address that buys HYPE on the order book. Hyperliquid’s fee documentation says the HYPE it holds is burned.
The tracker adds up the size of every HYPE purchase the fund makes. A trade counts only if HYPE is the market’s base token and the fund was the buyer, and each trade is counted once.
Trade-by-trade records begin on 22 March 2025. Everything the fund bought before then is one opening balance of 17,987,320.50473923 HYPE: the fund’s official balance minus the purchases recorded since. It is a reconciled figure, not a single transaction.
HyperCore protocol burns
HyperCore destroys HYPE as it runs. Spot-trading fees paid in HYPE, order-priority and gossip-priority fees, deploy-gas auctions, slashed HIP-3 stake and sub-lot dust all reduce HYPE’s total supply. Hyperliquid reports the result as one number and doesn’t split it by cause, so the tracker doesn’t either.
Everything destroyed from genesis through 30 September 2026 is one opening balance of 1,104,483.93233325 HYPE, read at 00:00 UTC on 1 October 2026. Since then the tracker reads the supply about every five minutes. Each UTC day adds the change from the first reading after 00:00 UTC to the first reading after the next midnight.
A reading is one request to the official HyperEVM RPC. It calls three of Hyperliquid’s read precompiles, the built-in functions that let HyperEVM read HyperCore, for HYPE (HyperCore token 150): tokenInfo, tokenSupply and spotBalance. Every read in the request has to see the same HyperCore block, or the request is repeated. A reading is rejected unless the token is HYPE with 8 decimals, maxSupply is exactly 1,000,000,000, and circulating supply + non-circulating balances + future emissions add up to totalSupply exactly. The two readings that bound a day are stored with that day’s figure, along with their HyperCore blocks.
HyperCore null-address burns
HYPE sent to HyperCore’s zero address (0x0000…0000) or dead address (0x0000…dEaD) can never move again. No one holds a key for either address, and Hyperliquid itself lists both balances as non-circulating.
From HYPE’s genesis to 00:00 UTC on 1 October 2026, every transfer into either address is its own record. The transfers come from Hyperliquid’s official ledger for the two addresses and are kept with the release. They add up exactly to the balances read at 00:00 UTC on 1 October 2026, with one exception: a 0.001 HYPE transfer to the dead address on 30 November 2024. It was smaller than one HYPE lot (0.01), so the daily spot dusting removed it, and it is not counted.
From 1 October 2026, each UTC day adds the change in the two addresses’ HYPE balances, measured the same way as the HyperCore protocol burns. If a balance falls or carries a hold, the tracker stops instead of counting it.
HyperEVM gas burns
HyperEVM burns the full gas charge of every transaction: the base fee and any priority fee. For every finalized block, the tracker adds up gasUsed × effectiveGasPrice from the receipts of its transactions.
The blocks and receipts come from Hyperliquid’s official S3 archive, a requester-pays bucket that serves as both the history and the live feed. Each sync covers a limited run of consecutive blocks. It verifies one object and its ETag for every block, recomputes the exact fee total from the receipts, and saves the burn records, daily totals, checkpoint and last-checked time in a single step.
Every 10 minutes the tracker also checks the official RPC. If the archive sync has fallen behind, it reads the missing blocks from RPC receipts: the official RPC for short gaps, Stakely’s public archive RPC for longer ones. Beyond 2,500 blocks it stops and waits for the official archive to recover.
What the record covers
Two of the four mechanisms have no day-by-day history for their first months. For that period the tracker holds one opening balance instead.
- Assistance Fund buybacks are recorded trade by trade from 22 March 2025. Earlier purchases are the opening balance described above.
- HyperCore protocol burns are counted day by day from 1 October 2026. Everything before is one opening balance, because no source records those burns by day. Hyperliquid’s raw archive holds spot fees, priority fees and auction gas, but not the ALO order-priority fees charged when orders are placed, and those were about a quarter of HyperCore burns in a block-by-block check on 30 September 2026.
- HyperCore null-address burns are complete from HYPE’s genesis.
- HyperEVM gas burns start at block 1 on 18 February 2025.
HyperCore burns before 1 October 2026 are in the all-time total, but not in the 1-day to 1-year figures.
That is how every opening balance works: it counts in the all-time total and in burned supply, but not in dated ranges, charts or pace. HyperCore amounts for the current UTC day are added when the day closes.
Why no HYPE is counted twice
The protocol-burn figure is the amount by which HyperCore’s totalSupply has fallen below 1,000,000,000 HYPE. The HYPE held by the Assistance Fund and by the zero and dead addresses is still part of totalSupply, so it can’t be inside that figure as well.
HyperEVM gas never reduces totalSupply either. The bridge address 0x2222…2222 holds a constant 1,000,000,011.358 HYPE across HyperCore and HyperEVM combined (to within 0.000001 HYPE of rounding), however much gas HyperEVM burns.
What is not counted
- HYPE sent to the HyperEVM zero address. Priority fees land there and are already counted as gas, and user transfers can’t be told apart from them without a full transfer scan.
- The 2.99 HYPE at the HyperEVM dead address.
- Staked, locked, bridged or treasury HYPE.
How the figures on this page are calculated
Every tracker works out its figures the same way. Days are UTC calendar days.
| Figure | How it is calculated |
|---|---|
| Total burned | Every accepted daily amount of every mechanism, from the date that mechanism’s coverage starts. A record counts only once it is final: a finalized burn record, or a finalized daily figure from the chain’s official data provider. Duplicates and records held back for review stay out. |
| Today, 7-day and 30-day burn | Burns are added up by UTC calendar day. Today is the current UTC day. The 7-day and 30-day figures add the current day and the 6 or 29 days before it. A day with no record adds zero, and opening balances are left out. |
| Daily and moving averages | The 7-day and 30-day averages on the cards divide those totals by 7 and 30. The average lines on the charts are plain averages of the last 7, 30, 90 or 365 daily rows, or of as many as there are. |
| Daily USD estimate | The day’s burn × the last CoinGecko USD price stored on that same UTC day. It is shown with ≈ and rounded. It is left out when no price was stored that day, and on cumulative-chart points that include an opening balance, because that balance built up before the date shown. It is a reference value: not the price at the time of each burn, not a volume-weighted price, and not sale proceeds or an exact trade value. The figure for the current UTC day can still change as burns and prices arrive. |
| Burned supply | Total burned ÷ the all-time peak supply × 100. That baseline is not the latest circulating supply, and it comes from a different source than the market data. |
| Mechanism and contributor shares | A mechanism’s amount ÷ the total burn on record, or a known contributor’s amount ÷ that total. Burns with no known sender stay in the total and are not assigned to anyone. |
| Cumulative chart | For the range you select, the chart starts at the all-time total minus the days in the range, then adds each UTC day back in order. The change over the range is the last value minus the first. |
| Burn calendar | A cell is the sum of all mechanisms for that day. Its colour ranks the day against the others, by relative size or by percentile, and never changes the amount. A day with no record is blank, which means unknown. The exception is a tracker whose every mechanism proves the day, in one of two ways. Either the mechanism holds every transfer into its burn addresses, or their exact balances, from the start of its coverage, checks them against the on-chain balances on each update, and has checked past the end of that UTC day. Or its history is complete and closed, because the chain or program that burned can burn no more. On those trackers a day with no burn shows as 0. |
| Time to burn another 10% | (Latest reported total supply × 10%) ÷ the selected daily burn pace ÷ 365.25, in years. It is a straight-line scenario, not a forecast: it assumes supply policy, issuance, activity and burn rate all stay as they are. |
