Exact contract and mint verification

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

Every later calculation depends on analysing the intended asset. A correct permission audit of the wrong contract is still a failed investigation. Names, symbols and icons help navigation but cannot serve as primary keys. This lesson extends exact-mint recognition into a reproducible identity record that distinguishes the account's role and the logic governing it.

You will match a declared target to supplied records, identify missing implementation evidence and write a result another analyst can repeat. You will not sign, approve or purchase anything.

Build the identity tuple

Start with network, exact address and object type. Distinguish mainnet from test environments and different EVM chains. An address-shaped string alone is incomplete. An explorer URL can select a different network even when the displayed address looks familiar. Preserve the requested network when a search returns a more popular lookalike.

Write the full identifier rather than a shortened prefix. In real inspection validate encoding and compare decoded address bytes with a trustworthy tool. EVM checksum casing and Solana base58 conventions require different handling. The fixture uses invalid labels so no learner can accidentally transact with them; its comparisons are educational string comparisons.

Ask what object the identifier names. A Solana mint is distinct from a token account holding units and from the Token Program containing instruction logic [S08-TOKENS]. An EVM implementation behind a proxy is not automatically the user-facing balance address. Describe the role before using values.

Separate existence, logic and affiliation

A source returning an account is evidence of an object at a context, not evidence that a brand endorses it. An explorer's source-code verification concerns correspondence between source and deployed code; it does not certify official affiliation or audit completeness. These questions require separate records [S08-CODE]. Etherscan distinguishes exact from similar matches; similar matching can leave constructor or initialization differences. Inspect the stated match type rather than treating every badge as the same finding.

Use distinct outcomes: exact object matched, implementation unresolved and affiliation uncorroborated. A positive identity match does not resolve the other two. If code correspondence is supplied, preserve compiler, configuration and deployment scope rather than paraphrasing it as “safe.”

ERC-20 describes an interface; name and symbol are optional metadata, and compatibility does not certify a project [S08-ERC20]. Receiving the expected symbol therefore cannot settle affiliation. An implementation can expose familiar methods while including additional controls not described by the basic interface.

Trace the logic boundary

For a Solana mint record the Token Program owning its data account. Do not confuse the base program-owner field with the token-account owner field used for holdings. An extension-enabled mint needs extension-aware decoding. A basic parser that ignores additional state cannot establish that no additional behavior exists.

For a proxy, the requested token address can stay stable while delegated logic changes. ERC-1967 describes implementation or beacon linkage and an optional admin slot [S08-PROXY]. The actual deployment determines applicability; empty standard slots do not establish that every possible upgrade mechanism is absent.

Keep proxy address, implementation and context together. Code at one context and state at another create a mixed record. If linkage is unavailable, identify the user-facing object while marking logic resolution incomplete. Never fill that gap with whichever contract an interface labels “implementation.”

Preserve retrieval provenance

Record source, retrieval time, block or slot context where returned, commitment/finality and decoder assumptions. A timeout means unavailable data. A wrong-network response is a mismatch, not absence on the intended network. Do not silently retry on a different chain and combine those values.

Two interfaces may share an indexer. Agreement is useful but not automatically two independent observations. Record the underlying source if visible; otherwise say independence is unknown. A raw record and its decoding are more reproducible than a cropped image without the exact identifier.

Separate declared and corroborated targets. A screenshot claiming an official address is a declaration. Matching it proves only that you inspected its named object. Affiliation requires appropriately authenticated issuer sources with capture context, and even corroborated affiliation does not prove safety.

Use a stop rule

Stop identity-dependent conclusions when the tuple mismatches or the object role is unresolved. You can still document the gap; you cannot attach another asset's supply or permissions to the target. A generic search-result match is not a substitute.

A concise finding could say: “The requested network/address resolves to a mint in supplied S0. Its extension inventory and issuer affiliation are not supplied.” This preserves a positive finding and its boundaries. A complete record should also state what additional evidence would permit the next step.

An independent reviewer should be able to start from your tuple without guessing which network tab or truncated address you selected. Read-only verification protects this workflow: no wallet approval is needed to establish an object's identity, and no exercise requires credentials.

• Identity tuple: network, full address and object role.
• Mint: Solana account representing a token.
• Token account: separate account holding units for a mint.
• Implementation: logic used by a delegated contract.
• Provenance: source and context supporting a record.
• Affiliation: relationship claimed to an issuer or brand.

ILLUSTRATIVE — FIX-P08-01. S0 is fictional, not a real block. Declaration D1 requests SIM-SOL-A / MINT-ALPHA as a mint; issuer attribution is not authenticated.

I1 contains basic fields but no extension inventory. I5 has linkage but no source/build correspondence.

OBSERVED in fixture: I1 matches D1's tuple; I3 references its mint but has a different role.

INFERRED: I1 is the correct starting record for basic inspection. I5/I6 describe a separate supplied proxy linkage.

UNKNOWN: Affiliation, omitted extension state and I5's code/build correspondence.

INSUFFICIENT EVIDENCE: Equal symbols cannot make I2/I4 the target. Logic-bearing I6 cannot replace user-facing I5.

Matching only symbols, forgetting network, substituting a holding account for a mint, analysing implementation balances and calling source visibility a safety certificate.

Choose the D1 match; reject I2–I4 with individual reasons. Write a separate I5 identity note. List three evidence gaps before a complete behavior review of I1.

• Preserve network and full identifier.
• Verify the role and program/logic linkage.
• Match contexts before combining evidence.
• Separate affiliation from code review.
• Stop when identity-dependent inputs mismatch.

Identity verification yields a bounded object record. The right network and role are prerequisites for subsequent measurement.

A symbol is a label. Mints, holder accounts and implementations are different objects. Missing linkage or affiliation evidence remains visible.

Compare D1 with I1–I4, annotating network/address/role differences. Put I5→I6 in a separate S0 logic panel; mark build correspondence unknown. Avoid safety badges.

Illustrative identity match; no issuer corroboration.

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.

• Etherscan Contract Code Tab — Exact versus similar bytecode match labels and separate compiler/constructor/audit information. Checked 2026-09-30.
• Solana Assets — Mint/account/program identity and decimals; distinguish account ownership fields. Checked 2026-09-30.
• ERC-20 Token Standard — Standard interface; optional name, symbol and decimals; not privilege or identity certification. Checked 2026-09-30.
• ERC-1967 Proxy Storage Slots — Implementation, beacon and optional admin slots; mechanism-specific inspection. Checked 2026-09-30.

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-L02 after the worked exercise and quiz review.