Metadata and identity

EN source master · P08-L05 · 45 minutes estimated · needs_review

A token can change its name or image without changing its exact mint. Two different mints can show identical branding. An immutable on-chain URI can still point to externally changeable content. These distinctions matter when an analyst reports that an asset “is official.”

This lesson teaches a metadata comparison with explicit provenance. It retains NFT metadata as a useful foundational example while focusing on token identity; no NFT launch or full NFT valuation workflow is required.

Separate the object from its description

Identity is the network/address/object tuple verified in P08-L01. Metadata describes the object. A familiar logo or name can help a user recognize a candidate, but neither uniquely identifies it. Preserve the tuple when display fields change.

The ERC-20 interface makes name and symbol optional [S08-ERC20]. An absent display field does not erase an object's existence. Conversely, successful display fields do not authenticate brand affiliation. Read metadata as a set of claims with a mechanism, not a certificate.

For a Solana asset using Metaplex Token Metadata, inspect the metadata account's linkage, update authority and mutable flag. Under this specific program, a mutable asset's update authority can change specified metadata fields, and some delegated authorities have additional scope [S08-METADATA]. Do not universalize those rules to every metadata implementation.

Follow the full description chain

A display can originate from an on-chain field, an on-chain URI, an off-chain JSON response, an image URL in that response and a platform cache. Each layer has a distinct source and possible update path. An analyst should record where the displayed name actually came from.

If the URI is stable but its HTTP response changes, the content changed without an on-chain URI edit. If an on-chain flag prevents future metadata-account updates, that does not by itself freeze all remote servers or caches. Content-addressed storage requires checking the actual reference and payload rather than trusting a storage-brand label.

Record a captured payload or reproducible digest with its acquisition context when conducting a real review. Do not invent a digest from a screenshot. The fixture supplies literal short payload fields so the exercise can compare contents without live network requests.

Distinguish mutability from authenticity

A mutable flag describes a control, not whether the data are truthful. False metadata can be immutable; legitimate metadata can need updates. A revoked update path cannot retrospectively authenticate an issuer relationship.

In the inspected Token Metadata implementation, isMutable=false rejects replacement of the descriptive Data object. It does not by itself prove that every field of the Metadata account—or the update authority—is frozen; those operations have separate authorization and invariants. Verify the instruction and deployed program version before asserting immutability for a specific field or authority. [S08-METADATA-CODE] Scope that statement to the reviewed mechanism and do not claim a universal freeze of all presentation. NFT-oriented fields such as verified creators or collections have their own semantics; a check mark is not a blanket guarantee of token economics or identity.

A domain in metadata is self-declared by whoever supplied that metadata. A website listing the same token is another declaration. Depending on control and provenance, these may be two directions of one self-assertion rather than independent corroboration. Preserve the distinction between declared links and independently verified association.

Corroborate carefully

Start from an authenticated issuer communication and compare the exact network/address. State how the communication's provenance was established. Search-result ranking, follower count and copied branding do not establish issuer control.

If issuer provenance is not supplied, classify the relationship as declared and unverified. If a reliably authenticated publication names a different mint, you can report a mismatch with that declaration. Do not leap from a mismatch to a legal fraud accusation; compromised communications or stale releases are alternative explanations requiring investigation.

Archive the relevant statement and its publication/capture context. A present-day webpage cannot prove what it displayed during a prior launch unless an appropriate historical record exists. Separate current retrieval time from the claimed date of a publication.

Handle competing displays

When two interfaces display different names for the same object, identify on-chain state, payload acquisition context and cache policy. Do not “resolve” the mismatch by silently selecting the more attractive branding. Your report may preserve the exact object while leaving the presentation discrepancy unresolved.

When two objects display identical names, preserve both identifiers and compare independently. One may be a wrapped representation or a deliberate copy; identical presentation alone cannot classify the relationship. A bridge claim needs its own mechanism and custody evidence outside this metadata exercise.

Display updates should not overwrite previously captured evidence. A report needs the version it relied on, so a later reviewer can reproduce the decision. The current lesson's synthetic S0/S1 labels are exercise contexts, not actual observation timestamps.

Write the narrow result

