What happens when a crypto exchange freezes accounts yet funds still move out days later? That exact puzzle landed on desks across the industry this week. BitGo stepped forward and stated its systems stayed intact. The outgoing transfers from Unocoin’s infrastructure used two keys the Indian exchange itself held. No participation from BitGo’s own key occurred. That detail changes the entire conversation about where responsibility sits and how self-custody setups can still leave gaps.
BitGo Clarifies Its Role After Unocoin Transfers
On November 13 BitGo released a clear statement. Unocoin’s account freeze on November 6 worked exactly as designed. The recent outgoing transactions were signed with the user key and the backup key that Unocoin controlled. Those signed transactions then hit the blockchain directly. BitGo’s key never entered the picture. The company added that no other clients faced similar activity and pointed any questions about customer balances straight to Unocoin.
I’ve followed enough custody incidents to know this kind of clarification matters. When a provider says its key stayed unused, the focus shifts from platform compromise to how the client managed its own material. Unocoin had already flagged the transfers on November 12 after spotting movement from an Ethereum address inside its BitGo wallet setup. The exchange had requested freezes several days earlier, yet the activity still appeared.
How The 2-Of-3 Wallet Structure Works
BitGo explained the arrangement in straightforward terms. Unocoin’s wallets run on a 2-of-3 self-custody model. The exchange holds the user key and the backup key. BitGo holds the third. Any two of those three keys can authorize a transaction. In normal operations the user key pairs with BitGo’s key. The backup key can pair with either of the other two when needed.
That design exists for a practical reason. If the provider becomes unavailable, the client still keeps a path to its funds. Recovery instructions outline the process. Clients gather the encrypted user key, the backup key, the wallet passphrase, and a destination address. For Ethereum they also supply the wallet contract address. The result is a fully signed transaction that can be broadcast through any explorer. No BitGo service is required at that stage.
In this case BitGo’s review found the user key and backup key did the signing. The transactions left without the third key. That points directly at material Unocoin controlled. Whether those keys were accessed through an internal process, a compromised backup procedure, or something else remains under investigation by the exchange.
Unocoin’s Evolving Account Of The Incident
Unocoin’s public notices shifted as more details arrived. On November 13 the exchange confirmed it had received the clarifications it sought from BitGo. It accepted that the freeze appeared to function and that the transfers were signed and broadcast outside the provider’s platform. The design that preserves access if BitGo goes offline is now under suspicion. Unocoin is examining how the backup mechanism may have been reached, whether any cryptocurrency left customer balances, and if private information became exposed.
Earlier statements painted a broader picture of disruption. Customer logins were disabled after unauthorized server access surfaced on November 9. The website returned gateway errors for a stretch. Initial claims held that no customer funds had been lost. Later updates noted suspicious activity first detected on November 6. Freezes were requested almost simultaneously from two providers that day. Further unauthorized activity on November 9 led to a full service suspension.
The exchange stated that more than 90 percent of customer cryptocurrency sat in cold storage. Rebuilding and securing the server infrastructure was expected to take four to five working days, followed by security checks before any restart. That timeline left many users watching and waiting while the investigation continued.
Why Client-Held Keys Create Both Strength And Risk
Self-custody arrangements give clients real control. They also place the burden of key security squarely on the client. When two of three keys live on the exchange side, any weakness in how those keys are stored, backed up, or accessed can open a path. The backup key in particular exists for recovery, yet that same convenience can become a target if processes around it are not airtight.
I’ve seen similar setups praised for resilience and then tested under pressure. The recovery path that lets funds move without the provider is valuable in theory. In practice it requires ironclad protection of the material that makes recovery possible. Encryption of the user key, secure handling of the backup key, and strict controls on who can initiate the process all matter. Any gap in those controls can produce exactly the kind of movement that appeared here.
BitGo’s documentation makes the boundaries clear. The provider does not hold the private user or backup keys for self-custody wallets. Clients generate those on their side and supply only an encrypted user key and a public backup key. That separation is intentional. It also means that when transfers occur using those two keys, the investigation naturally turns toward the client environment.
Timeline Of Key Events Leading To The Clarification
The sequence helps frame the situation. Suspicious activity registered on November 6. Freeze requests went out that same day, minutes apart. Confirmation arrived from both providers. Services continued under restricted conditions until further unauthorized activity on November 9 triggered a full suspension. Logins were disabled. Website access faltered. On November 12 Unocoin identified the outgoing transfers from the Ethereum address used for ERC-20 funding. The freeze had already been in place for nearly a week by then.
BitGo’s statement arrived the following day. It confirmed the freeze operated as intended and that its own key stayed out of the signing process. Unocoin acknowledged the information and shifted focus to how its backup path may have been used. No confirmed loss figure has been published by either side at this stage. No individual has been named in connection with the key use.
That absence of a final loss number keeps the picture incomplete. On-chain data can show movement, yet matching those movements to actual customer balances requires internal records that remain under review. The exchange has maintained that the large majority of holdings stayed in cold storage, which would limit the exposed surface if that claim holds.
Practical Lessons For Anyone Using Multi-Key Custody
Situations like this surface useful reminders. First, understand exactly which keys you control and which the provider holds. Second, treat the backup key with the same seriousness as the primary material. Recovery mechanisms exist for good reason, yet they expand the attack surface if not tightly managed. Third, freeze requests can stop provider-side signing, but they cannot stop a fully signed transaction that never needs the provider’s key.
- Map every key in the setup and document who can access each one
- Review backup procedures regularly and limit who can initiate recovery
- Test freeze processes in advance so response times stay short
- Keep clear records of cold storage ratios and access controls
- Monitor on-chain activity even after a freeze is confirmed
Those steps sound basic, yet they separate teams that recover quickly from those that spend weeks reconstructing events. In my view the most interesting aspect here is how cleanly the provider was able to demonstrate its key stayed unused. That level of clarity is not always available in custody incidents. It lets the conversation move to the next layer of controls rather than remaining stuck on platform integrity.
What Self-Custody Recovery Paths Actually Require
Recovery without the provider is not a simple click. The process demands the encrypted user key, the backup key, the wallet passphrase, and precise destination details. For Ethereum the wallet contract address is mandatory. Token recoveries need the additional token contract address. Once those pieces are assembled, a fully signed transaction can be created and broadcast independently.
That independence is the feature. It is also the risk. Anyone who obtains the required material can produce a valid transaction. Encryption protects the user key in transit and at rest, yet the decryption step still needs the passphrase and proper environment. If that environment is compromised, the encryption alone may not stop the process.
Unocoin has indicated it is examining exactly how the backup path was reached. That investigation will likely look at server access logs, key storage locations, and any temporary exposures during the earlier unauthorized activity. The outcome will matter for the exchange’s customers and for every other team running similar 2-of-3 arrangements.
Broader Implications For Exchange Custody Models
Exchanges face constant pressure to balance customer control with operational security. Full self-custody reduces the provider’s liability yet increases the client’s operational burden. Hybrid models like 2-of-3 attempt to split the difference. They deliver resilience if one party becomes unavailable. They also create shared responsibility that can blur during an incident.
When transfers occur after a freeze, the first question is always whether the freeze actually blocked the provider’s key. In this instance BitGo answered that question directly. The next questions concern how the remaining keys were protected and whether any internal process allowed their use outside normal channels. Those questions sit with the exchange.
Perhaps the most useful outcome of the clarification is the public separation of roles. Customers and observers can now focus on the client-side controls rather than debating whether the custody platform itself was breached. That separation is healthy for the broader market. It encourages clearer documentation of key handling and more rigorous internal audits of recovery procedures.
Cold Storage Claims And Exposure Limits
Unocoin’s statement that more than 90 percent of customer cryptocurrency remained in cold storage is significant if verified. Cold storage removes private keys from networked environments. It does not eliminate every risk, yet it sharply reduces the volume that can move quickly. The transfers under review appear to have originated from a hot or warm wallet address used for daily operations and ERC-20 funding. That distinction matters when estimating potential impact.
Rebuilding server infrastructure while simultaneously investigating key use creates a complex operational load. The estimated four to five working days for infrastructure work, plus validation time, leaves a window of limited service. During that window communication becomes critical. Customers need consistent updates even when final numbers are not yet available.
No confirmed loss figure has been released. That absence leaves room for speculation, yet it also reflects the reality of ongoing forensic work. Matching on-chain movements to internal ledgers takes time. Until that matching is complete, any public number would risk inaccuracy.
How Freezes Interact With Independent Signing
A freeze on a custody platform typically prevents the provider from co-signing new transactions. It does not invalidate signatures already possible with the remaining keys. Once a transaction is fully signed and broadcast, the freeze cannot reverse it. That is why the backup path deserves special attention. It is designed to operate without the provider. Any successful use of that path after a freeze is consistent with the design, not a failure of the freeze itself.
BitGo’s statement underscored this point. The freeze functioned. The transfers still occurred because they never required the frozen key. Understanding that distinction prevents misreading the event as a platform failure. It redirects attention to the controls surrounding the client-held material.
In practice this means teams should treat freeze confirmation as only one layer of defense. Continuous monitoring of relevant addresses remains necessary. Automated alerts on unexpected outflows can surface problems even when formal freezes are active.
Investigation Focus Areas Moving Forward
Unocoin’s current focus includes three clear lines. First, the method by which the backup mechanism was accessed. Second, the actual volume of cryptocurrency that may have left controlled addresses. Third, any exposure of private customer information during the earlier server compromise. Each line requires different evidence. Key access logs, blockchain analytics, and server forensics will all play roles.
The earlier unauthorized server access disclosed on November 9 provides a possible entry point. Whether that access reached the material needed for recovery is precisely what the investigation must determine. If the keys remained isolated from the compromised systems, the path may lie elsewhere. If they did not, the timeline of exposure becomes critical.
I’ve found that the most productive investigations in these situations stay methodical. They avoid premature conclusions and publish only what can be verified. That approach builds longer-term trust even when short-term uncertainty is uncomfortable.
Comparing Normal Operations To Recovery Mode
Under normal conditions a transaction uses the user key plus BitGo’s key. The provider participates in signing and can enforce policies, limits, and freezes. In recovery mode the backup key replaces the provider’s key. The transaction becomes fully independent. That switch is deliberate. It also removes the policy layer that the provider normally supplies.
Teams running this model need strong internal policies that govern when recovery mode is allowed and who can authorize it. Without those policies the recovery path can become an ungoverned exit. Documentation of every recovery attempt, successful or not, should be mandatory. Audit trails around key material access should be equally strict.
The current incident illustrates why those internal controls matter as much as the cryptographic design. The cryptography worked as specified. The question is whether the operational controls around the client keys matched the same standard.
Customer Communication During Service Disruption
When logins are disabled and websites return errors, communication channels shrink. Status pages, social updates, and direct notices become the primary tools. Consistency across those channels reduces rumor. Unocoin’s notices evolved as information arrived from BitGo. That evolution is visible in the public record and helps observers track the shifting understanding of events.
Customers watching from the outside often focus on two numbers: how much was at risk and how long until services return. Providing ranges or interim findings, even when incomplete, can lower anxiety. Absolute silence tends to do the opposite. The balance between accuracy and speed is difficult, yet it is part of the operational responsibility that comes with holding customer assets.
The four-to-five-day estimate for infrastructure work set a concrete expectation. Whether that timeline holds will become another data point in how the response is evaluated.
Technical Details That Shape The Outcome
Ethereum and ERC-20 recoveries require specific inputs. The wallet contract address identifies the correct on-chain object. The token contract address is needed when moving specific tokens rather than native ether. These requirements make accidental recovery harder, yet they do not prevent intentional recovery by anyone holding the necessary keys and addresses.
BitGo’s recovery guidance is public in its documentation. That transparency helps legitimate clients regain access when needed. It also means the process itself is not secret. Security therefore rests entirely on protection of the key material and the passphrase. Once those are obtained, the rest of the steps can be followed by design.
This is why the investigation into how the backup mechanism was reached is central. The mechanism itself is not the vulnerability. Access to the material that powers the mechanism is the question.
Industry Patterns In Similar Custody Events
Custody incidents rarely look identical, yet certain patterns repeat. Freezes are requested. Clarifications emerge about which keys were used. Attention shifts from the provider to the client environment. Final loss figures take time. Communication quality varies. Teams that document key handling thoroughly recover clearer narratives. Teams that treat recovery paths as afterthoughts face longer uncertainty.
The present case fits several of those patterns while adding a clean provider statement that removes ambiguity about platform involvement. That clarity is valuable. It allows the market to evaluate the client-side controls without the distraction of a possible platform breach.
In my experience the healthiest outcome from such events is improved internal practice rather than public blame. Whether that improvement materializes here will become visible in future disclosures and operational changes.
Key Takeaways From The BitGo Statement
Several points stand out. The freeze on November 6 operated as intended. The outgoing transactions used only the two keys held by Unocoin. BitGo’s key was never applied. No other clients were affected. Questions about customer funds belong with the exchange. Those points form a coherent picture that separates platform integrity from client key management.
Unocoin’s acknowledgment of the same facts and its shift toward investigating the backup path align with that picture. The absence of a confirmed loss figure and the ongoing infrastructure rebuild indicate that the operational response is still in progress. Customers and observers will continue watching for the next verified update.
The episode also reinforces a simple operational truth. Self-custody features that protect against provider failure can become liabilities if the corresponding internal controls are not equally robust. Designing for resilience requires attention to every path that can move funds, including the ones that bypass the provider.
Looking Ahead For Both Parties
BitGo has drawn a clear line around its own systems. That position is now on the public record. Unocoin continues the deeper examination of its environment, the possible exploitation of the backup route, and the state of customer balances. The next material update will likely address whether any funds left controlled addresses and what steps are being taken to harden the recovery process.
For the wider market the episode serves as a live case study in multi-key custody. It shows how freezes interact with independent signing paths. It highlights the importance of treating backup keys with the same care as primary keys. And it demonstrates the value of rapid, specific clarification from a custody provider when questions arise.
I expect teams reviewing their own setups after this news will pay closer attention to who can initiate recovery, how key material is segmented from general server access, and how quickly anomalous on-chain activity is detected even after freezes are confirmed. Those reviews are the practical response that turns an incident into improved practice.
The full picture is still forming. What is already clear is that the transfers did not require BitGo’s participation and that the freeze itself performed its intended function. The remaining questions sit with the handling of the two client-held keys and the security of the environment that protected them. Those questions will shape the final assessment of the event and the steps that follow.
Until more verified details emerge, the most accurate description remains the one both parties have now aligned on. The account freeze worked. The signatures came from keys Unocoin controlled. The investigation into how those keys were used continues. That alignment of facts provides a solid foundation for whatever comes next in the recovery and hardening process.
