POL Emission

POL emission is the process that creates new POL after the initial 10 billion token supply and directs the newly minted tokens to validator funding and the Polygon Community Treasury.

This topic is also commonly described as POL inflation, MATIC inflation, Polygon token inflation, POL issuance, or the POL inflation rate. These phrases are related but not identical. In this guide, emission means new POL minted by the protocol, while net inflation means the resulting supply growth after token burns are deducted. “MATIC inflation” remains a common legacy search term because POL replaced MATIC and inherited its validator reward transition, but the current Ethereum emission system mints POL.

Emission is a common part of the economic design of major Layer 1 networks, not something unique to POL. Proof-of-stake networks use new token issuance to reward validator participation and support long-term network security. Ethereum mints ETH as validator rewards, while Solana distributes inflationary SOL issuance to validators and delegated stake accounts. The rates and distribution rules differ by network, but the underlying purpose is similar: fund the participants and infrastructure that keep the network operating securely.

Gross emission does not determine net supply growth on its own. Token burns can partly or fully offset newly issued tokens:

Net issuance = newly minted tokens - burned tokens

If burn is lower than emission, supply still grows, but more slowly. If burn exceeds emission, net issuance is negative for that period. Polygon PoS has its own base-fee burn and routing mechanics, which POLTRACK measures separately from minting. See Polygon PoS Fees and Burn for the complete explanation.

This guide separates three things that are often combined incorrectly:

1. the policy proposed in the POL whitepaper;
2. the emission schedule actually executed on Ethereum mainnet;
3. future scenarios that would require a new protocol decision.

The short version is:

• POL launched on Ethereum with an initial supply of 10 billion tokens;
• its mainnet emission rate has moved from 3% to 2.5% and then to 2% under PIP-26;
• the current implementation targets 2% annual compounded emission, split equally between the StakeManager and Community Treasury;
• the contract accrues emission continuously by time, but tokens are minted in transactions when mint() is called;
• POLTRACK uses October 25, 2033 as the current baseline end date for the published ten-year inflation window;
• Polygon has not adopted a proposal that defines a later endpoint or a post-2033 emission rate;
• stopping emission still requires a deliberate protocol change because the active contract has no automatic end date;
• an earlier stop is technically possible through the same contract controls, but it is not the currently announced schedule;
• excess Community Treasury POL is not burned automatically. The whitepaper says the community could separately decide to burn excess funds.

Track the current numbers on POLTRACK: Value Flow shows minted POL alongside burn, Community Treasury, and validator flows, while Supply shows circulating supply, max expected supply, and net issuance.

Executed Mainnet History

The current 2% implementation was not active for the entire history of POL. PIP-26 preserved the final years of the original MATIC validator reward schedule before transitioning to the long-term 1% validator rate proposed for POL.

The EmissionManager proxy history records all four mainnet implementations.

v1.0: The Pre-Mainnet 2% Design

The repository's v1.0 code implemented the original 1% + 1% design:

Supply(t) = 10B * 1.02 ^ (elapsed / 365 days)

This version was used in pre-mainnet deployment work. Ethereum mainnet launched with v1.1 after PIP-26 had defined the validator transition schedule, so v1.0 was not a mainnet emission period.

v1.1: 3% From Mainnet Launch

Mainnet v1.1 started on October 25, 2023 with:

Supply(t)
= 10,000,000,000 * 1.03 ^ (elapsed since launch / 365 days)

One third of each mint went to the original Community Treasury multisig and two thirds funded validator rewards. For backward compatibility, the validator portion was sent through the migration contract and converted back to MATIC before reaching StakeManager.

The mainnet deployment transaction installed implementation 0x2126E6952C3af75C9D4CF21f63F509195C79ce44 behind the proxy.

v1.2: 2.5% And A New Calculation Base

On July 6, 2024, the Protocol Council executed the first PIP-26 reduction, from 2% validator funding to 1.5%, while treasury emission remained 1%.

