UTXOSUITE — home
← Back to Academy
LEVEL 5 · Professional

Web3 Security Professional

Combine incident response, treasury controls, threat modelling and integration design in a full security workflow.

8 lessons · 8 Field exercise · 8 Practical scenarios · 1 PROFESSIONAL CAPSTONE · 20 question · 80% passing score
Start learning0% · 0/22
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

Triage suspicious signatures and sessions before panic causes more damage or evidence is lost.

Design high-value operations so one compromised browser, operator or wallet cannot independently move everything.

Identify trust boundaries across browser, RPC, wallet, routers and external protocols before adding controls.

Combine every layer of evidence into a documented allow, warn, block or review decision.

Curriculum

1.1 · First determine what authority may have been granted30 min
1.2 · Containment and evidence need to happen together28 min
Lab · Triage the incident

This course includes

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

What this course expects of you

  • Produce a defensible security decision from incomplete evidence.
  • Passing score: 80%
  • Advanced Transaction Security
Course briefing

Training contract

Produce a defensible security decision from incomplete evidence.

01 · Target capabilityProduce a defensible security decision from incomplete evidence.
02 · Recommended prerequisiteAdvanced Transaction Security
Practical deliverables
01

Incident response for wallets

Triage suspicious signatures and sessions before panic causes more damage or evidence is lost.

Evidence memo · INCIDENT
02

Treasury separation & authorization

Design high-value operations so one compromised browser, operator or wallet cannot independently move everything.

Evidence memo · POLICY
03

Threat modelling wallet integrations

Identify trust boundaries across browser, RPC, wallet, routers and external protocols before adding controls.

Evidence memo · THREAT-MODEL
04

Capstone: transaction security review

Combine every layer of evidence into a documented allow, warn, block or review decision.

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

Web3 Security Professional

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

Guided study load24h
modules4
lessons8
01

Incident response for wallets

Triage suspicious signatures and sessions before panic causes more damage or evidence is lost.

1.1
First determine what authority may have been granted45 min · Deep technical lesson
1.2
Containment and evidence need to happen together45 min · Deep technical lesson
Module practical labTriage the incident
02

Treasury separation & authorization

Design high-value operations so one compromised browser, operator or wallet cannot independently move everything.

2.1
Separate holdings by purpose and blast radius45 min · Deep technical lesson
2.2
High-value authorization is a system, not a person45 min · Deep technical lesson
Module practical labApply treasury policy
03

Threat modelling wallet integrations

Identify trust boundaries across browser, RPC, wallet, routers and external protocols before adding controls.

3.1
Map trust boundaries before selecting controls45 min · Deep technical lesson
3.2
Security integrations should fail predictably45 min · Deep technical lesson
Module practical labMap the trust boundaries
04

Capstone: transaction security review

Combine every layer of evidence into a documented allow, warn, block or review decision.

4.1
Complex cases require evidence synthesis45 min · Deep technical lesson
4.2
No single detector should be your security boundary45 min · Deep technical lesson
Module practical labMake the final security decision
Competencies
  • Preserve the suspicious payload and transaction hashes.
  • Check approvals and sessions before assuming the incident is over.
  • Prioritize stopping active loss while preserving key evidence.
  • Do not rely on screenshots alone when raw hashes and payloads exist.
  • Separate hot operations from reserves.
  • Keep only necessary balances exposed to DeFi permissions.
  • Require independent authority for critical actions.
  • Make policy state observable and auditable.
  • List assets and authority before threats.
  • Model compromised dependencies, not only malicious users.
  • Define degraded modes explicitly.
  • Distinguish unavailable evidence from safe evidence.
Assessment path
  1. Written field exercise × 8
  2. Knowledge checks × 8
  3. Module practical lab × 4
  4. Timed final exam · 20 · ≥ 80%
  5. Capstone · 90 min
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 · 45 min
  6. Capstone · 90 min
COURSE HANDBOOK

Scope, outcomes and study standard

24h
Who this is for

Combine incident response, treasury controls, threat modelling and integration design in a full security workflow.

Prerequisites

Recommended prior study

  • Understand What You Sign
  • Advanced Transaction Security
