UTXOSUITE — home
← Back to Academy
LEVEL 3 · Free

Understand What You Sign

Learn approvals, calldata, EIP-712, Permit and Permit2 so wallet prompts stop being opaque.

8 lessons · 8 Field exercise · 8 Practical scenarios · 20 question · 80% passing score
Start learning0% · 0/21

What you will be able to do

Move from button labels to the actual destination, value and method encoded in the request.

Understand how approvals create persistent authority that can outlive the transaction that created them.

Read typed-data signatures as authorization objects, not harmless off-chain messages.

Combine origin, payload, authority and context into a decision the user can understand before signing.

Curriculum

1.1 · The button label is not the transaction22 min
1.2 · Destination and value are the first invariants16 min
Lab · Decode spend authority

This course includes

  • 8 lessons · 16 guided hours
  • 4 Lab · Practical scenarios
  • 8 Applied case files · 8 Knowledge checks
  • 52 Item exam bank · 80% pass mark
  • Completion credential: UTXO Certified · Signing & Approval Literacy

What this course expects of you

  • Translate a signing request into permissions, spend authority and risk.
  • Passing score: 80%
  • Wallet Security & Self-Custody
Course briefing

Training contract

Translate a signing request into permissions, spend authority and risk.

01 · Target capabilityTranslate a signing request into permissions, spend authority and risk.
02 · Recommended prerequisiteWallet Security & Self-Custody
Practical deliverables
01

Transaction intent & calldata

Move from button labels to the actual destination, value and method encoded in the request.

Evidence memo · APPROVAL
02

Token approvals & spend authority

Understand how approvals create persistent authority that can outlive the transaction that created them.

Evidence memo · APPROVAL
03

EIP-712, Permit & Permit2

Read typed-data signatures as authorization objects, not harmless off-chain messages.

Evidence memo · TYPED-DATA
04

Intent reconstruction & decision

Combine origin, payload, authority and context into a decision the user can understand before signing.

Evidence memo · APPROVAL
Assessment contract
Lesson checks8
Module labs4
Final exam20
Mastery threshold80%
Complete syllabus

Understand What You Sign

Review the full curriculum, competencies and assessment path before starting.

Guided study load16h
modules4
lessons8
01

Transaction intent & calldata

Move from button labels to the actual destination, value and method encoded in the request.

1.1
The button label is not the transaction45 min · Deep technical lesson
1.2
Destination and value are the first invariants45 min · Deep technical lesson
Module practical labDecode spend authority
02

Token approvals & spend authority

Understand how approvals create persistent authority that can outlive the transaction that created them.

2.1
An approval delegates future spending authority45 min · Deep technical lesson
2.2
Unlimited approvals trade convenience for blast radius45 min · Deep technical lesson
Module practical labDecode spend authority
03

EIP-712, Permit & Permit2

Read typed-data signatures as authorization objects, not harmless off-chain messages.

3.1
Typed data is readable structure, but still authorization45 min · Deep technical lesson
3.2
Permit and Permit2 can move approval off-chain45 min · Deep technical lesson
Module practical labRead the Permit2 message
04

Intent reconstruction & decision

Combine origin, payload, authority and context into a decision the user can understand before signing.

4.1
Reconstruct intent from multiple independent fields45 min · Deep technical lesson
4.2
Risk scoring must end in an understandable decision45 min · Deep technical lesson
Module practical labDecode spend authority
Competencies
  • Decode the selector and parameters.
  • Compare decoded action with stated user intent.
  • Confirm chain, destination and native value.
  • Intermediary contracts expand the trust surface.
  • No immediate transfer does not mean no economic risk.
  • Review spender identity and allowance size.
  • Unlimited approvals deserve explicit disclosure.
  • Prefer scoped amounts when workflows allow it.
  • Read primary type, domain, chain and verifying contract.
  • Treat a typed signature as an authorization object.
  • Off-chain signatures can create on-chain spending authority.
  • Inspect spender, amount, token, nonce and deadline.
