How to Read Token Contract Source Code on PolygonScan

25 October 2026

You can view and verify a token's contract source code directly on PolygonScan if the developer has published it. This page explains what you're looking at and how to spot basic warning signs.

Why bother reading the source code?

Most Polygon tokens are standard ERC-20 contracts. The source code shows exactly what the contract is programmed to do - how tokens are minted, transferred, and whether any special functions exist that could affect your holdings. If the source code is not published, you cannot independently verify the contract's behavior.

Step 1: Find the Token Contract on PolygonScan

Go to polygonscan.com and search for the token name, symbol, or contract address. On the token's page, click the "Contract" tab. If the developer has published the source code, you will see a "Code" sub-tab with the Solidity source displayed.

If you see "Contract Source Code Verified" with a green checkmark, the code has been submitted and matches the deployed bytecode. This does not mean the contract is safe - only that the published code matches what is actually running.

If the source code is not published, you have no reliable way to verify what the contract does. That is a red flag for any token you are considering using or holding.

Step 2: Identify the Token Standard

At the top of the source code, look for the line that says import or is ERC20. Most legitimate tokens inherit from OpenZeppelin's standard ERC-20 implementation. If you see import "@openzeppelin/contracts/token/ERC20/ERC20.sol";, that is a good sign. If the contract does not inherit from a well-known standard, or if it imports from an unknown or misspelled library, proceed with caution.

Step 3: Look for Minting Functions

Search the source code for the words mint, _mint, or minting. A standard ERC-20 token does not have a public mint function. If you find one, check who can call it.

• onlyOwner modifier on mint: The contract owner can create new tokens at any time. This is common in presale tokens but means the supply is not fixed.
• No restriction on mint: Anyone can create tokens. This is a serious warning sign.
• mint with a cap: Some contracts limit total supply. Read the cap logic carefully - does it actually enforce the limit, or is there a way around it?

Step 4: Check for Transfer Restrictions

Search for _beforeTokenTransfer, _afterTokenTransfer, or any custom transfer function. Some contracts include:

• Blacklists: Functions like addToBlacklist or _isBlacklisted that prevent certain addresses from sending or receiving tokens.
• Fee-on-transfer: Logic that deducts a percentage on every transfer and sends it to a specific address. This is common in "reflection" tokens.
• Pausable transfers: A pause function that stops all transfers. The owner can freeze the entire token.

If you see any of these, decide whether the feature is acceptable for your use case.

Step 5: Look for Owner Privileges

Search for owner, onlyOwner, Ownable, or transferOwnership. The contract owner typically has special powers. Common dangerous owner functions include:

• withdraw or withdrawAll: The owner can drain tokens or MATIC from the contract.
• setTax or updateFee: The owner can change transfer fees after deployment.
• burn or burnFrom: If the owner can burn tokens from any address, they can destroy your holdings.

A contract with no owner function is generally safer than one with extensive owner controls.

Step 6: Read the Constructor

The constructor runs once when the contract is deployed. It usually sets the token name, symbol, decimals, and initial supply. Check:

• Initial supply destination: Where did the tokens go? If the constructor mints all tokens to the deployer's address, that person holds 100% of the supply.
• Hardcoded addresses: Some contracts include addresses in the constructor that later receive fees or privileges. Verify these addresses on PolygonScan.

What you cannot tell from source code alone

Even verified source code does not guarantee a token is safe. The contract could have hidden logic in the constructor or in external calls. Some attacks use proxy contracts where the logic can be changed after deployment. If you see delegatecall, proxy, or upgradeable in the code, the contract may be changeable.

When to walk away

Consider avoiding a token if:

• The source code is not published.
• The contract uses an unknown or custom token standard.
• There is an unrestricted public mint function.
• The owner can blacklist addresses or pause transfers.
• The owner can change fees or withdraw funds from the contract.
• The code is obfuscated or heavily minified.

Final Advice

Reading source code is a basic safety check, not a guarantee. If you are not confident interpreting Solidity, ask someone with experience to review the contract. For tokens you plan to hold significant value, consider using a professional auditing service or sticking to well-known, widely used contracts.

Back to polygon