Beyond Multisigs: Execution Controls for Humans and Machines

Transcript

[applause] >> Yeah, thank you. So, this is a talk about control. Who has it? How do we enforce it? And why what we do today is not enough. And I want to start with a confession. Two weeks ago on Monday, almost all of the Gnosis Pay safes got backdoored. Most of the user funds got drained with just a public contract call.

And the bug was ours. It was in Zodiac. We built the um payment rails that sit under every user's credit card safe account. So, before anything else, two things. I'm sorry to everyone who was affected by it. I mean, yeah, you couldn't access your cards, couldn't use your card when you needed to, you couldn't access your funds for days. This is truly terrible, and I'm sorry for that. And second, to everyone at Gnosis who worked day and night to contain the damage, to bring back the infrastructure, to recover it,

and yeah, basically cared that every user's card goes back online in record time, a huge thank you. This was really an impressive feat under real pressure. And I'm not opening with it to dwell on it. I'm opening with it opening with it because this is a talk about security, and if we want to be serious about security, we have to be honest about our failures first. And I'm going to argue that this incident makes the case for what we do at Zodiac stronger, not weaker.

So, this was the bug. We dropped the static call's success flag, just one line, and it was harmless alone, but in a specific combination with safe's compatibility fallback handler, it became exploitable. The attacker could craft a transaction payload that made the signature check in safe revert with the EIP 1271 magic value. And since we didn't check the success the success flag, we interpreted this revert data as real return value and actually approved the signature.

Both contracts are were heavily audited and fine on their own, but became exploitable in combination. Let's go back 1 year or a bit more than 1 year to the biggest hack we ever had in crypto, and actually even the biggest heist ever beyond crypto, Bybit. 1 and 1/2 billion dollars were stolen. And here nothing broke. The signers signed, the hardware wallets worked, the threshold was met, the safe contracts worked according to spec.

But the safe web interface got compromised and showed legit transfer while the actual payload was swapping the safe's master copy, basically replacing the implementation and taking full control of the safe. HSMs, MPCs, TEEs, hardware wallets, multi-sigs, all our standard defenses are designed to protect the key, but this attack never needed the key. It compromised what the signers saw, and basically any centrally managed system, like an off-chain policy engine, can be compromised the same way.

The Yeah, can be corrupt the same way. And if you notice, the hardware wallets were not corrupted. They actually showed the real malicious payload. So, why didn't the signers catch it? Two reasons. One is repetition. Like approve the same kind of transfer every day and signing stops being a decision, but starts to become a reflex. You just stop reading it and hit approve. This is just how humans work, unfortunately, and attackers count on that.

And two, even if the signers had carefully checked on their devices, the devices they don't really show them what they're signing. They basically show raw hex data and no human can make sense of that. With initiatives such as clear signing, we are making real improvements here, but still also if the transaction shows up fully decoded on your device, it is asking a lot from signers if calls become more complex. Like a malicious call can sit in a huge multi-send with harmless calls buried deeply with a nested call, so it's really hard still also with decoded call data

to check every for every transaction if it does exactly what you want. So, if you can't count on a human at the time of signing to catch a bad transaction, not with more care, not with better hardware, what Yeah, what does it mean? It means that the safeguard can't live at the signature level. It has to live somewhere where it holds, no matter what the signers saw. Two different hacks.

Um in ours, our on-chain code had a bug. In Bybit Bybit's case, the chain was fine, but everything above it failed. But, yeah, these are opposite failure points, but the same conclusion. The only place where you can enforce intent is the chain itself. The signers can be tricked, the interfaces can be compromised, the bound on chain cannot. And our implementation was Yeah, our bug was in the implementation and not in the principle.

A smart contract bug is the kind of bug you can fix. Like, you can actually close it. You fix it once forever. But, yeah, with something like Bybit, it's much harder to fix because there's lots of people and system and off-chain systems involved that have to play together and get it right every single time. So, the real question, if a valid signature can authorize the wrong thing, how should we be doing the authorizing?

