Polygon smart contract audit

Polygon, as this product sees it

What has actually gone wrong on Polygon

One incident in our Hall of Hacks names Polygon, for $611M between them. These are researched write-ups with the real code, not a list of headlines.

Every one of these was a live, audited-or-not contract holding real money. The failure class of each is linked to the detectors that look for it.

What the scanner checks on Polygon

The same 201 detectors run on every chain. We do not have Polygon-specific rules and this page will not pretend otherwise — what differs by chain is the explorer, the RPC endpoints, the router used for the buy/sell simulation, and the incidents above. The analysis itself is one engine.

It covers 203 documented weaknesses across 20 categories:

• Access Control
• Arithmetic
• Best Practice
• Bridge / Cross-Chain
• Centralization
• DeFi Economic
• Denial of Service
• External Calls
• Governance
• Input Validation
• Logic / State
• Low-Level / Assembly
• MEV / Ordering
• Oracle / Price
• Randomness
• Reentrancy
• Signatures
• Time Dependence
• Token Standards
• Upgradeability

Each one has a page in the vulnerability database explaining the weakness, what it looks like in Solidity and how to fix it — generated from the detector table itself, so the explanation can never describe a different rule from the one that graded you.

If the contract is not verified on polygonscan.com

Most of what is worth checking is unverified, and for those the source engine has nothing to read. The bytecode analyser reads the deployed bytecode instead: the function selectors in the dispatcher, the opcodes present, proxy shape and the implementation slot, and the addresses compiled in.

It reports powers, not intent. A mint(address,uint256) selector proves a mint entry point exists; it cannot prove who is allowed to call it. Access control lives in control flow, and reconstructing that from bytecode is decompilation, which this is not.