Aster Loading data

ASTER burn tracker.

See every ASTER sent to the dead address or locked for good in the ASTER token contract, where no one can spend it.

Total burned — ASTER 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 ASTER burn total is calculated

Global verification standard →

ASTER has no burn function, so an ASTER burn is a transfer to an address from which no one can ever spend it. Total burned = the ASTER in every finalized Transfer on BNB Smart Chain since the token was created into two reviewed addresses: the dead address (Burned) plus the ASTER token contract itself (Permanently locked). On every update, the running total for each address is checked against that address's on-chain ASTER balance.

Burned (dead address)

Calculation: Burned = the sum of the ASTER amounts in finalized Transfer logs from the canonical ASTER contract (0x000Ae314…4f556A) into 0x…dEaD, whoever sent them. From December 2025 to May 2026 the large burns were of ASTER the project had bought back: 77,860,328 ASTER on 5 December 2025 and 98,400,345.47 ASTER in three transactions on 5 February 2026, both marked on the cumulative chart. Three smaller burns in that period were airdrop tokens forfeited on early claims, 1,520,328.10 ASTER in total. Since 29 June 2026 the burns, about every two weeks, come from the team's reserve, held in the team's multisig wallet (0x59d8…3b19) and not counted as circulating. Aster says each one equals the ASTER it bought back with trading fees over the same period; the bought-back ASTER goes to stakers instead of being burned. These burns cut ASTER's effective total supply (8 billion minus everything burned) but not its circulating supply, because the reserve was not in circulation. The contract itself still reports a total supply of 8 billion, because burned ASTER sits at the dead address rather than being destroyed.
Evidence and coverage: 0x…dEaD is the standard burn address: no one is known to hold its key, and its ASTER balance has always equalled the ASTER sent to it, so none has ever left. History from creation block 59,613,717 is a fixed-cutoff set of BNB Smart Chain logs, read from an authenticated NodeReal archive node, whose sum equals the address's on-chain balance at the cutoff. Each update reads new logs from the same provider, adds them to a running total and stops without advancing if that total differs from the dead address's balance. The team's multisig wallet is not counted: it holds the rest of the team's reserve, and its signers can move it, so its ASTER counts only once it reaches the dead address.

Permanently locked

Calculation: Locked = the sum of the ASTER amounts in finalized Transfer logs from the canonical ASTER contract into the ASTER token contract itself.
Evidence and coverage: The ASTER contract has no owner and no function to mint, burn, upgrade or withdraw tokens, so nothing can move the ASTER it holds, and a contract cannot sign the permit that would let it approve a transfer. Like the dead address, it has always held exactly the ASTER sent to it, so none has ever left, and it is reconciled on every update.

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.