Today, control means trusting who is allowed to sign. You approve transactions one at a time, and a valid signature counts as authorization, and Bybit is what that costs. So, let's stop authorizing by signature and start authorizing by policy. You define up front what's allowed to happen, which action, which recipients, within which limits, and the chain enforces it. So, now it doesn't matter if the signer signers were tricked. The action If the action isn't in the policy, the chain will reject it.

And we no longer have to unlock full root access for every little routine action. None of this is new in principle. It has been true basically since the first multi-sig. But, what is new is a pressure. The model we've leaned on, trust to ever sign is breaking. Like a three out of five is per- perfectly fine for a small team of founders. It does not scale to an institution. Institutions and yeah, they carry regulatory burdens that must be enforced and not just be promised. And the stablecoin boom is bringing a lot of these institutions on

chain. And we have to earn their trust. And for that, we have to build security together. It's an ambitious and collaborative effort. But, the work that we put in on the smart contract layer, it compounds for the whole ecosystem. While any like vendors policy engine is basically a band-aid. It doesn't move the foundation forward. Also, in the future, agents will be how most people are using will will be using crypto.

You say what you want, the AI turns your intent into an executable transaction and sends it. And it already works really well. But, the blocker for serious capital is trust because you know that models they hallucinate, they drift, they can get prompt injected. So, how do we fix it? We fix it the same way we fix it for an for an institution. We define the policies and we let the chain enforce them. So, a confused or hijacked agent simply can't move value outside of the rules.

Humans or machines, same problem basically, same answer. So, this may seem like I'm theorizing a lot. So, let's look at how actually money gets lost nowadays. These are the hacks of this year. There have been a lot of them. All of the Yeah, I plotted all of those that I could verify. Bubbles are sized by dollars lost. And two big ones in April stand out. Drift and KelpDAO. And in each almost 30 million dollars were lost.

At Drift, they social engineered the security council into pre-approving a malicious transaction payload. And at KelpDAO, they compromised an RPC node that fed some spoofed chain state to a single verified uh single trusted verifier. And that verifier then waved through a malicious message. Both are operational failures. Not clever code exploits. So, the question is how do you put the operations themselves under control?

And Zodiac is our answer to that. The move is to take the operating rules you already have, but instead of putting them into some policy docs and trusting people to read these and follow them, you turn them into guarantees that the chain enforces right on top of the safe that you already own. And it comes down to three building blocks. One is the multi-sig threshold you already know, N out of M signers. Second, a delay module, which lets you put sensitive actions behind a time lock, giving you a window to react.

And third, roles, which let you give scoped permissions to pin down exactly which actions, which limits, and which recipients. And you combine these three building blocks to express specific controls. So, let me run you through a couple of patterns that you can build with Zodiac. For example, for routine payments, you can have a single operator that acts through a scoped role. Only allowed recipients, only within a monthly cap.

So, the routine action no longer drags every other signer into every single approval. Meanwhile, for admin operations, such as updating the permissions themselves, you can route these through a delay module. With a 24-hour time lock, this gives you a window to react, ensure that the transaction actually does what you expect it to, veto if you need to, so you have some time before the changes actually take effect. You can have tiered approvals.

The full four out of five multi-sig governs high-risk actions, while a lighter two out of five plugs into a role scoped to a set of low-risk actions. Let me make this more concrete. So, here's what a role to make on-chain payroll can look like. You set it up once in our app, and it can execute exactly one action, transfer USDC. And we set it to a total of up to 120,000 a month.

Then we set a recipients allow list to just 12 addresses of, yeah, all our employees, and we assign the roles to our HR reps. And now they can each use that role to trigger payments, salary payments without asking anyone else for approval. So, let's watch a payment go through. Our HR rep goes to pay a salary and fat fingers two extra zeros. She hit send and the chain just rejects it with an allowance exceeded error.

