Contract decoding: a matching selector is not a verified action
A block explorer’s decoded function name is an interpretation of bytes, not independent proof of the economic action. Contract research should preserve raw calldata, the applicable ABI and execution evidence before treating a readable label as a verified event.
The Solidity ABI specification explains that the encoding is not self-describing and that a function selector uses four bytes derived from a function signature. These facts make schema selection material. A public signature lookup can suggest a candidate name without establishing that the deployed target implements that candidate.
Build the decoding chain
Save network, transaction hash, target address, block and raw calldata. Locate the ABI tied to code applicable at that block. For a proxy, distinguish the transaction target from the implementation handling the call. A current verified ABI may not describe the implementation used in an earlier transaction.
Record which source supplied the ABI and why it matches the deployment. Separate exact code-linked verification from a signature-database guess. Four bytes have finite possible values, so different signatures can share a selector. The readable name alone cannot resolve that ambiguity.
Decode arguments according to the candidate schema and check the complete payload, including dynamic offsets, lengths and remaining bytes. A plausible first argument is not enough. Type-compatible decoding also does not prove that the code used those arguments in the economic way suggested by a familiar name.
Hypothetical misleading action label
Assume a fictional explorer labels a call “deposit” after finding the first four bytes in a public signature database. The raw call contains a selector plus 64 bytes of argument data. A researcher copies that label into a memo saying that 100 tokens entered a vault.
Now suppose the historical implementation’s verified ABI maps those bytes to a different two-argument function. The call changes an internal setting and transfers no tokens. The initial label was a candidate interpretation, not evidence of a deposit.
| Evidence layer | Required question |
|---|---|
| Raw bytes | What target and payload were actually submitted? |
| Historical ABI | Which schema matches the code at that block? |
| Execution | Did the relevant call succeed? |
| Logs and state | What changed, and under which contract semantics? |
| Economic conclusion | Does that change establish a deposit or only a request? |
The example invents no real selector collision or transaction. It illustrates why a label cannot stand in for the full chain. Even when the correct name is deposit, its implementation might issue a request, record a claim or use another mechanism rather than immediately moving the named asset.
Treat logs as structured evidence too
Decode events with their emitting address and matching event schema. Indexed and non-indexed parameters occupy different places; a topic hash is not a plain readable value for every type. Preserve raw topics and data so a later reviewer can reproduce the interpretation.
Connect successful execution to relevant balance or state changes. A generic transaction success flag does not prove every inner economic action completed. Conversely, absence of a familiar event is not proof of no change when the implementation uses another event or state path.
Test the decoder on a small set with directly checked outcomes. Include one historical upgrade boundary, one dynamic-argument call and one unresolved schema if relevant. Do not force an ambiguous call into the most familiar category merely to complete a dataset.
Publish the decoded value with schema provenance, block-specific code identity and economic verification status. Recheck after ABI corrections, implementation-history updates or disagreements between labels and observed state. The deliverable is an auditable interpretation, not an assurance that every explorer label is wrong.
Keep the raw integer beside any display conversion. An ABI can decode a uint256 correctly while an interface applies the wrong token decimals or labels it as a different asset. Schema correctness and economic-unit correctness are separate checks. A readable amount with the right function name still needs the asset identity, scale and period relevant to the research claim.
FAQ
Does a selector match prove the function name?
No. It supplies a candidate. Confirm the applicable implementation and ABI, then decode the full payload.
Can an event name alone prove an asset transfer?
No. Check its emitter, schema, implementation semantics and relevant balances or state. Names are part of the evidence, not the conclusion.