Chapter 21 — Web3, blockchain and cryptoasset security: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 Functional security requirements"]
N2["21.2 Governance requirements"]
N3["21.3 Testability and priority"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 Functional security requirements"]
N2["21.2 Governance requirements"]
N3["21.3 Testability and priority"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 Functional security requirements]
|
v
[21.2 Governance requirements]
|
v
[21.3 Testability and priority]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) write security requirements for issuance, transfer and governance; (2) make them testable; (3) prioritise them.
21.1 Functional security requirements
Jonas writes requirements as testable statements. Issuance: credits are minted only by the minting role, only against signed meter batches, and never above the hourly capacity cap. Transfer: only the holder can move their credits, amounts are positive integers, and balances never go negative. Redemption: redeemed credits are burned and reported to the utility within a day. Each statement names who, what and under which condition, so that a test or review can check it. Vague requirements such as "the system must be secure" are rewritten until they say exactly what secure means here.
21.2 Governance requirements
Governance requirements cover privileged actions. Any change to contract code, the minting role or the cap requires approval by three of five board keyholders and a 48-hour timelock before execution, giving members and monitors time to see it. Emergency pause requires two of five and is announced to members within an hour. All privileged actions are logged with a change reference. Jonas links these to EthTrust's recommendation of timelock delays for sensitive operations and to its discussion of access control for upgradeable contracts, citing sources for each choice.
21.3 Testability and priority
For each requirement Jonas notes how it will be verified: unit test, property test, review checklist item, configuration check or monitoring alert. He then prioritises using impact on members and likelihood: minting controls and transfer correctness are highest, redemption reporting next, and user interface conveniences lowest. The board reviews the list and agrees the priorities. Testable, prioritised requirements let a small team focus scarce review time where failure would cause the most harm. The list is revisited whenever the threat analysis changes, so priorities stay aligned with risk.
Worked example
Jonas writes issuance, transfer, redemption and governance requirements with a verification method each; minting and transfer correctness are ranked highest.
Synthetic case. Requirements and priorities are synthetic; EEA EthTrust is a real source.
Errors and limits
Writing requirements like "the system must be secure" gives reviewers nothing to check.
Exercises
- EX061 — Minting requirement. Under what conditions may credits be minted? Rubric: 3 = by minting role, against signed batches, under hourly cap;; 2 = three conditions;; 1 = anytime;; 0 = none.
- EX062 — Upgrade approval. What approval do code changes need? Rubric: 3 = three of five keyholders and a 48-hour timelock;; 2 = 3-of-5 plus timelock;; 1 = one person;; 0 = none.
- EX063 — Highest priority. Which requirements are highest priority? Rubric: 3 = minting controls and transfer correctness;; 2 = minting;; 1 = interface;; 0 = none.
Synthesis
Testable, sourced and prioritised requirements guide design and verification effort.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →