Is a TEE Safer Than a Multisig Bridge?
Rift Research
Last updated
Neither is safe. They fail differently, and that difference is the entire decision. A multisig fails when enough signing keys are compromised, which historically has happened through spear phishing and endpoint malware rather than anything cryptographic. A TEE fails when the hardware vendor, the data centre, or someone with physical access to the machine is compromised. One threat model is remote and cheap. The other requires physical access or a vendor-level break.
The short version
- Every multisig bridge failure on record was a key compromise, not a cryptography failure. Attackers used ordinary IT intrusion.
- A threshold below a state-level attacker's budget is not a security model. Ronin required 5 of 9 and lost roughly $624M. Harmony's Horizon required 2 of 5 and lost roughly $100M.
- TEEs are not unbreakable. Published research extracts secrets from Intel and AMD DDR5 enclaves via physical bus interposition, including attestation keys.
- The distinction that matters is remote versus physical. A multisig threshold can be met from anywhere on the internet. The documented TEE attacks require physical access to the machine.
- Most TEE systems still contain a multisig. It usually governs upgrades rather than execution, which is a materially smaller blast radius.
What breaks each model?
| Model | What has to go wrong | Attack surface | Recovery if it fails |
|---|---|---|---|
| Multisig | Enough signing keys compromised to meet the threshold | Remote. Phishing, endpoint malware, insider access, key management failure | None. Funds move irreversibly once the threshold is met |
| MPC / threshold signatures | Enough key shares compromised. No single party holds a full key | Remote, but requires compromising multiple independent parties | None, unless the protocol has a separate freeze mechanism |
| Optimistic verification | A fraudulent assertion goes unchallenged through the dispute window | Remote, but requires every honest watcher to fail simultaneously | Dispute and slash, if someone is watching |
| Economic security | Attack value exceeds bonded value at risk | Economic rather than technical. The security budget is observable onchain | Slashing, which compensates but does not prevent |
| TEE | Hardware vendor compromise, data centre compromise, or physical access to the machine | Physical, or a vendor-level break in attestation | Depends on the upgrade and refund mechanism sitting around it |
What does the historical record actually show?
Multisig failures dominate the loss record, and none of them were clever.
Ronin, March 2022. A nine-validator set with five signatures required to approve withdrawals. Sky Mavis controlled four validators directly and held a delegated signing key for a fifth through the Axie DAO. Attackers compromised the four Sky Mavis nodes through a spear-phishing job offer and used the leftover DAO delegation to clear the threshold. They drained 173,600 ETH and 25.5M USDC.
Harmony Horizon, June 2022. A two-of-five multisig authorised withdrawals. Attackers compromised two signer keys, most likely through endpoint malware, and drained roughly $100M. Harmony confirmed the smart contracts and consensus were intact. Horizon was later upgraded to four-of-five.
Multichain, July 2023. Not a hack in the conventional sense. The CEO was reportedly detained and personally held the keys to the MPC custody wallets, so nobody else could move or refund the locked assets.
The pattern is consistent. The cryptography held every time. The people and the machines around it did not.
What breaks a TEE?
Stating this plainly is the point of the page.
Side-channel research is active and ongoing. Published attacks against Intel TDX modules include TDXdown and TDXploit. Independent security assessments have identified vulnerabilities in TDX module firmware. Side-channel attacks that leak memory access patterns are explicitly outside the scope of most vendor assessments.
Attestation itself has been broken in a lab. The TEE.Fail attack, from researchers at Georgia Tech, Purdue and Synkhronix, uses physical interposition on DDR5 memory to extract secrets from confidential VMs on both Intel and AMD. That includes ECDSA attestation keys from Intel's Provisioning Certification Enclave. In the researchers' framing, an attacker can pretend code is running inside a confidential VM when it is not, read the data, and return incorrect output while still passing attestation.
What that means in practice. TEE.Fail requires physical access to the machine and specialised equipment on the memory bus. That places the attack within reach of a data centre operator or someone who can coerce one, and out of reach of a remote attacker with a phishing kit. It does not make TEEs unbreakable. It makes them break under a different and more expensive threat model.
The honest summary. A TEE moves trust from a set of key holders to a hardware vendor and a data centre operator. That is a real trade, not an elimination of trust. Anyone claiming a TEE is trustless is wrong.
What does Rift trust, specifically?
Rift runs execution inside Intel TDX enclaves in Google data centres. It uses both models rather than choosing one.
Trusted: Intel, that attestation keys are not compromised and no critical vulnerability is unpatched. Google, that it is not tampering with the hardware and is maintaining physical security.
Not trusted: the team's ability to change running code. Upgrades are gated by an Ethereum contract holding the approved image hash, a multisig of hardware keys, and a seven-day timelock. Onchain reads are verified two-of-three across independent RPC providers inside the enclave.
The multisig is still there. It governs upgrades, not execution. A compromised majority cannot move funds; it can propose a malicious image, which then waits seven days in public. During that window any single uncompromised signer can refund all users.
Given up: permissionlessness. Anyone with enough stake can validate on a proof-of-stake chain. Nobody can run a Rift node without the hardware and the deployment.
Not yet done: no formal audit. Production runs on one cloud and one hardware vendor, which is the concentration this model is meant to reduce through multi-cloud deployment.
How do you verify a TEE claim yourself?
This is the property a multisig cannot offer, and it is checkable rather than promised.
- Take the attestation report from the running instance. It contains a measurement hash of the system image.
- Build the image from the published open-source repository.
- Compare the hashes. If they match, the hardware is asserting that the code you just read is the code that is running.
What this proves. That the running code matches the published code, conditional on attestation being intact.
What it does not prove. That the hardware is honest. TEE.Fail is precisely an attack on that conditional. Verification tells you the code is what it claims to be. It does not tell you the silicon is.
When is a multisig the better choice?
- When you need permissionlessness. A TEE deployment requires specific hardware in a specific data centre. Anyone can be a signer on a multisig.
- When you cannot accept vendor concentration. A TEE deployment on one cloud and one chip vendor is two single points of failure. A geographically and organisationally distributed signer set is not.
- When the signer set is large, independent and publicly identified. Ronin and Harmony failed because thresholds were low and signers were concentrated, not because multisig is inherently broken. A high threshold across genuinely independent parties is a serious security model.
- When you need no hardware dependency at all. Software-only systems cannot be attacked through the memory bus.
Sources
- Ronin validator structure, attack path and losses — Eco, "Are Crypto Bridges Safe? Hack History and Risk Tiers": https://eco.com/support/en/articles/15183716-are-crypto-bridges-safe-hack-history-and-risk-tiers
- Ronin and Harmony threshold analysis — Immunefi, "Common Cross-Chain Bridge Vulnerabilities": https://medium.com/immunefi/common-cross-chain-bridge-vulnerabilities-d8c161ffaf8f
- Harmony Horizon 2-of-5 multisig and remediation — Halborn: https://www.halborn.com/blog/post/explained-the-harmony-horizon-bridge-hack
- Cross-chain bridge hack taxonomy — "SoK: A Review of Cross-Chain Bridge Hacks": https://arxiv.org/html/2501.03423v1
- TEE.Fail attestation key extraction on Intel and AMD DDR5 enclaves — The Hacker News: https://thehackernews.com/2025/10/new-teefail-side-channel-attack.html
- Intel TDX firmware vulnerabilities and TDX side-channel research — "Security Assessment of Intel TDX": https://arxiv.org/pdf/2602.11434
Related: 12 Cross-Chain Swap Venues Compared scores the trust model of every major execution venue.