The Math Under Your Wallet: Trail of Bits on MPC and TEEs

Every large crypto hack follows the same ritual. A protocol loses nine figures, the post-mortem names a function, and within hours a screenshot circulates of the audit report that supposedly cleared it. The implied question is always the same: who audited the code? It is the wrong question, or at least an incomplete one, because a growing share of the money that leaves this market never passes through a flawed smart contract at all. It leaves through the cryptography: a reused nonce, a key share that should have stayed split, a hash that was never bound to the context it was meant for.

Trail of Bits is best known for the smart-contract side of that story. Its open-source tools, Slither and Echidna and Medusa, sit in thousands of continuous-integration pipelines, and the New York firm has become a default reference for what a serious Solidity audit looks like. But it runs a second, quieter practice that rarely makes the headlines and matters more every year: applied cryptography. In late September and early October 2026 that team shipped two pieces of research, one on multi-party computation inside secure enclaves and one on a safer way to hash data, that together map the exact faults now draining institutional wallets. With Bitcoin near $85,744 and Ethereum near $2,702, and the total crypto market around $3.03 trillion, the value sitting behind those faults has never been larger.

The Headlines Audit Solidity; the Money Leaves Through the Math

Start with the loss data, because it settles the argument. CertiK’s Hack3d report for the first half of 2026 counted more than $1.31 billion lost across 344 incidents. The single most destructive category was not a clever reentrancy or an oracle trick. It was wallet compromise: over $444 million across just 33 incidents. The two largest events of the half, the Kelp DAO compromise ($291 million) and the Drift Protocol breach ($285 million), both in April, together accounted for nearly 44% of all first-half losses, and neither was a bug in a line of Solidity.

The lesson repeats until it is dull: the contract usually does exactly what it was written to do. The failure sits upstream, in how a key was generated, stored, split, or signed. That is a cryptography and key-management problem, and reviewing it is a different craft from reading Solidity for logic bugs. It is the craft Trail of Bits sells under a separate banner, and the one its two newest research notes put on display.

Who Reviews the Cryptography, Not Just the Contract

Trail of Bits describes its cryptography practice as covering zero-knowledge proofs, MPC, post-quantum, and the classical primitives underpinning modern systems. The makeup of the team is the tell. By the firm’s own account, half of it holds PhDs in cryptography and the other half ships production cryptographic code in Rust, Go, and C, under engineering director Jim Miller. That split matters, because cryptographic review lives between two worlds, the proofs on paper and the bytes in memory, and most failures hide in the gap between them.

The practice’s public record runs to more than 60 cryptography engagements and roughly 345 person-weeks of work, and the deliverables are not only PDFs. Trail of Bits ships continuous-integration rules, fuzzing harnesses, and formal walkthroughs that an engineering team can wire into its pipeline right away. The free output tells the same story: ZKDocs, an interactive reference for zero-knowledge systems; Circomspect, a static analyzer for zero-knowledge circuits; and CodeQL queries tuned to catch cryptographic misuse. The firm gives this material away partly on principle and partly as a hiring funnel, the same logic behind its long-running capture-the-flag guides; a higher floor for everyone is also a wider pool of people who can be trusted to build the hard parts. The instinct that produced Slither for Solidity produced a toolbox for the math underneath it.

Dan Guido, the firm’s co-founder, has described the motivation in plain terms. “I don’t ever want to find the same bug twice,” he told Decential; “that was the motivation behind creating a static analysis framework and a verification tool.” The cryptography practice is the same idea, applied one layer down from the contract.

A Nonce Is a Number You Use Once, or You Lose Everything

To sign a transaction with ECDSA, the signature scheme that secures Bitcoin and Ethereum accounts, a wallet picks a secret random number called a nonce, usually written k. The rule is in the name: use each k exactly once. Reuse the same k to sign two different messages and the two signatures share a public value, r, that sits in plain view on-chain. From that pair, ordinary algebra recovers the private key. No brute force, no supercomputer, just a short calculation, and the coins are gone.

This is not a chalkboard worry. In August 2013, a flaw in Android’s random number generator left it poorly seeded on many devices, so Bitcoin wallets signing multi-input transactions produced repeated nonces. Anyone scanning the chain for two signatures from one address that shared an r could derive the key and sweep the balance; the episode drained real wallets and forced a coordinated rotation of Android-generated keys. The academic treatment of the whole family, lattice attacks that recover keys from even slightly biased nonces, is sobering: you do not need full reuse, only a little predictability. Hold that picture, because it is about to return in a far more modern costume.

