Technically Verifying Polygon: Checking Whitepaper, Source Code, and Active Contracts

Summary

This article shows in seven steps how the core claims about the POL token can be technically verified.

At the reviewed state, the technical assessment yields three key findings. First, the initial total amount of 10 billion POL is directly traceable in the Token contract. Second, the emission logic in the current code is implemented deterministically and corresponds to an annual rate of around 2% with compounding. Third, role checks and Proxy history can be used to determine which contract version is currently executing this logic.

This turns general tokenomics claims into a verifiable technical statement. The article shows not only what Polygon publicly claims, but how you can check for yourself whether these statements are consistent with the published code and the active deployment.

Goal of this article

This article describes how to technically verify key claims around the POL token. It focuses on three questions:

1. Which claims are made in the whitepaper and official communication?
2. Where can the corresponding logic be found in the source code?
3. How can you verify that exactly this logic is also running in the currently active contracts on the Blockchain?

The focus is on a reproducible verification path. This is therefore not about market sentiment or speculation, but about how public claims can be reconciled with publicly visible code and On-Chain data.

What you should have verified at the end

If you go through the following steps, you can specifically verify these points yourself:

• the initial total POL supply,
• the technical logic of POL emission,
• the involved contracts for community treasury and token staking,
• the currently active emission-manager implementation,
• the full upgrade history of the emission-manager proxy

Required sources and tools

Freely accessible sources are sufficient for this verification:

• POL Whitepaper¹
• POL technical information
• PIP-17: Polygon Ecosystem Token (POL)
• POL token repository on GitHub
• POL token on Etherscan
• PIP-26: Council Transparency Report
• PIP-40: Support for Community Treasury Contracts
• PolygonScan Charts

Step 1: Isolate the verifiable claims

The process starts not with code, but with Polygon Labs public communication. Only when it is clear what exactly should be verified can you check in a targeted way.

For POL, the core claims include:

1. The initial issuance is 10 billion POL.
2. Further emissions follow a predefined, deterministic rate.
3. Emission is often described as around 2% per year.
4. Parts of the emission go to the community treasury and token staking.
5. Governance can influence emission logic through upgrades.

These claims are spread across the whitepaper, technical documentation, and governance texts. For technical verification, it is useful to rewrite them into concrete verification questions:

• Where is the initial issuance defined in code?
• Which contract creates new tokens (Minting)?
• Which formula determines annual emission?
• Which contracts receive newly created tokens?
• Which contract is currently active?
• Is the active implementation identical to the source code on GitHub, or at least consistent?

Step 2: Check the initial POL amount in the token contract

The first technical baseline check is the token contract itself. To do this, open the published POL source code on GitHub:

• PolygonEcosystemToken.sol on GitHub

Search there for the mint instruction for the initial issuance. Relevant is line 39:

 _mint(migration, 10_000_000_000e18);

What this means

In the number 10_000_000_000e18, the underscores are used only for readability. The Solidity compiler ignores them completely. The suffix e18 is scientific notation and means “times 10 to the power of 18”; the decimal point is therefore shifted 18 places to the right. The value therefore corresponds to 10.000.000.000 × 10^18, written out as 10.000.000.000.000.000.000.000.000.000.

Fixed-point representation

Scaling by ten to the eighteenth (10^18) has a simple reason: In the Ethereum Virtual Machine used by Polygon, there are no true floating-point types (float, double), so on-chain calculations use only integers. Solidity therefore also supports only integers and uses fixed-point representation. The number of decimal places is fixed: 1e18 = 1 * 10^18.

In other words, in fixed-point representation, 10,000,000,000e18 means ten billion tokens before e as the integer part, and eighteen places as the token base unit “Wei”, i.e. the fixed-point fraction part of a token:

• 1e18 base units = 1 full token
• 1e17 base units = 0.1 token
• 1 base unit = 1 Wei

What this step proves

This directly verifies:

• The initial POL amount was technically set to 10 billion tokens.
• The number is not only marketing language, but hard-coded in contract code.
• The starting value for later supply development is therefore technically traceable.

What this step does not yet prove

This does not clarify,

• how much is newly emitted later,
• which contracts control minting,
• or whether the current emission logic still matches the original communication.

Step 3: Identify the emission contracts via PIP-17

Next, we need to clarify which contracts are responsible for later emissions.

For this, Polygon Improvement Proposal PIP-17 is a good starting point:

• PIP-17 on the Polygon forum

