In this article
A crypto OTC desk should set up multisig so that no single person, device or office can move client or house funds, and so that the loss of one key never freezes them: in practice a threshold such as 2-of-3 for a working wallet and 3-of-5 or higher for reserves, with each key held by a different person, in a different role, at a different place. The wallet is only half of the setup. The other half is a written approval policy, a signer rotation procedure and a recovery plan that has been rehearsed.
Multisig, short for multi-signature, is an arrangement in which a transfer needs approvals from several separate keys before the network accepts it. It is written "m-of-n": n keys exist, and any m of them together can approve. The first number says how many people must agree before money moves; the difference between the two says how many keys the desk can lose and still operate.
This article is general information for desks, brokers, funds and treasuries in any country. Custody rules, licensing conditions and the duties owed to clients differ from one jurisdiction to the next, and nothing here is legal advice. A standard quoted here is a benchmark, not a legal requirement.
What signer threshold should an OTC desk choose?
An OTC desk should choose a multisig threshold where m is at least two and n is larger than m, because that is the only shape that both blocks a single person from moving funds and survives the loss of a key. A 2-of-3 is the smallest arrangement that does both; 3-of-5 and 4-of-7 raise the number of people who must agree and the number of keys that can be lost.
Arrangements where every key must sign, such as 2-of-2 or 3-of-3, look strict and are fragile. They block a single signer, but one lost device, one resignation or one person on a long flight stops every transfer, and one destroyed key with no backup freezes the funds permanently.
In the table, "combinations" is the number of distinct groups of signers able to approve a transfer.
| Threshold | Keys needed to move funds | Keys that can be lost | Signer combinations |
|---|---|---|---|
| 2-of-2 | 2 | 0 | 1 |
| 2-of-3 | 2 | 1 | 3 |
| 3-of-5 | 3 | 2 | 10 |
| 4-of-7 | 4 | 3 | 35 |
Three practical rules follow from the arithmetic. First, the threshold should be a majority of the keys, so that two separate groups can never each form a quorum without sharing a member: in a 2-of-5, two pairs with no signer in common could act independently. Second, the number of keys should match the number of people the desk can genuinely make independent. Third, a larger quorum is slower on every settlement, so the threshold should follow what the wallet holds. A desk normally runs more than one wallet, with a lower threshold on the small balance used for daily settlement and a higher one on reserves; how much belongs in each is a separate sizing question.
How does the threshold change the chance that no quorum can be reached?
Adding spare keys to a multisig lowers the chance that a transfer is blocked far more than it raises the work of signing, while requiring every key to sign makes a blockage likely. The effect can be computed from one assumption.
Take an illustrative figure: each signer can be reached and can sign within the hour 90% of the time, independently of the others. With a single key, the transfer is blocked 10% of the time. With 3-of-3, all three must be reachable at once, which happens 72.9% of the time, so the transfer is blocked 27.1% of the time.
Worked example, binomial calculation. The 90% figure is an assumption, not a market statistic; a desk should substitute its own.
On these assumptions a 3-of-3 is blocked about 32 times as often as a 3-of-5, although both need three signatures.
The word "independently" carries the result. Signers who share an office, a time zone or a travel schedule are not independent: when one is unreachable, the others often are too. The calculation is a best case, which a desk approaches by spreading signers across time zones and naming the signers on duty for each settlement window.
Who should hold the keys, and which roles must stay separate?
Multisig keys should be held by named individuals whose roles differ, and the person who agrees a trade should never be able to both instruct the payment and supply the signatures that release it. The wallet enforces a number of signatures; only the allocation of keys makes those signatures independent judgments.
Five roles appear in a well-run setup, and a small desk may combine some of them but not all.
| Role | What the role does | What the role must not also do |
|---|---|---|
| Initiator | Prepares the transfer from the trade confirmation: asset, amount, destination | Count as one of the signatures on that transfer |
| Signer | Checks the transfer against the policy and signs on a dedicated device | Hold or access another signer's key or backup |
| Wallet administrator | Proposes changes to signers, threshold and the address allowlist | Approve a change alone; changes need the quorum |
| Reviewer | Reads the logs, reconciles transfers to trades, reports exceptions | Hold a key |
| Recovery key holder | Keeps a key used only when working signers cannot form a quorum | Take part in daily signing |
Signers should not all report to one person, because an instruction from a common manager turns several signatures into one decision. At least one key should sit outside the front office, with finance, compliance or a director, so that every transfer passes in front of someone who was not party to the negotiation.
Version 9 of the CryptoCurrency Security Standard, a benchmark for systems that hold digital assets published by the CryptoCurrency Certification Consortium, treats the people as part of the control. It expects references, identity and background to be checked before a person is trusted with key material, and at its highest level it expects key material to be held by distinct operators within the entity or by separate entities.
An outside recovery key holder, such as a law firm, a trustee or a custodian that offers a co-signing service, is one way to meet that last expectation. The engagement letter states when the key may be used and how the instruction is authenticated.
Where should the keys and their backups be stored?
Each multisig key should live on its own dedicated signing device, in a different location from the other keys, and no single location should hold enough keys to form a quorum or enough to prevent one. That last condition gives a simple rule for an m-of-n wallet: the most keys any one site may hold is the smaller of m minus one and n minus m.
The first half of the rule stops one event at one site from producing a quorum; the second stops a fire or a flood from destroying so many keys that the rest fall short.
| Threshold | Most keys at one site | Fewest sites needed | Example distribution |
|---|---|---|---|
| 2-of-3 | 1 | 3 | 1, 1, 1 |
| 3-of-4 | 1 | 4 | 1, 1, 1, 1 |
| 3-of-5 | 2 | 3 | 2, 2, 1 |
| 4-of-7 | 3 | 3 | 3, 2, 2 |
The table shows why 3-of-4 is an awkward choice: it tolerates the loss of only one key, so it needs four separate sites, more than a 3-of-5 needs. A 3-of-5 distributed 3, 1, 1 fails the test although it uses three sites, since one office holds a full quorum.
Backups follow the same logic as keys. A signing device generates its key from a recovery phrase, a list of words from which the key can be rebuilt on a new device, and that phrase is the backup. The standard cited above expects a backup of key material to exist, to be protected against environmental risks and to sit behind access controls at its first level; to be stored in a geographically separate location and in a way that shows whether it has been accessed at its second level; and to be strongly encrypted at its third. In practice: a phrase recorded on a durable medium, sealed in a tamper-evident bag whose serial number is logged, and kept away from the device it restores.
Two habits undo sound storage: keeping several signers' backups together, which rebuilds the single point of control the wallet was meant to remove, and photographing or typing a recovery phrase into a connected device, which turns an offline key into an online one.
Onchain multisig, threshold signatures or a custodian: which should enforce the quorum?
A desk can enforce a signing quorum in three ways: a multisig built into the blockchain's own rules, a threshold-signature scheme that splits one key into shares, or a custodian's approval workflow. The three give similar control over who can move funds and differ on which assets they cover, on whether the quorum is visible to outsiders, and on what a change of signer involves.
A native multisig is enforced by the network. On networks that use scripts, the wallet's address is derived from the set of public keys and the threshold; on networks with smart contracts, the wallet is a contract that keeps a list of owners and a required number of approvals. A threshold-signature scheme, often described under the heading of multi-party computation, never assembles a full key: each participant holds a share, and a quorum of shares produces one ordinary signature. A custodian's workflow keeps the keys with a regulated third party and applies the client's approval rules before the custodian signs.
| Criterion | Native onchain multisig | Threshold signatures | Custodian workflow |
|---|---|---|---|
| Who enforces the quorum | The network's own rules | The signing software | The custodian's systems and staff |
| Quorum visible onchain | Yes | No, one signature appears | No |
| Coverage across networks | One setup per network | One scheme, many networks | Assets the custodian supports |
| Changing a signer | New address or onchain update | Shares reissued, address kept | Change to the mandate |
A native multisig suits a desk that wants the control to be verifiable by anyone and independent of any vendor. Threshold signatures suit a desk active on many networks that needs one policy across them and accepts relying on the provider's software and logs. A custodian suits a desk whose clients or regulator require assets to be held by a licensed third party.
What should a multisig approval policy say?
A multisig approval policy should state, in writing, which transfers each wallet may make, who may initiate them, what each signer must verify, and how exceptions are handled. A quorum of signatures proves that several keys were used; only the policy makes each signature mean that a person checked something.
A workable policy for a desk covers seven subjects.
- Purpose of each wallet. What the wallet is for, the most it should hold, and the threshold that applies.
- Permitted destinations. An allowlist of addresses, each tied to a named counterparty and to the evidence used to verify it. A transfer to an address that is not listed is not signed.
- Adding a destination. A new address is verified through a channel set up before the trade, such as a call-back to a number already on file, is approved by the quorum, and becomes usable only after a waiting period.
- Limits. The largest single transfer and the largest daily total each wallet may send without a higher approval.
- Initiation. Who may prepare a transfer, and the rule that the initiator's own signature does not count towards the quorum on it.
- Evidence. What must be attached to a request: the trade confirmation, the counterparty's settlement instruction, the allowlist entry.
- Exceptions. What a signer does when something does not match, who is told, and the rule that urgency is never a reason to sign.
Here is how it reads on an illustrative desk. The working wallet is a 2-of-3 with a limit of $500,000 per transfer; the reserve wallet is a 3-of-5. A trade settles with a delivery of $3,200,000 in a stablecoin to a counterparty. The amount is above the working wallet's limit, so the transfer is prepared from the reserve wallet and needs three signatures. The counterparty's address was added to the allowlist the previous week after a call-back, so the waiting period has passed. The operations lead prepares a test transfer of $1,000, the counterparty confirms receipt by telephone, and the remaining $3,199,000 follows. Each of the two transfers carries three signatures, none of them from the trader who agreed the deal.
The waiting period on new addresses is the control most often removed under time pressure. A destination substituted at the last minute is the case the rule exists for: an address added today cannot be paid today. The practical consequence is to collect and verify settlement addresses when the counterparty is onboarded, not when the trade is agreed.
The security standard cited earlier puts the verification step at its second level: destinations and amounts are verified through approved communication channels, meaning channels designated in advance, not whichever thread the instruction arrived on.
What does each signer check before signing?
Before signing, each multisig signer should independently confirm four things on the signing device itself: the destination address in full, the asset and network, the amount, and that the request matches a trade confirmation the signer has seen. A signer who signs because a colleague already has adds a signature but no control.
The device display matters because it is the last place where the true content of the transaction can be read. Where the device shows a readable address and amount, the signer compares them with the allowlist entry, character by character for the address. Where the device shows only a hash, a short fingerprint of the transaction, the signer recomputes that hash on a second, separate machine and compares the two before approving. The policy forbids signing anything the signer could not verify by one of these two routes.
If the address, asset or amount on the device differs from the request in any way, the signer does not sign, tells the reviewer through a separate channel, and the transfer is prepared again from the start. A late settlement can be explained to a counterparty; a transfer to the wrong address usually cannot be recalled.
Signers also need to recognise transactions that are not transfers. On smart-contract networks, the same quorum that sends funds can change the wallet's owners, lower its threshold, add an extension that can move funds without further signatures, or grant another address a standing right to spend a token. These are administrative actions, and the policy should require more scrutiny for them than for a payment, with a written change request and a reviewer's confirmation afterwards that the wallet's configuration matches it.
How is a signer rotated?
A signer is rotated by adding the replacement key and removing the old one under the wallet's normal quorum, as a planned change with a checklist, and the old key is treated as live until the network no longer recognises it. Rotation is due whenever a signer leaves or changes role, whenever a device or backup is lost or may have been seen by someone else, and on a schedule the desk sets for itself.
The mechanics depend on the kind of wallet. In a smart-contract multisig, owners are swapped by a transaction and the wallet's address stays the same. In a script-based multisig, the address is derived from the keys, so a new signer set means a new wallet: funds are moved across, and every counterparty holding the old address must be told through a verified channel. In a threshold-signature scheme, new shares are issued and the old ones made useless, with the address unchanged.
Take the illustrative 3-of-5 reserve wallet, and suppose the finance director who holds one key gives notice.
- Open a change requestThe wallet administrator records who is leaving, who replaces them, the reason and the target date. The request goes over the desk's approved channels, not by an informal message.
- Prepare the incoming signerThe replacement passes the desk's identity, reference and background checks, receives a new device, generates a new key on it personally, and stores the backup at a site that keeps the distribution rule intact: no site with more than two keys.
- Swap the key under the quorumThree of the current signers approve the change. Until this step, only four dependable signers remain, the number of usable combinations falls from 10 to 4, and the wallet can tolerate one further loss instead of two.
- Verify the new configurationThe reviewer reads the wallet's configuration from the network or the provider's log and confirms five signers, a threshold of three, and the old key absent. The new signer completes a small test signature.
- Retire the old keyThe departing signer's device is wiped and its backup destroyed in front of a witness, and both acts are logged. For a script-based wallet, the old wallet is emptied first and monitored afterwards for stray incoming payments.
- Update everything that named the old signerCall-back lists, the custodian's authorised-person list, bank and exchange mandates, the signer roster in the policy, and the duty schedule.
A desk that collects the leaver's device on the last day and plans to add a replacement "next month" has quietly become a 3-of-4, which tolerates one loss. One more departure or broken device leaves exactly three keys and no margin.
The security standard cited earlier describes the paperwork in rising levels: checklists covering every task when someone takes on or vacates a key holder role, requests to grant or revoke made over approved communication channels, and records of who carried out each step.
How does a desk recover from a lost or exposed key?
A desk recovers from a lost multisig key by using the remaining quorum to replace it at once, and from an exposed key by doing the same on the assumption that the exposed key will be used against it. Recovery only works if it was designed before the loss: once more keys are gone than the wallet tolerates, no procedure brings the funds back.
A lost key, such as a failed device with a missing backup, reduces the margin: the 3-of-5 still operates, with one spare instead of two. An exposed key, such as a recovery phrase that may have been copied, reduces the barrier: an outsider who holds one key needs two more, not three. The desk therefore rotates on suspicion, without waiting for proof.
A recovery plan answers these questions in advance, in writing.
- Which signers form the emergency quorum, and how they authenticate each other when normal channels may be unreliable.
- Whether funds are moved to a fresh wallet prepared beforehand, or the signer set is changed in place.
- Where the backups are, who can retrieve each one, and how long retrieval takes at each site.
- When the recovery key holder is called on, and what evidence that holder needs before acting.
A small desk or a family office whose signers are founders who travel together needs the same planning: a third-party recovery key, sealed instructions held by counsel, and a rule that a quorum never shares a vehicle.
The standard used as a benchmark here expects a documented key compromise policy and an inventory of all key material at its first level, an annual review of that inventory at its second, and a test of the compromise procedures at least once a year at its third. A drill is the practical form of that test: one backup is retrieved from its site, its seal is checked against the log, the key is restored onto a spare device, a test signature is made and the spare is wiped. The drill measures how long retrieval takes and proves the phrase was recorded correctly. Between drills, each signer, the recovery key holder included, signs a test message on a schedule, because a key that has not signed for a year is an assumption, not a control.
What can a counterparty ask to see about a desk's multisig?
A counterparty can reasonably ask an OTC desk to show how many approvals its wallets require, that it controls the addresses it will settle from, who by role holds approval rights, and what independent review the arrangement has had. A desk can answer all of that without revealing anything that weakens the control, and should decline to share the rest.
| What a counterparty asks for | What it shows | How it can be checked |
|---|---|---|
| Threshold and number of signers | That no single person can move funds | Read from the network for a native multisig; from a provider or auditor letter otherwise |
| Control of the settlement address | That the desk, not a third party, holds the keys | A message signed by the wallet, or a small transfer agreed in advance |
| Signer roster by role | That signers are independent of the trader | Policy extract naming roles, not individuals |
| Approval policy summary | Limits, allowlist rule, call-back procedure | One- or two-page extract of the written policy |
| Independent assessment | That someone outside the desk tested the controls | Report or certificate, with its scope, date and period covered |
| Custody arrangement | Whether a licensed third party holds assets | Custodian confirmation, checked with the custodian directly |
Two of these need care. A threshold shown onchain proves how many keys are required, not that the keys are held by different people: five keys in one safe still appear as a 3-of-5. An independent report is only as wide as its scope. A controls report prepared under the trust services criteria of the American Institute of CPAs can cover security, availability, processing integrity, confidentiality or privacy, and a certification against a security standard applies to a named system at a stated level. Ask which wallets and which period the document covers, and whether the controls were tested in operation or only described.
A desk should not hand over, and a counterparty should not expect, the names and home addresses of signers, the locations of devices and backups, the make of the devices, the duty schedule, and the full allowlist. A desk onboarding a fund or a treasury can put the same questions to its client.