Useful findings distinguish exact identity, displayed fields, editable controls and issuer correspondence. “Same mint, changed off-chain name at S1” is specific. “The token changed identity” is misleading if the address remains fixed.

Commercial status, Creator Lab use and Academy completion cannot improve a metadata evidence classification. A metadata analysis provides neither a price prediction nor a safety certificate. It can still support a precise identity investigation without any paid tool access.

• Metadata: descriptive fields associated with an object.
• URI (uniform resource identifier): reference identifying a resource; this fixture uses it to locate an external payload.
• Payload: content retrieved from that resource.
• Update authority: permission governing a specified metadata operation.
• Mutability: whether a mechanism permits changes.
• Corroboration: evidence supporting a claimed relationship beyond an untested declaration.

ILLUSTRATIVE — FIX-P08-05. SIM-SOL-A at fictional S0/S1. URLs ending in .invalid are nonfunctional training labels.

No delegated-update inventory or authenticated issuer publication is supplied. All payloads are synthetic.

OBSERVED in fixture: A's exact mint and on-chain fields stay fixed across S0/S1; URI contents differ. B is a different mint with similar branding.

INFERRED: A's changed remote presentation does not require a supplied on-chain URI change. D1/D2 form a declaration loop.

UNKNOWN: Issuer authenticity, domain control, cache behavior and full delegated-update scope.

INSUFFICIENT EVIDENCE: B's immutable flag does not authenticate its logo or issuer. D1/D2 cannot alone establish independent corroboration.

Equating name changes with mint changes; calling unchanged URI immutable content; assuming immutable metadata is true; counting reciprocal declarations as independent verification; and treating collection/creator labels as economic endorsements.

Compare M1/M2 and J1/J2 separately. Explain whether A's mint changed. Evaluate B's claim to be “the official Alpha because immutable.” Classify D1/D2 and list three next evidence requests.

• Preserve the exact object while comparing displays.
• Trace fields to on-chain data, URI, payload or cache.
• Record change permissions and mechanism scope.
• Separate mutability from authenticity.
• Preserve reciprocal declarations as unverified until corroborated.

Metadata is a description chain with update mechanisms. Exact identity can remain fixed while displayed content changes.

Immutable is not authenticated. A stable URI is not automatically stable content. Same branding does not mean same mint or issuer.

Draw mint→metadata→URI→payload→image chain with S0/S1 columns. Mark on-chain fields equal, payload different. Compare MINT-B separately; use dashed D1/D2 declaration loop, never an official badge.

Illustrative display changes and declared links; issuer association unresolved.

Use deterministic SVG/HTML or charts with text alternatives, dark navy/black and restrained cyan, electric blue and violet. Label every quantity and uncertainty. At 390px stack panels; 768px/desktop and Arabic RTL verification remain future asset work. Keep identifiers LTR and factual axes/edge directions unchanged. Use only the official supplied ZECOIN mark if branding is added. Both records are specifications, not delivered assets.

Use RADAR for the lesson's bounded educational purpose only if network support, exact identity, fields and provenance are verified. No runtime endpoint or provider capability is asserted by this content. Use the embedded offline fixture without paid access. Missing data stays unknown; no wallet connection, transaction signature, token launch or live trade is required. Academy progress, payments and referrals never change Radar evidence. A Diagnostic Passport preserves observations and limits, not a price prediction or safety certificate.

• Metaplex Token Metadata Updating Assets — Update authority, mutable flag and editable metadata fields within this specific program. Checked 2026-09-30.
• ERC-20 Token Standard — Standard interface; optional name, symbol and decimals; not privilege or identity certification. Checked 2026-09-30.
• Metaplex Token Metadata implementation (pinned) — The is_mutable check rejects replacement Data; new_update_authority is handled separately under its authorization and invariants. Checked 2026-10-05.

Documentation supports mechanisms, not fictional dataset values. All examples and exercise records are original ILLUSTRATIVE material, frozen in this file. S0/S1 are synthetic context labels; observedAt is null because no live or historical ledger measurement was collected. Re-review documentation and actual deployed behavior before any publication or integration.

P08-L06 after the worked exercise and quiz review.