Detailed Instructions

First, query the NFT's smart contract to find the tokenURI function. This function returns the location of the metadata. Call it with the token ID, for example: tokenURI(1). The returned string will reveal the storage method.

• Sub-step 1: Analyze the URI format. An IPFS hash (e.g., ipfs://Qm...) or Arweave transaction ID indicates decentralized off-chain storage. An HTTP/HTTPS URL points to a centralized server. A long, encoded string may indicate fully on-chain SVG or metadata.
• Sub-step 2: Check the contract code. Look for a base URI variable (e.g., _baseURI) that is prepended to token IDs. Assess if it is immutable or controlled by an admin function.
• Sub-step 3: Verify the resolved content. Use the URI with a tool like curl or a blockchain explorer to fetch the JSON metadata. Ensure it returns a valid JSON object with standard fields like name, image, and attributes.

javascriptCopy
// Example using ethers.js to fetch a tokenURI
const uri = await contract.tokenURI(1);
console.log("Metadata URI:", uri);

Tip: For centralized HTTP URLs, check the domain's registration date and SSL certificate to gauge operational maturity.

Detailed Instructions

This step quantifies the risk of metadata becoming unavailable. For off-chain storage, the key is content addressing and redundancy.

• Sub-step 1: Check for pinning services. If using IPFS, determine if the CID is pinned by a reliable pinning service (e.g., Pinata, nft.storage, Infura) or just a single node. Use the public IPFS gateway https://ipfs.io/ipfs/{CID} to test availability.
• Sub-step 2: Assess Arweave permanence. For Arweave, verify the transaction is confirmed and check the endowment attached to it using a block explorer. A higher endowment suggests longer-term economic guarantees for storage.
• Sub-step 3: Analyze centralized server risks. For HTTP URLs, evaluate the likelihood of domain expiration, server downtime, or the project abandoning the endpoint. Look for historical uptime data or use a service like https://httpstatus.io/ to check the endpoint's current status and headers.

Tip: Truly permanent storage requires the data to be retrievable without relying on the original uploader's infrastructure. Prefer collections that use Arweave or permanently pinned IPFS CIDs.

Detailed Instructions

Examine the NFT contract for functions that allow an admin to change the metadata source after minting. This is a critical mutability risk.

• Sub-step 1: Locate setter functions. Search for functions like setBaseURI, setTokenURI, or reveal. Check their visibility (are they public or external?) and any access controls like onlyOwner modifiers.
• Sub-step 2: Verify immutability. The ideal is an immutable baseURI set in the constructor. Check if the contract uses the string type for _baseURI or the more gas-efficient bytes32 for a committed hash. Look for a contractURI function for collection-level metadata as well.
• Sub-step 3: Review upgradeability. Determine if the contract uses a proxy pattern (e.g., OpenZeppelin TransparentUpgradeableProxy). If so, the implementation logic, and thus the tokenURI logic, can be changed entirely, representing the highest risk tier.

solidityCopy
// Example of a risky, mutable baseURI function
function setBaseURI(string memory newBaseURI) external onlyOwner {
    _baseURI = newBaseURI;
}

Tip: Use a block explorer to review the contract's "Write Contract" tab to see all state-changing functions accessible to the owner.

Detailed Instructions

Fetch the metadata JSON and examine its internal links and attributes. The image and animation_url fields often host the highest risk.

• Sub-step 1: Follow the asset links. The image field should ideally point to a decentralized URI (IPFS, Arweave). If it's an HTTP link, the visual asset is at risk. Verify the MIME type and file size are correct.
• Sub-step 2: Check for nested dependencies. Some projects use layered SVG files or reference external scripts. An SVG with an <image> tag linking to an HTTP source inherits that server's risk. Projects that store traits as on-chain attributes are more resilient.
• Sub-step 3: Validate schema compliance. Ensure the JSON adheres to common standards (ERC721 Metadata, OpenSea). Inconsistent schemas can cause display issues on marketplaces and aggregators, affecting liquidity.

jsonCopy
// Example metadata with a decentralized image reference
{
  "name": "Asset #1",
  "image": "ipfs://QmX4s8A5Lp.../asset.png",
  "attributes": [{"trait_type": "Background", "value": "Blue"}]
}

Tip: Use a tool like ipfs-car to pack assets into a single CAR file for integrity checking, ensuring all referenced files are included in the storage deal.

Detailed Instructions

Create a simple scoring framework (e.g., Low, Medium, High) based on the collected data. This score directly impacts collateral valuation in NFT-Fi protocols.

• Sub-step 1: Categorize storage risk. Low Risk: Fully on-chain metadata or Arweave storage. Medium Risk: IPFS with reliable pinning. High Risk: Centralized HTTP URL or mutable contract.
• Sub-step 2: Factor in contract controls. Downgrade the score if admin functions like setBaseURI exist. An upgradeable proxy contract typically warrants a High Risk rating regardless of current storage.
• Sub-step 3: Document the assessment. Produce a brief report summarizing: Storage Method, Mutability Status, Key Vulnerabilities (e.g., "Centralized image host"), and a Final Risk Tier. This documentation is crucial for risk committees or smart contract automation.

Tip: For automated risk engines, encode these checks into a script that takes a contract address and token ID as inputs and outputs a score, querying on-chain data and off-chain endpoints.