UTXOSUITE — home
← Back to Academy
LEVEL 4 · Professional

Advanced Transaction Security

Study proxies, simulation limits, bridges and policy controls used in high-value transaction review.

8 lessons · 8 Field exercise · 8 Practical scenarios · 20 question · 80% passing score
Start learning0% · 0/21
Professional track. The curriculum is visible; commercial access control can be connected to UTXO billing without changing the course engine.

What you will be able to do

Trace execution through upgradeable contracts and delegatecall instead of trusting the visible proxy address.

Use simulation as evidence while understanding block-state, timing and conditional-execution divergence.

Model the additional validators, relayers, bridges and wrapped-asset assumptions introduced by cross-chain execution.

Turn security principles into deterministic controls for amounts, destinations, approvals and authorization paths.

Curriculum

1.1 · A proxy address is not the whole contract26 min
1.2 · Delegatecall executes foreign code in local state24 min
Lab · Resolve execution context

This course includes

  • 8 lessons · 20 guided hours
  • 4 Lab · Practical scenarios
  • 8 Applied case files · 8 Knowledge checks
  • 52 Item exam bank · 80% pass mark
  • Completion credential: UTXO Certified · Advanced Transaction Security

What this course expects of you

  • Review complex execution paths without trusting one signal.
  • Passing score: 80%
  • Understand What You Sign
Course briefing

Training contract

Review complex execution paths without trusting one signal.

01 · Target capabilityReview complex execution paths without trusting one signal.
02 · Recommended prerequisiteUnderstand What You Sign
Practical deliverables
01

Proxies & execution context

Trace execution through upgradeable contracts and delegatecall instead of trusting the visible proxy address.

Evidence memo · PROXY
02

Simulation & its limits

Use simulation as evidence while understanding block-state, timing and conditional-execution divergence.

Evidence memo · SIMULATION
03

Cross-chain trust & routing

Model the additional validators, relayers, bridges and wrapped-asset assumptions introduced by cross-chain execution.

Evidence memo · BRIDGE
04

Transaction policy controls

Turn security principles into deterministic controls for amounts, destinations, approvals and authorization paths.

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

Advanced Transaction Security

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

Guided study load20h
modules4
lessons8
01

Proxies & execution context

Trace execution through upgradeable contracts and delegatecall instead of trusting the visible proxy address.

1.1
A proxy address is not the whole contract45 min · Deep technical lesson
1.2
Delegatecall executes foreign code in local state45 min · Deep technical lesson
Module practical labResolve execution context
02

Simulation & its limits

Use simulation as evidence while understanding block-state, timing and conditional-execution divergence.

2.1
Simulation is a model of one possible execution45 min · Deep technical lesson
2.2
Execution can diverge from simulation45 min · Deep technical lesson
Module practical labChallenge the simulation
03

Cross-chain trust & routing

Model the additional validators, relayers, bridges and wrapped-asset assumptions introduced by cross-chain execution.

3.1
A bridge adds a new security system45 min · Deep technical lesson
3.2
More hops mean more independent failure modes45 min · Deep technical lesson
Module practical labReview the cross-chain route
04

Transaction policy controls

Turn security principles into deterministic controls for amounts, destinations, approvals and authorization paths.

4.1
Policies convert principles into enforceable conditions45 min · Deep technical lesson
4.2
Authorization should match consequence45 min · Deep technical lesson
Module practical labApply treasury policy
Competencies
  • Resolve the active implementation.
  • Identify who can upgrade it.
  • Trace delegatecall paths when reviewing critical execution.
  • Storage layout and implementation code both matter.
  • Record the state and assumptions used for simulation.
  • Compare predicted asset changes with user intent.
  • Ask what can change before execution.
  • Watch for time, block and mutable-state conditions.
  • Identify who attests to cross-chain events.
  • Understand custody or mint/burn assumptions.
  • Enumerate every contract and trust boundary in the route.
  • Scope approvals to the route where possible.
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 · 40 min
COURSE HANDBOOK

Scope, outcomes and study standard

20h
Who this is for

Study proxies, simulation limits, bridges and policy controls used in high-value transaction review.

Prerequisites

Recommended prior study

  • Wallet Security & Self-Custody
  • Understand What You Sign