Learning outcomes
  • Preserve the suspicious payload and transaction hashes.
  • Check approvals and sessions before assuming the incident is over.
  • Use a known-clean environment for remediation where possible.
  • Prioritize stopping active loss while preserving key evidence.
  • Do not rely on screenshots alone when raw hashes and payloads exist.
  • Document every remediation action.
  • Separate hot operations from reserves.
  • Keep only necessary balances exposed to DeFi permissions.
  • Design transfer paths between tiers deliberately.
  • Require independent authority for critical actions.
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
First determine what authority may have been granted
After a suspicious signature, start by identifying the signed payload, active approvals, connected sessions and whether assets have moved. Do not immediately destroy evidence or sign more messages from the possibly compromised context.
Containment and evidence need to happen together
Revoking approvals, disconnecting sessions and moving assets may be necessary, but remediation actions can also erase useful context. Record addresses, timestamps, domains, signatures and device indicators so the root cause can be understood later.
Separate holdings by purpose and blast radius
Treasury design should avoid one wallet holding operational liquidity, long-term reserves and every approval. Segmentation limits the maximum loss from a single compromised signer, browser session or protocol allowance.
High-value authorization is a system, not a person
Multisig, role separation, spend limits and destination allowlists reduce dependence on one operator. The goal is not bureaucracy; it is to ensure no single compromised component can silently satisfy every condition required to move critical value.
Map trust boundaries before selecting controls
A wallet-integrated application may trust browser code, RPC providers, routers, token contracts and wallet UX simultaneously. Threat modelling enumerates assets, actors, boundaries and abuse cases so controls address actual paths instead of generic fear.
Security integrations should fail predictably
A pre-execution security component must define what happens when simulation, reputation data or remote intelligence is unavailable. Silent allow-by-default can be dangerous, while unconditional blocking destroys usability. Failure policy should match transaction value and certainty.
Complex cases require evidence synthesis
Real incidents rarely present one perfect malicious indicator. Analysts combine origin age, approvals, proxy structure, simulation output, contract verification and user intent. Contradictions are not noise; they are often the most important signal.
No single detector should be your security boundary
Domain reputation, simulation, static decoding, policy and user confirmation each catch different failures. Defense in depth deliberately assumes that one layer can be wrong and still prevents a silent path to irreversible execution.
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.

Threshold signing and distributed key authority
Specialist study unit01
EXT / 01

Threshold signing and distributed key authority

Threshold schemes distribute a signing primitive across parties without reconstructing one ordinary private key during normal operation. Security still depends on participant threshold, protocol implementation, share backup and correlated-compromise assumptions.

Security focussecret shares · threshold · DKG · signing rounds · correlated compromise
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 referencesNIST IR 8214C ↗
Multisig governance beyond M-of-N
Specialist study unit02
EXT / 02

Multisig governance beyond M-of-N

An M-of-N threshold is only one part of treasury security. Owner independence, modules, guards, payload review, role separation, signer replacement and change control determine whether multiple signatures are truly independent decisions.

Security focusowners · threshold · modules · guards · independent review · change control
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 referencesSafe Smart Account concepts ↗
Key rotation, recovery and continuity drills
Specialist study unit03
EXT / 03

Key rotation, recovery and continuity drills

Key management is a lifecycle, not a one-time setup. Build rotation, replacement, emergency access and recovery drills that preserve control without creating an unmonitored bypass around ordinary authorization policy.

Security focusrotation · compromise response · recovery authority · continuity · tested runbooks
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 referencesNIST SP 800-57 Pt1 Rev5 ↗Safe recovery guidance ↗
Module 01

Incident response for wallets

Triage suspicious signatures and sessions before panic causes more damage or evidence is lost.

Lesson 1.1

First determine what authority may have been granted

30 min
UTXO ACADEMY / CONCEPT MODELINCIDENT TRIAGEAUTHORITY FIRSTVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

First determine what authority may have been granted

Deep technical lesson
01
Mental model

After a suspicious signature, start by identifying the signed payload, active approvals, connected sessions and whether assets have moved. Do not immediately destroy evidence or sign more messages from the possibly compromised context.

This concept matters because Preserve the suspicious payload and transaction hashes.

Triage determines what authority may exist and whether losses are ongoing before remediation changes the scene.

02
What actually happens

Preserve URL, timestamp, signature, active approvals, sessions and asset movement evidence first.

At protocol and execution level, inspect detect and scope and contain and preserve and prioritize. Protocol identifiers remain untranslated because they are part of the technical payload.

detect

identify suspicious event

scope

what accounts/sessions/approvals affected

contain

stop further authority

preserve

retain evidence

prioritize

assets at immediate risk first

03
Failure surface

Panic signing, revoking from the same compromised device or deleting sessions can destroy useful evidence or deepen compromise.

The practical consequence is that Check approvals and sessions before assuming the incident is over. Unknown is not equivalent to safe.

  • panic transactions
  • evidence deleted
  • wallet remains connected
  • active approvals unknown
  • compromised device reused
04
Decision standard

Stabilize, preserve evidence and move response to a known-clean environment.

The practical consequence is that Check approvals and sessions before assuming the incident is over.

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

    freeze risky activity

  2. 02

    capture transaction/signature evidence

  3. 03

    disconnect sessions

  4. 04

    enumerate approvals/assets

  5. 05

    choose containment actions by exposure