The v1.2 upgrade transaction performed an atomic sequence:

1. call mint() on v1.1 to realize all emission vested under the old 3% curve;
2. upgrade the proxy to implementation 0x5e875267f65537768435C3C6C81cd313a570B422;
3. call reinitialize() on the new implementation;
4. save the resulting totalSupply as START_SUPPLY_1_2_0;
5. set startTimestamp to the upgrade block time.

The resulting base was:

START_SUPPLY_1_2_0 = 10,208,953,168.522375 POL
startTimestamp     = 2024-07-06 17:47:59 UTC

Supply(t)
= START_SUPPLY_1_2_0 * 1.025 ^ (elapsed / 365 days)

The same upgrade also redirected the treasury share to the Community Treasury setup introduced by PIP-40. The sequence and validation requirements are documented in the official PIP-26 / PIP-40 Council Transparency Report.

v1.3: Direct POL Funding For StakeManager

On September 4, 2024, v1.3 changed the validator transfer path without changing the emission rate, base, or start timestamp.

// Before v1.3: convert the validator share back to MATIC
migration.unmigrateTo(stakeManager, stakeManagerAmt);

// From v1.3: transfer newly minted POL directly
_token.safeTransfer(stakeManager, stakeManagerAmt);

The v1.3 upgrade installed implementation 0x152442D77E9fB9C210953d583Cbb2da88027fCB9. It did not reinitialize the emission curve. This implemented PIP-41 as part of the MATIC-to-POL staking transition described in the official transparency report.

v1.4: The Current 2% Schedule

On July 9, 2025, the Protocol Council completed the planned PIP-26 transition by reducing validator funding from 1.5% to 1%. Treasury emission remained 1%.

The v1.4 upgrade transaction again closed the old period before switching rates:

Catch-up mint under old 2.5% curve: 1,168,637.300101 POL
Treasury share:                         467,454.920041 POL
StakeManager share:                     701,182.380061 POL

It then installed implementation 0x282FD46E108E40A45e4CE425bA75f80245e6C2E0 and reinitialized the curve from the resulting supply.

The official 2025 PIP-26 Council Transparency Report explicitly specifies the old mint() call, proxy upgrade, reinitialize(), new start supply, and new timestamp.

The sections below explain the two funding streams and contract mechanics behind this executed history.

The Two Emission Streams

The POL design establishes two economic purposes for emission.

These are separate policy purposes, even though the current implementation calculates one combined 2% supply curve and splits every mint in half.

The whitepaper describes each stream as up to 1% of the growing POL supply and sets an initial ten-year funding period. POLTRACK therefore uses October 25, 2033, ten years after the first mainnet EmissionManager timestamp, as the current planning horizon for scheduled inflation. No adopted PIP defines a later endpoint or a post-2033 rate.

The date is a policy endpoint rather than an automatic contract deadline. The active EmissionManager has no built-in shutoff, so ending or reducing emission in 2033 must be implemented through a protocol change. The same controls could technically stop emission earlier, although no published Polygon decision currently makes an earlier stop the base-case schedule.

Initial Supply And Emission

The initial 10 billion POL and later emission are different token events.

At launch, the POL token contract minted 10 billion POL to the migration contract so MATIC holders could migrate at a 1:1 ratio. Normal MATIC-to-POL migration moves tokens out of that initial pool; it is not scheduled emission.

New supply after launch can be created only by an address holding the token contract's EMISSION_ROLE. On mainnet, that role is held by the DefaultEmissionManager proxy.

Initial POL supply = 10,000,000,000 POL

Later gross supply change
= POL minted by the authorized EmissionManager
- any true ERC-20 supply-reducing burn

Transfers to a treasury, StakeManager, migration contract, collector, or dead address do not create tokens. The mint is the POL token Transfer from the zero address to the EmissionManager.

How The Current Contract Works

