An NFT listing can place a token, an image, a membership benefit, and an ambitious roadmap on one screen. Due diligence starts by separating those elements. Ask what exists now, what the holder may do with it, which party must keep providing something, and what happens after a transfer. A single word such as “ownership” is too broad to answer all four questions.

Build a review around the exact token and its documented relationships. The NFT screening guide provides a starting point for identity and provenance; the procedure below extends that review to permissions, technical controls, and continuing dependencies. The resulting record should make unsupported assumptions visible before they influence a valuation or an operating plan.

1. Separate the token from the rights being advertised

The ERC-721 specification defines an interface for tracking and transferring distinct tokens, including ownership queries and approval mechanisms. It also describes an optional metadata interface. That technical scope is a reason to examine the separate terms associated with a project; implementing the interface does not establish that a particular buyer receives copyright, commercial permissions, or an enforceable promise of future services.

Create four lines in the review: token control, referenced content, permitted uses, and continuing benefits. For each, name the evidence and the party responsible for it. This small separation prevents an attractive image or a visible wallet balance from silently standing in for every other part of the offer.

For example, a fictional collection might describe access to an event and permission to display an illustration. Those are two different claims. Investigate the event's conditions and operator separately from the illustration's permitted uses. If an item is missing from the available terms, label it undocumented rather than filling the gap with the interpretation most favorable to the project.

2. Resolve identity and provenance before discussing rarity

Record the network, contract address, token identifier, and observation time. Cross-check the identity in project-controlled materials against the record used by the marketplace or application. Save the exact identifiers; collection names and visual similarity are weak substitutes for a precise match. If the project has migrated, document the relationship between the earlier and current records.

Next, identify what the provenance evidence actually establishes. A transaction history can support a sequence of token movements. A creator announcement can support a claimed association with a contract. A media file can show what was accessible when examined. Keep these observations in separate fields so the presence of one does not become a claim about the others.

Delay conclusions about rarity until the reviewed set is defined. Ask who supplied the attribute list, whether it covers the collection being evaluated, and whether attributes can change. Record the version of the dataset used for any comparison. A rarity label without a reproducible population and method should remain a description supplied by its publisher.

3. Read the permissions as a usable set of conditions

Find the actual license or terms connected to the token and preserve its version, date, and relationship to the collection. A summary on a marketplace may be helpful navigation, but the screening record should identify the underlying text and the entity presenting it. Note whether the terms explain how later revisions are handled.

Turn the intended use into concrete questions. If a prospective holder wants to put the artwork on a commercial product, identify the provision addressing that use, any stated limits, and whether separate permission is required. If the intended use is personal display, examine that use directly. Avoid assuming that permission for one activity extends to all adjacent activities.

  • Scope: which content, token, and activities does the text cover?
  • Duration: when does the permission begin, end, or require renewal?
  • Transfer: what does the text say happens when the token moves to another holder?
  • Conditions: are attribution, revenue limits, geographic limits, or other requirements stated?
  • Uncertainty: which questions need clarification from the responsible party or qualified review?

This is document analysis for screening. When a business plan depends on a disputed interpretation, preserve the exact uncertainty and obtain appropriate legal review before treating the permission as settled.

4. Inspect how the content remains available

Follow the token's metadata reference and then the referenced media. Record what is actually retrievable, the identifiers used, and whether your result depends on a particular website or gateway. Preserve an authorized local copy for the review when appropriate, while distinguishing your copy from evidence that the project will maintain access for future holders.

Ask who can change the reference or content and what evidence supports claims of permanence. A technical storage description should lead to specific questions about retention, retrieval, and operational responsibility. If the media cannot be retrieved, document the failure and the attempted route. Do not replace the missing evidence with a marketplace thumbnail without explaining its source.

For a membership or game item, repeat this exercise for the application. List the login service, website, game environment, or other component that must continue operating. The Web3 screening framework helps connect a token to the services and people that give its advertised functions practical meaning.

5. Review contract controls and the requested interaction

Inventory the controls relevant to the deployed implementation. Ask whether a responsible party can pause activity, change application behavior, alter metadata, or replace components. Record the evidence for each answer and the addresses or governance process associated with a power. A generic description of the token standard does not establish the behavior of a particular deployment.

Keep technical review proportional to the consequence of an error. If reading the implementation is beyond the reviewer's competence, mark the relevant controls unverified and request a suitably scoped technical assessment. An assessment should identify the examined version and coverage; the mere existence of a report should not close every contract question.

For any contemplated wallet interaction, describe the intended action and the permissions it requests before proceeding. Check whether an approval concerns one token or a wider collection, which contract receives it, and why it is needed. Research can usually begin with public records. A request to sign should not be treated as a prerequisite for establishing basic identity or reading terms.

6. Evaluate promises, access, and a possible exit separately

Divide benefits into available now, documented but conditional, and proposed. Record the responsible operator, eligibility rules, expiry, and evidence of current availability for each existing benefit. Proposed features belong in a distinct section with the assumptions required for delivery. Do not count them as operating capabilities simply because a roadmap assigns them a date.

Then examine a transfer from the next holder's perspective. Would that person receive the same access, need a separate account, or face additional eligibility steps? Is there a documented process for transferring the associated benefit? The right question is whether the specific package can move as expected, rather than whether the token itself appears tradable.

For market evidence, distinguish active asking prices, verified completed transactions, and indicative bids. Explain why any comparison is relevant to the token under review. A neighboring sale does not establish demand for this exact item. Add shared marketplaces, operators, and application dependencies to the portfolio exposure review when several holdings rely on the same parties.

Use a resale walkthrough to expose hidden conditions

Imagine a fictional membership token whose project describes both event entry and access to downloadable artwork. Walk through a resale without assuming that both benefits move together. First identify the token transaction. Then check whether the entry record is updated, whether an account must be reassigned, and what the terms say about the artwork permission after the seller no longer holds the token.

Write the expected evidence beside each step: a current eligibility rule, a transfer procedure, or the relevant license provision. If the buyer would need separate approval, place that condition next to the advertised benefit. The result is a description of the package a new holder can investigate, with any missing connection visible. It also prevents a successful token transfer from being reported as proof that every associated benefit was delivered.

Conclusion: describe the package precisely

A completed NFT review should state what token is held, what content is referenced, which permissions are documented, and which benefits require continuing performance by others. Attach open questions to the specific layer they affect. That precision makes it possible to compare projects without confusing token control, media rights, and future promises, and gives the next reviewer a clear record to update when the evidence changes.