Independent education. No affiliation with Binance or BNB Chain.
BNB.info Español

Digital records and rights

NFT token, metadata, file and rights

Separate an NFT contract record, its metadata and file, and the legal permissions a person may or may not receive.

You will learn

  • Trace a token, contract, network, metadata pointer and media file as distinct evidence objects.
  • Explain why a token or metadata field does not by itself prove authorship, copyright, a license, legal ownership or file availability.
  • Resolve a fictional NFT record and list the separate evidence needed before relying on a claimed permission.

Before you begin

No wallet, account, token, funds, upload or transaction is needed. The worked record and every identifier are fictional.

Identify the onchain object first

An NFT is a token tracked by a particular contract on a particular network. For an evidence check, keep the network, contract address, token identifier and reported holder separate. A ticker, collection name, marketplace card or image preview is not a substitute for those identifiers.

ERC-721 is one Ethereum token-interface standard. Its base interface describes identifying and transferring tokens; its metadata extension is optional and can expose a tokenURI that points to a JSON description. This is a standards example, not proof that a particular contract implements ERC-721 or that every NFT on BNB Chain uses it. BNB Smart Chain is a distinct EVM-compatible network; check the exact chain and deployed contract rather than inferring identity from the BNB or Binance names.

Evidence: EIP-721 token and optional metadata interfaces · BSC overview

The metadata extension is OPTIONAL in ERC-721. The specification describes an interface and a URI that may point to JSON; it does not authenticate a deployed contract, creator, legal license, file persistence, or rights. It is a standards example, not a claim that every BNB Chain NFT implements ERC-721.

Used only for BNB Smart Chain identity and EVM compatibility. The same page includes time-bound performance, fee and adoption figures; they are not treated as current facts or a current support/availability list.

A pointer is not the media file or a retention promise

When a contract exposes metadata, the returned URI may point to JSON; a metadata field can in turn point to an image or another file. Those are linked records, not one indivisible proof. A name, creator field or license field is data supplied through the contract or referenced document; its presence alone does not authenticate the author or make the statement legally effective.

IPFS documentation explains that cached data can be removed by garbage collection and that pinning protects data from collection on the pinned node. It also says IPFS does not guarantee persistent availability. A content identifier or a successful display at one moment therefore does not prove that a file will remain retrievable, that every gateway serves the same experience, or that the person who supplied it had permission to publish it. Check the actual bytes, who maintains copies, and the issuer's retention terms separately.

Evidence: EIP-721 token and optional metadata interfaces · IPFS persistence, pinning and availability

The metadata extension is OPTIONAL in ERC-721. The specification describes an interface and a URI that may point to JSON; it does not authenticate a deployed contract, creator, legal license, file persistence, or rights. It is a standards example, not a claim that every BNB Chain NFT implements ERC-721.

The docs say cached data may be garbage-collected, pinning retains data on the pinned node, and IPFS does not guarantee persistent availability. This does not prove the availability, integrity, authorship, permission or legal status of a particular file.

Token control and intellectual-property rights answer different questions

A chain entry can describe which address a contract currently records for a token. That does not, without additional evidence, identify a human, establish who created the artwork, prove copyright ownership, grant a license to copy or sell the image, or create a right to redeem a physical object. Token ownership, ownership of a file copy, copyright and a contractual license are distinct questions.

For a narrowly scoped United States example, 17 U.S.C. §202 states that copyright ownership is distinct from ownership of the material object containing the work. Section 204(a) generally requires a writing signed by the owner or authorized agent for a transfer of copyright ownership, except a transfer by operation of law. These are U.S. federal copyright provisions, not a conclusion about every NFT sale, license, jurisdiction or dispute. A license can grant defined uses without transferring copyright; read the actual terms and verify the grantor's authority.

Evidence: U.S. copyright ownership and material objects, §202 · U.S. copyright transfer form, §204(a)

U.S. federal copyright statute. Section 202 says ownership of copyright is distinct from ownership of the material object embodying a work. It does not decide whether an NFT conveys a license or legal rights in another jurisdiction.

Section 204(a) concerns a transfer of copyright ownership under U.S. law, other than by operation of law. It is not a universal rule for licenses, token transfers, every jurisdiction, or the legal effect of any particular terms.

Solved fictional example: what does token 17 establish?

Fictional paper exercise only: assume a made-up contract on BNB Smart Chain implements an ERC-721-style metadata extension. It reports token ID 17 and a placeholder URI, ipfs://fictional-cid/art-17.json. The fictional JSON names an illustration and points to a fictional image file. No real contract, token, address, CID, artwork or request is involved.