The current mainnet implementation is DefaultEmissionManager v1.4. It stores a start supply and start timestamp, calculates a time-dependent target supply, and mints the difference between the target and the current POL totalSupply.

Its simplified formula is:

TargetSupply(t)
= StartSupply * 1.02 ^ (elapsedSeconds / 365 days)

AmountToMint
= TargetSupply(t) - CurrentTotalSupply

The Solidity implementation represents the annual factor through fixed-point binary exponentiation:

INTEREST_PER_YEAR_LOG2 = log2(1.02)

SupplyFactor
= exp2(INTEREST_PER_YEAR_LOG2 * elapsedSeconds / 365 days)

The current v1.4 base is:

START_SUPPLY_1_4_0 = 10,466,456,329.199770 POL
startTimestamp     = 2025-07-09 23:03:59 UTC

Every successful mint is divided as follows:

Treasury amount     = AmountToMint / 2
StakeManager amount = AmountToMint - TreasuryAmount

The slight subtraction form used for StakeManager ensures that integer rounding does not leave token dust in the EmissionManager.

Accrual Is Continuous; Minting Is Transactional

The target supply grows continuously with elapsed seconds, but the token contract does not execute itself every second. mint() is a public function that any Ethereum address may call.

When someone calls it, the manager mints all emission that has vested under the target curve since the supply was last brought up to date. The caller does not receive the minted POL. The tokens go only to the configured treasury and StakeManager destinations.

If nobody calls mint() for several days, the scheduled amount is not lost. A later call attempts to catch supply up to the same time-based target.

The Token-Level Safety Cap

The non-upgradeable POL token contract separately applies mintPerSecondCap. At the time of this review, the cap was 13.37 POL per second.

Maximum amount accepted by one token mint
= seconds since the previous token mint * mintPerSecondCap

This is a rate limiter and safety control. It is not a lifetime supply cap and it does not establish a maximum POL supply. The address holding CAP_MANAGER_ROLE can update it through an authorized contract call.

Why June, July, And October All Appear

The dates describe different concepts:

PIP documents describe intended policy periods. Ethereum transaction timestamps identify when the implementation actually changed. A precise historical calculation must use the executed timestamps.

Reconstructing Executed Emission

The full executed history can be represented as a piecewise compounded curve:

Period 1: 10B at 3% for 255.3622 days
Period 2: resulting supply at 2.5% for 368.2194 days
Period 3: resulting supply at 2% from July 9, 2025 onward

For a projection to the exact ten-year anniversary of the original start timestamp:

10,000,000,000
* 1.03  ^ (255.3622 / 365)
* 1.025 ^ (368.2194 / 365)
* 1.02  ^ (3029.4183 / 365)
= approximately 12,336,136,524.75 POL

This is an executed-history-plus-current-contract scenario. It assumes the current v1.4 implementation remains unchanged through the ten-year horizon on October 25, 2033. It is not a guarantee or a hard cap. POLTRACK subtracts permanent burn from this gross baseline when reporting current max expected supply.

Why Supply Projections Differ

Different assumptions produce different values even when they are internally consistent.

The executed model is the current POLTRACK gross max-expected-supply baseline because it reproduces contract history. It is not an immutable maximum because the stop still has to be implemented in the protocol.

How Emission Changes Are Implemented

Emission changes have a public proposal layer and an onchain execution layer.

Public Protocol Process

The POL whitepaper refers to future community decision-making, but the EmissionManager is not currently controlled by direct POL-holder voting. In practice, emission changes have been documented through the Polygon Improvement Proposal repository and Polygon forum, then executed through the protocol's contract administration process.

PIP-29 established the Protocol Council to execute regular and emergency changes to Polygon system smart contracts. PIP-67 later updated its membership.

PIP-29 describes:

• a regular route requiring 7/13 Protocol Council consensus and a ten-day timelock;
• an emergency route requiring 10/13 consensus with no timelock.