The fix the ecosystem reached for was to stop trusting the random number generator at all. A standard called RFC 6979 specifies a way to derive the nonce deterministically from the private key and the message, so two different messages can never share a k by accident, and most modern Bitcoin and Ethereum libraries use it. But determinism only closes the door for a single signer on a single machine. The moment signing is split across parties, or moved inside hardware that an untrusted host can manipulate, the one-time guarantee has to be rebuilt from scratch. That is precisely where the next two sections go.

MPC: Splitting the Key So It Never Exists

The institutional answer to key theft is to make sure there is no single key to steal. Multi-party computation, in its threshold-signature form, splits a secret across several parties so that a quorum can jointly produce a valid signature without any one of them ever holding the whole key. Fireblocks, the most widely deployed MPC infrastructure for institutions, puts the pitch bluntly: the full private key is never created, never stored, and never assembled at any point. An attacker who compromises one share cannot sign a transaction or reconstruct the key; they would need to compromise a quorum of shares at the same moment.

MPC is not multisig, and the difference runs deeper than marketing. Multisig lives on-chain, encoding an m-of-n rule in a contract or script that every blockchain implements its own way; the trade-offs there are their own long subject, one worth reading up on in its own right. MPC instead lives at the cryptographic layer, so it applies consistently across Bitcoin, Ethereum, Solana, and hundreds of other networks, and key refreshes or threshold changes happen off-chain with no new address and no transaction. For custodians moving institutional size, that chain-agnostic, operationally quiet model is why MPC became the default. Fireblocks alone reports processing more than $16 trillion in transactions and creating over 750 million wallets; providers such as Copper, Dfns, and the consumer-facing Zengo build on the same foundation. For ordinary users, the same technology is what lets a wallet drop the seed phrase entirely, which quietly reshapes who you are really trusting.

The appeal for a custodian is operational as much as cryptographic. A traditional cold-storage setup demands a physical signing ceremony for every large movement; an MPC system can enforce the same quorum in software, apply policy rules about who may approve what, and sign in seconds. That convenience is real, and it is why trillions of dollars now move this way. The catch is that the convenience rides on a protocol with many moving parts, and each part is a place a subtle bug can hide. Done right, MPC removes the single point of failure that a lone private key represents. Done wrong, it adds new ones, because the protocol is intricate and the implementations are still young.

The Catalog of Ways MPC Breaks

The list of MPC implementation bugs is now long enough to have its own reference site. mpcsec.org documents 27 real-world vulnerabilities, many of them disclosed by Trail of Bits researchers, and sorts them into seven families. The representative faults read like a bestiary of subtle mistakes: systems that accept elliptic-curve points without checking subgroup membership; Paillier moduli accepted without proof that they are well-formed; missing domain separation, where a hash reused across protocols without a context tag turns forging a proof into, in the catalog’s phrase, a coin flip per attempt; and, tellingly, presignature reuse, where nonce-extraction attacks become possible when signing artifacts are restored from a backup.

That last family should sound familiar. It is the 2013 Android bug again, dressed in threshold-signature clothing: the instant a nonce (here, a share of one) is used twice, the key leaks. The attack surface changed; the underlying mistake did not. The value of a catalog like this is that it turns folklore into a checklist, so the next team building a threshold wallet does not have to rediscover each trap by losing customer funds to it first.

Don’t Let the Chip Break the Math

One increasingly popular way to harden an MPC deployment is to run the signers inside a trusted execution environment: a hardware enclave such as Intel SGX, AMD SEV, or AWS Nitro that is meant to keep code and data secret even from the operator of the machine it runs on. The appeal is obvious. MPC spreads trust across parties, a TEE roots trust in silicon, and stacking the two looks like belt and suspenders. A wave of 2026 custody and infrastructure products leans on exactly this pairing; Turnkey, for one, competes by running key operations inside secure enclaves.

Attestation is the mechanism that is supposed to make a TEE trustworthy. The chip produces a signed measurement of the code running inside it, and a remote party checks that signature against the manufacturer’s certificate before trusting the enclave. It is a genuine advance, but it proves only what was measured. If the design measures the wrong things, or trusts storage the host can tamper with, the attestation can be perfectly valid while the system is already compromised.

