POL Burn

POL burn is the part of Polygon token economics that removes POL or legacy MATIC from circulating-supply accounting. It links network activity to token supply and can offset part or all of new POL emission over a measured period. Burn does not automatically stop the EmissionManager or create a hard supply cap.

This topic is also searched as POL token burn, MATIC burn, Polygon burn, Polygon EIP-1559 burn, POL burn rate, burned POL supply, Polygon deflation, POL inflation after burn, or is POL deflationary. These phrases are related, but they do not always describe the same on-chain event.

Why Burn Matters

Polygon Chain charges a dynamic EIP-1559 base fee for transactions. Instead of treating all transaction fees as validator income, Polygon directs the base-fee component toward its burn system. More network use can therefore remove more POL from circulating-supply accounting.

Burn matters because gross emission and net supply growth are not the same:

Net issuance = newly minted POL - permanent burn

POL currently has gross emission for validator funding and the Community Treasury. Base-fee burn counterbalances that issuance. If burn is lower than minting, supply grows more slowly; if burn equals minting, net issuance is zero; and if burn exceeds minting, POL is net deflationary for that measured period.

The most important current point is that PIP-82 did not end Polygon's base-fee burn. The PIP authors' published specification confirms the underlying design: fees associated with eligible public x402 facilitators can be recycled as rebates, the total program is capped at 1,000,000 USD, and all non-recycled POL continues to the existing burn collector. This is a limited exception, not a network-wide suspension of burn. A correction in the official PIP-82 forum discussion makes the same point in plain language: normal transactions continue on the burn path, and rebates apply only to eligible public facilitators.

For that reason, saying that almost all Polygon base fees remain intended for burn is a useful plain-English summary of the current design: only a limited eligible subset can be recycled, and the rest is forwarded to the burn collector. It is not a guaranteed fixed percentage. The exact realized share depends on eligible transaction volume, POL prices at settlement, rebate payments, and collector transfers.

See the live numbers on POLTRACK:

• Value Flow shows base fees, the routing-wallet balance, rebates, 30-day burn, and all-time burn;
• Supply shows permanent burn, net issuance, circulating supply, and the burn-adjusted max expected supply.

Short Answer

• Polygon introduced EIP-1559 base-fee burn on January 18, 2022.
• The original MATIC path used a Polygon-side burn contract and an Ethereum-side transfer to the MATIC dead address.
• PIP-24 changed the Polygon recipient to the 0x7A8e... burn collector on November 29, 2023.
• Since the Lisovo hardfork on March 4, 2026, PIP-82 sends new base fees first to 0x3ef5....
• Normal transactions still follow the burn path. Only fees associated with eligible public facilitators can be recycled under the capped PIP-82 program.
• Non-recycled POL is sent to 0x7A8e..., so almost all base fees are expected to remain burn-directed under the program's limited scope.
• POLTRACK does not count the 0x3ef5... routing balance as permanent burn.
• POLTRACK counts the 0x7A8e... collector balance as non-circulating burn under its published methodology.
• A collector transfer does not reduce the Ethereum POL token's ERC-20 totalSupply() by itself.
• POLTRACK also carries forward the observed legacy MATIC dead-address balance so historical MATIC burn is reflected once, not twice.
• MATIC held by the MATIC token contract itself is disclosed as inaccessible legacy context but is not included in POLTRACK calculations.

Executed Burn History

The meaning of "Polygon burn address" changed over time. A reliable burn history must use the recipient active at each block.

The active addresses and block boundaries are visible in the official Bor mainnet configuration and in the PIP-82 implementation commit.

January 2022: Original EIP-1559 Burn

Polygon activated EIP-1559 at block 23,850,000. Transaction fees were split into:

Transaction fee = base fee + priority fee

The base fee was assigned to the configured burn contract rather than paid to the block producer. The priority fee remained the validator-facing fee component.

In the original Polygon design, base-fee MATIC accumulated at 0x70bc... on Polygon. The corresponding burn flow could be completed on Ethereum, where MATIC was sent to:

0x000000000000000000000000000000000000dEaD

