Skip to content
Satnam SatoshiIn service of humanityFind your place ↗
Menu

Sikh Bitcoin · Expert · Lesson 1 of 21

Threat model before tools

Design around concrete failures and the people who must recover.

About 14 minutes with practice. You only need something to take notes with. No real wallet details or payments are part of this lesson.

Course contents · Lesson 1 of 21
  1. Threat model before tools
  2. Design a custody architecture
  3. Entropy, mnemonics and passphrase tradeoffs
  4. Hardware signing and trusted displays
  5. Multisig and independent control
  6. Recovery and continuity across people
  7. Coin control and privacy tradeoffs
  8. Lightning operations and recovery
  9. Payment operations and reconciliation
  10. Native bitcoin and wrapped claims
  11. USDC, reserves and redemption
  12. Identify a Morpho market precisely
  13. Oracles, prices and measurement risk
  14. LTV, liquidation and nonlinear losses
  15. Variable rates and growing debt
  16. Vaults, allocation and exit liquidity
  17. Arc, Base and cross-chain dependencies
  18. Allowances, signing and simulation
  19. Treasury accounting and restricted funds
  20. Incident response with clear human authority
  21. Capstone: a defensible treasury design

What you will learn

  • Separate assets, threats and controls.
  • Identify residual risk after a control is added.

Name what needs protection

A custody design protects more than a balance. It may also protect privacy, access to operating funds, continuity after illness and the ability to explain decisions. List the asset, authorized people and consequence of failure. Avoid starting with a favorite device and inventing reasons it solves every problem.

Model distinct failures

Theft, accidental deletion, coercion, unavailable signers, misleading interfaces and a provider outage require different responses. A control can reduce one threat while increasing another. For example, a demanding approval threshold may resist one compromised signer but make urgent recovery harder. Geographic separation can reduce a shared physical failure while complicating access and maintenance.

Make assumptions testable

For a fictional community treasury, write who can prepare, authorize, reconcile and pause operations. Record the evidence a second person needs to reproduce the result. A tabletop exercise should include a missing device, an unavailable provider and an unexplained payment request. No real secrets or transfers are needed. The useful outcome is a list of unresolved dependencies, not a declaration that the system is institution grade because it uses several tools.

Practice on paper

A team introduces a second approval but both approvers share one laptop and one recovery account. What risk remains?

Reveal the worked answer

A compromise or loss of that shared environment can affect both approvals. The nominal number of people does not establish independent control. Review the shared device, credentials, recovery route and ability to refuse separately.

Check your understanding

Choose an answer in your head or on paper, then reveal the explanation. Retry whenever you like. Answers are not submitted or scored; completion marks are your own learning notes.

1. Can one control remove every threat?

  • Yes
  • No
Reveal answer 1

No. Controls have scope and tradeoffs.

2. Is a vendor label a substitute for a recovery exercise?

  • Yes
  • No
Reveal answer 2

No. Test the actual people, tools and information.

Take this with you

Start with failure stories, then choose controls with explicit limits.

Your learning, at your pace

Read every lesson freely. Optional progress tracking needs JavaScript and browser storage; it does not require an account or wallet.