Phishing and approval-abuse evidence

An approval can authorize a spender without itself moving funds. Confusing approval with loss conceals which later record would establish an actual asset transfer.

Separate the proposed sequence into records: user-facing representation, authorization change, attempted spend and observed movement. ERC-20 allowance is a technical spending permission; an approval event does not alone show a completed transfer. A successful transferFrom-style movement requires the relevant execution/receipt and state reconciliation. A signature-based authorization has its own scheme and scope; do not generalize ordinary approve semantics to every signed message.

Preserve exact asset, owner, spender, amount, network and time basis for a real case. Here use non-executable paper labels only. If a displayed page promises one action while a stipulated authorization grants another, report that inconsistency. Deception or coercion claims require admissible evidence about representation and context; a broad allowance is a control exposure, not automatic criminal intent.

Never ask a learner to connect a wallet, sign, grant approval, send funds or provide a seed/private key to demonstrate the mechanism. Work from sanitized records. Real incident response can require context-specific expertise; this lesson is an evidence-reading exercise, not a transaction procedure.

Allowance: technical spending authorization for a spender.

Approval: permission update, distinct from actual movement.

Spending event: execution evidence that assets moved under a capability.

Representation conflict: promised action differs from granted control.

ILLUSTRATIVE: a paper page P promises “claim 10 units.” Record R1 stipulates that owner W grants spender S allowance 1000 for asset T. Record R2 stipulates that S successfully moves 400 T from W to D; receipt R2 exists only as an invented exercise row. The page capture does not identify a human operator.

Contract-permissions timeline P→R1 authorization→R2 movement with separate amounts 10/1000/400 and an unknown-identity lane. No active URLs or executable approval instruction.

Caption: Fictional sanitized approval sequence; authorization and completed movement are distinct records.

SPECIFICATION_ONLY — the rendered visual has not been produced or independently reviewed.

Within the fixture, R1 changes permission and R2 records a 400-unit movement. The 10-unit claim text conflicts with the 1000-unit permission scope.

It proves no real phishing site, live signature, actual wallet loss, operator identity or criminal intent. R1 alone would not establish any movement; a later revocation would not undo R2.

Calling approval itself a transfer; using an unlimited permission label as proof of fraud; inventing a missing receipt; asking a learner to sign to test the scenario.

Build a four-column sequence for P,R1,R2 and identity. Calculate remaining stipulated allowance under the exercise’s simple reduction assumption and state how the conclusion changes if R2 is absent.

• Separate representation, approval and movement.
• Bind each row to asset/owner/spender/network.
• Do not invent absent execution records.
• Use sanitized offline inputs with no signatures or funds.

Approval abuse analysis needs both the permission record and movement evidence, with representation and identity claims assessed separately.

• Approval is not a transfer.
• A later spending record can establish movement within its scope.
• Technical authorization does not identify a human or prove intent.

P13-L03

Use the named ZECOIN tool only as an evidence-reading context. This lesson creates no tool output, account session or entitlement. Offline exercise; do not sign, deploy, approve or fund anything.

• ERC20: ERC-20 standard — Token interface and allowance semantics; the standard does not establish issuer identity or safe permissions. Boundary: Mechanism documentation only; original illustrative values are stipulated, not observations. Historical records have separately frozen provenance and explicit collection gaps.

ILLUSTRATIVE — entirely fictional offline inputs; no current observation.

null — no real observation

1

null

needs_review