Verified source metadata
Where a contract's name comes from, what "verified" means, and what it does not vouch for.
#Plain languageIn plain terms
A contract on the chain is machine code. Nobody can read it comfortably. Developers can publish the human-readable source, and a public service can check that compiling that source reproduces the code on the chain. When that check passes, the contract is called verified.
Forensia looks up that verification and shows the contract's published name, its compiler, and how many functions and events it declares. This tells you what the code is. It does not tell you the code is safe or who runs it.
#How it worksHow it works
For any address classified as a contract, the lookup asks Sourcify, an open verification registry, for its record. It keeps a compact summary and never downloads the source files themselves.
- Request the contract's record from Sourcify for this network and address.
- Accept it only if it reports a match and a verification date.
- Keep the name, compiler details, list of source file names and any deployment details Sourcify reports.
- Read the published interface (the ABI) to count functions, events and errors, and to work out each function's selector.
#Technical detailThe exact rules
One GET to Sourcify's v2 contract endpoint with the fields compilation, deployment, abi, proxyResolution and sourceIds. The request times out at 8 seconds and the response is capped at 2 MiB.
| Field | Rule |
|---|---|
| Match | Must be exact_match or match. Anything else is treated as unverified. |
| Creation and runtime match | Kept separately. Each is one of the same two values, or absent. |
| Source files | Names only, first 100. |
| Interface entries read | First 5,000. |
| Functions kept | Up to 512, de-duplicated, sorted by selector. |
| Events kept | Up to 256 signatures. |
| Proxy implementations listed | First 20. |
A function selector is the first four bytes of the Keccak-256 hash of the canonical signature, for example transfer(address,uint256). Tuple types are expanded recursively into a parenthesised list of their component types before hashing, which is the canonical form selectors are computed from.
In a transaction lookup the same table is used the other way round. The first four bytes of the call data are matched against the verified selectors. One match is reported as unique-verified-abi. More than one is reported as selector-collision, and no name is chosen. Logs emitted by the recipient are matched the same way, by their first topic against the verified event signatures. In a transaction lookup the recipient's record is requested without classifying the recipient first, and only the recipient's own record is used.
The result is the finding finding:sourcify-verification, class attribution, confidence high. It is an attribution because a third party is the source of the claim.
#LimitsWhat it does not tell you
- If Sourcify is unreachable, the contract simply shows as unverified. The two cases are not distinguished. The same happens when the registry is switched off or cooling down after failures in this deployment, or when its response is over the size cap.
- In a transaction lookup, a call to a proxy is matched against the proxy's own verified interface. The implementation's interface is not consulted, so the call can go unnamed.
- Deployment details from the registry are shown as the registry reported them. They are not re-checked against the chain.
- A function name is a label on a selector. It does not prove what the function does or why it was called.
- Arguments are not decoded at this step.