Assessment path
  1. Written field exercise × 8
  2. Knowledge checks × 8
  3. Module practical lab × 4
  4. Timed final exam · 20 · ≥ 80%
Guided study load
  1. Deep technical lesson · 360 min
  2. Written field exercise · 160 min
  3. Module practical lab · 140 min
  4. Specialist units · 105 min
  5. Timed final exam · 35 min
COURSE HANDBOOK

Scope, outcomes and study standard

16h
Who this is for

Learn approvals, calldata, EIP-712, Permit and Permit2 so wallet prompts stop being opaque.

Prerequisites

Recommended prior study

  • Crypto & Blockchain Foundations
  • Wallet Security & Self-Custody
Learning outcomes
  • Decode the selector and parameters.
  • Compare decoded action with stated user intent.
  • Unknown calldata deserves more scrutiny, not blind confirmation.
  • Confirm chain, destination and native value.
  • Intermediary contracts expand the trust surface.
  • A zero-value call can still grant powerful token authority.
  • No immediate transfer does not mean no economic risk.
  • Review spender identity and allowance size.
  • Revoke obsolete permissions when appropriate.
  • Unlimited approvals deserve explicit disclosure.
Study method
  1. 01

    Read the six-part technical chapter

  2. 02

    Inspect the unique visual and protocol model

  3. 03

    Work through the case file and evidence map

  4. 04

    Submit the written field exercise

  5. 05

    Pass the knowledge check and module lab

  6. 06

    Complete the timed final assessment

Evidence standard

Claims should be tied to observable fields, protocol behavior, primary references or clearly stated assumptions. Unknowns must remain explicit instead of being silently treated as safe.

Completion standard

Completion requires the written work, knowledge checks, all module labs and a final exam score of at least 80%. Professional level also requires the capstone.

Core glossary
The button label is not the transaction
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.
Destination and value are the first invariants
Before deeper analysis, establish which address receives native value, which contracts are called and which chain is active. Many attacks exploit chain switches, hidden value fields or unexpected intermediary contracts.
An approval delegates future spending authority
ERC-20 approval typically allows a spender contract to transfer tokens later up to an allowance. The approval transaction may move no tokens, yet it can create persistent authority that becomes exploitable later if the spender is malicious or compromised.
Unlimited approvals trade convenience for blast radius
Applications often request the maximum integer as an allowance so users do not approve repeatedly. That convenience means the spender can potentially move the entire future balance of that token while the approval remains valid.
Typed data is readable structure, but still authorization
EIP-712 gives signed data a typed structure and domain separator, improving display and replay resistance. It does not make a message safe. The fields can encode orders, permits or other rights that produce later on-chain effects.
Permit and Permit2 can move approval off-chain
Permit-style systems let a signature authorize token spending without a traditional approval transaction first. Permit2 can centralize allowance mechanics across tokens. The security question becomes who the spender is, what amount and deadline are granted, and which verifying contract enforces the signature.
Reconstruct intent from multiple independent fields
A useful pre-signature layer compares what the user intended with the origin, chain, destination, method, parameters, approvals and expected asset changes. No single field proves safety; consistency across independent signals increases confidence.
Risk scoring must end in an understandable decision
A score without evidence encourages automation bias. The useful output is a decision context: what is unusual, what authority is granted, what could be lost and which uncertainty remains. Final execution should remain explicit unless an organization has deliberately configured policy automation.
SPECIALIST EXTENSIONS

Modern protocol and operational topics

These extensions broaden the core curriculum with current standards and security boundaries that practitioners are expected to recognize.

Replay protection, nonces and domain separation
Specialist study unit01
EXT / 01

Replay protection, nonces and domain separation

Authorization must be scoped to the intended chain, contract, account state and lifetime. Transaction nonces, EIP-155 chain binding and EIP-712 domains reduce replay in different ways but still require correct application design.

