What the Binance incident means for enterprise custody
Binance found no evidence that its private keys leaked, yet USD 6.3 billion left its hot wallets. Protecting the key and preventing unauthorised signing are separate requirements.
What happened
On 29 October 2026, Binance suffered unauthorised withdrawals from its hot wallets, with losses estimated at approximately USD 6.3 billion. Its initial findings pointed to a potentially compromised DevOps engineer’s laptop. A subsequent investigation identified additional points of compromise, making it too early to attribute the incident to a single device or access route. Binance said it had found no evidence that wallet private keys had leaked.
Binance began restoring withdrawals in phases on 1 November, while deposits remained operational. In its recovery update that day, the exchange said it had replenished approximately 95% of the affected assets and reaffirmed its commitment to absorb the losses. Replenishment should not be confused with recovery of the stolen funds: efforts to trace and recover those assets continued separately.
The full attack sequence has yet to be publicly established, and Binance has committed to publishing a detailed post-incident report. The architectural question remains relevant to every institution holding digital assets: what prevents a compromised operational system from authorising a transfer?
Protecting the key is only part of the problem
Binance’s statement that it had found no evidence of a private key leak highlights an important distinction: protecting key material and preventing unauthorised signing are separate security requirements. The findings disclosed so far suggest that funds may have been moved without extracting the keys themselves, although the precise mechanism remains under investigation.
The Bybit incident in February 2025 illustrated a related risk. Investigators found that a compromised Safe developer environment had been used to manipulate the transaction interface, leading authorised signers to approve a malicious transaction. The two incidents should not be treated as technically identical. Both, however, underline the importance of protecting the systems that prepare, display and approve transactions.
For institutions choosing a custody model, “Where are the keys stored?” remains an important question. It needs a second one alongside it: “Who can make those keys sign, and what independent control can stop an unauthorised request?”
Encryption, hardware security modules and multi-party computation can protect key material. Their effectiveness also depends on how transaction policies and approvals are enforced. If every signing participant relies on the same compromised service for instructions, distributing the key may leave the underlying authorisation risk unresolved.
Self-custody changes the responsibilities
After a major exchange incident, moving assets into self-custody can seem like the obvious response. It gives an institution greater control, but also makes it responsible for securing the entire operating environment: signing devices, access rights, approval policies, recovery procedures and monitoring.
An organisation can do this well. It can also recreate the same concentration of authority it wanted to avoid. The outcome depends on the controls it builds and maintains.
Whether custody is outsourced or managed internally, the questions are similar: which parties must agree before funds move, how independently do they operate, and can their decisions be verified? Clear answers make custody easier to assess and audit.
Why enterprises should consider on-premise custody
For enterprises holding substantial digital assets, this incident strengthens the case for bringing critical custody and signing infrastructure on-premise. Direct control over signing systems, access policies and transaction approvals can reduce dependence on a cloud provider’s security environment and give institutions greater visibility into how their assets are protected.
For organisations with the resources and expertise to operate it securely, on-premise custody should be a serious consideration when reviewing their architecture. The objective is to keep critical signing authority within infrastructure they control and can audit, with clear limits on provider access and independently enforced approvals.
That control comes with responsibility. The institution must secure and monitor the environment, manage updates and recovery, and maintain separation between administrators and signers. Moving software on-premise does not make these safeguards automatic. Whatever the deployment model, compromising one operational system should not be enough to move funds.
Three custody models compared
Institutions commonly hold assets on an exchange, use a hosted MPC custody platform, or operate custody software on their own infrastructure. These are deployment models, not security guarantees. The details of each implementation matter.
| Exchange account | Hosted MPC custody | On-premise MPC custody | |
|---|---|---|---|
| Where assets are held | Often in pooled wallets managed by the exchange | Can use dedicated client wallets; segregation should be verified | Can use dedicated client wallets managed through the client’s infrastructure |
| Who holds signing authority | Generally controlled by the exchange | Depends on how shares are distributed and which combinations can sign | Depends on how the client distributes shares and administrative access |
| Who approves withdrawals | The exchange’s systems apply its internal controls | Client policies can govern approvals and signing | The client configures and operates approval policies |
| Independent approval | Customers generally rely on the exchange’s controls | A client-held signer can provide an independent check if the configuration requires it | Independence must be established between the client’s signers and systems |
| How far a breach can spread | Shared infrastructure and pooled assets may expose multiple customers | Separate wallets help identify exposure; shared infrastructure can still create common risks | Depends on isolation within the client’s environment and shared dependencies |
| Risk from a provider compromise | Depends on the exchange’s safeguards and ability to absorb losses | A provider unable to meet the signing threshold alone faces an additional barrier | Depends on whether the provider retains access, update privileges or a signing role |
| Operational burden | Generally lowest for the client | Shared between client and provider | Generally highest for the client |
The meaningful distinction is how much authority any one compromised component can obtain. Separate wallets, multiple key shares and approval policies each serve a purpose, but they need to work together.
What independent co-signing changes
Threshold signing allows several parties to produce a valid signature using separate key shares, without assembling the complete private key during signing. Its value depends on the independence of those parties. A second signer provides a stronger safeguard when it can check the transaction against its own trusted information and refuse to participate.
At The Vault, this principle underpins our threshold-signing architecture, which distributes signing authority across separate key shares. Client-defined allowlists, limits and approval requirements are enforced within the signing process. Clients using our hosted platform can also hold a signing share on their own device through a mobile signer.
The security of this arrangement depends on how signing authority is distributed and governed. Clients should understand which combinations of participants can authorise a transfer, when their own approval is required, and how recovery works.
Institutions that want to operate the platform themselves can deploy it on-premise. In that model, the client takes responsibility for the infrastructure, the key shares and the procedures governing their use, with no provider component participating in signing.
Our platform uses our own threshold ECDSA and EdDSA library, audited by Halborn. That audit is one part of the assurance process. Institutions should also assess the surrounding implementation, policy enforcement, access controls and operating procedures.
A role for warm storage
Hot wallets support immediate liquidity, but automated signing exposes them to risks that offline storage is designed to reduce. Cold storage introduces operational friction of its own. Institutions need a practical way to manage both requirements.
A distinct warm-storage tier can help. It can support less urgent transfers with additional approvals, separate signing participants and tighter transaction limits. This allows hot-wallet balances to stay aligned with immediate operational needs while longer-term reserves remain offline.
“Warm” is not a security standard in itself. The useful questions are what additional checks the tier requires, how independently they operate, and what happens if an internal service is compromised. Its purpose is to make access to one operational system insufficient to move funds across every tier.
What we are building next
Alongside our existing on-premise deployment, we are developing:
- A distinct warm-wallet tier, with its own policies and limits.
- An SDK for client-side signing, allowing a client-controlled system or device to hold a key share and participate in signing.
These are roadmap items, and we will share availability dates once they are confirmed. Both are intended to give institutions more flexibility in how they distribute operational responsibility and signing authority. Together with our existing on-premise deployment, they support a direction we believe is important for enterprise custody: institutions should be able to control the systems that authorise transfers and verify the safeguards protecting their assets.
A private key does not have to leak for funds to be stolen. Institutions need to understand who can request a signature, which checks apply, and whether an independent participant can refuse. That is how we should assess custody: by what an attacker would need to compromise before assets can move.
Five questions to ask your custodian
- Are our assets held in dedicated wallets or pooled with other clients’ assets, and how is that separation maintained?
- Could a compromised employee device or internal service cause a transfer without an independent check?
- Which combinations of parties can authorise a withdrawal, and can funds move without our participation?
- Are our limits, allowlists and approval requirements enforced within the signing process, and who can change or bypass them?
- What has been independently audited (the cryptography, the implementation and the operational controls), and can we review the scope and findings?
Clear, specific answers provide a better basis for choosing a custodian than broad claims about security. They show how the system is intended to behave when one of its safeguards fails.
Sources
Incident information reflects public updates reviewed on 2 November 2026. Technical findings remain preliminary and may change as the investigation progresses.