Learning outcomes
  • Resolve the active implementation.
  • Identify who can upgrade it.
  • Treat upgradeability as an ongoing trust assumption.
  • Trace delegatecall paths when reviewing critical execution.
  • Storage layout and implementation code both matter.
  • Proxy safety cannot be inferred from address reputation alone.
  • Record the state and assumptions used for simulation.
  • Compare predicted asset changes with user intent.
  • Simulation is evidence, not an oracle.
  • Ask what can change before execution.
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
A proxy address is not the whole contract
Upgradeable proxy patterns store state at one address while delegating logic to an implementation that can change. Reviewing only the proxy's verified surface can miss the current implementation, upgrade authority or initialization risks.
Delegatecall executes foreign code in local state
Delegatecall runs another contract's code while preserving the caller's storage and execution context. This is powerful for proxies and modular systems but means the apparent callee and the actual code path can differ substantially.
Simulation is a model of one possible execution
Transaction simulation executes a candidate payload against a chosen state snapshot and environment. It is extremely useful for predicted balance and state changes, but its result is conditioned on the block state, RPC fidelity, external calls and environmental values used during simulation.
Execution can diverge from simulation
Contracts can branch on mutable storage, block values, external state or other conditions that change between simulation and inclusion. Adversarial code may deliberately exploit those differences. Independent static/context analysis therefore remains valuable even when simulation looks clean.
A bridge adds a new security system
Moving value across chains generally introduces validators, relayers, light-client logic, liquidity providers or wrapped representations. The destination asset may therefore depend on a security model that differs from both source and destination chains.
More hops mean more independent failure modes
A routed swap can traverse aggregators, DEXs, bridges and destination contracts. Each hop can be individually correct while the end-to-end path introduces slippage, approval, trust or availability risk. Review the route as a composed system.
Policies convert principles into enforceable conditions
A transaction policy can require review for new destinations, cap amounts, forbid unlimited approvals or demand a second approver. Good policies use deterministic facts and clear exceptions so operators know why an action was stopped.
Authorization should match consequence
Low-value routine actions and six-figure treasury transfers should not share identical approval paths. Risk-based controls can require independent review, allowlists, time delays or hardware signing based on amount, destination novelty and permission scope.
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.

Wallet execution permissions and ERC-7715
Specialist study unit01
EXT / 01

Wallet execution permissions and ERC-7715

Permission requests can authorize another account or session to act under explicit rules. Allowance, expiry, target and permitted behavior form a policy object whose scope must be understandable before consent.

Security focuspermission type · rules · expiry · allowance · delegated session authority
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-7715 ↗
MEV, ordering and transaction exposure
Specialist study unit02
EXT / 02

MEV, ordering and transaction exposure

Transaction safety also depends on where and when a valid request enters the ordering pipeline. Learn frontrunning, sandwich risk, private orderflow and how ordering can alter outcomes without changing the signed payload.

Security focusmempool exposure · ordering · frontrunning · sandwiching · private submission
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 referencesEthereum MEV docs ↗
L2 sequencers, data availability and finality states
Specialist study unit03
EXT / 03

L2 sequencers, data availability and finality states

Rollups add sequencing, data publication and settlement states between intent and finality. Distinguish unsafe, safe and finalized states, sequencer outage/censorship assumptions and the actual data-availability layer.

Security focussequencer · unsafe/safe/finalized · data availability · forced inclusion · L1 settlement
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 referencesOP Stack components ↗OP transaction finality ↗
Module 01

Proxies & execution context

Trace execution through upgradeable contracts and delegatecall instead of trusting the visible proxy address.

Technical environment related to this course module
Lesson 1.1

A proxy address is not the whole contract

26 min
UTXO ACADEMY / CONCEPT MODELPROXYRESOLVE IMPLEMENTATIONVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

A proxy address is not the whole contract

Deep technical lesson
01
Mental model

Upgradeable proxy patterns store state at one address while delegating logic to an implementation that can change. Reviewing only the proxy's verified surface can miss the current implementation, upgrade authority or initialization risks.

This concept matters because Resolve the active implementation.

A proxy preserves address/state while executable logic can change behind it.

02
What actually happens

Resolve current implementation, verification state, upgrade admin and timelock.

