Wallet Security & Self-Custody
Protect keys, recovery material, destinations and devices using practical operational boundaries.

What you will be able to do
Treat seed phrases and private keys as signing authority, not as support credentials or cloud data.
Recognize when a legitimate-looking interface is separated from the origin and authority it claims.
Defend against look-alike addresses, clipboard substitution and history poisoning before value leaves the wallet.
Reduce exposure by separating devices, roles, hot balances and recovery procedures.
Curriculum
This course includes
- ·8 lessons · 14 guided hours
- ·4 Lab · Practical scenarios
- ·8 Applied case files · 8 Knowledge checks
- ·52 Item exam bank · 80% pass mark
- ·Completion credential: UTXO Certified · Wallet Security Fundamentals
What this course expects of you
- ·Recognize common wallet-compromise paths before funds move.
- ·Passing score: 80%
- ·Crypto & Blockchain Foundations
Training contract
Recognize common wallet-compromise paths before funds move.
Secret material & recovery boundaries
Treat seed phrases and private keys as signing authority, not as support credentials or cloud data.
Evidence memo · KEY-BOUNDARYPhishing, origins & social pressure
Recognize when a legitimate-looking interface is separated from the origin and authority it claims.
Evidence memo · PHISHINGDestination integrity
Defend against look-alike addresses, clipboard substitution and history poisoning before value leaves the wallet.
Evidence memo · ADDRESS-POISONINGOperational wallet security
Reduce exposure by separating devices, roles, hot balances and recovery procedures.
Evidence memo · KEY-BOUNDARY
Wallet Security & Self-Custody
Review the full curriculum, competencies and assessment path before starting.
Secret material & recovery boundaries
Treat seed phrases and private keys as signing authority, not as support credentials or cloud data.
Phishing, origins & social pressure
Recognize when a legitimate-looking interface is separated from the origin and authority it claims.
Destination integrity
Defend against look-alike addresses, clipboard substitution and history poisoning before value leaves the wallet.
Operational wallet security
Reduce exposure by separating devices, roles, hot balances and recovery procedures.
- Never type a seed phrase into a website presented as support.
- A leaked seed cannot be made secret again.
- Test recovery before an emergency.
- Avoid single points of failure and single points of compromise.
- Branding is not evidence of origin.
- Verify domains independently before sensitive signing.
- Time pressure should increase scrutiny, not reduce it.
- Never let support channels dictate signing steps without independent verification.
- Verify the full destination or a trusted address-book entry.
- Do not copy destinations from transaction history blindly.
- Re-check the final signer display when available.
- Treat new destinations differently from established ones.
- Written field exercise × 8
- Knowledge checks × 8
- Module practical lab × 4
- Timed final exam · 20 · ≥ 80%
- Deep technical lesson · 360 min
- Written field exercise · 160 min
- Module practical lab · 140 min
- Specialist units · 105 min
- Timed final exam · 30 min
Scope, outcomes and study standard
Protect keys, recovery material, destinations and devices using practical operational boundaries.
Recommended prior study
- Crypto & Blockchain Foundations
- Never type a seed phrase into a website presented as support.
- A leaked seed cannot be made secret again.
- Move assets to new keys after suspected disclosure.
- Test recovery before an emergency.
- Avoid single points of failure and single points of compromise.
- Document inheritance or emergency access deliberately.
- Branding is not evidence of origin.
- Verify domains independently before sensitive signing.
- A wallet request inherits risk from the context that initiated it.
- Time pressure should increase scrutiny, not reduce it.
- 01
Read the six-part technical chapter
- 02
Inspect the unique visual and protocol model
- 03
Work through the case file and evidence map
- 04
Submit the written field exercise
- 05
Pass the knowledge check and module lab
- 06
Complete the timed final assessment
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 requires the written work, knowledge checks, all module labs and a final exam score of at least 80%. Professional level also requires the capstone.
- Never turn recovery material into a support credential
- A recovery phrase or private key is not a password reset token. Anyone who receives it can usually reconstruct signing authority. Legitimate support workflows should never require it, and security processes should assume any disclosed recovery material is permanently compromised.
- Backups need availability and confidentiality
- A recovery strategy must survive device loss without creating an easy theft path. One cloud note or a photo roll backup may improve availability while destroying confidentiality. Strong recovery separates copies, locations and access mechanisms according to the value at risk.
- Read the origin, not the logo
- Phishing sites can reproduce a brand perfectly while using a different origin. Unicode look-alikes, subdomain tricks and sponsored search results exploit visual trust. The authoritative question is which origin requested the wallet connection and whether that origin matches a known, independently verified destination.
- Urgency is part of the exploit
- Attackers combine technical payloads with emotional pressure: expiring claims, account freezes, emergency migrations or support impersonation. Security controls should deliberately slow high-risk operations so urgency cannot bypass verification.
- History is not an address book
- Address-poisoning attacks send tiny or crafted transactions from look-alike addresses so a user copies the wrong destination from recent history. Prefix and suffix similarity is not sufficient verification when meaningful value is moving.
- Verify destinations before value becomes irreversible
- Destination integrity can be attacked through clipboard malware, poisoned history, compromised QR codes or incorrect ENS-style resolution. A robust workflow verifies the resolved destination at the signing boundary and escalates new high-value addresses.
- A secure wallet on an insecure device inherits risk
- Malware can alter clipboard data, inject browser content, steal sessions or replace installers. Self-custody therefore requires device hygiene, software provenance and separation between everyday browsing and high-value signing.
- Good procedure reduces dependence on perfect software
- No single product can eliminate every failure mode. Procedures such as transaction limits, role separation, allowlisted destinations and dry runs make one compromised component less likely to become a catastrophic loss.
Modern protocol and operational topics
These extensions broaden the core curriculum with current standards and security boundaries that practitioners are expected to recognize.
RPC and provider trust boundaries
A provider transports requests and chain state but should not become an invisible source of truth. Model chain/account changes, stale or adversarial RPC responses, and the difference between connectivity and authorization correctness.
Wallet software supply-chain security
Treat dependencies, build systems, registries and release artifacts as part of the signing threat model. Provenance and reproducibility reduce the chance that a trusted frontend or extension becomes the delivery path for malicious request code.
Hardware-backed key management
Separate key generation, storage, use, backup, rotation and destruction as distinct lifecycle operations. Hardware isolation reduces extraction risk but does not automatically make an incorrect transaction safe to authorize.