PIP-24 describes this original contract as immutable and states that the Ethereum-side step permanently removed the MATIC from supply. Polygon's launch materials also explained that EIP-1559 made the base fee burnable while validators received the priority fee.

The original path matters because historical MATIC burn still affects POL-era supply comparisons. It must not be discarded merely because POL later replaced MATIC as the native gas token.

November 2023: PIP-24 Burn Collector

PIP-24 changed the Bor burntContract recipient from 0x70bc... to:

0x7A8ed27F4C30512326878652d20fC85727401854

The change was activated by the Agra hardfork at block 50,523,000.

PIP-24 calls 0x7A8e... a temporary holder contract intended to collect MATIC, or POL after the native-token migration, for burn. It also states that a later protocol change would be required to complete a future Ethereum-side burn route.

This creates two valid but different descriptions:

• Polygon protocol description: 0x7A8e... is the current burn collector and receives POL intended for burn.
• Strict ERC-20 description: a native POL balance at this Polygon address does not call _burn() on the Ethereum POL token and does not reduce Ethereum totalSupply().

The current 0x7A8e... implementation accepts POL and exposes no ordinary withdrawal method. The address is nevertheless an upgradeable proxy, as anticipated by PIP-24. POLTRACK therefore does not claim that the collector is cryptographically identical to a dead address. It applies an explicit economic classification:

POL at 0x7A8e...
= protocol-designated burn collector balance
= non-circulating under POLTRACK methodology

That classification preserves the existing POLTRACK interface term Permanent burn while documenting exactly what the metric means.

September 2024: MATIC Became POL On Polygon Chain

The native-token migration changed Polygon Chain gas and staking from MATIC to POL. It did not reset the EIP-1559 accounting history.

From that point, new native base-fee value accumulated as POL. Historical Ethereum MATIC dead-address balances remained legacy evidence of tokens already removed before or during the migration period.

This is why a complete POL burn model can contain both a current native POL collector component and a legacy MATIC dead-address component. They represent different periods and are not interchangeable.

March 2026: PIP-82 Routing And Rebates

PIP-82 changed the configured EIP-1559 recipient to:

0x3ef57def668054dd750bd260526105c4eeef104f

The change was included in Bor v2.6.0 and activated by the Lisovo hardfork at block 83,756,500.

Under the PIP-82 design:

1. block execution sends base fees to 0x3ef5...;
2. eligible Agentic Commerce and x402 base fees can be recycled as rebates;
3. non-recycled POL is periodically sent to 0x7A8e...;
4. the program is limited to 1,000,000 USD and ends when the allowance is exhausted or on December 31, 2026, whichever comes first, unless replaced by another protocol decision.

The routing address can make outgoing transfers. Its balance is therefore not permanent burn and is not subtracted from supply.

PIP-82 routing balance
= base fees received
- POL sent to burn collector
- eligible rebates and other classified program outflows

On POLTRACK, this appears as Base Fees (routing wallet) in Value Flow and Awaiting burn in Supply. The wording in the product remains unchanged.

How Bor Creates The Base-Fee Balance

The most important accounting distinction is:

Base fee generated != POL permanently removed at that moment

Polygon Chain, historically and technically also known as Polygon PoS, routes EIP-1559 base fees through protocol-defined addresses. Depending on the active period, the route can involve a bridge burn contract, a burn collector, or a temporary program wallet. POLTRACK therefore separates:

• base-fee generation - the fee calculated from block gas use;
• routing balance - POL waiting in a wallet that can still send funds elsewhere;
• rebates - eligible POL returned under the PIP-82 program;
• realized burn - value that reached a sink counted as non-circulating under the POLTRACK methodology;
• net issuance - newly minted POL minus realized burn for the same period.

Polygon's Bor execution client calculates the base-fee amount from gas used and the block base fee:

Base fee amount = transaction gas used * block base fee

The Bor state transition code selects the configured BurntContract for the current block and credits that address with the base-fee amount.

This is different from Ethereum's usual accounting, where the base fee is removed without crediting an account. On Polygon Chain, the client credits a protocol-selected address, so the economic result depends on what that address can subsequently do.

Priority fees follow a different path and must not be included in base-fee burn merely because both are paid by the same transaction. See Polygon Chain Fees and Priority Fee Distribution.

What POLTRACK Counts As Permanent Burn

POLTRACK keeps the existing product label Permanent burn. In methodology terms, it means the cumulative value in the approved burn components treated as non-circulating for public supply accounting.

The current model includes:

The public supply formulas are:

Permanent burned total
= Polygon burn collector balance
+ POL zero-address balance
+ legacy MATIC dead-address balance

Circulating supply
= gross POL supply - permanent burned total

Current max expected supply
= 12,336,136,524.75 POL - permanent burned total

The gross 12,336,136,524.75 POL baseline and burn adjustment are explained in POL Emission.

What POLTRACK Does Not Count

The following balances are excluded from permanent burn:

These exclusions are deliberate. They prevent temporary routing, proposals, and duplicated MATIC-to-POL representations from silently reducing reported supply.

PIP-25 And Historical MATIC Burn

PIP-25 proposed using the PolygonMigration contract's burn() function to send POL corresponding to previously burned or inaccessible MATIC to the Ethereum dead address.

The current PolygonMigration source implements burn(amount) as a transfer of POL to 0x000...dEaD. It does not call the POL token's internal _burn() and therefore does not reduce ERC-20 totalSupply().

The official PIP-25 transparency report prepared a transaction for 28,574,088.177694505243495294 POL. The report's own validation rule required the POL dead-address balance to be at least that amount after execution.

POLTRACK does not assume that a PIP status or prepared transaction proves execution. The published validation condition has not been observed, so the proposed POL amount is not added to burn.

MATIC Held By The MATIC Token Contract

PIP-25 also identified MATIC held at the MATIC token contract's own address as permanently inaccessible. An ERC-20 contract can have a balance in its own balance mapping when users or contracts transfer tokens directly to the token address. The legacy MATIC contract has no ordinary recovery path for that self-balance.

The PIP-25 execution report used a fixed historical snapshot of this component. The live balance can continue increasing when more MATIC is sent to the token address.

POLTRACK currently excludes the entire MATIC self-balance from:

• permanent burned total;
• circulating supply adjustments;
• net issuance;
• current max expected supply.

It is disclosed here for completeness only. No POLTRACK interface value or calculation changes because of this balance.

Burn, Emission, And Deflation

Burn and emission must be compared over the same period:

Net issuance = newly minted POL - permanent burn

POL can therefore be net deflationary for a particular day, month, or year while the EmissionManager continues minting. "POL is deflationary" is incomplete unless the statement includes a time period and a burn definition.

Burn also does not create a hard cap. Future gross issuance still depends on the active emission implementation, while POLTRACK's current max expected supply is a ten-year scenario adjusted downward by observed permanent burn.

Why Burn Charts Move In Batches

Before PIP-82, base fees were sent directly to the configured burn collector, so collector growth could track fee generation closely.

After PIP-82, base fees first accumulate at the routing wallet. Transfers to the collector and rebate settlements happen in transactions that can combine many days of value.

As a result:

• a high-base-fee day may show little same-day realized burn;
• a collector settlement day may show a large burn spike;
• the routing-wallet balance can grow between settlements;
• a negative routing-wallet delta is not negative burn; it usually means funds left the routing wallet;
• fee generation and realized burn should be reconciled over a suitable period, not assumed equal day by day.

POLTRACK preserves these batch effects instead of redistributing them across earlier dates.

Common Questions

Does Polygon burn POL?

Yes. Polygon Chain directs the EIP-1559 base-fee component toward its burn system. Since POL became the native gas token, new base-fee value is denominated in POL. Historical MATIC burn remains relevant to the migrated token's economic supply history.

Are almost all Polygon base fees still burned?

That is a reasonable summary of the current PIP-82 design, with one qualification: it is not a guaranteed numerical percentage. Only fees associated with eligible public x402 facilitators can be recycled as rebates, the program has an aggregate 1,000,000 USD cap, and non-recycled POL is sent to the existing burn collector. Normal transaction base fees continue on the burn path.

Did PIP-82 stop POL burn?

