Multisig and timelock - managing a contract without a single point of failure

A single private key is a single point of failure: it can be lost, stolen, or its owner can act dishonestly. For personal sums that is acceptable, but not for someone who controls other people's money (a contract owner, a guarantor, a project treasury). The answer: multisig and timelock. The basics of keys are in the article public-key cryptography.

Multisig: m of n

A multisig is an address that is a smart contract and carries out actions only if at least m of n designated participants have approved them.

Example schemes:

The choice of numbers is a balance. The more signatures required, the harder to hack, but also the harder to carry out an action.

What it looks like in practice

The most widespread tool is Safe (formerly Gnosis Safe). The process:

1. One participant proposes a transaction (for example "call pause()").
2. The others review and sign it with their wallets. Signatures are collected off-chain and for free.
3. When there are enough signatures, any participant executes the transaction on the network, paying gas.

To the outside world a multisig is just an address. Other contracts see msg.sender as the Safe's address.

What a multisig protects against

• Theft of one key. An attacker with one key can do nothing.
• Loss of one key. The other participants can replace the lost one.
• Dishonesty of one participant. Coordinated actions by several are required.
• Mistakes. A second pair of eyes on a transaction before execution.

What it does not protect against

• Collusion of m participants.
• Phishing of the group. If signers blindly sign whatever is sent to them, the scheme is pointless (how scammers act).
• A shared point of failure. All keys on one computer or with one person is a single key in disguise.
• Wrong settings. A wrong threshold (for example 1 of 5) reduces protection to zero.

Timelock: delay as protection

A timelock is a contract that does not execute an administrative action at once but postpones it for a fixed time (for example 48 hours). The action is first queued, and it can be executed only after the delay.

Why:

• users have time to notice a change and decide: withdraw their money, stop using the service;
• owners have time to cancel an erroneous action;
• even a compromised key cannot cause damage instantly.

A timelock is especially important for proxy contracts, whose logic can be replaced: without a delay an upgrade could be malicious and instant.

Multisig + timelock

A reliable governance scheme: the multisig queues an action in the timelock, and after the delay it is executed. This way even with several keys compromised users have time to react.

Use in the Coin-Trust ecosystem

The contract owner. The contract has administrative functions: allow a token, pause creation of deals, withdraw fees (the full list). The contract's developers recommend a multisig for the owner. It lowers the risk of loss and abuse. Important: these functions give no access to the money of active deals (why).

The guarantor. An organisation acting as guarantor can use a multisig: several people decide a dispute and it is executed by one transaction. This raises reliability and lowers the risk of a "lost key", and therefore of the 50/50 emergency exit (why it is critical).

Example

A team of 5 manages a treasury. The scheme is 3 of 5 via Safe. Platform fees need to be withdrawn. The accountant proposes a transaction, three independently check the amount and recipient address, sign, and a fourth executes. If a laptop of one signer is stolen, the attacker with his key is powerless.

What to read next

Find out what access-control patterns exist in code: access-control patterns. Or how upgradeable contracts are built: proxies and upgradeability.