BitGo: Unocoin Outflows Were Signed With the Exchange's Own Keys

BitGo says outgoing transactions from Indian exchange Unocoin were signed with keys Unocoin itself held, and that no breach of BitGo's systems occurred, according to a statement addressing an unusual wallet event that Unocoin is still investigating.

The custodian's account lays out a precise technical sequence. The transactions in question were signed using Unocoin's user key and backup key, BitGo said, and were then broadcast on-chain outside BitGo's infrastructure entirely. BitGo's own key — the third key in the wallet's setup — was never used in the transactions, the company stated.

When was the account frozen?

BitGo said it froze Unocoin's account on Nov. 6. The freeze mechanism worked as designed, according to the custodian. That timing matters: it establishes when the custodian acted relative to the unusual outbound activity that prompted Unocoin to open an investigation into its own wallet.

The wallet at the center of the dispute used a 2-of-3 self-custody multisignature configuration. Under that structure, Unocoin held two of the three keys — the user key and the backup key — while BitGo held the third. Two signatures are enough to move funds. Because Unocoin controlled two keys on its own, transactions could be constructed and signed without BitGo's participation at all, which is exactly what BitGo says happened.

That structural detail is the crux of the dispute. In a 2-of-3 arrangement where the client holds two keys, the custodian's role in authorizing movements is limited by design. BitGo's statement that its key was never used is consistent with the wallet's architecture: Unocoin's key pair was sufficient on its own.

What is Unocoin investigating?

Unocoin has said it is investigating a possible misuse of the wallet's backup access mechanism. That wording suggests the exchange is examining how its backup key — one of the two keys it held — came to be used in the outbound transactions, rather than pointing at BitGo's infrastructure. BitGo's version of events, in which both signatures came from Unocoin-held keys, would fit a scenario in which the backup access mechanism itself was compromised or misused.

BitGo has drawn a firm boundary around the blast radius. No other customers were affected, the company said, and it directed questions about the status of Unocoin users' funds to the exchange itself. That deflection is operationally significant: if the signing keys sat with Unocoin, then questions about client balances, withdrawals and remediation sit with Unocoin, not the custodian.

What does this mean for self-custody setups?

The episode is a working illustration of both the strength and the awkward edge of shared-key custody models. BitGo's freeze functioned — the account was frozen Nov. 6 and the mechanism engaged as intended. But a freeze at the custodian level cannot retroactively invalidate transactions that were validly signed by a quorum of keys the client controls. In a 2-of-3 scheme where the client holds two keys, the client's own key security is the binding constraint on the wallet's safety.

For exchanges using similar multisig arrangements, the operational lesson is straightforward: the backup key is a live signing key, not a dormant failsafe. Any process that can invoke it can move funds, and controls around that mechanism deserve the same rigor as the primary key. Unocoin's investigation into possible misuse of its backup access mechanism is now the open thread, and the exchange's findings will determine whether the event traces to internal process failure, credential compromise, or something else entirely.