Institutional custody has to answer two separate questions. First: who is allowed to authorize a transaction? Second: what are they allowed to authorize? Key-centric custody answers both on a vendor’s infrastructure — and the two questions fail in different ways, so it’s worth separating them.
Signing: MPC vs. the multisig smart account
MPC splits a private key across multiple parties — typically two or three — so that no single party ever holds the full key. Signatures are produced collaboratively through a protocol that never reconstructs the key. Compromise any single party and you don’t get the key. It’s a genuinely good answer to “don’t let one machine hold the whole key.”
But notice what it is: an off-chain reimplementation of what a multisig already does on-chain. A Safe is a smart-contract account whose owners and threshold live in contract code on the chain the assets sit on. That m-of-n logic is immutable bytecode, protected by the blockchain, and verifiable by anyone. MPC moves the same “no single point” guarantee into a vendor’s protocol and presents on-chain as a single opaque key — so the multi-party guarantees now depend on the vendor’s protocol and the vendor’s infrastructure being sound. The multisig keeps them on the chain.
Here’s the part neither one fixes: a valid signature is not a statement of intent. MPC and multisig both authorize any transaction that clears their signing rule — including a malicious one the signers were tricked into approving. The ways that happens:
- Frontend / dashboard compromise. The interface used to construct and approve a transaction can be modified to show one thing and submit another. The signer signs; the signature is valid.
- Adversarial counterparty data. An agent or operator that pulls external data into its decision logic can be steered into authorizing transactions that look legitimate but aren’t.
- Operator coercion or social engineering. A legitimate operator, pressured or coerced, can produce a perfectly valid signature on a malicious transaction.
Policy: a vendor’s engine vs. the chain’s
Closing that intent gap takes a second layer: a policy engine that says what a signature is allowed to do — allowlists, per-asset limits, approval rules. Bybit is the case in point: a Safe multisig produced a perfectly valid signature on a transaction its operators never meant to approve, because the centrally hosted interface that assembled it had been compromised. The signing layer did exactly its job; what was missing was a rule that refused the unapproved contract upgrade. Every serious vendor ships such a policy engine. The only question that matters is where it runs.
Vendor policy engines run on the vendor’s own centrally hosted infrastructure — the same class of system whose compromise drained Bybit. They’re frequently attested by a TEE to argue the logic wasn’t tampered with, but that only moves the trust; it doesn’t remove it. You still depend on one vendor’s uptime, keys, attestation chain, and lock-in. If the service is subverted, or the interface and data feeding it are, the policy is subverted with it. You’ve added a second lock to the same door.
An onchain policy engine is different in kind. The rule is contract bytecode, enforced by the same chain that settles the transaction. It always holds: there’s no separate service to keep honest, no vendor to trust, no attestation to forge, and nothing to migrate off of. To get past the policy you’d have to get past the chain — which is no one’s threat model. Concretely: instead of a Safe whose owners can move any amount of any token anywhere, a Roles module scopes signers to specific contracts, function selectors, parameter ranges, and per-period caps. Any transaction outside the role reverts at the account, regardless of who signed it or what the interface displayed. In Bybit’s case, a rule gating implementation upgrades would have reverted the malicious call — and the compromised interface could have done nothing about it.
And the thing running that vendor engine has a poor track record
There’s a second reason to be wary of putting the policy engine in a TEE: the empirical security record of production TEEs over the past decade has been bad. A non-exhaustive list of attacks that successfully extracted secrets from production enclaves:
- Foreshadow / L1TF (2018). L1 cache side-channel extraction of SGX attestation keys.
- Plundervolt (2019). Undervolting-based fault injection inside SGX.
- SGAxe + CacheOut (2020). Attestation key recovery enabling forged quotes.
- SpecROP, LVI, ÆPIC Leak (2020–2022). Speculative execution and CPU bug classes that affect enclave integrity.
- Battering RAM (2024). Sub-$50 DDR4 interposer extracting SGX provisioning keys.
- WireTap (2024). Hardware monitor capable of extracting attestation keys via memory bus probing.
- Iago attacks. Malicious kernels steering enclave control flow by returning crafted syscall results.
- ECALL/OCALL side channels. Size and timing patterns at the enclave boundary leaking inputs.
Each of these has been mitigated, in some cases at significant performance cost. The pattern is: a new attack class is published, the vendor issues microcode updates, a new attack class is published, the vendor issues more microcode. The assumption that the silicon is trustworthy has been falsified repeatedly enough that “trust the silicon” isn’t a defensible foundation for the policy engine guarding institutional-scale custody.
This isn’t a polemic against TEEs in general. They’re useful for many things. Anchoring the enforcement of tens of billions of dollars to a silicon attestation chain with a long history of being broken is a specific choice that deserves more scrutiny than it gets.
Where MPC still wins
We should be honest about what MPC does better than smart-account custody. The biggest one is reach: MPC works across signature schemes — Bitcoin, Solana, Cosmos, every chain with its own cryptography. Smart-account custody is EVM-native and gets harder the further you go from Ethereum.
For an institution that needs first-class support for non-EVM chains today, MPC is the right tool. For institutional onchain operations on EVM — where the vast majority of onchain value sits — moving both answers onto the chain is structurally stronger.
The synthesis
Custody answers two questions — who can authorize, and what they can authorize. MPC and vendor policy engines answer them on the vendor’s infrastructure, with the vendor in the trust path and lock-in baked in. Onchain custody answers both on the chain: a multisig account decides who, a policy module decides what, and both are immutable bytecode the chain enforces before any state changes. No vendor, no separate enforcer, nothing to migrate off of.
We’re building Zodiac as the open standard for that pattern on top of Safe. If your custody architecture today depends on the assumption that the key — or the vendor running your policy — is the boundary, we’d like to walk through your threat model with you.