No. PIP-82 changed the first recipient of base fees and introduced a limited rebate path. It explicitly keeps the existing collector active for non-recycled POL. The routing step can delay when burn appears in POLTRACK, but it does not replace the burn system with a general rebate system.

Does Polygon burn every transaction fee?

No. The EIP-1559 base-fee component is associated with burn mechanics. The priority-fee component follows validator and staker distribution policy. Under PIP-82, even base-fee value can remain in routing or be recycled as an eligible rebate before the non-recycled amount reaches the burn collector.

Is the PIP-82 wallet a burn address?

No. It is the configured base-fee recipient and a routing wallet. It can make outgoing transfers, so POLTRACK shows its balance as awaiting burn and excludes it from supply burn.

Is the 0x7A8e... collector the same as a dead address?

No. It is a protocol-designated burn collector. Its current implementation exposes no ordinary withdrawal method, but it is an upgradeable proxy described by PIP-24 as a temporary holder. POLTRACK counts the balance as non-circulating under an explicit methodology rather than claiming it is technically identical to 0x...dEaD.

Does burn reduce POL totalSupply()?

Not necessarily. Sending native POL to a Polygon collector or ERC-20 POL to a dead address leaves the Ethereum POL contract's totalSupply() unchanged. POLTRACK applies burn-adjusted economic accounting separately.

What is the difference between base fees and priority fees?

The base fee is the EIP-1559 component directed through Polygon's burn mechanics. The priority fee is the additional transaction-fee component used for validator and staker economics under the active fee-distribution policy. POLTRACK never classifies priority fees as base-fee burn.

Why does POLTRACK still include legacy MATIC burn?

POL replaced MATIC 1:1, but previously burned MATIC could never migrate into circulating POL. The legacy dead-address component preserves that historical reduction in the POL-era economic supply model.

Does POLTRACK count the PIP-25 amount?

No. POLTRACK does not treat the prepared 28.574M POL transaction as executed because the published on-chain validation condition has not been satisfied.

Does POLTRACK count MATIC trapped in the MATIC token contract?

No. The balance is documented as inaccessible legacy context, but it is excluded from all POLTRACK burn and supply calculations.

Can POL burn offset the 2% emission?

Yes, over a selected period if permanent burn is equal to or greater than minted POL. This changes net issuance for that period; it does not automatically switch off gross emission.

Is POL deflationary?

It can be net deflationary over a day, month, or year when permanent burn exceeds new minting during that same period. That does not prove POL will be deflationary forever, and it does not mean the emission contract has stopped.

What is the POL burn rate?

There is no fixed protocol percentage for the number of POL burned per year. The amount depends mainly on network gas use, base-fee levels, PIP-82 rebates, and the timing of transfers from the routing wallet to the collector. A burn-rate claim should always identify its time window and burn definition.

Why does the POL burn chart show sudden spikes?

After PIP-82, base fees accumulate in the routing wallet before non-recycled POL is transferred to the collector. One settlement can therefore realize several days of burn at once. POLTRACK reports the observed transfer timing instead of spreading the amount backward across earlier dates.

Where can I see POL burn live?

Open Value Flow for 30-day and all-time burn, the PIP-82 routing balance, and rebates. Open Supply for permanent burn, net issuance, circulating supply, and the burn-adjusted max expected supply.

Primary References

• Polygon Developer Docs: EIP-1559
• Polygon Developer Docs: genesis contracts
• Polygon EIP-1559 testnet announcement
• PIP-24: Change EIP-1559 Policy
• PIP-25: Adjust POL Total Supply
• PIP-28: Agra Hardfork
• PIP-82: Agentic Commerce Gas Program
• Official PIP-82 forum discussion
• PIP-25 Council Transparency Report
• Bor burn-recipient configuration
• Bor EIP-1559 state transition
• Bor v2.6.0 / Lisovo release
• PolygonMigration burn implementation
• Polygon burn collector
• PIP-82 routing wallet
• MATIC dead-address balance

Related Pages

• POL Emission
• POL Tokenomics
• Polygon Chain Fees
• Priority Fee Distribution
• Methodology & Data Sources