A multisig treasury is a wallet that needs approval from several independent signers before any transaction can execute, so no single person, device or stolen key can move your funds. Setting one up properly takes more than deploying a contract and adding names: you need separate wallets by purpose, a signer policy, a threshold that fits your team, a verification routine and a plan for the day something goes wrong. This checklist walks through each stage in order, with a short reason behind every item.
It deliberately skips the question of whether to use a multisig at all. If you are still choosing between multisig, MPC and a custodian, read crypto custody solutions for token teams first, then come back here to set it up.
Why Setup Matters More Than the Tool
A multisig only protects you as much as its weakest assumption. Three signers who share one laptop, one cloud backup or one person's judgment are a single point of failure with extra steps. Proceeds that land in a single-signer wallet during a sale undo every other control, a recurring problem described in public token sale mistakes. Get the structure right before any funds arrive.
Section 1: Before Deployment
- Define wallets by purpose. Create separate wallets for the treasury reserve, day-to-day operations, market maker allocations and vesting administration. Why: a compromise or mistake in a frequently used wallet should never expose the long-term reserve.
- Write a one-page treasury policy. State which wallet holds what, who may propose, who may sign, and what size of transfer needs extra approval. Why: rules agreed in advance are far easier to follow under pressure than rules improvised during an incident.
- List every privileged role in your contracts. Token owner, minter, pause, upgrade and vesting admin roles all need a home. Why: you cannot move them to the multisig later if you never inventoried them.
- Choose widely used, audited wallet software. On EVM chains that usually means an established smart-contract wallet such as Safe; on other chains it means that ecosystem's standard multisig tooling. Why: popular tooling has more reviewers, better signer support and more recovery knowledge in the community.
Section 2: Signer Selection and Policy
A good multisig signer policy answers who signs, on what hardware, from where, and under what conditions. Write it down.
- Use a hardware wallet for every signer key. No browser extension keys, no keys in a password manager. Why: hardware devices keep the private key off internet-connected machines and show you what you approve.
- One person, one key, one device. No signer holds two keys in the same multisig, and no two signers share a device. Why: a threshold of three means nothing if two keys fall to the same theft or the same person.
- Separate locations and networks. Avoid signers sharing an office, a home, a cloud account or a seed backup location. Why: physical or account-level compromise should hit one signer, not several.
- Require each signer to confirm they can sign. Test the hardware wallet and the signing flow before any funds move. Why: discovering a broken device on launch day is expensive.
Section 3: Threshold Design
Your multisig threshold is the number of approvals required out of the total signers. Higher thresholds resist compromise but slow down operations; lower thresholds do the opposite. The right choice depends on the amount at risk and how fast you need to act.
| Configuration | Security profile | Operational profile | Typical fit |
|---|---|---|---|
| 2-of-3 | Tolerates one lost or compromised key; two colluding or compromised signers are enough to move funds | Fast to coordinate; losing two keys locks the wallet | Small operations wallets and early-stage teams |
| 3-of-5 | Tolerates two lost or compromised keys; needs three to act | Reasonable speed; still works if two signers are unavailable | Core treasury for most funded projects |
| 4-of-7 | Needs a larger majority; resists collusion and compromise better | Slower coordination, more signers to track and rotate; tolerates three unavailable | Large reserves, DAO treasury multisig, protocol-level admin |
- Choose thresholds per wallet, not one for everything. An operations wallet can run lighter than the reserve. Why: matching friction to risk keeps routine work moving.
- Avoid thresholds equal to the signer count. A 3-of-3 has no tolerance for a lost key. Why: one dead device becomes permanent loss of access.
Section 4: Deployment and Verification
- Deploy from a clean setup and record the address on every chain. Why: you want a documented, reproducible origin for the wallet.
- Verify the signer set and threshold on-chain. Read them from the contract or ledger, not just from the interface. Why: the interface can display what you expect while the chain says otherwise.
- Send a small test transaction in and out. Receive a minimal amount, then send it back with the full signing process. Why: it proves every signer can sign and the process works before real value is at stake.
- Move admin roles to the multisig, then verify. Transfer ownership of token, vesting and any upgrade or pause roles, and confirm the new holder on-chain. Why: an admin key left on a deployer address undermines the entire setup. Audit the contracts first so you know exactly what each privileged function can do.
- Set up an address book or allowlist where the tooling supports it. Pre-approve recipients such as the vesting contract, your operations wallet and your market maker's address. Why: it cuts the chance of pasting a wrong or poisoned address.
Section 5: Operating Procedures
- Decode every transaction independently. Before signing, check the destination, function and parameters on a separate device from the one that proposed it, and compare the transaction hash your hardware wallet displays with the one in the interface. Why: blind signing, where you approve data you cannot read, is one of the main ways a compromised interface tricks signers into draining a multisig.
- Never sign what you cannot read. If the hardware wallet shows only raw data, pause and decode it elsewhere. Why: a malicious payload can look routine in a summary screen.
- Document a signing SLA. Agree response times and coverage across time zones, especially for launch day, listings and liquidity operations, and name backup signers for each window. Why: a transfer that waits twelve hours for the one available signer can stall a launch. See the TGE launch day runbook for how this fits the wider timeline.
- Run periodic signer liveness checks. Every quarter, have each signer sign a harmless message or minimal transaction. Why: it exposes dead devices, forgotten PINs and unreachable people before an emergency does.
Section 6: Signer Rotation and Offboarding
- Define triggers for rotation. Departure, role change, lost device, suspected exposure or a scheduled review date. Why: without triggers, stale signers accumulate.
- Add the new signer before removing the old one. Why: it keeps you above the threshold throughout the change.
- Verify the new set on-chain after every change. Why: a rotation that silently failed leaves a former employee with signing power.
Section 7: Emergency and Incident Plan
- Name an incident lead and a backup. Why: one person coordinates while the rest follow, instead of everyone acting at once.
- Predefine the first moves. Pause what can be paused, stop signing, reject suspicious queued transactions and move remaining funds to a pre-prepared recovery wallet if the threshold allows. Why: minutes matter and improvisation costs time.
- Prepare a recovery wallet in advance. A fresh multisig with independent signers, ready to receive funds. Why: you do not want to design one mid-crisis.
Section 8: Transparency to the Community
- Publish treasury and admin addresses. List each wallet, its purpose, its threshold and the chain. Why: holders can verify your claims and track movements themselves.
- Publish the multisig structure. Share the threshold and, if you are comfortable, signer roles. Why: it shows control is distributed rather than trusted on faith.
- Report periodically. Share a short summary of inflows, outflows and role changes. Why: consistent reporting builds trust and supports sound treasury management.
Putting It Together
If you only have time to do five things, do these: separate wallets by purpose, put every signer on their own hardware wallet, decode transactions on a second device, move all admin roles to the multisig, and publish the addresses. The rest of the list hardens the process, but these five close the gaps that cause the most damage.
Good treasury structure also makes liquidity work cleaner. When market maker allocations are funded from a dedicated wallet with its own threshold and allowlist, the loan or inventory transfer is simple to approve, easy to verify and easy to report. If you are planning a listing or a liquidity program and want your wallet structure to support it, get in touch with Fibonacci Capital and we will help you set up allocations from the right wallet.