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

Burned supply Loading supply reference

30-day burn — Loading 30-day average

Burn history

Burn activity over time

Move across the chart to inspect a date.

Primary indexed: ——
Other indexed: ——

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

Global verification standard →

ICP exposes separate cumulative native series for ledger fees and explicit protocol burns. The tracker converts consecutive official cumulative observations into non-overlapping UTC-day amounts.

Ledger fee burns

Calculation: For each complete UTC interval, daily fee burn = official burn_type=fee cumulative value at the end boundary − the value at the start boundary.
Evidence and coverage: Both boundary rows and the raw official Ledger API response are retained as immutable evidence. Missing boundaries or a regressing cumulative series fail validation.

Native protocol burns

Calculation: For each complete UTC interval, daily protocol burn = official burn_type=burn cumulative value at the end boundary − the value at the start boundary.
Evidence and coverage: The protocol series is kept separate from fees, uses the same two-boundary proof, and does not create synthetic transaction records.

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 holds every transfer into its burn addresses since the token was created and checks the running total against their on-chain balances on each update: there, a whole UTC day that the latest checked update has passed, with no transfer, 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.