Trail of Bits used its 25 September research note to explain why the combination can quietly make things worse. The two models do not share assumptions. MPC is built to avoid trusting any single party; a TEE, by contrast, centralizes trust in the hardware manufacturer that controls the root certificate. Bolt them together carelessly and a system can inherit the weaknesses of both while its operators believe they have the strengths of each.

Paul Bottinelli, the cryptographer who wrote the note, lays out the sharpest failure first. Because a TEE cannot by itself guarantee that the untrusted host is giving it honest storage, a “malicious host could roll back the filesystem state after a threshold signer deletes a used pre-signature, causing the signer to reuse their nonce share and disclose their private key share.” Read that slowly. The enclave did its job. The MPC math is correct. And the key still leaks, because the host was allowed to turn back the clock on disk and hand the signer a nonce it had already spent.

The Rollback That Reuses Your Nonce

The rollback attack deserves a slow look, because it ties the whole story together. A well-built threshold signer generates pre-signatures, consumes each exactly once, and deletes it so it can never be reused, the same single-use discipline the word nonce demands. The enclave is supposed to make that deletion trustworthy. But storage usually sits outside the enclave, on a disk the host controls, and if the design does not bind the enclave’s state to something the host cannot forge, the host can simply restore yesterday’s snapshot. The signer wakes up believing a spent pre-signature is fresh, signs again, and reproduces the 2013 Android catastrophe through a 2026 mechanism.

Bottinelli’s three other failure modes rhyme with it. If the attestation measurement leaves out a critical component, an attacker can modify that component without detection while still presenting a valid-looking attestation. If data availability is not guaranteed, a malicious host can serve a stale backup to force a rollback. And the host, sitting underneath the enclave, can run side-channel attacks to extract information the enclave believes is private. The firm’s recommendation is not to abandon TEEs but to treat them as defense-in-depth: one layer among several, never a substitute for a protocol that stays sound even when the hardware does not, with attestation bound tightly to the identities of the MPC parties.

Hashing a Bunch of Things Together Is Harder Than It Looks

If MPC and TEEs are where keys break, hashing is where proofs and messages break, and it fails in a way that looks far too simple to be dangerous. Cryptographers constantly need to hash several values at once; a line in a paper that reads compute N = Hash(X, Y, Z, A, B) is doing what Trail of Bits calls multihashing. The naive implementation glues the inputs together and hashes the blob, and that is where the trouble begins, because concatenation is ambiguous. Hashing the pair (ab, c) and the pair (a, bc) produces the same input bytes and therefore the same digest. Collisions the designer never intended become tools for an attacker.

Multihashing is everywhere once you look for it: it binds the inputs of a digital signature, the leaves of a commitment, the messages of a multi-round protocol, and the transcript a zero-knowledge proof is built on. Get the encoding wrong in any of those and the security proof silently stops applying. On 2 October 2026, Trail of Bits cryptographers Opal Wright and Scott Arciszewski published SequenceHash and its keyed sibling SequenceMAC to fix this for everyone not using Keccak. Keccak, the SHA-3 family, already ships a safe construction called TupleHash, but the enormous installed base of SHA-256 and BLAKE2 had no standard equivalent. SequenceHash supplies one: a double-hash construction similar to HMAC, plus an explicit length encoding that makes the boundaries between inputs unambiguous and neutralizes length-extension attacks regardless of the base hash. It is hash-agnostic, so a team can keep SHA-256 and still hash sequences safely. The specification is version 1.0.0, open source, and now part of the Community Cryptography Specification Project, with Go and Python implementations shipped alongside it.

Domain Separation, or How a Missing Tag Forges a Proof

SequenceHash’s most important feature is also its least glamorous: native support for customization strings, so a developer can bind a hash to a single purpose. This is domain separation, and its absence is a thread running through everything above. It is the mpcsec family where a reused hash becomes a coin flip for a forger. It is the heart of Trail of Bits’ widely cited work on weak Fiat-Shamir attacks, which showed how zero-knowledge proof systems that derive their challenges from an under-specified hash can be fooled into accepting proofs of false statements. SequenceHash lets a protocol lock a Fiat-Shamir transcript to a specific proof type, closing exactly that door.