06
Required analyst output

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

Preserve the suspicious payload and transaction hashes. and Use a known-clean environment for remediation where possible.

Required analyst outputincident triage worksheet
First determine what authority may have been granted
LESSON VISUALFirst determine what authority may have been grantedincident triage
First determine what authority may have been granted
REAL-WORLD CONTEXT · INCIDENT RESPONSE ENVIRONMENTFirst determine what authority may have been grantedCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / POLICY MATRIXincident-triage
N01N02N03N04N05N06POLICY MATRIXFirst determine what authority may have been granted
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Preserve the suspicious payload and transaction hashes.

Mechanics
detectidentify suspicious event
scopewhat accounts/sessions/approvals affected
containstop further authority
preserveretain evidence
prioritizeassets at immediate risk first
Failure signals
  1. 01

    panic transactions

  2. 02

    evidence deleted

  3. 03

    wallet remains connected

  4. 04

    active approvals unknown

  5. 05

    compromised device reused

Verification procedure
  1. 01

    freeze risky activity

  2. 02

    capture transaction/signature evidence

  3. 03

    disconnect sessions

  4. 04

    enumerate approvals/assets

  5. 05

    choose containment actions by exposure

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverableincident triage worksheet
Protocol walkthrough

Follow the security decision path

incident / triage
01Observe
  • detect: identify suspicious event
  • scope: what accounts/sessions/approvals affected
02Trace
  • contain: stop further authority
  • preserve: retain evidence
  • prioritize: assets at immediate risk first
03Challenge
  • panic transactions
  • evidence deleted
  • wallet remains connected
04Verify
  • freeze risky activity
  • capture transaction/signature evidence
  • disconnect sessions
05Output
  • incident triage worksheet
Authority surfacedetect · scope · contain
Failure conditionpanic transactions
Balancer linear-pool vulnerability triage
DOCUMENTED CASE STUDY · 2023-08-22Balancer linear-pool vulnerability triage
Documented case study

Balancer linear-pool vulnerability triage

On 22 August 2023 Balancer disclosed a critical vulnerability affecting some pools. Its Emergency SubDAO had mitigated more than 80% of affected liquidity, enabled proportional exits and urged users in remaining at-risk pools to withdraw.

Verified facts
findingcritical vulnerability in selected pools
mitigationmore than 80% of affected liquidity
emergency actionpause + proportional exit
remaining exposureapproximately 4% of Balancer TVL at disclosure
Operational lesson

Incident response starts before exploitation when credible evidence exists. Asset classification, emergency authority, user-specific exposure and a safe exit path materially change the blast radius.

Analyst question

What evidence threshold should trigger emergency controls, and how would you separate mitigated, pausable and still-at-risk assets in the first response hour?

Primary sourceBalancer — Vulnerability found in some pools ↗
Applied case file
first-response
CASE / incident-triage
eventunexpected Permit2 signature
assets Movedunknown
wallet Connectedyes
device Compromisepossible
approvalsnot enumerated
evidenceURL + timestamp + signature available
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?

wallet Connectedyes
02
Authority

What capability can be granted, retained or exercised?

approvalsnot enumerated
03
Execution

What will the payload, route or system actually do?

—
04
Context

Which surrounding facts can materially change the decision?

eventunexpected Permit2 signature
assets Movedunknown
device Compromisepossible
evidenceURL + timestamp + signature available
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.

Focusdetect · scope · contain
Failure signalpanic transactions
Verify firstfreeze risky activity
Deliverableincident triage worksheet
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

    Preserve the suspicious payload and transaction hashes.

  2. 02

    Check approvals and sessions before assuming the incident is over.

  3. 03

    Use a known-clean environment for remediation where possible.

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

Containment and evidence need to happen together

28 min
UTXO ACADEMY / CONCEPT MODELCONTAIN + PRESERVEEVIDENCEVISUAL AID · NOT A SECURITY VERDICT
Technical chapter

Containment and evidence need to happen together

Deep technical lesson
01
Mental model

Revoking approvals, disconnecting sessions and moving assets may be necessary, but remediation actions can also erase useful context. Record addresses, timestamps, domains, signatures and device indicators so the root cause can be understood later.

This concept matters because Prioritize stopping active loss while preserving key evidence.

Containment reduces ongoing authority while evidence collection maintains a reproducible incident timeline.

02
What actually happens

Separate active-loss controls from forensic preservation tasks.

At protocol and execution level, inspect session revoke and approval revoke and asset migration and forensics and communication. Protocol identifiers remain untranslated because they are part of the technical payload.

session revoke

remove connected authority

approval revoke

remove token spend authority

asset migration

move to uncompromised keys

forensics

preserve logs/hash/timestamps

communication

coordinate without leaking secrets

03
Failure surface

