Network and explorer verification

EN source master · P02-L06 · 30 minutes estimated · needs_review

Read-only study. No wallet connection, real money, seed phrase, private key, signature or live trade. Duration is an editorial estimate; visual assets are specifications, not deployed components.

A technically valid-looking address or transaction can be queried on the wrong network. A page's title is a weak substitute for a sourced network context.

Start with independent context

Ethereum networks have network-specific identifiers [NET]. Solana exposes a genesis-hash query [GENESIS]. These help distinguish contexts, but a response is still made by an endpoint. A malicious or misconfigured service can return a plausible string. Record how the endpoint was selected, not just what it calls itself.

Match the complete tuple

A research key includes network, exact asset/transaction identifier and observation context. For token work, keep the contract or mint separate from the account holding it. An address string reused across EVM networks does not imply shared code, balance or activity.

An explorer domain and branding are provider provenance, not proof of network correctness. Cross-check against independently established documentation or configuration. A search ad or an unsolicited link is not a trusted origin just because the site displays a familiar chain name.

Compare like-for-like records

When two sources disagree, ask whether they queried the same network, identifier and block or commitment. Different observation times can explain a difference without proving either source malicious. Two pages using the same upstream data are not necessarily independent observations.

A resolved chain ID is useful evidence but not authentication of every returned record [RPC]. Keep verification layers separate: intended network, returned identifier, data context and provider trust.

Fail closed on unresolved mismatches

Do not average incompatible network responses or pick the one with a nicer interface. Preserve each response and mark the intended-state conclusion unresolved. The next action is a targeted provenance check, not a live transfer to test which service is right. All exercise identifiers are invalid training labels.

Evidence-state classification

OBSERVED in the fixture: expected and returned identifier/genesis fields and E2's mismatching title. INFERRED: E2 conflicts with the stipulated intended context. UNKNOWN: independent endpoint authenticity and service ownership. INSUFFICIENT EVIDENCE: a matching identifier authenticates every returned record or a mismatch establishes malicious intent.

• Chain identifier: network context value.
• Genesis hash: identifier of a network's genesis state, interpreted according to that network's rules.
• Endpoint provenance: origin and selection of a service.
• Cross-check: comparison with separately grounded evidence.

ILLUSTRATIVE. Trusted training configuration expects NET-A identifier101 and GENESIS-A. Endpoint E1 reports101/GENESIS-A. E2 reports202/GENESIS-B while its page title says NET-A. Both display ACCOUNT-X. Independent service ownership is not established.

Mint/network comparison table: expected101/A, E1 match, E2 conflict202/B; separate authenticity UNKNOWN column. Alt: E1 agrees but is not authenticated; E2 title does not resolve its mismatch.

Agreement or conflict between supplied identifiers.

Endpoint authenticity, record integrity, equal balances across chains or malicious intent.

• Trusting a page title over identifiers.
• Treating equal address strings as equal state.
• Calling a mismatch an accusation.

Write a comparison table. Which result conflicts with intended context? Does E1 agreement prove authenticity? What must remain UNKNOWN?

Submit a short evidence table and reasoning, using only the provided material. Suggested allocation: study 12 min, inspection/calculation 8 min, correction/quiz 10 min.

• Intended network.
• Returned identifiers.
• Source origin.
• Same observation context.
• Record discrepancies.

A technically valid-looking address or transaction can be queried on the wrong network. A page's title is a weak substitute for a sourced network context. The supplied material supports agreement or conflict between supplied identifiers. It does not establish endpoint authenticity, record integrity, equal balances across chains or malicious intent.

• Cross-check network identifiers and source provenance.
• Separate identifier agreement from endpoint authenticity.
• Preserve conflicts without guessing a resolution.

P02-L07 after reviewing this exercise and its prerequisites.

NONE. The authoritative catalog requires no product access for this lesson. Use the frozen/offline material.

• [NET] Ethereum networks — Distinct networks and network-scoped chain identifiers. Checked 2026-10-01.
• [GENESIS] Solana getGenesisHash — Network genesis identifier returned by an endpoint; not authentication of that endpoint. Checked 2026-10-01.
• [RPC] Ethereum JSON-RPC — Receipt status, block context and network-scoped API results. Checked 2026-10-01.

Synthetic values are author-created exercise inputs. Historical values, if any, must use the linked dataset and its narrower provenance. Source inspection is not independent editorial acceptance.