Security focusnonce · chainId · domain separator · verifyingContract · replay window
Study taskRead the primary material, identify the trust boundary, and explain how the mechanism changes the authorization or execution model.
Required outputProduce a concise analyst note containing assumptions, material evidence, failure conditions and a justified security decision.
Primary referencesEIP-155 ↗EIP-712 ↗
ERC-4337 UserOperations and account abstraction
Specialist study unit02
EXT / 02

ERC-4337 UserOperations and account abstraction

UserOperations move validation into smart-account logic and introduce bundlers, EntryPoint, paymasters and simulation rules. Review therefore shifts from one transaction envelope to a larger validation and sponsorship pipeline.

Security focusUserOperation · EntryPoint · bundler · paymaster · validation simulation
Study taskRead the primary material, identify the trust boundary, and explain how the mechanism changes the authorization or execution model.
Required outputProduce a concise analyst note containing assumptions, material evidence, failure conditions and a justified security decision.
Primary referencesERC-4337 ↗
EIP-7702 delegated EOAs
Specialist study unit03
EXT / 03

EIP-7702 delegated EOAs

EIP-7702 lets an EOA persistently delegate code execution through signed authorization tuples. Review chain binding, nonce, delegate implementation, initialization and revocation because a weak delegate can greatly expand account authority.

Security focusauthorization tuple · delegated code · persistent delegation · nonce · revocation
Study taskRead the primary material, identify the trust boundary, and explain how the mechanism changes the authorization or execution model.
Required outputProduce a concise analyst note containing assumptions, material evidence, failure conditions and a justified security decision.
Primary referencesEIP-7702 ↗
Module 01

Transaction intent & calldata

Move from button labels to the actual destination, value and method encoded in the request.

Technical environment related to this course module
Lesson 1.1

The button label is not the transaction

22 min
UTXO ACADEMY / CONCEPT MODELCALLDATADECODE INTENTVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

The button label is not the transaction

Deep technical lesson
01
Mental model

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.

02
What actually happens

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.

selector

calldata[0:4]

arguments

ABI-decoded parameters

target

transaction.to

native value

transaction.value

nested execution

multicall / router subcalls

03
Failure surface

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.

  • UI intent != decoded method
  • unknown selector
  • unexpected recipient
  • hidden native value
  • nested call changes authority
04
Decision standard

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.

05
Verification procedure

Verify the request through independent evidence before irreversible authorization.

  1. 01

    capture exact payload

  2. 02

    resolve selector / ABI

  3. 03

    decode every material parameter

  4. 04

    trace nested calls when present

  5. 05

    compare decoded action with user intent

06
Required analyst output

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.

Required analyst outputdecoded-intent record + mismatch list
The button label is not the transaction
LESSON VISUALThe button label is not the transactioncalldata intent
The button label is not the transaction
REAL-WORLD CONTEXT · SIGNATURE REVIEW ENVIRONMENTThe button label is not the transactionCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / REQUEST FLOWcalldata-intent
N01N02N03N04N05N06REQUEST FLOWThe button label is not the transaction
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Decode the selector and parameters.

Mechanics
selectorcalldata[0:4]
argumentsABI-decoded parameters
targettransaction.to
native valuetransaction.value
nested executionmulticall / router subcalls
Failure signals
  1. 01

    UI intent != decoded method

  2. 02

    unknown selector

  3. 03

    unexpected recipient

  4. 04

    hidden native value

  5. 05

    nested call changes authority

Verification procedure
  1. 01

    capture exact payload

  2. 02

    resolve selector / ABI

  3. 03

    decode every material parameter

  4. 04

    trace nested calls when present

  5. 05

    compare decoded action with user intent

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverabledecoded-intent record + mismatch list
Protocol walkthrough

Follow the security decision path

calldata / intent
01Observe
  • selector: calldata[0:4]
  • arguments: ABI-decoded parameters
02Trace
  • target: transaction.to
  • native value: transaction.value
  • nested execution: multicall / router subcalls
03Challenge
  • UI intent != decoded method
  • unknown selector
  • unexpected recipient
