One compromised person should not be enough

A wallet can require several people to approve a transaction while one developer controls the software that checks withdrawal requests. If that developer can change the checks a signer relies on, an attacker with access to their account may not need to steal a private key. Changing what the system is willing to sign could be enough.

In its October 30 incident update, Binance said its initial investigation suggested a compromised DevOps laptop had given an attacker access to a service container and the ability to submit unauthorized withdrawal transactions. It estimated the impact at $6.3 billion and reported no evidence of a wallet private key leak. In a follow-up update, Binance reported additional points of breach. These preliminary accounts do not establish the full attack sequence, but they underline why protecting the keys alone is not enough.

The same reasoning behind requiring multiple signers applies here: changes to the software that uses the keys should also require independent approval.

Limited access can still give one person too much control

Least privilege is usually explained as giving each person only the access they need. A developer gets access to one service. An operator gets permission to deploy it. The scope is narrower, but one individual still holds all the authority within it.

Quorum-based authorization goes further: a consequential action needs several independent participants to cooperate, so no individual can perform it alone. The smallest unit of control does not have to be one person.

The approvals must be independent: compromising one account, device, or recovery path must not give an attacker enough authority to satisfy the quorum.

The digital asset industry already works this way at the key layer. Multisignature wallets require several keys to authorize a transaction, and threshold MPC signing requires multiple share holders to produce a signature.

That protection also needs to cover the software that decides when and how a key is used. Consider a service that checks withdrawal requests before passing them to a signer. If one developer can replace it with a version that skips those checks, and the signer relies on those checks, that developer may have enough authority to move the money without ever extracting a key. Getting a system to use its authority on an attacker’s behalf can be just as useful as stealing its credentials.

Extend quorum control beyond the keys

An administrator who controls a cloud account, VM, or container is a single point of failure wherever that access can change a consequential operation. They do not need to be malicious: their laptop can be compromised, their tools tampered with, or they can be phished. A sound design has to assume good people get compromised.

So the quorum that governs the keys should also govern how they are used: the signing policy, the software enforcing it, its build and configuration, and the recovery procedures that can replace them. Requiring three people to approve a policy is meaningless if one person can rewrite its implementation.

Make quorum approval enforceable

An approval means something only if participants can verify that production runs the software they approved. Reviewing source code alone cannot establish that: a compromised build server can produce a different binary, and an administrator can deploy something other than the reviewed build.

Reproducible builds let independent builders produce the same artifact from the same source. A secure enclave isolates that workload from the host running it, and remote attestation provides signed evidence of the enclave’s measured software. Together they connect reviewed source to the running workload.

On Caution, a quorum key protects application secrets. Release of those secrets follows the approval:

1. The quorum approves a build: its source, configuration, and policy.
2. Each custodian rebuilds it and checks that the enclave’s attestation matches the result. On Caution, that is one command: caution verify.
3. Each custodian sends their share of that quorum key over a channel bound to the verified enclave.
4. Only a quorum can unlock the secrets the approved workload needs, such as a credential for a signing service or its own MPC signing share.

A different build has a different measurement, so it receives no shares until a quorum approves it.

Consider a withdrawal service built this way. Under the enclave’s isolation assumptions, a compromised host cannot read its memory or rewrite the code inside it. A replacement build that skips the withdrawal checks has a different measurement and receives no shares of the quorum key without fresh quorum approval. Host access alone therefore cannot let an attacker replace the approved policy code and retain its signing authority.

Layered defenses still matter. The approved code must validate requests correctly, so its own authorization rules carry real weight. Configuration, rollback, and recovery paths must preserve the same controls, as must any administrative interface that can change the workload’s authority. Enclaves also carry hardware and firmware trust assumptions. None of these limits justify leaving one administrator with unilateral authority over the funds.

Why we built Caution

We built Caution to make quorum-based control practical across the systems surrounding the keys. Caution is a hosting platform with the developer experience teams already know, plus reproducible builds, hardware-isolated execution, and verification built into the deployment workflow. A quorum can verify the software before entrusting it with secrets, and no single administrator can swap that software and keep access to them. Teams get a familiar way to deploy applications, with much stronger security guarantees and no need to assemble the underlying security infrastructure themselves.

That approach grew out of years building and securing systems for digital asset firms including BitGo, Unit410, Turnkey, and Ledn. That work shaped our threat model: a single compromised person or machine should not be enough to take control. Quorums belong throughout the stack, wherever unilateral authority could undermine that property. Our team reached the same conclusion at Distrust, in an analysis of the Safe{Wallet}/Bybit incident: distributing control over signing keys is insufficient when one person can change the software around them.

We started with StageX, a Linux distribution built around reproducibility, a toolchain bootstrapped from source, and verification by multiple parties. It extends independent verification down to the tools and dependencies that build the operating system and the application, so a system’s integrity does not depend on trusting one builder’s output.

Our FAQ covers performance and deployment.

Find where one person still has sole control

Start with one consequential action, such as a withdrawal. Follow it through the signer, policy checks, deployment process, and build. Wherever one person or machine can unilaterally change the outcome, extend the shared control you already expect at the wallet layer. Check the recovery paths and the controls themselves too.

One compromised person should not be enough to put everyone else’s assets at risk.

Put quorum control into practice

We want to work with teams putting these controls into practice, including Binance. If deployment constraints or recovery requirements stand in the way, talk to our team. We can help work through them.