This document describes the involved components. Particularly relevant are:

• the current source code on GitHub
• the upgradeable Emission Manager contract with its DefaultEmissionManager implementation,
• the address of the contract for token-staking rewards (Staking Rewards) 0x5e3ef299fddf15eaa0432e6e66473ace8c13d908,
• the address 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 of the community treasury multisignature wallet, which according to PIP-17 was intended as a transitional solution; the cutoff date 2024-06-24 is derived from the creation date of the later treasury address 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 on Etherscan. In addition, PIP-40 explicitly describes migration of treasury logic to the new community treasury address 0x86380e136a3aad5677a210ad02713694c4e6a5b9.

This shifts verification from a general whitepaper comparison to a concrete technical search: now we know which contract names and addresses to look up on Etherscan and GitHub.

Step 4: Inspect the DefaultEmissionManager contract in source code

Now comes the most important part of technical verification: the concrete emission logic. Open the current DefaultEmissionManager contract on GitHub:

• DefaultEmissionManager.sol in the GitHub repository

First, look at the description in line 14 of the source code on GitHub:

 /// @dev The contract allows for a 2% mint per year (compounded). 1% staking layer and 1% treasury
 

This comment line is important because it shows how the developers themselves describe the logic. Then comes the key constant in line 19:

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18;
 

How to interpret this line

Logarithm and exponent base two

Furthermore, the comment in line 14 suggests that the constant INTEREST_PER_YEAR_LOG2 is meant to be the result of a base-2 logarithm: log2(p) = INTEREST_PER_YEAR_LOG2.

In line 89, the proof can be found in the form of the inverse calculation:

  uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);

The function PowUtil.exp2(q) computes two to the power of q: 2^q. Our sought p is therefore
p = PowUtil.exp2(q) = PowUtil.exp2( log2(p) )

So it follows that

    p = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days)
