Internet Computer Loading data

ICP burn tracker

See ICP burned through ledger fees and protocol burns, using daily totals from the official ledger data.

Total burned — ICP indexed burns

Checking sources Loading current status

Burned today — Loading latest UTC day

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

Burned at — Loading transaction

Amount — Loading mechanism

Usual gap between burns — Loading recent burns

Move across the chart to inspect a date.

Mechanism	Share of burns	Burned	Status

Daily totals

Daily burn pace

Loading history

7-day 30-day 90-day 365-day

Daily burn pace —

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

Move across the chart to inspect an exact price.

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

Rank	Entity	Direct	Fees	Total	Share	Txs

Largest indexed burn records ranked by token amount
Rank	Date / mechanism	Amount	Current value	Source events	Source
Loading largest indexed records...

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

Loading burn index Loading records

Time	Type	Amount	Block	Source / Reference
Loading burn records...

Methodology

How the ICP burn total is calculated

The Internet Computer’s ledger publishes two running totals of burned ICP: one for ledger fees, and one for ICP that the protocol burns explicitly. The tracker turns each running total into an amount per UTC day.

Each day’s amount is the difference between two official readings, so the days never overlap, and the two series are kept apart.

Internet Computer ledger

Ledger fee burnsrunning total with burn_type=fee

Native protocol burnsrunning total with burn_type=burn

Added upICP total burnedTwo official series, kept apart

The two official running totals behind the ICP figure.

Which ICP burns are counted

Ledger fee burns

Fee burn for one UTC dayfee total at the end of the day − fee total at the startThe fee total is the official cumulative series with burn_type=fee.

A day is published only when both of its boundary values exist. Both boundary rows are kept, together with the raw response of the official Ledger API, as evidence that is never changed. If a boundary is missing, or the running total ever goes down, the day fails validation.

Native protocol burns

Protocol burn for one UTC dayburn total at the end of the day − burn total at the startThe burn total is the official cumulative series with burn_type=burn.

This series is kept separate from the fee series and is proven the same way, from two boundary values. Each day is one record: the tracker does not make up individual transaction records for it.

What the record covers

Both series start at ICP’s launch on 7 May 2021. Only complete UTC days are published. Each live refresh reads a limited stretch of recent days again, so a revision by the source is noticed.

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.