The 2024 and 2025 EmissionManager upgrades were publicly documented in Council Transparency Reports and executed through the higher-threshold route.

Current Contract Controls

The current mainnet control structure observed during this review is:

The current rate is compiled into the EmissionManager implementation as a constant. Changing the curve or the split requires a new implementation and proxy upgrade. Separately, the token's authorized administrators can update the mint-per-second cap and administer the address holding EMISSION_ROLE.

The 2033 Policy Endpoint And Technical Controls

The whitepaper says the two 1% rates should remain fixed during the initial ten-year policy period and may be decreased or discontinued afterward. On that basis, October 2033 is POLTRACK's current reference point for ending scheduled inflation. No adopted proposal defines a later endpoint or post-2033 rate.

The Solidity contracts do not contain an immutable ten-year timer. Authorized contract administrators could technically upgrade the EmissionManager, change token roles, or change the mint cap before 2033. This makes an earlier stop possible, but not automatic or currently expected: it would require an explicit protocol decision and implementation.

Community Treasury Emission

The Community Treasury stream is minted at the same time as validator funding. In v1.4, half of every successful emission mint is transferred directly to the configured treasury address.

The EmissionManager does not decide which grants receive funds. Treasury allocation and spending are administered separately. PIP-40 redirected emission to the Community Treasury contracts and describes the Community Treasury Board structure.

This creates three separate questions:

1. Future treasury emission: Should new POL continue to be minted for ecosystem support?
2. Treasury allocation: How should already minted treasury POL be used?
3. Excess treasury POL: Should treasury POL that is no longer required be retained, allocated, or burned?

The whitepaper says that if the ecosystem matures early and the treasury accumulates more POL than it realistically needs, the community should decide how to use the excess. Burning it is given as one possible decision. It is not mandatory and there is no automatic burn mechanism or expiration date for unspent treasury POL.

Stopping future treasury emission would also not automatically burn the treasury's existing balance. These are two independent protocol actions.

Validator Funding Is Not The Same As Rewards Paid

The EmissionManager's validator half is funding sent to StakeManager. Actual validator reward accrual and claims are controlled by staking and checkpoint mechanics.

These stages should be distinguished:

POL minted by EmissionManager
-> POL transferred to StakeManager
-> rewards accrued under staking/checkpoint rules
-> rewards claimed by validators and delegators

PIP-78 found that actual validator reward distribution after the July 2025 transition was running above the intended annual target because checkpoint frequency had changed. PIP-86 further recalibrated checkpoint rewards for shorter block times.

This is why a transfer from EmissionManager to StakeManager should be called validator funding, not necessarily rewards paid or claimed.

Emission, Burn, And Net Issuance

Emission and burn are separate economic flows.

Gross issuance = newly minted POL
Net issuance   = gross issuance - qualifying burn under a stated methodology

An address transfer does not reduce ERC-20 totalSupply. Some Polygon burn processes route POL to collector or dead addresses rather than calling an ERC-20 _burn function. Analysts must therefore state whether burn means:

• an irreversible reduction of ERC-20 total supply;
• a transfer to a proven irrecoverable address;
• a transfer to a policy-designated burn collector;
• an economic exclusion used by a tracker.

Burns do not create a hard cap. They may offset emission economically, but future gross emission remains governed by the active EmissionManager and token controls.

For live minted-POL and burn totals, open Value Flow. For current supply and net issuance, open Supply. For the underlying Polygon PoS fee burn and routing mechanics, read Polygon PoS Fees.

Common Questions

Is POL emission the same as POL inflation?

Not exactly. POL emission is the gross amount of new POL minted by EmissionManager. POL inflation usually refers to the increase in supply after accounting for burn. POLTRACK uses net issuance = minted POL - burned POL, so gross emission can be positive while net inflation is lower, zero, or negative for a selected period.

Does MATIC have inflation, or is this POL inflation?