Aggressive cleanup without records prevents root-cause analysis; slow containment can allow further loss.

The practical consequence is that Do not rely on screenshots alone when raw hashes and payloads exist. Unknown is not equivalent to safe.

  • revoke from compromised device without plan
  • move assets before understanding attacker
  • no evidence timestamps
  • seed exposed during support
  • containment actions conflict
04
Decision standard

Prioritize active loss prevention while logging every remediation step.

The practical consequence is that Do not rely on screenshots alone when raw hashes and payloads exist.

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

    preserve evidence first where safe

  2. 02

    rank active authority

  3. 03

    revoke sessions/approvals

  4. 04

    migrate keys/assets if needed

  5. 05

    record every containment action

06
Required analyst output

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

Prioritize stopping active loss while preserving key evidence. and Document every remediation action.

Required analyst outputcontainment timeline + evidence bundle
Containment and evidence need to happen together
LESSON VISUALContainment and evidence need to happen togethercontainment evidence
Containment and evidence need to happen together
REAL-WORLD CONTEXT · INCIDENT RESPONSE ENVIRONMENTContainment and evidence need to happen togetherCONCEPT → REAL ENVIRONMENT → OPERATIONAL DECISION
VISUAL MODEL / INCIDENT TIMELINEcontainment-evidence
N01N02N03N04N05N06INCIDENT TIMELINEContainment and evidence need to happen together
CONCEPT → EVIDENCE → FAILURE MODE → VERIFICATION
Technical workbook

Analyst objective

Prioritize stopping active loss while preserving key evidence.

Mechanics
session revokeremove connected authority
approval revokeremove token spend authority
asset migrationmove to uncompromised keys
forensicspreserve logs/hash/timestamps
communicationcoordinate without leaking secrets
Failure signals
  1. 01

    revoke from compromised device without plan

  2. 02

    move assets before understanding attacker

  3. 03

    no evidence timestamps

  4. 04

    seed exposed during support

  5. 05

    containment actions conflict

Verification procedure
  1. 01

    preserve evidence first where safe

  2. 02

    rank active authority

  3. 03

    revoke sessions/approvals

  4. 04

    migrate keys/assets if needed

  5. 05

    record every containment action

Reasoning chain
  1. 01

    facts → material evidence

  2. 02

    evidence → consequence / authority

  3. 03

    consequence → explicit decision + next action

Required deliverablecontainment timeline + evidence bundle
Protocol walkthrough

Follow the security decision path

containment / evidence
01Observe
  • session revoke: remove connected authority
  • approval revoke: remove token spend authority
02Trace
  • asset migration: move to uncompromised keys
  • forensics: preserve logs/hash/timestamps
  • communication: coordinate without leaking secrets
03Challenge
  • revoke from compromised device without plan
  • move assets before understanding attacker
  • no evidence timestamps
04Verify
  • preserve evidence first where safe
  • rank active authority
  • revoke sessions/approvals
05Output
  • containment timeline + evidence bundle
Authority surfacesession revoke · approval revoke · asset migration
Failure conditionrevoke from compromised device without plan
Applied case file
containment-plan
CASE / containment-evidence
active Sessions3
suspicious Approvalyes
assets At Risk$74,000
devicepossibly compromised
logsavailable
safe Secondary Deviceavailable
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?

suspicious Approvalyes
03
Execution

What will the payload, route or system actually do?

—
04
Context

Which surrounding facts can materially change the decision?

active Sessions3
assets At Risk$74,000
devicepossibly compromised
logsavailable
safe Secondary Deviceavailable
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.

Focussession revoke · approval revoke · asset migration
Failure signalrevoke from compromised device without plan
Verify firstpreserve evidence first where safe
Deliverablecontainment timeline + evidence bundle
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

    Prioritize stopping active loss while preserving key evidence.

  2. 02

    Do not rely on screenshots alone when raw hashes and payloads exist.

  3. 03

    Document every remediation action.

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

Treasury separation & authorization

Design high-value operations so one compromised browser, operator or wallet cannot independently move everything.

Technical environment related to this course module
Module locked

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

Module 03

Threat modelling wallet integrations

Identify trust boundaries across browser, RPC, wallet, routers and external protocols before adding controls.

Operational security environment related to this course module
Module locked

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

Module 04

Capstone: transaction security review

Combine every layer of evidence into a documented allow, warn, block or review decision.

Module locked

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

PROFESSIONAL CAPSTONE

This assessment combines origin integrity, typed-data authority, upgradeability, simulation evidence and treasury policy. Passing requires a reproducible evidence trail, not a guessed risk label.

FINAL EXERCISE · FORENSIC MACHINE

A treasury incident, and a machine to investigate it on.

Complete the modules and the capstone to open the forensic machine.

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