How to Verify Whether an Artwork Is Actually On-Chain

Obtain the contract address from the project’s official page and cross-check it with the artist and a block explorer. A similarly named collection can use entirely different code.

Confirm the chain and token ID. Token IDs are only meaningful together with a contract address and chain.

A green verified-source badge makes a contract readable, but a proxy may delegate execution to another address. Follow the explorer’s “Read as Proxy” or implementation link and verify the implementation source as well.

Not all delegation is upgradeable. An EIP-1167 minimal proxy normally embeds a fixed implementation address, while EIP-1967 patterns store an implementation and may expose an upgrade authority. Record the current implementation, admin or beacon, and any upgrade events before judging immutability.

Open the collection contract in Etherscan, Basescan, Shapescan or another explorer. Under Read Contract or Read as Proxy, call tokenURI with a minted token ID. Read-only calls do not require a transaction or gas.

An HTTPS response uses a hosted access endpoint. An ipfs:// response identifies IPFS content; ar:// identifies an Arweave transaction. A data:application/json response contains the metadata directly in the returned URI.

For ;base64 data URIs, decode the characters after the first comma as Base64. Other data URIs may contain percent-encoded UTF-8 instead. The MIME type and parameters before the comma tell you how to interpret the payload.

Inspect image, image_data and animation_url. Each may use a different storage method. A hosted image does not necessarily invalidate a chain-built live artwork, but it should be described as a preview rather than the sole preserved object.

If animation_url is another data URI, decode it. Search the HTML for HTTPS imports, CDN scripts, IPFS gateways, fonts, fetch calls and WebSocket connections. Every required request is another dependency. Also note any browser features used to decompress or execute embedded code.

A data URI at the first layer is evidence, not proof of completeness. Chain-built JSON can still point to every important asset somewhere else.

Determine where the artist script and token seed live. If a separate generator contract is required, record its address and method. If libraries are stored in another registry, verify their exact entries.

For contract-bytecode storage, follow the addresses returned or referenced by the collection and confirm that deployed bytecode exists there. If a script is compressed, preserve the compression format and decompression step as part of the reconstruction path.

Check whether the collection contract can change script pointers, base URIs, registry entries or metadata after mint. Determine who can exercise those controls and whether they have been irreversibly frozen. Ownership renunciation is one possible mechanism, not the only evidence of immutability.

The strongest practical test is to render the work without the platform website. Use the contract’s standard metadata, documented generator or retrieval method through a public RPC or explorer.

Save the decoded metadata, contract addresses, chain ID and exact steps. For dynamic art, record the block at which you performed the read because current ownership or block state may intentionally change the output.

Repeat the test with another RPC or ask another person to reproduce it. Verification should not depend on an unexplained platform binary, a single cached response or your own browser session.