The active emission system mints POL, not MATIC. “MATIC inflation” is still used informally because MATIC was Polygon's previous native token and PIP-26 carried its validator reward schedule into the POL transition. Normal 1:1 MATIC-to-POL migration is separate from emission and does not create additional scheduled supply.

Why is the POL supply increasing?

POL supply increases when the authorized EmissionManager mints new tokens for validator funding and the Community Treasury. The current v1.4 target is 2% annual compounded emission. Burns offset part or all of that gross issuance when calculating net supply growth; see Polygon PoS Fees and Burn.

How much POL is minted each year?

The current target is 2% of the growing calculation base per year, not a permanently fixed number of POL. The amount compounds over time, is split equally between validator funding and the Community Treasury, and is realized in transaction batches when mint() is called. Historical rates were 3%, then 2.5%, before reaching the current 2% schedule.

Can POL become deflationary?

Yes, over a measured period if more POL is burned than minted. That does not switch off gross emission: it means burn exceeded issuance during that period. POLTRACK therefore reports mint, burn, and net issuance as separate metrics.

Does POL have a hard maximum supply?

No. The initial supply was 10 billion POL, and POLTRACK models scheduled inflation through October 25, 2033. However, that date is not an immutable hard cap because the active contract requires a protocol change to stop emission. A 2033 supply number is therefore a projection under stated assumptions, not a permanently coded maximum.

Is POL inflation exactly 2% every year?

The current EmissionManager v1.4 targets 2% annual compounded growth, split into 1% validator funding and 1% treasury funding. Mainnet history was different: v1.1 targeted 3%, v1.2 and v1.3 targeted 2.5%, and v1.4 targets 2%.

When did POL emission begin?

The mainnet EmissionManager start timestamp is October 25, 2023 at 09:06:23 UTC. Mainnet launched with the PIP-26 transition rate of 3%, not the pre-mainnet v1.0 rate of 2%.

Why does PIP-26 use June while the contract started in October?

PIP-26 inherited the June-to-June calendar of the original MATIC validator reward schedule. The POL contract started in October 2023, while the actual rate-changing Ethereum upgrades were executed in July 2024 and July 2025. Policy dates and execution timestamps are therefore different timelines.

What does the ten-year period mean?

The whitepaper proposed ten years of predictable funding, after which the long-term 1% validator and 1% treasury streams could be reduced or discontinued. POLTRACK maps that period to October 25, 2023 through October 25, 2033. The contract contains no countdown, so the ending still has to be implemented onchain.

Why does POLTRACK use October 25, 2033?

It is the ten-calendar-year anniversary of the first mainnet EmissionManager start timestamp. This makes it the clearest end date for POLTRACK's ten-year model, and Polygon has not adopted a proposal defining a later endpoint or post-2033 rate. The contract does not reference 2033 directly, so ending emission then requires an implementation change.

Can POL emission be stopped before ten years?

It is technically possible because authorized administrators can replace the EmissionManager implementation, change the mint cap, or change the emission role. An earlier stop would require an explicit protocol decision and onchain execution; it is not automatic or the current baseline. The present reference point remains October 2033.

Can POL emission continue after ten years?

Technically, yes: the current v1.4 formula has no end date, so it would keep calculating emission until the implementation is changed. That technical fallback should not be presented as Polygon's current plan. POLTRACK's baseline remains October 2033; no post-2033 schedule has been adopted.

Can emission be reduced or discontinued after ten years?

Yes. The whitepaper says validator emission, treasury emission, or both may be decreased or completely discontinued after the initial policy period. Implementing that outcome requires an onchain protocol change because the current v1.4 split and rate are compiled into the implementation.

Can the emission rate be increased after ten years?

The whitepaper says neither long-term stream can be increased beyond 1% per year. The earlier 2% validator rate was a temporary PIP-26 transition inherited from the MATIC reward schedule. Although the contracts can be changed through their administrative controls, an increase above the whitepaper limits would be a new policy rather than continuation of the published design.