At protocol and execution level, inspect proxy and implementation and admin and storage and upgrade path. Protocol identifiers remain untranslated because they are part of the technical payload.

proxy

user-facing state address

implementation

delegated logic

admin

upgrade authority

storage

proxy state layout

upgrade path

logic can change after review

03
Failure surface

A previously reviewed address can execute newly upgraded logic controlled by a single compromised admin.

The practical consequence is that Identify who can upgrade it. Unknown is not equivalent to safe.

  • proxy verified / implementation unknown
  • admin untrusted
  • recent implementation change
  • initialization ambiguity
  • upgradeable spender
04
Decision standard

Treat implementation and upgrade authority as first-class evidence for critical calls.

The practical consequence is that Identify who can upgrade it.

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

    identify proxy pattern

  2. 02

    read implementation slot / resolver

  3. 03

    verify implementation code

  4. 04

    identify admin / timelock

  5. 05

    record upgradeability as ongoing trust

06
Required analyst output

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

Resolve the active implementation. and Treat upgradeability as an ongoing trust assumption.

Required analyst outputproxy trust-boundary map
A proxy address is not the whole contract
LESSON VISUALA proxy address is not the whole contractproxy upgradeability
A proxy address is not the whole contract
REAL-WORLD CONTEXT · PROXY & EXECUTION ARCHITECTUREA proxy address is not the whole contractCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / STATE GRAPHproxy-upgradeability
N01N02N03N04N05N06STATE GRAPHA proxy address is not the whole contract
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Resolve the active implementation.

Mechanics
proxyuser-facing state address
implementationdelegated logic
adminupgrade authority
storageproxy state layout
upgrade pathlogic can change after review
Failure signals
  1. 01

    proxy verified / implementation unknown

  2. 02

    admin untrusted

  3. 03

    recent implementation change

  4. 04

    initialization ambiguity

  5. 05

    upgradeable spender

Verification procedure
  1. 01

    identify proxy pattern

  2. 02

    read implementation slot / resolver

  3. 03

    verify implementation code

  4. 04

    identify admin / timelock

  5. 05

    record upgradeability as ongoing trust

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverableproxy trust-boundary map
Protocol walkthrough

Follow the security decision path

proxy / upgradeability
01Observe
  • proxy: user-facing state address
  • implementation: delegated logic
02Trace
  • admin: upgrade authority
  • storage: proxy state layout
  • upgrade path: logic can change after review
03Challenge
  • proxy verified / implementation unknown
  • admin untrusted
  • recent implementation change
04Verify
  • identify proxy pattern
  • read implementation slot / resolver
  • verify implementation code
05Output
  • proxy trust-boundary map
Authority surfaceproxy · implementation · admin
Failure conditionproxy verified / implementation unknown
Applied case file
proxy-review
CASE / proxy-upgradeability
proxyverified
implementation0xImplV7
implementation Verifiedyes
upgrade Adminsingle EOA
last Upgrade2 days ago
timelocknone
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?

upgrade Adminsingle EOA
03
Execution

What will the payload, route or system actually do?

proxyverified
implementation0xImplV7
implementation Verifiedyes
04
Context

Which surrounding facts can materially change the decision?

last Upgrade2 days ago
timelocknone
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.

Focusproxy · implementation · admin
Failure signalproxy verified / implementation unknown
Verify firstidentify proxy pattern
Deliverableproxy trust-boundary map
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

    Resolve the active implementation.

  2. 02

    Identify who can upgrade it.

  3. 03

    Treat upgradeability as an ongoing trust assumption.

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

Delegatecall executes foreign code in local state

24 min
UTXO ACADEMY / CONCEPT MODELDELEGATECALLCODE / STORAGE CONTEXTVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

Delegatecall executes foreign code in local state

Deep technical lesson
01
Mental model

Delegatecall runs another contract's code while preserving the caller's storage and execution context. This is powerful for proxies and modular systems but means the apparent callee and the actual code path can differ substantially.

This concept matters because Trace delegatecall paths when reviewing critical execution.

delegatecall runs external code in the caller's storage and execution context.

02
What actually happens

Trace every delegatecall target and determine whose storage is mutated.

