Purr Loading data

PURR burn tracker.

See the 400,000,000 PURR that Hyperliquid burned at PURR's launch in 2024, which is most of the total, and the trading fees paid in PURR that HyperCore burns.

Total burned — PURR indexed burns
Checking sources Loading current status
7-day burn — Loading seven-day average
30-day burn — Loading 30-day average
Total burned supply — Loading supply reference
Burn history

Burn activity over time

Latest burn Loading latest burn
Burned at — Loading transaction
Amount — Loading mechanism
Usual gap between burns — Loading recent burns
Cumulative burned — PURR
Loading history
Cumulative token burns A cumulative burn chart for the selected time range.
Move across the chart to inspect a date.
Burn mechanism Where burns originate
Burn mechanism breakdown Recorded burns grouped by mechanism. — indexed
Primary indexed
——
Other indexed
——
Daily totals

Daily burn pace

Loading history
Daily burns — average per day
7-day 30-day 90-day 365-day
Supply impact model What does the current pace mean?
Time to burn another 10% of supply —
Current 30d average
Selected pace

Straight-line estimate. It does not predict token price, network activity, or future policy.

Burn calendar

Daily burn calendar

Loading 52-week UTC window
Active days — Loading elapsed UTC days
Longest streak — Consecutive days with indexed burns
Peak day — Loading indexed daily totals

Loading daily burn totals…

No daily record
Less More

Select a day to see its recorded burn total. A blank cell means there is no daily record; it does not mean zero tokens were burned.

Market context

Price history and reference levels

Checking market history
Price history —
Token price history Token price history for the selected time range.
Move across the chart to inspect an exact price.
Reference levels Market range
24-hour low
—
24-hour high
—
All-time high
—
All-time low
—
Below ATH
—
Supply ratio
—

Loading connected market data and reference levels.

Supply

Burned share of supply

— burned — current supply — initial supply
Contributors

Top burners

Attributed wallets and protocols
RankEntityDirectFeesTotalShareTxs
Burn records

Largest indexed burn records

Loading ranked records
Largest indexed burn records ranked by token amount
RankDate / mechanismAmountCurrent valueSource eventsSource
Loading largest indexed records...

Current value uses the latest available market price, not the token price when the burn occurred.

Ledger

Latest burns

Loading burn index Loading records
TimeTypeAmountBlockSource / Reference
Loading burn records...
Methodology

How the PURR burn total is calculated

Global verification standard →

PURR's burned total has two lines, shown separately. The launch burn is one burn of 400,000,000 PURR on 16 April 2024, when spot trading in PURR opened on Hyperliquid. The HyperCore fee burns are the trading fees paid in PURR, which HyperCore destroys. Most of the total is the launch burn: 98.7% of it at the opening reading on 2 October 2026. Both lines come from Hyperliquid's own PURR supply on HyperCore: total burned = 1,000,000,000 PURR (maxSupply) − totalSupply, of which the launch burn is a fixed 400,000,000 PURR and the HyperCore fee burns are the rest.

01

Launch burn

Calculation
Launch burn = 400,000,000 PURR, counted once as an opening balance dated 16 April 2024. That is 40% of PURR's 1,000,000,000 supply. It had first been set aside as HIP-2 liquidity for the PURR/USDC order book (Hyperliquidity, the automatic market making that Hyperliquid runs on a new token's order book), and Hyperliquid burned it instead when spot trading opened.
Evidence and coverage
The source is Hyperliquid's own announcement on X on 16 April 2024 (x.com/HyperliquidX/status/1780079468918587507): 40% of the supply first allocated to HIP-2 would be burned instead. Hyperliquid published no transaction or exact time for the burn, so it is dated to that day. Hyperliquid's own figures agree with it: maxSupply − totalSupply is above 400,000,000 PURR in every reading the tracker takes, and PURR's linked HyperEVM contract (0x9b498c3c…1872b44e) has a total supply of exactly 600,000,000 PURR, the supply left after the burn. The tracker reads PURR's supply every hour for this line, and both PURR lines stop if maxSupply − totalSupply is ever below 400,000,000 PURR. Each UTC day that passes this check is recorded as 0.
02

