BC3: Multi-signature approvals and looking after keys
Running approvals as a group
🎯You'll be able to
Set up a process around a multi-signature vault so approvals are careful, recorded and hard to trick.
🏠The everyday picture
At a bank branch, two staff check a large cheque against the customer's file and call the customer back on a number already on record, not one written on the cheque.
📘What it really is
-
Check what you sign: read the payee, amount and call data in the wallet. Compare the payee address with one you saved, character by character, not one pasted from a message.
-
Out-of-band checks: for a new payee, confirm the address by a phone call to a number you already have.
- Address poisoning: attackers send tiny amounts from look-alike addresses, hoping you'll copy theirs from your history.
- Records: keep notes of what each transaction was for. On-chain events show what happened, not why.
- Practice: run a test payment and a lost-key drill on a test network before real money.
- Keep keys apart: different people, devices and places; hardware wallets for owners where possible.
📝A worked example
Input: a "supplier" emails a new bank-style address for payment.
Steps:
- M01 submits the payment, then M02 phones the supplier on the number in the group's records.
- The supplier says they haven't changed their address. The email was fake.
- The owners revoke their approvals and record why.
Expected output: no payment to the attacker, and a note for next time.
🌍Where it's used
- Finance teams with two-person checks.
- Treasury policies for DAOs and companies.
- Security reviews that test the process, not just the code.
📝Case scenario
In a large theft from an exchange, signers approved a transaction whose details their screens showed wrongly, because the interface they used had been tampered with. Checking the transaction on a separate device would have shown the real call. The lesson: verify on a device you trust before approving.
🖱️Try it
Write a four-step checklist the group follows before any owner confirms a payment. Success: it includes checking the address against a saved record and an out-of-band call for new payees.
⚠️Common mistakes
- Copying addresses from history. Sign: a look-alike payee. Fix: saved, checked addresses.
- Trusting one screen. Sign: approving what the interface says. Fix: check details on the signing device.
- No drill. Sign: the first lost key causes panic. Fix: practise on a test network.
🛠️For your project
Project 2's docs/multisig-design.md needs a "Lost or stolen keys" section; the capstone design notes cover how real owners would
hold keys.
✅Quick check
How should an owner check a new payee's address?
Show the answer
Against a saved record, with an out-of-band call for any change.
Why practise a lost-key drill on a test network?
Show the answer
So the steps are known and work before real money depends on them.