Polygonscan contract verification: Source Code and ABI

Polygonscan contract verification checks whether submitted source code compiles to the bytecode deployed at a particular Polygon PoS contract address. The process publishes matched source and compilation details for inspection. The contract’s application binary interface (ABI) describes callable functions and their argument types, while the source reveals the implementation that determines behavior.

Reproducing a deployment requires its original build inputs. Constructor values, linked libraries and compiler settings can affect the match. Proxy contracts add another relationship: their callable logic may reside at a separate implementation address.

Source Code Behind a Callable Function

Verified source lets a reader examine the checks inside a callable function, including permissions that its argument fields do not describe. The ABI identifies the function and its typed inputs. The source supplies its body, modifiers and inherited logic. A familiar function name alone does not establish who may call it or which checks it performs. This distinction also applies to token approvals: function signatures describe arguments, while contract code defines how it applies permission changes.

Compiler Settings, Constructor Data and Libraries

A bytecode match depends on reproducing the deployed build, including settings that can change compiler output without changing a contract’s apparent purpose.

Compiler and Optimizer Settings

The compiler version must match the build used for deployment. A compiler that accepts the source may still produce different bytecode from the deployment compiler. Optimizer enablement, optimizer runs and the targeted EVM version also belong to the compilation settings. Advanced options such as viaIR require the corresponding Standard JSON configuration. Selecting a compiler default is appropriate only when that default reproduces the deployment build.

Constructor Arguments

Constructor arguments supply deployment-time values, separate from the constructor’s source code. For parameterized constructors, use the original deployment values wherever verification requests an ABI-encoded argument payload. Creation code includes deployment logic; deployed runtime bytecode is the code that remains at the contract address. Comparing only runtime code can leave differences in initialization unresolved.

Linked Libraries and Source Files

Linked libraries need the names and deployed addresses used by the original build. Matching a library’s source while changing its linked address can still change bytecode. Imported files must also resolve to the same source contents. A Standard JSON submission can carry the source tree and compiler settings together. The filename and contract name identify the compilation target when the submitted sources contain several contracts.

Manual Submission, API Calls and Similar Matches

The browser form accepts a manual source submission, while Etherscan API V2 supports automated submission of the same build information. Cross-chain similar matching draws on code already verified elsewhere.

Polygon PoS mainnet uses chainid=137 in V2 requests. Source submissions use module=contract and action=verifysourcecode ; neither parameter identifies the network by itself.

What Does a Verification Match Prove?

Source-code verification reproduces compilation to compare its output with deployed bytecode. An exact match supports the relationship between published code and that particular deployment. A similar match carries a narrower meaning: runtime bytecode can match previously verified code while constructor arguments or initialization differ. Initial values may affect behavior even when deployed code looks identical.

Verification status does not measure the quality of access controls or establish that every callable action is safe. Security review examines code behavior and privileges, including the powers that administrators retain. Current storage also matters when conditions depend on balances, roles or configuration.

Proxy Code and Implementation Changes

Proxy verification connects a proxy address with an implementation, making the distinction between routing code and callable logic visible during inspection.

Proxy and Implementation Addresses

The proxy receives calls at its own address and delegates execution to implementation code. Source verification of the proxy establishes the proxy build, while implementation verification concerns the delegated logic. Supported Read as Proxy and Write as Proxy interfaces use the implementation ABI with the proxy address. Checking only the proxy’s small source file can therefore miss the application logic.

Open full-size image

Upgrades and the Active ABI

An upgradeable proxy can retain its address while changing the implementation that handles calls. Verification of an earlier implementation does not verify replacement code. A previously retrieved ABI may no longer describe the replacement. Rerunning proxy verification can refresh the implementation association. Proxy detection does not guarantee that the displayed implementation handles a particular call; the association must agree with the proxy’s actual routing.

Submission Status and Build Mismatches

A verification submission and a completed match are different states, so API automation must read the verification result after submission.

With Etherscan API V2, verifysourcecode returns a GUID for the submitted job. The checkverifystatus action uses that identifier to report its outcome, including Pass - Verified for success. An initial status value of 1 with a GUID confirms submission. It does not by itself confirm a bytecode match.

Compilation errors concern the submitted source or its dependencies. A bytecode mismatch means that the reproduced build does not agree with the deployed code. Compiler options, constructor data and linked-library settings are distinct possible causes. A metadata-hash mismatch may require Standard JSON with the original metadata settings. Repeating an unchanged submission cannot correct a different build input.

ABI Retrieval and Its Inspection Limits

ABI retrieval supports call encoding and result interpretation, while source retrieval preserves the code and build details needed for closer inspection. In Etherscan API V2, getabi returns the verified contract interface and getsourcecode returns source with compilation metadata. The ABI names functions, inputs and outputs. Its event entries identify which parameters are indexed, giving decoders the layout needed to interpret retrieved event logs.

A function entry’s stateMutability distinguishes view , pure , nonpayable and payable behavior. These labels do not list every runtime precondition. A script can reuse an ABI for encoding while the callable interface remains unchanged. A source review must also account for active settings and any delegated implementation.

Polygonscan contract verification questions worth asking