Treasury and multisig operations, day to day
Setting up a multisig treasury: the propose, verify, sign and execute routine, signer changes, Bitcoin descriptors and PSBTs, and records an auditor can follow.
Updated 14 Sept 2026 · Advanced · 4 min read
In short
- A multisig is only as strong as the routine around it: who proposes, how each signer verifies, and what happens when a signer leaves.
- Every signer checks each transaction independently, on their own device, before signing. Nobody signs because the others already have.
- Back up the configuration as well as the keys. A Bitcoin multisig needs its descriptor to be restored, and a Safe needs its address, chains and owners on record.
Set it up to be operated
- Threshold. High enough that no single person or small group can act alone, low enough that the treasury still works when two signers are travelling. 3-of-5 and 4-of-7 are common for organisations; 2-of-3 suits smaller ones.
- Signers. Different people, each on their own hardware wallet, ideally from more than one manufacturer, kept in different places. Nobody should hold two keys.
- Tiers. A high-threshold vault for reserves and a lower-threshold operating wallet for payments, topped up on a schedule. Protecting a treasury covers the design; this guide covers running it.
- Receiving. A Safe is deployed separately on each chain, so the same address on another network is not automatically yours. Confirm the Safe exists, with the owners you expect, on every chain you will receive funds on.
Record the configuration
Keys alone do not restore a multisig. For a Bitcoin multisig you also need its output descriptor: the script type, every signer’s extended public key and derivation path, and the threshold. With the descriptor and enough seeds you can rebuild the wallet in any compatible software. Without it, even a quorum of seeds may not be enough, because the missing signers’ public keys cannot be derived from anyone else’s. Keep a copy of the descriptor with every seed backup. It cannot spend, but it reveals every address and balance, so store it privately.
For a Safe, record its address, the chains it is deployed on, the owners, the threshold, the Safe version and any modules or guard. Our contract admin inspector reads the live owners, threshold, modules and guard, so you can check your record against the chain.
The routine: propose, verify, sign, execute
- Propose. One person creates the transaction, with a written reason and the source of the destination address, ideally an approved request in your accounting or ticketing system.
- Verify independently. Each signer checks the destination against the approved address list, never a chat message; the amount against the request; and, for EVM transactions, the operation type and decoded calldata. Anything more than a plain transfer gets extra scrutiny.
- Check the hash. For a Safe, compare the safeTxHash on your hardware wallet with one computed independently. Our Safe transaction checker decodes pending transactions, flags delegatecalls, owner changes and unlimited approvals, and recomputes the hash. Verifying a Safe transaction explains, through the Bybit theft, why this step matters.
- Sign on the device. Read the details on the hardware wallet’s screen, not only on the computer.
- Execute and reconcile. Once the threshold is met, execute, confirm the result on-chain and record the transaction hash, who signed and the request it fulfilled.
Safe transactions execute in nonce order. To cancel one that is queued, create a rejection, an empty transaction with the same nonce, and have it signed and executed; until then the original can still be executed by anyone once it has enough signatures.
Bitcoin multisig and PSBTs
On Bitcoin the same routine runs on PSBTs. A coordinator such as Sparrow builds the unsigned transaction, and it passes between signers by file, QR code or USB, collecting signatures until the threshold is met. Before signing, open it in our PSBT decoder, which runs in your browser, to see every output, the fee and which output returns to the wallet as change.
Register the multisig configuration on each hardware wallet when you set it up. A device that knows the wallet can confirm that the change output really belongs to it; one that does not has to take the computer’s word for it.
When signers change
People leave, devices fail and keys get exposed. Decide how you will handle each case before it happens.
- On a Safe, owners and the threshold can be changed by a transaction that the current threshold signs. Swap a departing owner for a new one promptly: a former employee’s key remains a valid signer until you remove it.
- On Bitcoin, the keys are built into every address the wallet creates, so a signer cannot be removed. Create a new multisig with the new set of keys, check it with a small deposit, then move the funds across.
- One suspected compromise is not an emergency in a well-built multisig, but it uses up your margin. Rotate that key as above, and treat a second compromised key as an incident.
Monitoring, records and drills
Wardcrest monitoring watches a Safe for owner, threshold, module and guard changes and analyses pending transactions before they execute. It also follows timelocks and watches Bitcoin wallets through their xpub, and alerts the people on call by email, Slack, Telegram, PagerDuty or webhook.
- Every quarter, have each signer prove that their key and device still work, for example by signing a test transaction that is never executed.
- Once a year, rehearse restoring the wallet from backups on spare hardware.
- Keep the signer list, the configuration record and the incident contacts current, and review access whenever someone joins or leaves.