<=> p = 2^ ((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
<=> p = 2^ ((log2(p) * timeElapsed) / 365 days);

What this means in practice can easily be verified with a calculator:

  // reminder:
  INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18 // ~ 0.02857

  // Check with your calculator
  2 ^ 0.02857 => 1.02 => ~2.0 %  // => p=1.02, i.e. factor to increase by 2%

  // Countercheck with inverse function
  log2(1.02)= 0.02857 // = INTEREST_PER_YEAR_LOG2

This calculation proves that the constant INTEREST_PER_YEAR_LOG2 stands for a two-percent increase.

Proportional interest

So far we have however neglected that q in the term 2^q is actually
q = (INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days. Note that in Solidity 365 days is a time unit literal and is evaluated in seconds.

    (log2(p) * timeElapsed) / 365 days   // 365 days = 31,536,000 seconds
<=>  log2(p) * timeElapsed  / 31,536,000  
<=>  0.02857 * (timeElapsed / 31,536,000)  

// 0.02857 = annual 2-percent interest rate
// 1 year = 365 days = 31,536,000 seconds
// 0.02857 * (timeElapsed  / 365 days) => proportional interest rate per second

An annual 2% interest rate is here converted proportionally into seconds.

Why this matters

This step allows you to show precisely:

• The mathematical constant in current GitHub code actually stands for 2% in this version.
• If someone misreads this value, they can derive a wrong inflation rate.

Step 4.1: Reconstruct the amount of newly created tokens

In the DefaultEmissionManager contract, line 88 states:

   function inflatedSupplyAfter(uint256 timeElapsed) public view returns (uint256 supply) {
      uint256 supplyFactor = PowUtil.exp2((INTEREST_PER_YEAR_LOG2 * timeElapsed) / 365 days);
      supply = (supplyFactor * START_SUPPLY_1_4_0) / 1e18;
   }
 

In line 68, the value block.timestamp - startTimestamp is passed in, which sets function parameter timeElapsed.

block.timestamp uses seconds and gives the creation timestamp of the current block in the Ethereum blockchain. It is the current execution time of function inflatedSupplyAfter().

The variable startTimestamp was set to the start point, i.e. initialization or re-initialization of the POL token start supply. See the two functions in lines 44 and 49.

The formula setting variable supplyFactor models a 2% rate with compounding. It uses a continuous time share in seconds per year.

In short, variable supply is increased by approximately 2.0% in each year since the start of POL. This can be reproduced easily with a spreadsheet:

Column C shows annual supply progression based on the formula from the Default­Emission­Manager contract. Column D shows, for comparison, ordinary interest calculation based on the previous year value.

What this step demonstrates

Annual POL emissions are determined by a deterministic formula based on the constant identified in the previous step. Specifically, this proves:

• The amount of newly created tokens is not arbitrary but mathematically derived from elapsed time since start.
• The formula implements compounding exactly: each year growth is applied not only to the original start supply, but to the already increased supply.
• The around-2% annual emission can be independently reproduced and verified with a simple spreadsheet using the formula.
• The start timestamp (startTimestamp) is fixed in the contract, so the emission curve can be traced from a defined starting point.

Step 4.2: Check distribution of newly created tokens in code

In the same contract, you can trace where emitted tokens flow. Relevant are lines 74 and 75:

 uint256 treasuryAmt = amountToMint / 2;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

The amount of newly minted tokens (amountToMint) is split into two equal halves.

A few lines later, in lines 82 and 84:

 _token.safeTransfer(treasury, treasuryAmt);

 _token.safeTransfer(stakeManager, stakeManagerAmt);
 

The amounts are sent to the treasury address and the stakeManager address. Both addresses are set during blockchain deployment and are immutable afterwards.

 constructor(address migration_, address stakeManager_, address treasury_) {
   if (migration_ == address(0) || stakeManager_ == address(0) || treasury_ == address(0)) revert InvalidAddress();
   DEPLOYER = msg.sender;
   migration = IPolygonMigration(migration_);
   stakeManager = stakeManager_;
   treasury = treasury_;

   // so that the implementation contract cannot be initialized
   _disableInitializers();
 }
  

What this step shows

The minted amount is split into:

• treasury share
• staking share

This is relevant because whitepapers or blog texts often emphasize only the rough emission rate, while the economic impact becomes understandable only when it is clear who receives the new tokens.

Step 5: Check emission-manager contract versions on-chain

PIP-17 states that the emission manager is upgradeable. Therefore, we must find the currently active version. If you open an older visible DefaultEmissionManager contract on Etherscan, you can see that the constants there differ significantly from the current GitHub source code:

See line 19

 uint256 public constant INTEREST_PER_YEAR_LOG2 = 0.04264433740849372e18;
 

and lines 65 and 66

 uint256 treasuryAmt = amountToMint / 3;
 uint256 stakeManagerAmt = amountToMint - treasuryAmt;
 

A single contract is therefore not enough when the system is upgradeable. So the next step is to check which versions exist at all.

For this, Etherscan contract search is useful:

• Search for additional DefaultEmissionManager contracts

However, it is unclear whether contracts with this name were used exclusively for POL. Also, only actually active contracts are relevant here. Etherscan provides a direct solution: through the proxy contract, you can inspect all implementations that were ever active, in chronological order, without additional tools:

• Historical contracts of the emission-manager proxy

Goal of this step

You want to find out:

• how many contract versions exist,
• which versions have been active behind the proxy,
• which version is currently active.

This is crucial for upgradeable systems. A clean GitHub state is of little use if a different implementation has long been active on-chain.

Source: Screenshot from 2026-03-31 - etherscan.io

Procedure

1. Open the Historical Proxy view of proxy address 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53.
2. Identify the most recently activated entry as the currently running implementation.
3. Open each implementation address and check the verified source code on its Contract page.

What to verify there

• version notes
• emission parameters (INTEREST_PER_YEAR_LOG2)
• split between treasury and staking
• start values and initialization logic

What this step enables

You can see at a glance which version is currently active and which versions were previously in production. This makes upgrade history transparent and interpretation of emission logic robust.

Step 6: Verify whether the emission manager has the required role

A proxy contract alone does not yet constitute proof. Therefore, you must check whether the emission-manager proxy address actually has emission rights for POL.

To do this, go to the read view of the POL token contract:

• Read Contract of the POL token

Procedure

1. Find entry 4. EMISSION_ROLE.
2. Copy the bytes32 value of this role, e.g.
   • 0x573321b8a13c75b2702bc4b0ad9afaae98bf6985285411964a564e68bf6da1c9
3. Open function 14. asRole.
4. Enter the copied value as role.
5. Enter the emission-manager proxy as account (address):
   • 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53
6. Execute by clicking Query.

Note: The emission-manager proxy address 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53 was taken from the Council Transparency Report: PIP-26.

Expected result

If the answer is true, this technically proves that this proxy address has the emission role.

Why this step is indispensable

This identifies not just a contract, but an active contract path. Only then does verification of the live emission logic become robust.

Step 7: Classify contract history and circulating supply

A look at circulating supply shows why the total amount on 2026-03-31 was already around 10,617,468,716 POL: todays 2% rule did not apply for the entire period, but is the result of multiple contract versions.

The Historical Proxy view documents the sequence of active implementations:

1. Contract from 2023-10-25, 0x2126E6952C3af75C9D4CF21f63F509195C79ce44

   • 3% emission per year (with compounding), of which 2% for token staking and 1% for the community treasury.

2. Contract from 2024-07-06, 0x5e875267f65537768435c3c6c81cd313a570b422

   • 2.5% emission per year (with compounding), of which 1.5% for token staking and 1% for the community treasury.

3. Contract from 2024-09-04, 0x152442D77E9fB9C210953d583Cbb2da88027fCB9

   • 2.5% emission per year (with compounding), of which 1.5% for token staking and 1% for the community treasury.

4. Contract from 2025-07-09, 0x282FD46E108E40A45e4CE425bA75f80245e6C2E0

   • 2% emission per year (with compounding), of which 1% for token staking and 1% for the community treasury.

Recalculated

The initial issuance amount is 10,000,000,000 POL. If emissions are calculated step by step along the respectively active contract versions, and gas effects are ignored, the result is a theoretical maximum circulating supply.

On Etherscan you can view current circulating supply. On 2026-03-31 it was Circulating Supply: 10,617,468,716.00 POL

Actual circulating supply is therefore slightly lower, among other reasons because token portions are burned via transaction fees. At verification time, the difference was about 84,322 POL.

Note: Using the spreadsheet, and depending on emission rate, you can make projections of how Polygon supply may develop in the future. These values are model-based extrapolations and can differ slightly depending on actual gas use and rounding effects. For end of 2026, we expect less than 10,777,152,308 POL.

The result

We performed this verification on 2026-03-31.

1. At that time, the active emission-manager contract was
   • 0x282fd46e108e40a45e4ce425ba75f80245e6c2e0.
2. The contract-stored address for token-staking rewards was
   • 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908.
3. The registered community treasury address is an ERC-1967 proxy contract. Etherscan lists the upstream deployer address with the name tag “Agglayer: Deployer”; this is an indicator of affiliation within the Polygon ecosystem, but not standalone proof of ownership. The proxy is the permanently established community treasury that replaced the temporary multi-signature wallet:
   • 0x32bdc6a4e8c654df65503cbb0edc82b4ce9158e6 Etherscan name tag: Agglayer: Deployer
   • 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9 ERC-1967 proxy contract, treasury address
   • 0x2ff25495d77f380d5F65B95F103181aE8b1cf898 temporary multisignature wallet

Our comparison showed:

1. INTEREST_PER_YEAR_LOG2 = 0.02856915219677089e18
2. START_SUPPLY = 10_000_000_000e18;
3. uint256 treasuryAmt = amountToMint / 2; uint256 stakeManagerAmt = amountToMint - treasuryAmt;
4. version() = "1.4.0"
5. Arg[1]: stakeManager_ (address): 0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908
6. Arg[2]: treasury_ (address): 0x86380e136A3AaD5677A210Ad02713694c4E6a5b9
7. Circulating Supply
   • 10,617,468,716.00 POL - on 2026-03-31
   • 10,777,152,308.67 POL - expected by 2026-12-31

Conclusion

With this 7-step guide, technical verification of central POL claims can be carried out systematically. The key point is this: you do not stop at general wording in whitepapers, blog posts, or governance contributions, but trace every relevant claim all the way to the actually active contract on-chain.

The verification shows that three core questions can be answered cleanly:

• The initial issuance of 10 billion POL is directly traceable in the token contract.
• Subsequent emission follows deterministic logic in the current code, around 2% per year with compounding.
• Through proxy history and role assignment, you can verify which contract version is currently executing this logic.

The comparison between GitHub, Etherscan, and governance sources is indispensable. A repository alone is not enough when contracts are upgradeable. Only when it is clear which implementation was or is active and which rights the proxy holds does code reading become robust technical verification.

For POL, this results in a consistent picture at verification time: the publicly communicated core claims on initial supply, emission logic, and distribution to community treasury and token staking can be technically reproduced on all essential points.

At the same time, the method shows its strength beyond this individual case. It is not only useful for Polygon, but generally for token projects with upgradeable contracts, emission mechanisms, and governance structures. Anyone proceeding this way does not verify narratives, but the technically effective reality.