04Verify
  • capture exact payload
  • resolve selector / ABI
  • decode every material parameter
05Output
  • decoded-intent record + mismatch list
Authority surfaceselector · arguments · target
Failure conditionUI intent != decoded method
Applied case file
decode-calldata
CASE / calldata-intent
ui ActionSwap 1 ETH
method Selector0x095ea7b3
decoded Methodapprove(address,uint256)
spender0xNew...
amountMAX_UINT256
native Value0
Analyst task

Before answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.

Evidence map

Organize before you decide

Separate identity, authority, execution and context before reaching a security decision.

01
Identity

Who or what is requesting, receiving or representing authority?

—
02
Authority

What capability can be granted, retained or exercised?

spender0xNew...
03
Execution

What will the payload, route or system actually do?

method Selector0x095ea7b3
decoded Methodapprove(address,uint256)
amountMAX_UINT256
native Value0
04
Context

Which surrounding facts can materially change the decision?

ui ActionSwap 1 ETH
Field exercise

Produce an analyst-ready finding

Local-only analyst record

Do not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.

Focusselector · arguments · target
Failure signalUI intent != decoded method
Verify firstcapture exact payload
Deliverabledecoded-intent record + mismatch list
Completion criteria
  • Cites material evidence, not UI appearance.
  • Names the authority, state transition or consequence.
  • Provides a reproducible next action or decision.
Security notes
  1. 01

    Decode the selector and parameters.

  2. 02

    Compare decoded action with stated user intent.

  3. 03

    Unknown calldata deserves more scrutiny, not blind confirmation.

Analyst notebook

Build your evidence memo

Local-only learning record

Record your reasoning before the checkpoint. Finish with an explicit decision or next action. Notes stay on this device.

LOCAL STORAGE
Field exercise

Develop all three sections before completion.

Lesson 1.2

Destination and value are the first invariants

16 min
UTXO ACADEMY / CONCEPT MODELVALUE / DESTINATIONFIRST INVARIANTSVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

Destination and value are the first invariants

Deep technical lesson
01
Mental model

Before deeper analysis, establish which address receives native value, which contracts are called and which chain is active. Many attacks exploit chain switches, hidden value fields or unexpected intermediary contracts.

This concept matters because Confirm chain, destination and native value.

Routers and intermediary contracts separate the visible call target from the entity that ultimately receives value or authority.

02
What actually happens

Confirm chain, top-level destination, native value and final value receiver.

At protocol and execution level, inspect chain and recipient and native value and token movement and intermediary. Protocol identifiers remain untranslated because they are part of the technical payload.

chain

chainId / network context

recipient

to / resolved destination

native value

msg.value / value

token movement

decoded transfer / transferFrom

intermediary

router / bridge / proxy

03
Failure surface

Wrong-chain or newly deployed intermediary contracts can redirect otherwise plausible transactions.

The practical consequence is that Intermediary contracts expand the trust surface. Unknown is not equivalent to safe.

  • chain switch
  • new destination
  • clipboard substitution
  • visible recipient != payload target
  • zero-value call grants authority
04
Decision standard

Do not proceed until value path and destination identity are explainable.

The practical consequence is that Intermediary contracts expand the trust surface.

Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.

05
Verification procedure

Verify the request through independent evidence before irreversible authorization.

  1. 01

    confirm chainId

  2. 02

    resolve full destination

  3. 03

    inspect native value

  4. 04

    decode token movements

  5. 05

    verify intermediary purpose

06
Required analyst output

Record the facts, assumptions, unknowns and decision so another analyst can reproduce the review.

Confirm chain, destination and native value. and A zero-value call can still grant powerful token authority.

Required analyst outputdestination-integrity record
Destination and value are the first invariants
LESSON VISUALDestination and value are the first invariantsvalue destination
Destination and value are the first invariants
REAL-WORLD CONTEXT · SIGNATURE REVIEW ENVIRONMENTDestination and value are the first invariantsCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / INCIDENT TIMELINEvalue-destination
N01N02N03N04N05N06INCIDENT TIMELINEDestination and value are the first invariants
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Confirm chain, destination and native value.

