Handle the hard cases: proxies, minimal contracts, Vyper, and metadata-level detail.
Proxy contracts
Most upgradeable systems deploy a small proxy that delegates to an implementation contract. Users interact with the proxy address, so the proxy page is where decoded methods matter.
How proxy detection works
The explorer automatically detects common proxy patterns — EIP-1967 (the standard storage slots), OpenZeppelin transparent and UUPS proxies, EIP-1167 minimal proxies (clones), and Diamond (EIP-2535) — and reads the implementation address from chain state.
What you need to do
- Verify the implementation contract at its own address, using any method from the Examples Library.
- Open the proxy’s page. If the implementation wasn’t auto-detected, use Contract → Verify proxy to point at the implementation address.
Once linked, the proxy’s read/write tabs expose the implementation’s ABI, and transactions through the proxy decode with implementation method names.
Implementation upgrades
When you upgrade to a new implementation, verify the new implementation address — the explorer follows the proxy’s current implementation slot, so no re-verification of the proxy itself is needed.
Similar-match (bytecode twin) lookup
Contracts deployed from identical source — token clones, factory-produced pairs — share bytecode. When you query an unverified contract whose bytecode exactly matches an already-verified contract, the explorer can surface the twin’s source and ABI automatically.
This means: if your factory deploys a thousand clones, verify the first one properly and the rest often decode without individual verification. Exact metadata differences may still mark them as partial matches.
Minimal proxies (EIP-1167 clones)
Clones carry no logic of their own — just a hardcoded implementation address. Verify the master contract; clones pointing at it are recognized and decode with the master ABI. For clones the explorer doesn’t auto-detect, submit the master address via the proxy verification form.
Vyper contracts
Vyper verification mirrors Solidity:
- Flattened source or multi-part files via the verification API (
/via/vyper-code,/via/vyper-multi-part-files). - The compiler version string follows Vyper’s format (
v0.3.10+commit.91361694). - Constructor arguments are ABI-encoded identically to Solidity.
Vyper’s metadata handling differs from Solidity’s, so exact-match semantics can vary — use the precise compiler version to avoid partial matches.
Yul and low-level contracts
Contracts written in raw Yul (or hand-assembled) verify through the same standard-input path, with language: "Yul" in the compiler input. The resulting source view shows Yul rather than Solidity.
Metadata and source hashes
Every compiled contract embeds a metadata hash (IPFS or bzzr) pointing at its compilation metadata. Implications:
- Exact match requires reproducing that metadata — same sources, same settings, same compiler build.
- Partial match ignores the metadata hash and compares executable bytecode only.
- If you publish source to IPFS yourself, keep the metadata hash consistent with what the explorer stores so external tools can cross-check.
License display
The explorer reads the SPDX-License-Identifier comment from verified source and displays it on the contract page. Include it in every source file — unlicensed contracts show a warning to users.
Custom ABIs for unverified contracts
When you can’t verify a contract (not your source, lost build settings) but know its interface, upload a custom ABI to your account. The explorer then decodes methods and events for your account’s views without public verification. See Watchlists & Private Tags and the Account API.