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.

Protocol emission does not determine Total Supply Change on its own. Base Fees accrued toward burn can partly or fully offset newly issued tokens:

Total Supply Change = newly minted tokens - Base Fees accrued toward burn

If Base Fee accrual is lower than emission, Total Supply still grows, but more slowly. If it exceeds emission, Total Supply Change is negative for that period. Polygon Chain has its own base-fee burn and routing mechanics, which POLTRACK measures separately from minting. See POL Burn for the complete burn history and Polygon Chain Fees for transaction fee mechanics.

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;
• the whitepaper describes an initial ten-year funding period rather than an automatic contract deadline;
• Polygon has not adopted a proposal that defines a later emission schedule after that policy period;
• 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 the latest 30-day POL mint total and its Community Treasury and validator/staker destinations alongside burn, while Supply shows Total Supply, its 30-day change, and the historical/projected supply graph.

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. No adopted PIP defines a later schedule after that policy period.

The policy period is not an automatic contract deadline. The active EmissionManager has no built-in shutoff, so ending or reducing emission must be implemented through a protocol change. The same controls could technically stop emission earlier.

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 on-chain 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.

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

This is a rate limiter and safety control. It limits minting speed rather than cumulative issuance. 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

The live Supply graph starts from the latest observed on-chain supply and compounds it at 2% per year through October 25, 2033, using elapsed UTC calendar days divided by 365. It subtracts the current Burn Adjustment and projected net Base Fee accrual. The historical 12,336,136,524.75 POL contract-curve calculation remains a reference, not a fixed live endpoint.

Why Supply Projections Differ

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

How Emission Changes Are Implemented

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

Published Changes And Mainnet Execution

The EmissionManager is not controlled by direct POL-holder voting. In practice, emission changes have been published through the Polygon Improvement Proposal repository, Polygon forum reports, and public contract transactions, then implemented through the protocol's contract administration controls.

The 2024 and 2025 rate changes were documented before or alongside execution. Their transparency reports identify the implementation, calls, expected state, and validation checks, while Ethereum transactions provide the final evidence of what ran on mainnet. POLTRACK therefore treats the PIP or report as policy context and the executed contract state as the source of truth for historical calculations.

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 Ten-Year Policy Period 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. No adopted proposal defines a later schedule after that period.

The Solidity contracts do not contain an immutable ten-year timer. Authorized contract administrators can upgrade the EmissionManager, change token roles, or change the mint cap. Any stop or rate change requires 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 Total Supply Change

Emission and burn are separate economic flows.

Protocol issuance   = newly minted POL
Total Supply Change = protocol issuance - Base Fees accrued toward burn

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 may offset emission economically, but future gross emission remains governed by the active EmissionManager and token controls.

For the latest 30-day POL mint and destination split, plus burn metrics, open Value Flow. For current Total Supply and Total Supply Change, open Supply. For the underlying burn classifications and routing history, read POL Burn; for transaction fee mechanics, read Polygon Chain Fees.

Common Questions

Is POL emission the same as POL inflation?

Not exactly. POL emission is the amount of new POL minted by EmissionManager. POLTRACK measures the period's Total Supply Change = minted POL - Base Fees accrued toward burn, so emission can be positive while Total Supply grows more slowly, stays unchanged, or decreases 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 On-chain 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. Base Fees accrued toward burn offset part or all of that issuance when calculating Total Supply Change; see POL Burn and Polygon Chain Fees.

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 Base Fees accrued toward burn exceed minted POL. That does not switch off protocol emission. POLTRACK therefore reports mint, burn, and Total Supply Change as separate metrics.

What happens after the initial ten-year policy period?

The whitepaper allows the validator and treasury streams to be reduced or discontinued after the initial policy period. The active contract does not stop automatically, so any such change requires protocol action and on-chain implementation.

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. The contract contains no countdown, so the end of that policy period still has to be implemented on-chain.

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 on-chain execution; it is not automatic.

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 an adopted long-term policy; no schedule after the initial policy period 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.

What does mintPerSecondCap limit?

It limits how much the POL token contract accepts relative to the time since the previous mint. It is a rate safety control and does not define cumulative issuance.

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.

How should the Supply graph label its October 2033 endpoint?

Describe it as the graph's scenario on-chain supply on October 25, 2033 under stated assumptions. For example: executed emission history plus continuation of EmissionManager v1.4 through October 25, 2033. The label must include the graph horizon and assumptions.

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
• POL Burn
• Polygon Chain Fees
• Validators & Staking
• Methodology & Data Sources