Mechanics
chainchainId / network context
recipientto / resolved destination
native valuemsg.value / value
token movementdecoded transfer / transferFrom
intermediaryrouter / bridge / proxy
Failure signals
  1. 01

    chain switch

  2. 02

    new destination

  3. 03

    clipboard substitution

  4. 04

    visible recipient != payload target

  5. 05

    zero-value call grants authority

Verification procedure
  1. 01

    confirm chainId

  2. 02

    resolve full destination

  3. 03

    inspect native value

  4. 04

    decode token movements

  5. 05

    verify intermediary purpose

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverabledestination-integrity record
Protocol walkthrough

Follow the security decision path

value / destination
01Observe
  • chain: chainId / network context
  • recipient: to / resolved destination
02Trace
  • native value: msg.value / value
  • token movement: decoded transfer / transferFrom
  • intermediary: router / bridge / proxy
03Challenge
  • chain switch
  • new destination
  • clipboard substitution
04Verify
  • confirm chainId
  • resolve full destination
  • inspect native value
05Output
  • destination-integrity record
Authority surfacechain · recipient · native value
Failure conditionchain switch
Applied case file
first-invariants
CASE / value-destination
chainArbitrum
ui ChainEthereum
native Value0.3 ETH
top Level To0xRouter...
final Recipientunknown
contract Age2 hours
Analyst task

Before answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.

Evidence map

Organize before you decide

Separate identity, authority, execution and context before reaching a security decision.

01
Identity

Who or what is requesting, receiving or representing authority?

final Recipientunknown
02
Authority

What capability can be granted, retained or exercised?

—
03
Execution

What will the payload, route or system actually do?

native Value0.3 ETH
04
Context

Which surrounding facts can materially change the decision?

chainArbitrum
ui ChainEthereum
top Level To0xRouter...
contract Age2 hours
Field exercise

Produce an analyst-ready finding

Local-only analyst record

Do not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.

Focuschain · recipient · native value
Failure signalchain switch
Verify firstconfirm chainId
Deliverabledestination-integrity record
Completion criteria
  • Cites material evidence, not UI appearance.
  • Names the authority, state transition or consequence.
  • Provides a reproducible next action or decision.
Security notes
  1. 01

    Confirm chain, destination and native value.

  2. 02

    Intermediary contracts expand the trust surface.

  3. 03

    A zero-value call can still grant powerful token authority.

Analyst notebook

Build your evidence memo

Local-only learning record

Record your reasoning before the checkpoint. Finish with an explicit decision or next action. Notes stay on this device.

LOCAL STORAGE
Field exercise

Develop all three sections before completion.

Practical lab locked

Pass both lesson knowledge checks in this module before attempting the practical lab.

Module 02

Token approvals & spend authority

Understand how approvals create persistent authority that can outlive the transaction that created them.

Module locked

Complete the previous module, including its practical lab, before continuing.

Module 03

EIP-712, Permit & Permit2

Read typed-data signatures as authorization objects, not harmless off-chain messages.

Operational security environment related to this course module
Module locked

Complete the previous module, including its practical lab, before continuing.

Module 04

Intent reconstruction & decision

Combine origin, payload, authority and context into a decision the user can understand before signing.

Module locked

Complete the previous module, including its practical lab, before continuing.

Final examination

Final examination

This is a cumulative assessment. Questions are rebuilt from the course concepts and practical scenarios on every attempt.

You must score at least 80% to pass. Completing theory alone does not issue a credential.

Passing score80%
Best score0%
Bank52
Attempt20
Attempts0
Time limit35 min
Final examination
UTXO ACADEMY / FINAL EXAMINATION · understand-signingFinal examination
LOCKEDComplete every lesson checkpoint and every practical lab before the final examination unlocks.
Progress · 0%
Continue