At protocol and execution level, inspect opcode and code source and storage context and msg.sender / value and risk. Protocol identifiers remain untranslated because they are part of the technical payload.

opcode

DELEGATECALL

code source

callee implementation

storage context

caller storage

msg.sender / value

preserved call context

risk

foreign code mutates local state

03
Failure surface

Reviewing only the entry contract misses the code that actually controls state changes.

The practical consequence is that Storage layout and implementation code both matter. Unknown is not equivalent to safe.

  • unexpected delegatecall
  • implementation not verified
  • storage collision risk
  • privileged method reachable
  • dynamic implementation selection
04
Decision standard

Require verified implementation paths for high-impact delegatecall execution.

The practical consequence is that Storage layout and implementation code both matter.

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

    identify delegatecall edge

  2. 02

    resolve callee code

  3. 03

    map caller storage context

  4. 04

    trace privileged effects

  5. 05

    compare reachable authority to intent

06
Required analyst output

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

Trace delegatecall paths when reviewing critical execution. and Proxy safety cannot be inferred from address reputation alone.

Required analyst outputdelegatecall execution trace
Delegatecall executes foreign code in local state
LESSON VISUALDelegatecall executes foreign code in local statedelegatecall context
Delegatecall executes foreign code in local state
REAL-WORLD CONTEXT · PROXY & EXECUTION ARCHITECTUREDelegatecall executes foreign code in local stateCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / STATE GRAPHdelegatecall-context
N01N02N03N04N05N06STATE GRAPHDelegatecall executes foreign code in local state
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Trace delegatecall paths when reviewing critical execution.

Mechanics
opcodeDELEGATECALL
code sourcecallee implementation
storage contextcaller storage
msg.sender / valuepreserved call context
riskforeign code mutates local state
Failure signals
  1. 01

    unexpected delegatecall

  2. 02

    implementation not verified

  3. 03

    storage collision risk

  4. 04

    privileged method reachable

  5. 05

    dynamic implementation selection

Verification procedure
  1. 01

    identify delegatecall edge

  2. 02

    resolve callee code

  3. 03

    map caller storage context

  4. 04

    trace privileged effects

  5. 05

    compare reachable authority to intent

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverabledelegatecall execution trace
Protocol walkthrough

Follow the security decision path

delegatecall / context
01Observe
  • opcode: DELEGATECALL
  • code source: callee implementation
02Trace
  • storage context: caller storage
  • msg.sender / value: preserved call context
  • risk: foreign code mutates local state
03Challenge
  • unexpected delegatecall
  • implementation not verified
  • storage collision risk
04Verify
  • identify delegatecall edge
  • resolve callee code
  • map caller storage context
05Output
  • delegatecall execution trace
Authority surfaceopcode · code source · storage context
Failure conditionunexpected delegatecall
Applied case file
delegate-path
CASE / delegatecall-context
entryproxy
methodexecute(bytes)
delegatecallfacet 0xF...
storageproxy
calleruser wallet
facet Verifiedno
value0 ETH
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?

—
03
Execution

What will the payload, route or system actually do?

methodexecute(bytes)
delegatecallfacet 0xF...
storageproxy
calleruser wallet
value0 ETH
04
Context

Which surrounding facts can materially change the decision?

entryproxy
facet Verifiedno
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.

Focusopcode · code source · storage context
Failure signalunexpected delegatecall
Verify firstidentify delegatecall edge
Deliverabledelegatecall execution trace
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

    Trace delegatecall paths when reviewing critical execution.

  2. 02

    Storage layout and implementation code both matter.

  3. 03

    Proxy safety cannot be inferred from address reputation alone.

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

Simulation & its limits

Use simulation as evidence while understanding block-state, timing and conditional-execution divergence.

Module locked

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

Module 03

Cross-chain trust & routing

Model the additional validators, relayers, bridges and wrapped-asset assumptions introduced by cross-chain execution.

Operational security environment related to this course module
Module locked

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

Module 04

Transaction policy controls

Turn security principles into deterministic controls for amounts, destinations, approvals and authorization paths.

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 limit40 min
Final examination
UTXO ACADEMY / FINAL EXAMINATION · advanced-securityFinal examination
LOCKEDComplete every lesson checkpoint and every practical lab before the final examination unlocks.
Progress · 0%
Continue