Multisig as an Internal Control, Not a Gadget

Every corporate bank account I have ever set up asked the same question on the signing card: how many signatures does a cheque need above a given amount. Nobody finds that controversial. It is the oldest control in accounting, and it exists because one person with sole authority over cash is a structural weakness regardless of how much you trust them.

A single-signature crypto wallet is a chequing account with one signatory, no daily limit, no reversal window, and no bank compliance department watching the outflows.

Multisig fixes the specific part of that which can be fixed.

What it is, in control language

A multisig wallet enforces an m-of-n rule: n keys exist, and m of them must sign before a transfer executes. Two of three, three of five, whatever you set. The rule is enforced by the protocol, not by a policy manual and not by a bank clerk who might be persuaded.

That last difference cuts both ways. A dual-signature requirement at a bank is enforced by people, so it can be overridden by people, which means an urgent transfer can be pushed through and a mistake can be unwound. Multisig cannot be overridden and cannot be unwound. If you lose enough keys that you can no longer reach m, the funds are gone in the same permanent way described in lost keys and exchange collapse.

So the design question is not “how secure can I make this”. It is “how do I get segregation of duties without creating a quorum I can lose”.

Choosing m and n

The two configurations I still see chosen are 2 of 2 and n of n, usually by someone who reasoned about theft and never about loss. Both give you the worst of each world: no tolerance for a lost key and no tolerance for an unavailable signer.

Two of three is the honest default for a small Canadian corporation. Two officers hold operational keys and a third key sits in sealed offline storage under dual control, so the company can still transact if one officer is on a plane, ill, or no longer with the business.

Segregation of duties, applied properly

The threshold is only half of it. Multisig gives you segregation of duties only if the keys sit in genuinely different hands and genuinely different failure domains.

Two keys on two devices belonging to the same person is one key. Two keys backed up to the same cloud account is one key. Two keys in the same safe in the same building is one key against fire and one key against a burglary. The question to ask of any configuration is what single event takes out two of them, and if you can name that event easily, the design has not done its job.

The roles I would separate on paper before anyone touches a device:

Initiator. Prepares the transaction and the supporting documentation, usually whoever runs operations or accounts payable.

Approvers. The m signers. At least one should be an officer or director with authority to bind the company.

Reconciler. Compares on-chain activity to the accounting records. This person must not hold a key. A reconciler who can also sign is not a control, and this is the most common flaw I find when I look at an arrangement someone set up themselves.

Recovery custodian. Holds the sealed backup, under dual control, and never participates in routine signing.

The policy that has to exist in writing

A signing arrangement that lives only in the wallet software is not a control environment. Put it in a document the directors approve, covering the addresses in use, the threshold, who holds which key and where, the dollar thresholds at which additional approval is required, what happens when a signer leaves, and how often the arrangement is tested.

Where there are no directors to approve it, because the treasury belongs to a group that never incorporated anything, the signing policy is not the first problem. The absence of a legal person is, and no threshold rule fixes it.

FINTRAC’s compliance program requirements are written for reporting entities rather than for ordinary businesses, but the shape is instructive for anyone: a named accountable person, written policies approved by a senior officer, a documented risk assessment, training, and a periodic effectiveness review. If your business does fall into the regulated category, whether by accepting crypto payments or by moving virtual currency for others, that structure is not optional and the registration analysis comes first.

The Cyber Centre’s baseline controls covers the device layer underneath all of this, and its guidance on backups makes the point that matters most here: a backup nobody has restored is a hypothesis, not a backup.

Deciding whether you need it

Can one person move company crypto without a second approval?
│
├── No, and it is documented and tested  → You are fine.
│
└── Yes
    ├── Is the balance immaterial and would you accept
    │   losing all of it tomorrow?
    │      → Single signature is defensible. Cap it.
    │
    └── Material balance
        ├── Do you have two people who can be trained and
        │   held accountable?
        │      No  → Use a custodian instead. Multisig with
        │            one competent person is theatre.
        │      Yes → 2 of 3, with the third key sealed and
        │            held offsite under dual control.
        └── Regulated activity or external assurance needed?
               → 3 of 5 and a written policy the board
                 approves. Expect to show the register.

The failures that actually happen

A signer leaves and nobody moves the funds. Revoking building access takes ten minutes; the departing person’s key stays valid forever unless you replace the wallet. Offboarding has to include a rotation, and the key continuity plan is where that gets written down.

Backups get consolidated for convenience. Someone tidies up, puts all three recovery phrases in one fire safe, and the configuration silently becomes 1 of 1. The written procedure for handling key material exists to stop exactly that.

The arrangement is never tested. The first time anyone attempts a recovery is the day it is needed, which is also the day you discover the third key was written down wrong. Run a small test transfer at setup and repeat it annually, and treat it the way you would treat a fire drill. The Cyber Centre’s incident response guidance is the right template for the runbook.

And the quiet one: paying people in crypto without any of this in place. If part of compensation goes out in crypto, those transfers are payroll, and payroll running through a one-person wallet is the arrangement I would flag first in any review. The corporate structuring around crypto held in a corporation assumes the company can actually control the asset.

If your business holds crypto and one person can move it, send me the balance at your last year end, who currently signs, and what your offboarding process says. I will map it against the same segregation-of-duties test I would apply to a bank account and tell you what to change first. Get in touch.