Nobody had to catch the mistake on the ledger. Nobody had to count zeros, check decimals. The Zodiac on chain guardrail caught it. And the same idea stops by it. Like you can restrict treasury rebalancing operations to a Yeah, to a list of your internal vaults and a malicious transfer just basically has nowhere to go. So, now we remove the extra zero, hit send, the send goes straight through, nobody has to review the call data or sign the transaction.

And this matters beyond convenience because routine payroll now runs efficiently. There's no signing ritual to go numb to. A mistake or a malicious transaction will just be caught by the on chain guardrails. We just watched a person use that role, but notice we no longer have to trust who signs a transaction or even if that who is a person at all. So, with the right permissions in place, we might as well hand payroll to an AI agent with a prompt such as Yeah, do June's payroll. Joe took two weeks unpaid leave, reimburse Suzy 1,500 bucks. Alice moved up a salary band. We

hit send. The agent can pull in all the context it needs. It figures out all the transfer transactions that we need to happen to make this month's payroll. And yeah, if it misreads, hallucinates, or even gets prompt injected into trying something crazy, it still can't exceed the budget and it still can't pay anyone off the list. So, we will always be able to recover from such mistakes. Same machinery basically as before, just pointed at a machine, and yeah, this is finally how you can hand your agents real money.

Our own hack, Bybit, the whole wave of hacks caused by poor operational security, the institutions, the agents, it all points to one shift. We need to stop trusting whoever signs, and instead enforce what's allowed. And we need to do that on chain, because that's the only place that can't be tricked or circumvented. And when it has a bug, like ours, that's the kind of bug you can fix once and for good. And open, because closed isn't safer.

A vendor's policy engine, like a closed source one, can be compromised just like the safe interface was. And hiding your sources doesn't really protect you. I mean, you don't hide them like you would hide a production secret. You have checked out to plenty of developers' machines. With leaks and AI reading everything, you basically have to assume that your sources are already out there. And open is actually the only model where independent defenders, white hats, read the same code that the attackers do.

Imagine the Ethereum Foundation participating in Project Glass Wing and running Frontier security tooling across the entire deployed smart contract surface, like treating Ethereum like one global product, because that's where composition bugs like ours hide. I think that is how we harden security for DeFi together. Well, that's basically the end of my talk. We just launched the Zodiac app. It lets you configure policies on top of your existing safes, no code required.

So, give it a try, please. Go to zodiac.eco and come talk to me. Reach out. This my Telegram Twitter handle. And yeah, reach out because we really want to help everyone, every team, every organization to operate on chain safely and securely. Thank you. >> [applause] >> All right. We have space for just one question. So, show of hands. Okay, we have someone.

>> I think Yeah. >> Hello. I've got a dumb question for you. Um those three blocks you're talking about, those three basic blocks of security capability or defense, the delay thing gives my stomach the most turn because like as a non-crypto guy, I see that and I see like that just delays like someone has to look at that later, right? Like or someone has to like to me that's like the same thing as just like kicking the can down the road. Can you explain like the risks and like your view on why is delay not just a like a weak uh mechanism?

>> Yes, you're touching on a very crucial point here. A delay is worth nothing if nobody basically watches what's going on. So, basically the moment something is enqueued, you really need to have monitoring in place so that people notice and actually review. But, the point that it delivers is that it locks in the actual transaction on the on chain state. And this is kind of the state that everybody can trust. This is the trusted surface. What I mentioned can't be circumvented and you can look at that state from like a diverse set of interfaces. So, you can use block explorers, safe transaction you can use every app to basically

inspect what was locked in and simulated and then build more and more confidence until it will actually be triggered. >> So, there should be like a policy attached to it like like someone needs to actually like do that stuff that you just said. >> Right. >> Otherwise, it's pointless, right? >> Right. You You still need off-chain systems to make sense of what's happening on chain. That's for sure. But I think our message is control needs to be enforced on chain and then you have diverse clients that basically let you make sense of what's going on on chain.