Mint and exact identity

EN source master · P07-L02 · 45 minutes estimated · needs_review

Learning objectives:

• Resolve asset identity using full network and mint identifiers.
• Distinguish mint, token account, pool and wallet roles.
• Write a bounded identity conclusion without inferring fraud or safety.

An analysis can be mathematically correct and still describe the wrong asset. Names, tickers, images and social handles are presentation labels that can be copied. Before interpreting a liquidity chart or a holder table, establish exactly which network and mint the evidence concerns. This lesson trains identity resolution and the ability to stop when identity remains ambiguous.

Separate the identifier from the story attached to it

For Solana token analysis, the network plus mint address identifies the asset under investigation. A token account holds units associated with a mint; it is not the mint itself [S-TOKENS]. A wallet address, a pool address and a mint can all appear on one explorer page, yet answer different questions. The correct-looking logo does not repair using the wrong account type.

A safe investigation record therefore names the chain/cluster, full asset identifier, expected account/program type, source and observation context. Do not reduce this to a truncated address. Truncation is useful for display but unsuitable for comparing look-alike identifiers. Store the full value and show a copyable, isolated string when a future interface supports the record.

The on-chain account proves that a particular asset exists under particular rules. It does not establish that a project, community or brand endorses it. Conversely, a project page can declare an address without proving every technical field about that address. Keep technical identity and declared affiliation as separate claims, with separate sources.

Triangulate without double-counting copied declarations

Imagine three websites repeat the same address. They may be independent publications, or all may copy one compromised feed. Three appearances do not automatically make three independent confirmations. Write a provenance chain: who originally declared the identifier, when the declaration was available, and what technical record the researcher inspected.

A source reached through a search advertisement or a forwarded message is not automatically the organization's official channel. Inspect the exact domain and the origin of the reference. Similar spelling, a renamed account or an unrelated subdomain can mislead. Even when an official channel is established, label its address statement DECLARED unless the planned independent checks have actually been performed.

“Verified” is also ambiguous. A badge may refer to a social account, an explorer listing or a metadata submission. State what was checked instead of using the badge as a broad asset endorsement. A useful conclusion is “the declared full identifier matches the inspected mint on the specified network,” not “this token is legitimate.”

Permissions and metadata answer narrower questions

A mint authority and a freeze authority represent specific permissions. Removing a selected authority does not erase every possible risk [S-AUTHORITY]. Metadata and token extensions need their own inspection; base fields alone do not exhaust additional token behavior [S-EXTENSIONS]. An analyst should preserve these distinctions rather than combine them into a green safety label.

For this lesson, you do not need to perform a contract security audit. You need to verify that the evidence you plan to use actually belongs to the claimed asset. If a source describes a standard token but an inspected account uses another program or unexamined extensions, record the discrepancy and stop short of assumptions about transfer behavior.

The refusal to complete an identification prematurely is a useful result. UNKNOWN says a relevant fact has not been obtained. INSUFFICIENT EVIDENCE says the collected facts cannot support a particular claim. These are not interchangeable with “fake.” A mismatch can justify rejecting a candidate as the exact declared asset without justifying a fraud accusation against its creator.

Make the decision reproducible

Use an identity matrix with one row per candidate. Record the full identifier, network, account type, declaration match and unresolved questions. The decision rule should be fixed before looking at popularity or market performance: a candidate must match the required network and full mint, and its type must be interpretable. If multiple candidates remain, describe the ambiguity and request the missing declaration or technical record.

This procedure avoids a common behavioral trap: choosing a candidate because its chart looks more plausible. Price action cannot disambiguate an asset identifier. Identity work also precedes merging records from multiple providers. A shared ticker does not authorize combining one candidate's social profile with another candidate's holder distribution.

• Exact identity: full network-and-asset identifier, not a ticker match.
• Mint: the token's identifying account in the Solana scope of this lesson.
• Token account: a balance-bearing account associated with a mint.
• Declaration: a source's statement about affiliation or identity.
• Corroboration: an explicitly described cross-check, with provenance.
• Authority: a specific permission, not general human/project identity.

ILLUSTRATIVE EXAMPLE — FIX-P07-02. MINT-A and MINT-B are deliberately invalid fictional address labels. Never paste them into an explorer as real addresses.

The fictional project's supplied declaration is “training-cluster-A / MINT-A.” Candidate A matches this fixture. B is a different mint, C fails the network check, and D is the wrong account role. No row establishes the human operator or investment quality.

OBSERVED: A matches the supplied full declaration and account-type record in the fixture.

INFERRED: A is the appropriate record for this narrowly defined analysis, conditional on the supplied declaration being the intended reference.

UNKNOWN: Whether the fictional project declaration was authorized by a real organization; source authenticity beyond the supplied fixture.

INSUFFICIENT EVIDENCE: Matching an identifier cannot establish project safety, fair distribution, creator honesty or future return. A different candidate is not automatically fraudulent.

Using ticker search as final identification; comparing only the first/last characters; merging data across networks; confusing token accounts with mints; counting copied declarations as independent checks; and treating authority removal as comprehensive safety verification.

Given FIX-P07-02, select the matching candidate and write a one-sentence bounded conclusion. Explain each rejected candidate. Then rewrite “B is a scam” and “A is verified safe” into claims supported by the fixture. List the two checks needed before using a real official declaration.

• Match network and complete identifier.
• Confirm mint/account role before reading metrics.
• Keep declaration and technical evidence distinct.
• Record source independence and observation context.
• State unresolved identity and authority/extension questions.

Exact identity is a prerequisite for every later measurement. Resolve the asset with full identifiers and explicit account roles, then describe affiliation and technical controls as separate evidence claims.

A ticker is not an identity key. Agreement with a declaration is a bounded match, not a safety verdict. Ambiguity should stop the merge of unrelated data.

Draw four comparison cards from FIX-P07-02. Highlight network, full synthetic identifier and account type; mark matching fields separately from affiliation claims. Show no safety shield or price cue. A second panel must explain why token account D is not the mint.

Visual delivery rules: dark navy/black, cyan/electric-blue/violet accents, units and uncertainty explicitly labelled. Use deterministic charts or SVG, not fabricated screenshots. At 390 px stack annotations and provide the data table as a text alternative; verify 768 px and desktop later. In Arabic localize labels and layout with native RTL, while isolating addresses/hashes LTR and retaining the actual direction of transfers and chronology. Use only the supplied official ZECOIN logo if branding is added. No visual asset or mobile/RTL rendering is claimed ready.

Use RADAR only when the exact network, asset and needed fields are supported and their provenance is visible. This is a read-only educational inspection, not a trade or a token launch. Use the supplied offline dataset if access or data is unavailable; missing information remains unknown. A future Open in ZECOIN action needs validated runtime routing and source coverage. No executable asset CTA is supplied for illustrative identifiers. Academy participation and commercial status never change Radar observations.

• Solana Assets: mint and token accounts — Mint identity, token-account ownership and distinct mint/creation roles. Checked 2026-09-30.
• Solana Set Authority — Specific authority roles and removal of a selected authority. Checked 2026-09-30.
• Solana Token Extensions — Additional token behavior requires extension-specific inspection. Checked 2026-09-30.

The tables and exercise fixtures are original educational material unless explicitly designated HISTORICAL. Fictional identifiers are deliberately invalid as blockchain addresses. Documentation supports mechanism definitions, not the invented exercise values. Source inspection is editorial research, not a live-chain measurement. Sources may change; re-review before publication.

P07-L03; proceed after completing the exercise and reviewing each quiz explanation.