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

Sikh Bitcoin · Expert · Lesson 20 of 21

Incident response with clear human authority

Respond to uncertainty without creating a second incident.

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 20 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

  • Distinguish a monitoring failure from a confirmed asset loss.
  • Draft an evidence-preserving escalation path.

Classify the observation first

A stale data feed, suspicious approval request, unavailable signer and confirmed unauthorized transaction are different incidents. Record what was observed, when, from which source and what remains unknown. Avoid claiming a theft simply because a dashboard cannot load, or claiming safety because an old snapshot still looks healthy.

Pause the affected workflow and preserve evidence

A response can stop new actions in the affected application, preserve nonsecret logs and notify the designated human through an established channel. Keep credentials, seed material and private personal data out of shared incident notes. Do not follow a stranger’s recovery link or rush a compensating transfer. The exact containment action depends on the system and must be authorized by its responsible people.

Test decisions before an emergency

Run a tabletop exercise with an oracle mismatch, a duplicated invoice event or a compromised public account. Name who can assess evidence, approve operational changes and communicate verified facts. An agent’s job can be observation and drafting; it does not gain signing authority during an emergency. End with a dated incident record, unresolved risks and a follow-up owner. This course provides no active account-level monitoring, and reading it does not establish a liquidation alert or recovery service.

Practice on paper

A read-only market feed fails for an hour. What should a responsible status message say?

Reveal the worked answer

State that the feed is unavailable or stale, give the last verified time and describe the resulting observation gap. Do not infer that a user’s position is safe, liquidated or even monitored. Escalate according to the defined service scope.

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. Should recovery instructions from an unsolicited message be trusted?

  • Yes
  • No
Reveal answer 1

No. Verify through established official and internal channels.

2. Does an incident give a research agent automatic spending authority?

  • Yes
  • No
Reveal answer 2

No. Human authorization boundaries still apply.

Take this with you

Clear facts and authority reduce the chance that urgency causes more harm.

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.