Why should a token holder care about Fiat-Shamir transcripts? Because the integrity of a growing slice of the market now rests on them. Zero-knowledge rollups post proofs that a batch of transactions is valid; bridges increasingly verify proofs instead of trusting committees; privacy systems prove statements without revealing them. A proof system that accepts a forged proof is, in economic terms, an oracle reporting a false price: it lets value move on a lie. The market has already watched that failure play out when price oracles are manipulated across chains, and the cryptographic version is quieter and harder to spot. A missing context tag is precisely the kind of fault an audit focused on business logic sails straight past.

What a Cryptography Review Actually Looks Like

None of this is caught by a scanner. A cryptographic review is closer to a proof seminar than a lint pass: the reviewer rebuilds the protocol’s security argument, hunts for the assumption that quietly fails to hold, and only then checks whether the code matches the math. That is why Trail of Bits staffs the practice half with PhDs and half with shipping engineers, and why its peers are blunt about the limits of automation. “‘Claude, audit my smart contract, make no mistakes’ is not a security program,” David Schwed, chief operating officer at SVRN, told CoinDesk in a discussion of artificial intelligence in crypto security. Alexander Urbelis, chief information security officer at ENS Labs, made the deeper point in the same report: the bugs that drain treasuries often turn on intent and adversarial incentives, the very things a model does not reason about on its own.

Guido has been pressing a related argument about language design for years. Solidity and the EVM, he told Decential, have reinvented every security issue that modern languages like Rust, Go, and Swift had eliminated. The cryptographic layer is where that reinvention is most expensive, because the mistakes stay invisible until someone does the algebra, and by then the coins have already moved. A tool can flag a reused function selector; it takes a person to notice that a nonce can be replayed, that a modulus was never proven well-formed, or that a hash is doing the work of two different hashes at once.

The Money Really Does Leave Through the Keys

Step back from the primitives and the pattern in the loss data is impossible to miss. The costliest crypto failures of 2026 were not contract logic; they were keys, infrastructure, and the human and cryptographic machinery around them. Wallet compromise alone took more than $444 million in the first half of the year, and the two marquee incidents, Kelp DAO and Drift, were compromises of cross-chain and operational infrastructure rather than flaws in a smart contract. After funds frozen and returned, CertiK put the adjusted half-year total at about $1.2 billion.

An audit of the Solidity would have cleared most of these, and in several cases did. The value moved because of how keys and signing were handled, operationally and cryptographically. That is the terrain Trail of Bits’ cryptography practice works, and it is why who audited the contract is the wrong first question. The better one is who reviewed the cryptography, the key management, and the hardware you are trusting to keep a nonce used exactly once.

Zero-Knowledge and Post-Quantum: a Widening Surface

The cryptographic surface is still expanding. Zero-knowledge proving is moving from research curiosity to core infrastructure for rollups, bridges, and digital identity, which means more Fiat-Shamir transcripts, more hand-written circuits, and more places where a single missing domain tag can matter. Post-quantum migration is running in parallel: Trail of Bits has shipped the NIST post-quantum standards ML-KEM and ML-DSA into pyca/cryptography, one of the most widely used cryptography libraries in the Python world, and its researchers keep publishing fresh low-qubit estimates for the day a quantum computer could threaten secp256k1, the one curve sitting under most of the market’s value. Every one of these transitions is a fresh chance to reintroduce an old bug class in a new setting. The nonce you must use only once does not care whether the system around it is a 2013 Android phone or a 2030 post-quantum signer.

For Trail of Bits, this is less a prediction than a description of its order book. The same migration that pushes zero-knowledge proofs and post-quantum signatures into production is what fills a cryptography reviewer’s calendar, because every team making the jump is writing code against primitives it has never shipped before. A rollup team that was writing Solidity last year is suddenly maintaining a prover; a wallet vendor that leaned on a library is suddenly negotiating hybrid classical and post-quantum key exchange. Each of those shifts takes a well-understood system and swaps in a newer one whose failure modes the industry is still learning, which is exactly the moment an old bug class slips back in wearing new clothes.

Who Pays, and Who Regulates