HyperCore fee burns

Calculation
HyperCore fee burns = 1,000,000,000 PURR (maxSupply, set when PURR was created, which never grows) − totalSupply − 400,000,000 PURR (the launch burn), in HyperCore's native 5-decimal units. Everything burned from PURR's launch until 18:15 UTC on 2 October 2026 is one 5,200,813.97007 PURR opening balance, read at that time. After it, each UTC day adds the change from its first reading to the first reading after the next midnight (2 October 2026 counts from 18:15 UTC only); the tracker reads about every five minutes. Between 15:45 UTC on 1 October and 18:15 UTC on 2 October 2026, HyperCore burned 9,523.62813 PURR in fees, about 8,600 PURR a day.
Evidence and coverage
Under Hyperliquid's HIP-1 token standard, the trading fees paid in a spot token go to the token's deployer at the deployer's fee share, and the rest is burned. PURR's deployer fee share is 0, so every trading fee paid in PURR on the PURR/USDC order book is burned. Buyers pay their fee in PURR, the token they receive; sellers pay theirs in USDC, which is not burned. So only the fees paid in PURR burn PURR, not every trading fee. Each reading is one request to the official HyperEVM RPC that calls Hyperliquid's tokenInfo, tokenSupply and spotBalance read precompiles for PURR (HyperCore token 1). Every read in the request must see the same HyperCore block (otherwise the request is repeated), and a reading is rejected unless the token is PURR with 5 decimals, maxSupply is exactly 1,000,000,000 and circulating supply + non-circulating balances + future emissions add up to totalSupply exactly. Both boundary responses, with their HyperCore blocks, are stored with every daily figure.
Shared formulas

How the page derives every displayed metric

Total burned
Sum all accepted daily mechanism amounts on or after each mechanism's coverage boundary. Only finalized, published normalized events or accepted finalized provider-day observations enter the aggregate; duplicate identities and quarantined records do not.
Today, 7-day, and 30-day burn
Sum mechanism amounts by UTC calendar day. Today uses the current UTC day; the other cards sum the current day plus the preceding 6 or 29 UTC days. Missing days contribute zero. Reconciled opening balances are excluded from these pace windows.
Daily and moving averages
The 7-day and 30-day card averages divide those fixed UTC-window totals by 7 and 30. Chart lines are trailing arithmetic means over up to 7, 30, 90, or 365 available daily rows.
Daily USD estimate
Positive UTC-day burn amount × the last positive CoinGecko USD reference price stored within that same UTC day. It is displayed with ≈, rounded for readability, and omitted when no same-day price exists. Cumulative-history points containing a reconciled opening balance also omit it because that balance accrued before the displayed date. This is a reference valuation, not transaction-time pricing, VWAP, sale proceeds, or an exact execution value; the current UTC day can change as new burn and price observations arrive.
Burned supply
Total burned ÷ the disclosed all-time peak protocol-supply baseline × 100. The baseline is not the latest circulating supply and is sourced separately from market data.
Mechanism and contributor shares
Mechanism amount ÷ total indexed burn, or attributed contributor amount ÷ total indexed burn. Unattributed burns remain in the total and therefore are not reassigned to known entities.
Cumulative history and calendar
For a selected range, start at lifetime total minus the included daily rows, then add each UTC day back in order; the range change is the last cumulative value minus the first. Calendar cells sum all mechanisms per day and rank positive days by relative or percentile intensity, which changes color only—not the amount. A day with no row is blank (unknown), except on trackers whose every mechanism proves the day: either it holds every transfer into its burn addresses, or their exact balances, from its coverage start, 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. There, a day with no burn shows as 0.
Time to burn another 10%
(Latest reported total supply × 10%) ÷ selected daily burn pace ÷ 365.25. This is a straight-line scenario, not a forecast; it assumes no change in supply policy, issuance, activity, or burn rate.