Result: within this hypothetical record, an inspection of the named chain and contract could support what that contract reports for token 17 and its URI. The URI and JSON would not independently prove that the named artist created the file, that the file will stay available, that the token is authentic, or that a token holder may reproduce or sell the illustration. Because no license document or authorized grantor is supplied, commercial permission is unknown; the safe reading is not to infer it.

Evidence: EIP-721 token and optional metadata interfaces · IPFS persistence, pinning and availability · U.S. copyright ownership and material objects, §202

The metadata extension is OPTIONAL in ERC-721. The specification describes an interface and a URI that may point to JSON; it does not authenticate a deployed contract, creator, legal license, file persistence, or rights. It is a standards example, not a claim that every BNB Chain NFT implements ERC-721.

The docs say cached data may be garbage-collected, pinning retains data on the pinned node, and IPFS does not guarantee persistent availability. This does not prove the availability, integrity, authorship, permission or legal status of a particular file.

U.S. federal copyright statute. Section 202 says ownership of copyright is distinct from ownership of the material object embodying a work. It does not decide whether an NFT conveys a license or legal rights in another jurisdiction.

Use a paper-only rights checklist

Write down what is claimed and which evidence could support each part: network and contract for the token record; token identifier and metadata response for the pointer; the retrieved bytes and retention arrangement for file access; and an issuer or creator document for attribution and permission. A BNB Chain record does not establish a Binance Exchange account credit, and the Binance brand is not automatically the token issuer or license grantor.

For a claimed license, note the grantor and authority, the exact work, allowed actions, commercial or noncommercial limits, media, territory, duration, sublicensing, termination and governing law. Keep the original terms and date. If the terms, issuer identity, file, or applicable law cannot be verified, mark that item unresolved rather than converting a token display into a rights conclusion.

Evidence: EIP-721 token and optional metadata interfaces · U.S. copyright ownership and material objects, §202 · U.S. copyright transfer form, §204(a) · BSC overview

The metadata extension is OPTIONAL in ERC-721. The specification describes an interface and a URI that may point to JSON; it does not authenticate a deployed contract, creator, legal license, file persistence, or rights. It is a standards example, not a claim that every BNB Chain NFT implements ERC-721.

U.S. federal copyright statute. Section 202 says ownership of copyright is distinct from ownership of the material object embodying a work. It does not decide whether an NFT conveys a license or legal rights in another jurisdiction.

Section 204(a) concerns a transfer of copyright ownership under U.S. law, other than by operation of law. It is not a universal rule for licenses, token transfers, every jurisdiction, or the legal effect of any particular terms.

Used only for BNB Smart Chain identity and EVM compatibility. The same page includes time-bound performance, fee and adoption figures; they are not treated as current facts or a current support/availability list.

Check your understanding

A fictional NFT shows an image and its metadata says “commercial use allowed.” What evidence is still missing before treating that as permission?

Show explanation

The token and metadata only show what the contract and linked data report. Verify the issuer, the creator or authorized grantor, the actual terms and their scope, and the applicable law. Without that evidence, the permission is unresolved; do not infer it from a token balance or image preview.

Primary sources

  1. ERC-721: Non-Fungible Token StandardEthereum Improvement Proposals · 2026-10-26

    The metadata extension is OPTIONAL in ERC-721. The specification describes an interface and a URI that may point to JSON; it does not authenticate a deployed contract, creator, legal license, file persistence, or rights. It is a standards example, not a claim that every BNB Chain NFT implements ERC-721.

  2. Persistence, permanence, and pinningIPFS Docs · 2026-10-26

    The docs say cached data may be garbage-collected, pinning retains data on the pinned node, and IPFS does not guarantee persistent availability. This does not prove the availability, integrity, authorship, permission or legal status of a particular file.

  3. 17 U.S.C. §202: Ownership of copyright as distinct from ownership of material objectU.S. House Office of the Law Revision Counsel · 2026-10-26

    U.S. federal copyright statute. Section 202 says ownership of copyright is distinct from ownership of the material object embodying a work. It does not decide whether an NFT conveys a license or legal rights in another jurisdiction.

  4. 17 U.S.C. §204: Execution of transfers of copyright ownershipU.S. House Office of the Law Revision Counsel · 2026-10-26

    Section 204(a) concerns a transfer of copyright ownership under U.S. law, other than by operation of law. It is not a universal rule for licenses, token transfers, every jurisdiction, or the legal effect of any particular terms.

  5. BNB Smart Chain: overviewBNB Chain · 2026-10-26

    Used only for BNB Smart Chain identity and EVM compatibility. The same page includes time-bound performance, fee and adoption figures; they are not treated as current facts or a current support/availability list.