In mid-May 2025, Coinbase publicly disclosed that, earlier in the year, cyberattackers were successful in stealing assets belonging to customers who were custodying their funds with the cryptocurrency exchange. According to many reports, the damages were in the range of $400 million.

According to the company’s 8-K filing with the U.S. Securities and Exchange Commission about the cyberattack, Coinbase “received an email communication from an unknown threat actor claiming to have obtained information about certain Coinbase customer accounts, as well as internal Coinbase documentation, including materials relating to customer-service and account-management systems. The communication demanded money in exchange for not publicly disclosing the information.” Coinbase has vowed not to pay the ransom and to reimburse any customer funds that were lost in the attack.

In other words, in addition to looting Coinbase’s customers for as much as $400 million, the malicious actors were also looking to extort a ransom from Coinbase – later reported to be $20 million – in order to prevent the online disclosure of a tranche of customer data. 

Coinbase also disclosed another important detail regarding the perpetration of the attack: it was an inside job. According to the SEC filing, “The threat actor appears to have obtained this information by paying multiple contractors or employees working in support roles outside the United States to collect information from internal Coinbase systems to which they had access in order to perform their job responsibilities.”

The filing goes on to say that “these instances of such personnel accessing data without business need were independently detected by the Company’s security monitoring in the previous months. Upon discovery, the Company had immediately terminated the personnel involved and also implemented heightened fraud-monitoring protections and warned customers whose information was potentially accessed in order to prevent misuse of any compromised information.”

But, once the company discovered that something was amiss, whatever policies and procedures may have gone into effect were apparently not enough (nor fast enough) to avoid the damage. While some of the details of the attack still remain confidential, it has since come to light that the funds weren’t stolen as a result of a breach of Coinbase’s systems. Rather, some of the perpetrators (at least one of whom was a contractor to Coinbase) working at an India-based support center accepted bribes to take photos of their computer’s screens with their phones. 

According to a June 2 report by Reuters, Coinbase “knew as far back as January about a customer data leak at an outsourcing company connected to a larger breach.” The report continues “At least one part of the breach…. occurred when an India-based employee of the U.S. outsourcing firm TaskUs was caught taking photographs of her work computer with her personal phone, according to five former TaskUs employees.”

On its own blog, Coinbase wrote “Criminals targeted our customer support agents overseas.They used cash offers to convince a small group of insiders to copy data in our customer support tools for less than 1% of Coinbase monthly transacting users. Their aim was to gather a customer list they could contact while pretending to be Coinbase—tricking people into handing over their crypto.” According to the blog post, customers’ names, addresses, phone numbers, email addresses, government ID images and account balance and transaction history were among the fields of data that were stolen. 

In a nutshell, some people working for Coinbase were bribed into stealing Coinbase customer data by taking photos of that data while it was displayed on the screen(s) of systems that are somehow involved with the company’s customer support function. Those insiders turned that information over to the threat actors who then used that information to socially engineer those customers and, as a result, made off with as much as $400 million. Oddly, that haul apparently wasn’t enough and the threat actors came back to Coinbase directly for an additional $20 million (just five percent of the original haul). 

So, what does any of this have to do with the Decentralized Recovery (DeRec) Protocol?

One of the more common questions we get at the DeRec Alliance is: Why can’t I just use a password manager to keep track of all my secrets (secrets like passwords, mnemonic seed phrases, private keys, etc)? After all, when you use a password manager to its most potential, it typically synchronizes all of your secrets across all of your devices. We also get asked about Metamask’s Profile Sync feature since Metamask itself markets the feature as a means to backing up your cryptocurrency wallet in a way that protects you against the loss of at least some of the assets that you might have in that wallet. In the same way that MetaMask’s Profile Sync feature relies on a MetaMask-operated central cloud in order to sync one wallet on one platform to a copy of that wallet on another, most users rely on password managers to do the same exact thing through a similar central cloud that’s operated by the password manager (although some password managers give users the option of syncing through their own user-operated central resource). 

As noted in one of our related blog posts – see The Decentralized Recovery Protocol is Complementary to Password Managers. Here’s Why. – the ability to keep your credentials and secrets in sync across multiple devices and browsers (and therefore supposedly safe) is wholly based on those centralized resources. In both cases, the key word is “centralized.” 

In his post about Why Not To Trust a Lone Entity – Even Yourself – To Best Protect Your Secrets, Dr. Leemon Baird, the inventor of the DeRec Protocol wrote: “Web3 proponents sometimes call decentralization a ‘trustless’ system. That’s something of a misnomer. You still have to trust that the majority of mining power is owned by honest people, or the majority of stake, or the majority of computers on a blockchain. So there is still trust involved. But it is a lower bar that is easier to achieve than putting all your eggs in one basket, and giving a single individual or organization the ability to steal everything. Even if that single entity were honest, it can still be dangerous if they are hacked.”

The point that Dr. Baird is making – and that he repeatedly makes in conversation – is that the safety of your secrets should never be entrusted to a single entity because of how that actually centralizes the risk of compromise in ways that theoretically trustworthy entities cannot always account for. 

For example, organizations like wallet and password manager providers may have institutionalized all sorts of controls to guarantee the integrity and security of their centralized synchronization infrastructures and the customers who use them. Coinbase undoubtedly had its own controls in place. In MetaMask’s case, even though its profile sync feature uses MetaMask’s centralized cloud to keep two wallets on two different platforms in sync with one another, nothing secret is actually passed through that cloud. One could argue that it’s perfectly safe. Meanwhile, the Coinbase incident teaches us that regardless of the controls that an organization puts into place, there’s always a chance that a motivated (or bribed) insider will find a way around those controls. Maybe it could be a developer or a group of developers who can change originally non-secret bearing code to secret-bearing code. 

In situations like these where trust has been centralized to a single entity, those entities typically have reasonable and believable explanations for why they should be trusted and customers needn’t worry. But all one needs to do is scan the records of the SEC to find filings like Coinbase’s aforementioned 8-K or the agency’s never ending list of litigations to confirm that, for whatever reasons (deliberate malicious acts, incompetence, etc.), our eggs are really much less secure when we put them in one basket.

The Coinbase incident is by no means a reminder that you shouldn’t do business with Coinbase.The fact that Coinbase is reimbursing affected customers for their losses is a testimony to the exchange’s good intentions. But it’s also a reminder about the risks inherent to the centralization of anything sensitive and why we, and even organizations like Coinbase, should look for opportunities to decentralize trust wherever those opportunities may exist. 

Surely, there are certain aspects of an exchange’s services and operations that could benefit from the additional safety of decentralization. Decentralizing certain centralized risks might even protect an exchange from the next $400 million reimbursement. In a recent post, decentralized ID infrastructure provider Ontology argued that the use of  Decentralized IDs (a.k.a. “DIDs”) can minimize the degree to which customer support systems must display personally identifying data to potentially malicious support personnel.

And applications like that needn’t involve blockchain. After all, many people are surprised to learn that the DeRec Protocol doesn’t use or rely on any blockchain technology. It’s living proof that decentralization isn’t just a web3 phenomenon. Likewise, in addition to all the great things they already do, there’s no reason password managers cannot embrace the open DeRec Protocol to decentralize the backup and recovery of the secrets (not just passwords) they manage. Similarly, MetaMask and other wallet developers can leverage the DeRec Protocol to offer their users a fully decentralized approach to backing up (or recovering) mnemonic seed phrases and private keys. In fact, if we really put our thinking caps on, there’s virtually no limit to the number of applications that can benefit from the increased safety of a decentralized architecture.