Chapter 29 — Web3, blockchain and cryptoasset security: operations
Lesson map
Lesson 29 published. Map, example, EX085.
flowchart TD
N0["Learning outcomes"]
N1["29.1 Routine operations"]
N2["29.2 Responding to incidents"]
N3["29.3 Records and handovers"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX085"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["29.1 Routine operations"]
N2["29.2 Responding to incidents"]
N3["29.3 Records and handovers"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]
[Learning outcomes]
|
v
[29.1 Routine operations]
|
v
[29.2 Responding to incidents]
|
v
[29.3 Records and handovers]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX085]
Learning outcomes
You will (1) run routine security operations; (2) respond to incidents with a plan; (3) maintain records and handovers.
29.1 Routine operations
Sofia writes a weekly operations routine for volunteers: confirm all three validators are in sync, check disk and memory alerts, review privileged actions in the past week, confirm reconciliation results, check pending library updates and confirm keyholder availability for the next batch. Each item takes a few minutes and is recorded in a shared log. Routines catch problems early, when they are small. She designs the routine to fit in thirty minutes, because a routine that takes too long will be skipped by busy volunteers, which is worse than a shorter routine done reliably.
29.2 Responding to incidents
The incident plan defines what counts as an incident, who is contacted, and the first steps. For example, if reconciliation shows an unexplained mismatch above 50 vouchers, the duty volunteer contacts two keyholders, who decide whether to pause transfers. The plan lists contacts, decision rules and how to inform members. It avoids technical detail that could be misused and focuses on decisions and communication. Sofia runs a tabletop exercise where the board talks through a scenario. They find that no one knew who should inform members, so a named communications lead is added.
29.3 Records and handovers
Volunteers change often. Sofia keeps a handover file listing current keyholders, validator operators, open issues, recent incidents, pending updates and where procedures are stored. When a volunteer leaves, a checklist removes their access and transfers their duties. She notes that the 2-of-3 multisig must be updated promptly when a keyholder leaves, or the cooperative risks having too few active signers. Good records make the system resilient to people changes, which in small organisations are often a greater risk than technical failures or attacks from outsiders.
Worked example
Sofia's thirty-minute weekly routine, a pause threshold of 50 unexplained vouchers and a named communications lead strengthen operations.
Synthetic case. The routine, plan and exercise are synthetic.
Errors and limits
A routine too long for volunteers will be skipped, leaving problems undetected.
Exercises
- EX085 — Routine length. How long is the weekly routine designed to take? Rubric: 3 = thirty minutes;; 2 = 30 minutes;; 1 = all day;; 0 = none.
- EX086 — Pause threshold. What mismatch triggers contacting keyholders? Rubric: 3 = an unexplained mismatch above 50 vouchers;; 2 = above 50;; 1 = any mismatch;; 0 = none.
- EX087 — Tabletop gap. What gap did the tabletop exercise reveal? Rubric: 3 = no one knew who should inform members;; 2 = communications;; 1 = no gaps;; 0 = none.
Synthesis
Short routines, a decision-focused incident plan and good handovers keep operations dependable.
Continue studying — chapter 29 of 40
← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →