Unocoin: why an account freeze leaves another signing route

What changed in the explanation

Unocoin’s update of 13 November changes how its wallet incident should be understood. The exchange says its BitGo enterprise freeze worked as intended, while the disputed transactions were signed and broadcast outside BitGo. It suspects misuse of a backup mechanism and continues investigating. An account restriction and an on-chain transfer can therefore coexist without the restriction having failed at the service it controls.

The chronology matters. Unocoin says it detected suspicious activity on 6 November, suspended services after further activity on 9 November, and identified outgoing transactions on 12 November. That last date describes discovery, not necessarily when every transfer occurred. The analytical question is which signing routes remained available after the account was frozen. Answering it requires separating access to the provider’s platform from authority over the wallet. [1]

Two routes through the same wallet

BitGo’s documentation describes a standard arrangement with a user key, a backup key and a BitGo key. Two are needed to authorize the relevant wallet transfers. The ordinary route combines the user key with BitGo’s key. A recovery route can instead combine the user and backup keys, allowing the customer to access funds when the provider is unavailable.

This is a deliberate continuity feature. It also means the provider is not an unavoidable participant in every valid transfer. BitGo’s recovery documentation expressly says recovery transactions bypass its policies. The trade-off is straightforward: independence from a provider also creates an authorization route that the provider cannot stop merely by refusing its own signature. The comparison below describes these routes conceptually; it is not a reconstruction of every transaction in the incident. [2][3]

The boundary of an account freeze

In its own statement of 13 November, BitGo says the reviewed Ethereum transactions used Unocoin’s user and backup keys, without its key. It says requests to build transactions through its platform on 9 November were blocked. These are the provider’s findings, consistent with Unocoin’s updated explanation, rather than an independent forensic audit by this publication.

A platform freeze tells BitGo to stop processing outgoing requests and providing its signature. It does not rewrite the wallet’s on-chain signing conditions. If another permitted combination of keys remains usable, the wallet can still accept an independently submitted transfer. This explains why stronger platform login controls alone do not resolve a compromise of both customer-held signing keys. BitGo says it advised Unocoin to move remaining funds to wallets with newly generated keys. [1][4]

A backup key is spending authority

The word backup can suggest a passive copy that matters only after a failure. Here it represents active authority: together with another eligible key, it can authorize movement of funds. Its storage, access controls and recovery process therefore belong in the same security assessment as everyday signing.

Our inference from this design is that counting keys is less useful than counting independent ways to obtain them. If the same compromised environment exposes both the operational key and the recovery material, the threshold offers less separation than the label suggests. This is a general risk model, not a claim about exactly where Unocoin stored its keys.

The useful organisational test is whether recovery requires a genuinely separate access path and accountable approval. A backup that is always reachable from routine signing systems can defeat the intended separation even when the cryptography works correctly. [2][3]

Custody labels need a key map

BitGo’s wallet-type documentation distinguishes self-custody from custody arrangements. In the self-custody configuration described here, the customer controls the user and backup keys. Its custody offering assigns key creation and signing operations to the provider’s organisation. A brand name on an exchange’s infrastructure does not identify which arrangement applies.

Nor does the hot-or-cold distinction answer every question. That classification concerns how signing material is handled; the custody question concerns who controls authorization. Multisignature and MPC are another distinction: their signatures and operational workflows differ. BitGo describes both in its product documentation, but its detailed incident explanation focuses on the affected Ethereum multisignature wallet. Extending that account to every asset or every BitGo product would miss the configuration that makes the explanation meaningful.

For an institutional assessment, request a map of the signers, ordinary approval route and recovery route for each wallet type actually used. [5]

What customers can take from the incident

For exchange customers, control is indirect: they depend on the exchange’s handling of keys and incident response. The relevant updates are the status of withdrawals, the affected assets, reconciliation of balances and the conditions for restoring service. A statement that a platform account is frozen answers only part of that picture.

Three questions make future disclosures more useful: - Which transaction routes does the freeze stop? - Who controls the remaining signing combinations? - What evidence supports restored access to customer funds?

Unocoin’s latest update still describes an investigation and work to restore services. We do not calculate a loss from third-party estimates or treat an infrastructure rebuild as a withdrawal guarantee. The central lesson is about control coverage: a response plan must address every valid signing route, including recovery, while customers need a separate account of when and how their own access will resume. [1][3][4]