Secret material & recovery boundaries
Treat seed phrases and private keys as signing authority, not as support credentials or cloud data.

Never turn recovery material into a support credential
Never turn recovery material into a support credential
A recovery phrase or private key is not a password reset token. Anyone who receives it can usually reconstruct signing authority. Legitimate support workflows should never require it, and security processes should assume any disclosed recovery material is permanently compromised.
This concept matters because Never type a seed phrase into a website presented as support.
Seed phrases deterministically reconstruct signing authority and therefore cannot be scoped like a password reset token.
Identify whether the workflow requests recovery words or raw signing material.
At protocol and execution level, inspect seed phrase and derived key and signer and backup and compromise. Protocol identifiers remain untranslated because they are part of the technical payload.
seed phraseroot recovery secret
derived keyaccount-specific authority
signeruses key without exposing it
backupoffline recovery copy
compromiseauthority must be migrated
Entering a seed into a support portal gives the requester durable authority over all derived wallets.
The practical consequence is that A leaked seed cannot be made secret again. Unknown is not equivalent to safe.
- seed typed into website
- seed photographed/cloud-synced
- support asks for recovery words
- same seed used in insecure environment
- suspected disclosure without migration
Never disclose; if already entered, migrate assets from a known-clean environment.
The practical consequence is that A leaked seed cannot be made secret again.
Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.
Verify the request through independent evidence before irreversible authorization.
- 01
classify recovery material
- 02
remove online copies
- 03
verify signer never exports secrets
- 04
design recovery test
- 05
migrate assets after suspected exposure
Record the facts, assumptions, unknowns and decision so another analyst can reproduce the review.
Never type a seed phrase into a website presented as support. and Move assets to new keys after suspected disclosure.
Analyst objective
Never type a seed phrase into a website presented as support.
Mechanics
root recovery secretaccount-specific authorityuses key without exposing itoffline recovery copyauthority must be migratedFailure signals
- 01
seed typed into website
- 02
seed photographed/cloud-synced
- 03
support asks for recovery words
- 04
same seed used in insecure environment
- 05
suspected disclosure without migration
Verification procedure
- 01
classify recovery material
- 02
remove online copies
- 03
verify signer never exports secrets
- 04
design recovery test
- 05
migrate assets after suspected exposure
Reasoning chain
- 01
facts → material evidence
- 02
evidence → consequence / authority
- 03
consequence → explicit decision + next action
secret-material handling policyFollow the security decision path
seed / private / key / boundary- seed phrase: root recovery secret
- derived key: account-specific authority
- signer: uses key without exposing it
- backup: offline recovery copy
- compromise: authority must be migrated
- seed typed into website
- seed photographed/cloud-synced
- support asks for recovery words
- classify recovery material
- remove online copies
- verify signer never exports secrets
- secret-material handling policy
enter 24 wordswallet recovery portalwallet-helpdesk.iounsolicitednotreat material as compromised if enteredBefore answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.
Organize before you decide
Separate identity, authority, execution and context before reaching a security decision.
Identity
Who or what is requesting, receiving or representing authority?
wallet-helpdesk.iounsolicitedAuthority
What capability can be granted, retained or exercised?
Execution
What will the payload, route or system actually do?
Context
Which surrounding facts can materially change the decision?
enter 24 wordswallet recovery portalnotreat material as compromised if enteredProduce an analyst-ready finding
Do not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.
- Cites material evidence, not UI appearance.
- Names the authority, state transition or consequence.
- Provides a reproducible next action or decision.
- 01
Never type a seed phrase into a website presented as support.
- 02
A leaked seed cannot be made secret again.
- 03
Move assets to new keys after suspected disclosure.
Build your evidence memo
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.
Backups need availability and confidentiality
Backups need availability and confidentiality
A recovery strategy must survive device loss without creating an easy theft path. One cloud note or a photo roll backup may improve availability while destroying confidentiality. Strong recovery separates copies, locations and access mechanisms according to the value at risk.
This concept matters because Test recovery before an emergency.
Recovery design balances availability against the creation of additional theft paths.
Map number of copies, storage media, physical locations and recovery testing.
At protocol and execution level, inspect availability and confidentiality and redundancy and separation and test. Protocol identifiers remain untranslated because they are part of the technical payload.
availabilitycan recover after loss
confidentialityunauthorized recovery prevented
redundancyno single physical failure
separationcopies not compromised together
testrecovery procedure validated
Cloud photos, single-site backups and untested procedures create either compromise or permanent loss.
The practical consequence is that Avoid single points of failure and single points of compromise. Unknown is not equivalent to safe.
- single backup
- all copies same location
- cloud photo/note
- backup never tested
- inheritance/emergency path undefined
Use separated, tested recovery paths appropriate to asset value and threat model.
The practical consequence is that Avoid single points of failure and single points of compromise.
Escalate when evidence is contradictory, incomplete or the consequence exceeds routine policy.
Verify the request through independent evidence before irreversible authorization.
- 01
define loss scenarios
- 02
choose independent backup locations
- 03
protect access separately
- 04
test recovery with non-production funds
- 05
document emergency/inheritance procedure
Record the facts, assumptions, unknowns and decision so another analyst can reproduce the review.
Test recovery before an emergency. and Document inheritance or emergency access deliberately.
Analyst objective
Test recovery before an emergency.
Mechanics
can recover after lossunauthorized recovery preventedno single physical failurecopies not compromised togetherrecovery procedure validatedFailure signals
- 01
single backup
- 02
all copies same location
- 03
cloud photo/note
- 04
backup never tested
- 05
inheritance/emergency path undefined
Verification procedure
- 01
define loss scenarios
- 02
choose independent backup locations
- 03
protect access separately
- 04
test recovery with non-production funds
- 05
document emergency/inheritance procedure
Reasoning chain
- 01
facts → material evidence
- 02
evidence → consequence / authority
- 03
consequence → explicit decision + next action
tested recovery runbookFollow the security decision path
backup / recovery- availability: can recover after loss
- confidentiality: unauthorized recovery prevented
- redundancy: no single physical failure
- separation: copies not compromised together
- test: recovery procedure validated
- single backup
- all copies same location
- cloud photo/note
- define loss scenarios
- choose independent backup locations
- protect access separately
- tested recovery runbook
2home safecloud photoaccount passwordnonenever$95,000Before answering the checkpoint, identify the authority being granted, the trust boundary that can fail, and the consequence that becomes irreversible.
Organize before you decide
Separate identity, authority, execution and context before reaching a security decision.
Identity
Who or what is requesting, receiving or representing authority?
Authority
What capability can be granted, retained or exercised?
Execution
What will the payload, route or system actually do?
$95,000Context
Which surrounding facts can materially change the decision?
2home safecloud photoaccount passwordnoneneverProduce an analyst-ready finding
Do not answer from memory. Use the case, protocol fields and verification procedure above to write a reproducible finding.
- Cites material evidence, not UI appearance.
- Names the authority, state transition or consequence.
- Provides a reproducible next action or decision.
- 01
Test recovery before an emergency.
- 02
Avoid single points of failure and single points of compromise.
- 03
Document inheritance or emergency access deliberately.
Build your evidence memo
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.

Pass both lesson knowledge checks in this module before attempting the practical lab.
Phishing, origins & social pressure
Recognize when a legitimate-looking interface is separated from the origin and authority it claims.
Complete the previous module, including its practical lab, before continuing.
Destination integrity
Defend against look-alike addresses, clipboard substitution and history poisoning before value leaves the wallet.

Complete the previous module, including its practical lab, before continuing.
Operational wallet security
Reduce exposure by separating devices, roles, hot balances and recovery procedures.
Complete the previous module, including its practical lab, before continuing.

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.