Can you keep $45,000,000?

“Protocol multisigs fail operationally more often than cryptographically.”Security Alliance, multisig security framework

Not our sentence. It is the one we keep coming back to. The failures that drain treasuries rarely touch the protocol or its cryptography. They happen in the operation around it: signer keys get phished. Routine actions run on permissions far wider than the task, where address poisoning, a manipulated frontend, or a simple mistake is enough. Admin changes land instantly and silently. Nothing broke, and the money is gone.

Zodiac's answer is structural. You compose the setup that fits your organization: vaults, policies with real limits, a timelock on power, a guardian with an exit. Every rule in that setup is enforced onchain, on every call that goes through it. Not by a runbook, not by a vendor's server, and not by us.

Whether that holds up is not something you settle in a blog post, so here is the challenge instead. Below is a treasury holding $45,000,000 in ETH and USDC (simulated, nothing onchain), and it starts where a lot of real treasuries start: a single key that can move everything. Your job is to make it survivable, and every dashed piece in the graph is a click away.

Start with Address poisoning and watch what the bare setup loses. Then add the Payroll policy, whitelist the Team wallets, and run it again. Seven more threats sit beside the graph, from a phished owner to a decimals bug in your own code, and each one runs against exactly the setup you have. Get all eight to $0, or get rekt.

Build it, then break it

On a phone, pick a ready-made setup in the threat card and run the threats against it. Building your own needs a bigger screen.

This is a demo, not an assessment: the treasury, the amounts and the eight outcomes are illustrative, and what your own setup survives depends on its signers, its policies and how it is run day to day. The Zodiac enforcement model is real. The settings tagged v3 in the editors (USD-priced budgets, the slippage bound, session expiry) preview Roles v3, which is in development. Everything else is Roles v2, in production today.

Why it holds up

Policies are contract state, not settings in an app. A policy lives on the treasury's own account and is checked onchain at execution time, on every call that goes through it. That is why a lying interface changes nothing. Whatever the screen said, the calldata still has to pass. It is why a stolen member key is an incident report and not an obituary, because the key can only do what its role allows and the destinations are pinned. And it is why no vendor, ours included, sits in the trust path. An app can propose transactions all day. It cannot authorize one.

A role is not a convenience. It is how you shrink the owner set. The fastest way to reduce the number of people who can move everything is to stop needing them. Once routine work runs on scoped roles, the people doing that work no longer need a key with full power, and the people who keep one use it rarely enough that using it is an event. Every task that moves onto a policy is one fewer reason for anybody to hold root.

The dangerous transactions look exactly like the work. A recipient address that matches your counterparty at both ends, an amount encoded with the wrong number of decimals: nobody signed anything they were not entitled to sign, and nothing about either transaction looks wrong to the person reading it. A queue and a veto do not help here, because a queue is human review, and human review is the thing being defeated. What stops them is a limit written down before the mistake. A recipient list the account checks. A budget it will not exceed. A price bound it will not cross.

A quorum stops one stolen key, not one careless signature. Two of five leaves an infiltrator holding a single key exactly where they started, which is why the patient ones go after the second signature rather than the first. A signature already sitting on a transaction is the strongest social proof there is. The structural answer is a public delay on everything the owners sign, wired so that no path around it exists, plus a separate guardian that can veto what is in the queue and, on the worst day, withdraw everything to safety.

Some things you survive only by being fast. When the protocol your deposits sit in is the one being exploited, nothing you signed was wrong and the only currency is minutes. A quorum does not assemble that quickly, and a delay, which exists to slow your own owners down, cannot be asked to hurry. So the speed goes to a machine. A monitoring service holds a role whose single capability is withdrawing your positions back into your own vault. It cannot choose another destination, cannot move anything out of the vault, and one transaction revokes it. The part that sounds reckless, a third party with a key that fires without asking anyone, is safe for exactly the reason every other role is.

None of this structure is our invention. Separated functions, a timelock on privileged actions, thresholds matched to blast radius: that is what the SEAL framework prescribes, and the council's 4-of-7 matches a threshold they suggest for large treasury transfers. One deliberate step beyond it: SEAL wants emergency paths that pause and never move funds. Our council can also withdraw everything, because its exit is pinned to your own vault. That is a trust decision you make when you seat it.

And the part worth re-reading: none of it waits on us. If Zodiac the company disappeared tomorrow, every rule you clicked into place would keep enforcing itself, unchanged.

Where we go deeper

This post is the start of a series about secure and efficient onchain operations. Over the coming weeks we go deeper, one topic at a time.

Follow the series on X, or get every part by email with the product newsletter.