There is still no regulator anywhere that accredits a smart-contract auditor, let alone a cryptography reviewer. In the United States, the SEC under chair Paul Atkins has reoriented its crypto agenda around token classification and a promised rulebook, not code or cryptography standards, and its enforcement posture has cooled markedly from the crackdown of the prior administration. Custody rules touch the edges, and MPC has had a quiet nod from regulators as a valid self-custody model since 2019, but nobody is certifying that a given threshold-signature implementation handles its nonces correctly. Quality is policed by reputation, by the publication of audit reports, and by the slow accumulation of catalogs like mpcsec.org. For a holder, that means the burden of asking the right questions falls on builders first and, in the end, on the user.

In that vacuum, the market has improvised its own signals. Custodians lean on SOC 2 reports and insurance, publish proof-of-reserves attestations, and point to the brand names of the firms that reviewed them. None of those is the same as a guarantee that the cryptography is correct, and a holder who treats a logo as a warranty has misread what an engagement actually certifies: that a specific version of specific code was examined, for a specific time, against a specific threat model, and nothing more.

What Builders and Holders Should Take Away

The practical reading of Trail of Bits’ recent work is not that MPC or TEEs are bad. They are real improvements over a single hot key on a single server. It is that they are not magic, and that the marketing word secure hides a stack of assumptions worth interrogating. A team shipping an MPC wallet should ask who holds the root certificate behind any enclave in the design, whether state is bound so the host cannot roll it back, and whether every hash in the protocol is domain-separated. A team deploying a zero-knowledge system should treat its Fiat-Shamir transform as a security-critical component, not plumbing. An institution choosing a custodian should ask for the cryptography review, not just the Solidity audit, and read what it actually says. And because smart accounts under account abstraction are making key management programmable for ordinary users, the stakes on getting the underlying cryptography right are only rising.

The uncomfortable truth in the loss data is that the industry has become very good at auditing the part of the system that fails least expensively. The math underneath, the keys and nonces and hashes most users never think about, is where the money actually goes. Trail of Bits built an entire practice on that premise, and its newest research is one more reminder that the honest answer to whether something is secure usually depends on a question almost nobody asks.

Frequently Asked Questions

What is the difference between MPC and multisig wallets?

Multisig enforces an m-of-n rule on-chain, so several complete private keys must each sign, and the logic is implemented separately on every blockchain. MPC, or multi-party computation, splits a single key into shares using threshold cryptography so the full key is never assembled, and it works the same way across Bitcoin, Ethereum, Solana, and hundreds of other chains because it operates at the cryptographic layer rather than in a contract. MPC removes the single stored key, but it adds protocol complexity that has to be implemented carefully.

Why is reusing a nonce so dangerous in crypto?

A nonce is the one-time secret number a wallet uses when signing with ECDSA, the scheme behind Bitcoin and Ethereum accounts. If the same nonce signs two different messages, the two signatures expose a shared value on-chain from which anyone can compute the private key with simple algebra. A 2013 Android randomness bug caused exactly this and drained Bitcoin wallets, and the same failure reappears in modern threshold-signature systems when a used pre-signature is restored from a backup.

What did Trail of Bits say about running MPC inside a TEE?

In a 25 September 2026 post, Trail of Bits cryptographer Paul Bottinelli warned that trusted execution environments and MPC have conflicting trust models, because MPC avoids trusting any one party while a TEE centralizes trust in the hardware maker. He described failure modes including a malicious host rolling back storage to force nonce-share reuse and key disclosure, incomplete attestation, stale-backup rollbacks, and side-channel leakage, and he recommended treating TEEs as a defense-in-depth layer rather than a replacement for a sound protocol.

What is SequenceHash and why does it matter?

SequenceHash and SequenceMAC are hash constructions published by Trail of Bits on 2 October 2026 that let developers safely hash multiple values together using hash functions other than Keccak, such as SHA-256 and BLAKE2. They use an HMAC-like double hash plus explicit length encoding to prevent ambiguous encodings, length-extension attacks, and cross-context replay, and they support customization strings for domain separation. The specification is open source and part of the Community Cryptography Specification Project.

Are smart-contract audits enough to keep crypto safe?

No. In the first half of 2026, CertiK attributed the single largest share of losses to wallet compromise, more than $444 million, rather than to contract bugs, and the two biggest incidents, Kelp DAO and Drift, were infrastructure and operational compromises rather than Solidity flaws. A contract audit checks program logic; it does not review key management, the cryptographic protocols behind a custodian, or the hardware you trust to keep a nonce used only once. Those require a separate cryptography review.

By Anneke de Vries, HOGE Wire security desk.