Is Community Treasury emission automatically burned if it is not spent?

No. Treasury POL is minted and transferred to the treasury address. Unspent tokens remain treasury assets. The whitepaper says the community could decide to burn excess POL if the treasury accumulates more than the ecosystem needs, but it does not require that outcome and no automatic burn is performed by EmissionManager.

What does burning excess Community Treasury POL require?

It requires a separate Community Treasury decision and an executable transaction using an accepted burn mechanism. Reducing future treasury emission and burning an existing treasury balance are different actions.

Can validator emission and treasury emission be changed independently?

The whitepaper treats them as independent policy streams. The current v1.4 contract hardcodes one 2% curve and a 50/50 split, so changing only one stream requires a new EmissionManager implementation or equivalent protocol change.

Who can call mint?

Anyone can call the EmissionManager's public mint() function. The caller does not choose the amount or recipients and receives no emission. Only the EmissionManager holds the token's EMISSION_ROLE, so only the amount calculated by its logic can be passed to the POL token mint function.

What happens if nobody calls mint for a while?

The emission entitlement continues to grow under the time-based target curve. A later call attempts to mint the accumulated difference. Emission is therefore calculated continuously but realized in transaction batches.

Does mintPerSecondCap limit total POL supply?

No. It limits how much the POL token contract accepts relative to the time since the previous mint. It is a rate safety control, not a lifetime maximum supply.

Does StakeManager receive exactly 1% as rewards paid to validators?

StakeManager currently receives half of EmissionManager mints, representing the validator funding stream. Reward accrual and distribution depend on checkpoint, milestone, staking, and claim mechanics. PIP-78 and PIP-86 show why funding, accrued rewards, and claimed rewards must be measured separately.

Are emission transfers the same as mint events?

No. The actual mint is the zero-address transfer into EmissionManager. The subsequent transfers to treasury and StakeManager distribute the newly minted tokens. Counting recipient transfers as separate mint events would double count the same economic flow.

Does MATIC-to-POL migration create additional emission?

Normal 1:1 migration uses POL from the initial migration supply and does not represent scheduled emission. Migration accounting and EmissionManager minting are separate systems.

Why can two correct-looking POL supply forecasts disagree?

They may use different start dates, annual buckets, execution timestamps, compounding conventions, burn assumptions, or future protocol assumptions. A reproducible projection must publish its starting supply, starting timestamp, rate periods, formula, horizon, and treatment of future protocol changes.

What is the most accurate way to describe the October 2033 number?

Describe it as projected gross supply at the current ten-year endpoint under a named scenario. For example: executed emission history plus continuation of EmissionManager v1.4 through October 25, 2033. It should not be called an immutable maximum supply or a hard cap.

Mainnet Contracts

• POL token
• DefaultEmissionManager proxy
• DefaultEmissionManager v1.4 implementation
• ProxyAdmin
• StakeManager
• Community Treasury
• PolygonMigration proxy

Primary References

• POL whitepaper
• Polygon Docs: POL token
• Official POL token repository
• Current DefaultEmissionManager source
• Current POL token source
• PIP-17: Polygon Ecosystem Token
• PIP-26: Transition from MATIC to POL Validator Rewards
• PIP-29: Polygon Protocol Council
• PIP-40: Support for Community Treasury Contracts
• PIP-41: Enable Direct POL Emissions to StakeManager
• PIP-67: Update Membership of the Protocol Council
• PIP-78: Adjustment of CHECKPOINT_REWARD
• PIP-86: Recalibrate CHECKPOINT_REWARD
• 2024 PIP-26 / PIP-40 Council Transparency Report
• MATIC-to-POL Migration Transparency Report
• 2025 PIP-26 Council Transparency Report

Related Pages

• POL Tokenomics
• POL Token FAQ
• Polygon PoS Fees
• Polygon Validators
• Methodology & Data Sources