On EVM chains, calldata specifies which function is called and with which parameters. A UI can say swap while the payload authorizes a different contract or action. Transaction security reconstructs the method and parameters from the payload rather than trusting the page label.
This concept matters because Decode the selector and parameters.
Calldata is the executable request; the frontend description is merely a claim about that request.
Decode selector and parameters before trusting the UI action label.
At protocol and execution level, inspect selector and arguments and target and native value and nested execution. Protocol identifiers remain untranslated because they are part of the technical payload.
selectorcalldata[0:4]
argumentsABI-decoded parameters
targettransaction.to
native valuetransaction.value
nested executionmulticall / router subcalls
A swap button can submit approve(), transferFrom() or arbitrary multicall logic while looking visually normal.
The practical consequence is that Compare decoded action with stated user intent. Unknown is not equivalent to safe.
Block or review whenever decoded behavior materially diverges from declared intent.
The practical consequence is that Compare decoded action with stated user intent.
Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.
Verify the request through independent evidence before irreversible authorization.
capture exact payload
resolve selector / ABI
decode every material parameter
trace nested calls when present
compare decoded action with user intent
Record the facts, assumptions, unknowns and decision so another analyst can reproduce the review.
Decode the selector and parameters. and Unknown calldata deserves more scrutiny, not blind confirmation.
Decode the selector and parameters.
calldata[0:4]ABI-decoded parameterstransaction.totransaction.valuemulticall / router subcallsUI intent != decoded method
unknown selector
unexpected recipient
hidden native value
nested call changes authority
capture exact payload
resolve selector / ABI
decode every material parameter
trace nested calls when present
compare decoded action with user intent
facts → material evidence
evidence → consequence / authority
consequence → explicit decision + next action
decoded-intent record + mismatch listcalldata / intentSwap 1 ETH0x095ea7b3approve(address,uint256)0xNew...MAX_UINT2560Before answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.
Separate identity, authority, execution and context before reaching a security decision.
Who or what is requesting, receiving or representing authority?
What capability can be granted, retained or exercised?
0xNew...What will the payload, route or system actually do?
0x095ea7b3approve(address,uint256)MAX_UINT2560Which surrounding facts can materially change the decision?
Swap 1 ETHDo not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.
Decode the selector and parameters.
Compare decoded action with stated user intent.
Unknown calldata deserves more scrutiny, not blind confirmation.
Record your reasoning before the checkpoint. Finish with an explicit decision or next action. Notes stay on this device.
Develop all three sections before completion.
Move from button labels to the actual destination, value and method encoded in the request.