An NFT is not simply an image stored in a wallet. The token exists within a blockchain program or smart contract, and the associated metadata often points to media stored elsewhere. The contract may permit updates, the metadata server may fail, a gateway may be unavailable, or a marketplace may display a cached version. Understanding that chain of references is essential for technical due diligence.
This checklist helps collectors and researchers trace an asset from token identity to metadata and media, identify who can change each layer, and review approvals and display risks. It is not a security audit and cannot guarantee that a contract is safe. It provides a structured set of questions that can reveal when deeper review is necessary.
Confirm the token and collection identity
Begin with the chain, contract or mint address, and token identifier. Do not rely on a name, image, or marketplace search result because counterfeit collections can copy all three. Open the record through more than one reputable explorer or indexer and confirm that the owner, collection relationship, and transfer history agree. Save the identifiers in your research notes.
For multi-contract collections, find the issuer’s documented mapping and verify it against on-chain announcements or signed statements when available. A marketplace verification badge can be useful but should not be the only evidence. If the collection migrated, determine whether the old token remains active, whether it can be exchanged, and which supply the market treats as canonical.
Follow the metadata reference
On many EVM NFTs, a `tokenURI` function returns a URI for a metadata document. Other standards use different account relationships or asset interfaces. The document commonly includes name, description, image, animation, and attributes. Record the original URI before an application rewrites it through a gateway. The original may use an `ipfs://`, `ar://`, `data:`, or HTTPS scheme.
The IPFS documentation on best practices for NFT data explains why content-addressed URIs are useful for verifiable storage. A content identifier lets a client check whether retrieved bytes match the referenced content. It does not guarantee that someone will continue hosting or pinning the content, so persistence and verifiability should be evaluated separately.
Distinguish immutable, content-addressed, and mutable storage
On-chain data can be highly durable but may still be generated by upgradeable logic. Content-addressed storage makes changes visible because new content produces a new identifier. Conventional HTTPS hosting can be updated at the same URL without an obvious trace. None of these patterns is automatically right for every project. Dynamic games may require updates, while finished art may benefit from strong immutability.
Ask whether the contract’s base URI can change, who controls that function, and whether the privilege can be revoked. Check whether metadata is frozen and what “frozen” means in the specific implementation. A marketplace label is helpful only when it corresponds to an inspectable technical condition. Save metadata snapshots for historical research.
Review contract administration
Identify owner, administrator, upgrade authority, pause authority, mint authority, freeze controls, and transfer restrictions. For proxy contracts, inspect both the proxy and implementation and determine who can upgrade. A multi-signature wallet can reduce single-key risk, but review the threshold and signers when public. Timelocks can provide notice before changes, though emergency functions may bypass them.
Administrative power is contextual. A game may need to update mechanics; a redeemable asset may need status controls; an art contract may intentionally minimize privileges. The research task is to describe the power accurately and compare it with project claims. Avoid treating “renounced” as automatically safe because immutable bugs and inaccessible metadata can also create harm.
Inspect supply and mint behavior
Confirm total supply, maximum supply if enforced, burned tokens, and remaining mint authority. A website statement about scarcity is weaker than a contract rule, and even a contract cap may apply only to one contract in a larger series. Check whether the issuer can mint additional token IDs, increase edition quantities, or deploy a parallel collection with similar branding.
Review unusual transfers around launch, reserved allocations, and team-controlled wallets. Concentration does not prove misconduct, but it affects market structure. For edition standards, verify quantities rather than counting token IDs. The collection research guide provides a broader framework for combining supply evidence with ownership and market data.
Understand approvals and operator risk
NFT approvals allow another address or contract to transfer a token under specified rules. An item-level approval covers one token, while an operator approval can cover all eligible tokens in a collection. Marketplaces need permissions to execute trades, but malicious sites can request broad approvals. Review the target contract and transaction details before signing.
A display-only research site should never require transfer approvals. If a tool asks for an approval merely to show a portfolio, stop and investigate. Periodically review active approvals through a trusted explorer or wallet security interface. Revoking an approval is an on-chain transaction and may not recover assets already transferred.
Treat media as untrusted input
NFT media can include SVG, HTML, video, audio, or files with misleading extensions. Wallets and marketplaces should sanitize or isolate active content, but researchers should still avoid downloading or opening unfamiliar files outside a controlled viewer. A media URL can also expose an IP address or use tracking parameters. The fact that an asset is referenced by a token does not make every linked resource safe.
For technical analysis, record content type, file size, hash, and retrieval source. Prefer gateways or viewers that apply security controls. Do not execute scripts from an NFT’s metadata or follow embedded links without verifying the destination. Spam NFTs often use alarming names or images to lure users into a malicious site; simply receiving such a token does not require interaction.
Document what can change and who can change it
Finish the review with a control map. List token ownership, contract administration, upgrade authority, metadata URI controls, storage persistence, domain ownership, and marketplace dependence. For each layer, state the controlling party and the evidence. This map exposes single points of failure that a polished collection page can hide.
Add confidence and recheck dates. A contract may be immutable while the project’s domain expires, or metadata may be content-addressed while no one maintains availability. Technical durability is a system property. The strongest research notes distinguish immutable facts, current operational observations, and assumptions that require ongoing monitoring.
Conclusion
NFT due diligence is an end-to-end trace: chain identity, contract logic, metadata reference, media storage, administrative controls, approvals, and display behavior. Each layer can fail differently, and a working image today does not prove permanent access or immutable terms.
Record the original identifiers, verify who controls change, treat linked media as untrusted, and use deeper audits for contracts that hold meaningful value or unusual privileges. A concise control map is often more useful than a generic security badge because it shows exactly where trust remains. Add a recovery column to that map. Note what can be restored if a gateway fails, a domain expires, a metadata server disappears, or an administrator key is compromised. Then identify who is expected to act and whether the process is documented. Periodic checks of content availability, contract ownership, proxy implementation, and approval status can detect changes that a one-time review will miss.
