Engineering a $70B Crypto Transfer — Coinbase Keynote | Boston Blockchain Week 2026

Hey, good afternoon everybody. Um it's uh it's amazing to be here. I think just almost a year ago um somebody approached me about being on a panel at ETHBoston on the other side of the river at MIT Media Lab. They're like, "Hey, can you be on the panel talk about securing billions?" I was like, "I think I can talk about this.

I've been thinking about this really deeply." And it's just 6 weeks before we did this on-chain migration. And so I really appreciate the Boston blockchain um organizers for inviting me to sort of bring this full circle and chat with everybody a little bit about sort of like how we went about um making this happen um in November of 2025. So of course this is crypto, cryptography was involved. Um anybody want to like come up here and be my partner here and we're going to go into a protocol review of asynchronous multi-party computation with like linear communication efficiency.

I know we've got some Anchorage people out here. Okay, that's good. I'm glad nobody raised their hand because I am not a patient cryptography. Um I do have a wonderful partner with Yuta Lendell who I work with at Coinbase who specialize in that. I instead am going to take you through how last November we moved the um crypto value equivalent of 600 metric tons of gold in 24 hours.

So and we did this next slide. Oh. This This is the next slide. The green button. In a very very aggressive adversarial environment.

We started out 2025 if anybody was following crypto at all during that time with a $1.5 billion hack at Bybit. And they were doing exactly the same thing. They're running their day-to-day operations, transferring value between wallets that they controlled or that they thought they controlled. But in the months leading up to this, there were actually multiple small smaller exchange hacks happening.

Um there was WazirX, there was Indodax. All of them sort of not in the billion-dollar range, but really good practices using the same techniques, tactics, and protocols by Lazarus to go after exchanges and subvert their control of the tokens that they were custodying for their customers. Okay, so that happens in Q1. Then we come to Q2, and our CEO, Brian Armstrong, gets a ransom note. Uh we are ransomed um by an adversary um threatening to release uh PII information, most of it masked, um um that they were using and threatening to sell on the dark market uh the dark web and whatnot.

And I'm here like, "Ah, this means we have insiders." And in fact, they were. They were malicious insiders who were solicited um from our customer service operations um desk. So, we're in this really high-stakes environment, and yet operationally we need to migrate these funds. Why Why do we do regular wallet migrations here at Coinbase?

It is fundamentally to help um proactively mitigate risk to the wallets and also to improve the security posture of the wallets for all the funds that we custody for our customers that operate and do business on our platform. The difference here is that we do all of these on-chain operations and wallet migrations in a very, very visible environment. Uh TradFi on a daily basis will move multiples the value that we moved last November. I think State Street, um I learned maybe um moves probably two to three trillion in a 24-hour period just as part of doing their regular business. We are in extreme level of public accountability here when we do on-chain migrations um for customer value.

The regulators um are aware. It's near real-time visibility, in fact, of what's happening on chain. If something goes awry, it immediately hits the crypto social circles and networks. In fact, many times, it's not unusual for um sort of like missent funds to um notifications to reach the wallet controllers and owners and exchanges through social media before their systems has even detected them. So, the continuously verifiable, publicly visible situation is a real thing here that we had to deal with.

Um what you see here on the far left of the slide is the mining pool. Those very large blocks um were our blocks that we were mining. Um each one of those was $4 billion in transactions in our batches for the Bitcoin network. And we did all of this with three immutable requirements that we had to satisfy. The first requirement um of the tripod that we had to balance was safety, of course, right?

Because the funds that we custody um on our platform represent our customers' hard-earned savings and in for many cases their business capital that they needed operate on, as well. And most importantly, our customers trust in doing business with Coinbase, as well. So, um safety, not losing a single token, was really important. The scale at which we were moving tokens on the platform in $4 billion um tranches um for every batch that we were sending out, um was a one-and-done deal, right? One batch gone awry, landing on chain, um would be the last one that we would do as part of our migration movement.

Continuity was really important uh because of the nature of uh blockchain operations, we couldn't really anticipate how long the operations would last. We could complete in hours, we could complete in days, um because of block confirmation times, especially for the Bitcoin blockchain, as well, right? So, we could do sort of like high-low estimates on how long this would take, but there's no way we could say and put out an advance notice and say, "We're going to be going down for maintenance for 2 hours on a Sunday afternoon. Um please notify the customers, we're taking everything down." We had to be able to do all of these migrations while keeping all of the products running uh with no impact to the customer and or the business.

Because at the end of the day, everybody knows crypto is 24/7, 365. Um I think when Robinhood first launched, they had this logo, "Crypto Never Sleeps." That's still the case today. Lastly, um speed was very important to us. The longer uh funds and and value stay in flight, um in movement um on chain, the more they are exposed to market volatility, particularly uh infrastructure issues that might arise internally to the systems that they operate on, whether it's the chains and or our internal funds crypto funds movement services.

And mostly importantly of all, we had to set up special teams to actually operate these migrations. Human fatigue is a real factor here. And human fatigue was also something we designed around as well. Most importantly, um, you know, speed was important because we knew that we would be very publicly visible. Regulators would be watching.

Whether it was the New York DFS, the CSSF in Luxembourg, who are accountable for our MiCA licenses, auditors would be watching, sophisticated observers would be watching. Arkham, right? They have every single one of our wallets tagged, our on-chain wallets tagged. They would be able to see and account for every single movement. Um, and most importantly, a very very sophisticated nation state adversaries, for which even just one batch would be a record-setting haul for them to be able to take for a $4 billion transaction.

And so, we had observed from the TTPs of the Bybit hack, um, the previous hacks in 2024, that our adversaries actually understand the day-to-day business rhythms, the funds flows, outflows, and inflows of our wallets very acutely. In fact, I would say my first encounter with this was back in 2018 when I did the the my very first migration for a new a wallet architecture that I built out for Coinbase. And I would say 6 months later, I identified it was actually a Chinese website had the most detailed and accurate accounting of every single wallet and how many tokens for which currencies we moved um from wallet to wallet on chain. And so, knowing that what I needed to do was not understanding whether or not we had any adversaries already inside our infrastructure, whether or not we had any um adversaries um operators inside our infrastructure, that what I wanted to do was minimize the window of observability and ability for the adversary to react and potentially subvert or compromise our operations as well. We could have done this as a very slow drip over multiple months.

We decided against that. We decided to compress the time and reduce the time for observing and also time for attention to drift for a critical mission. So, how do you design for safety? Our number one requirement here. Um first of all, we ensure there are no single points of failure.

Right? Single points of failure both in the technical stack as well as the operations. From a technical stack perspective, we knew every single wallet that we wanted to migrate. Right? And so, what we did was we actually codified it out, required code commits with consensus like sort of like signed consensus approvals in order for those batches to be able to go into production and be released one at a time.

So, every single batch that we released required the successful on-chain first block confirmation of the previous batch before we would move on to the second batch. So, that required uh technical approvals. And then on top of that, we had a trust but verify um method um going on. So, we had the the technical release of the batches for the transactions sent online. Then, we had our cold restore operators who were distributed in multiple time zones globally across the world.

Um that would then separate our technical operators who built and designed the systems from the ones who were actually doing the restore operations for us. So, a segregation of duties here, consensus enforcement, so that there would be no single points of failure and or trust and or control. Another example of this is even though we codified our batches going into the um transaction formation system, at that very end, uh we would also verify that the destination addresses were actually controlled by Coinbase. And we did that by building a special service to cryptographically verify that the key that was actually in the unsigned as well as the signed transaction that came out the other end was one that we controlled. And so, having checks and balances between different services within our internal crypto infrastructure was essential for that.

Second, um every funds movement was observable. We built very specific, detailed funds movement observability that we still operate today. Um for every single movement, whether it's from the initial transaction registration and intent registration to all the different wallets that will assemble the unsigned transactions, at every single point, we don't even trust our internal services, right? They all have to authenticate to each other, but every single interface and data that comes out will be verified by the independent verification track that we have that sits outside of the actual crypto funds movement path. So, pre-signing and post-signing, we do verifications before we broadcast out to the blockchain.

We could move We could We could track every single movement within our internal services. When we got to the actual blockchain, we also had observability. We would be able to see which mining pools were active, which ones were picking up our transactions. We would also monitor where those mining pools were based. Were these mining pools that were based in Texas?

Are these mining pools that are based in in Asia or in the Middle East or you know, some other region. Also thinking about those mining attacks because we are still Bitcoin at least a proof of stake um ecosystem. We also assume that something would go wrong. And because you assume something that goes wrong, you have to have automated circuit breakers so you can fail safe. Funds will not be sent on track.

You would rather be able to fail safe and slow down your operations and be able to investigate and manually triage and decide whether or not to accept the transactions to move forward or whether you should roll back and pause your transactions and activities for the particular mission. And so always assume that something will go wrong. Design for the eventualities, build in the fail safes. Um do the threat modeling, understand what could go wrong. There are technical and non-technical issues that could happen.

Your One of the things that we were really concerned about was um a broad market fluctuation, right? Um so moving $4 billion uh um adding up to $70 billion could look like an attack on the exchange. That could cause fear, uncertainty, and doubt in the market, right? How did we design against this? We designed against this by not trying to be efficient in our operations, right?

What we did was we made sure wallet A had 10 Bitcoin, the destination wallet A prime had that 10 Bitcoin. So, it looked like a very structured movement, right? If we weren't If you look at exchange hacks, you'll see a funneling of funds from multiple wallets to a tornado cash or some other mixer environment, right? Of new addresses, but never the one-to-one correlation. So, we made it very obvious in communicating to the rest of the world that our, you know, our transactions were planned, that the balances were trued up exactly for every single source and destination wallet, right?

Um What else did we do? Um We also thought about what's going to happen. Oh, I think it was maybe in early October, mid-October, um there was a market anomaly. Uh there was a USD uh USD Athena was like a BTC sort of like base stable coin um had pegged itself against only a single oracle, which is a Binance oracle that had sort of like a uh an anomaly in sort of like their um their their oracle uh data coming up. Um And that caused a sudden like $19 million liquidation, right?

Because the the pegging of the USD Athena um dropped precipitously in a um technical um anomaly there. So, that triggered us to think, "Oh, wait. What happens if the price of Bitcoin, which had already fallen from its all-time high of around 120, 124k in the summer all the way down to um 90k as we were approaching the date of the mission and then further down to around 85k on the the day of the mission. And so, what if you know, what kind of unintended sort of like market liquidations is going to cause in like the DeFi ecosystem in our derivatives and options um contracts that customers platform and other exchanges platforms had. And so, we went to talk to the financial product like risk management team and said, "What is what is the uh what's the the margin of error that we can support here?

That we should be watching if, you know, if the market does react negatively to seeing all these outflows from our platform." And so, they gave us a numerical range that we could work within um when we would have to stop and pause um and maybe wait for the price to recover um so that we wouldn't sort of, you know, make many, many DeFi investors go broke. At the end of the day, um although novel cryptography does underpin sort of our wallet architecture and wallet infrastructure to support what we need for all the current verbs in the crypto ecosystem, it's not the only it's not the only element. In fact, um cryptography and the cryptographic libraries that underpin um sort of how we securely operate wallets for our Coinbase customers is one part of a much larger equation, right? So, this is the systems of systems engineering.

We think about the hardware security, the software security, the operations personnel, um physical and and governance and compliance um dimensions as well. From a people perspective, we had a very clear roles and responsibilities both on the technical and operations side. For the particular mission, we had an executive uh DRI or responsible individual. In this case, it was our CFO, Alicia Haas. So, I would say 6 weeks prior to our readiness to actually um execute on the mission, we had our first conversation with hers with her.

And we were saying, "Uh so, we're going to do this major migration of 800,000 Bitcoin tokens in your custody, in your care as a um as our CFO, and another 4.2 million ETH on our platform, totaling approximately at that time $120 million worth of value um a billion dollars worth of value on the platform. Um And so, and we for the time sake of operational efficiency want to move, you know, $10 billion in each tranche that we do so that we can make sure we finish in the weekend time frame. Um how do you think about this? Um And he said, "Yolanda, wait a second.

Um we just said in our last earnings report, like, we have $10 billion in cash reserves for the entire company. That would be an existential threat to the business. Why don't we negotiate this? How about this? Um for operational efficiency, I understand what you need to do um to execute in a short amount of time.

How about we settle on $5 billion? So, we agreed 6 weeks ahead, we settled on $5 billion. That was sort of our working with our executive DRI to balance that risk and operations um mission that we had um to be accountable for the business. But even a $5 billion loss would be a really, really bad day for the business, right? There would be a no more M&A.

Um there might not be any more bonuses uh and equity awards for the business. We might have to cut down some of our venture bets um and our new product lines that we were working towards, but the company would survive. Then for the actual operations, we had very specific roles um laid out. Everybody had their run book, they knew what they were monitoring for from anomalies and decision-making purposes. Um so it's really important from a personnel perspective um for everybody to understand what they're doing um to the T in a very scripted fashion.

And actually be experts and generally understand the operations of their role very specifically. For a process perspective, um it's important to always have um a primary and secondary, right? So for each of the roles, we had a primary and secondary verifying um what was going on. We had the observability, we had the communications that we needed. And most importantly, um we had the separation of duties again across technical um and operations.

From a systems perspective, um independent verification and oversight. Although we had operators of our cold storage systems, we also had a set of persons whose only job was to sit and audit the operations to um warn us when we needed to slow down in favor of safety as opposed to speed up um for the um favor of efficiency.

[snorts]

I do we finally earned the green light. When it came down to the final weeks, um we prepared multiple dimensions. Um we briefed the enterprise risk management working group. We got legal sign-off. We had to think about whether or not we were executing during this during normal business hours or whether we were going to do it this on a weekend.

When we selected the days and times to do this, we thought about, you know, what if there is a market reaction to seeing all the funds outflow? This is during an open trading window for employees as well. And we wanted to understand what would be the implications not only for the crypto token prices, but also for the Coinbase um share prices as well. And making sure that we could sort of cleanly carve out sort of like the right window of operations um for this. We worked with the comms team to proactively reach out to um our customers with a general blog post, with our Twitter post announcing our operations.

We reached out to crypto influencers, um Zach CBT, Taylor Monahan, um telling them and giving them advanced notice so that they would understand what was happening and not inadvertently perpetuate fear, uncertainty, and doubt in the networks in the market. Uh we also reached out, as I said before, to our regulators to give them advanced notice of the funds movements um so that they knew that we were accountable to them and that we were doing normal business operations. And we also went out and uh contacted Arkham as well so that Arkham would have advanced notice. And a couple of crypto media outlets as well so that they could help um and promote and keep the market stable for us. From a legal perspective, we verified this was not material information, right?

This is normal business operations. And only in the case that um the mission did go sideways, would we need to like make sure we sort of corralled um the operations and made sure that we minimize so like um movement of operations. And so after going through all of these um these hoops um at the very end our CEO Brian Armstrong was like, "Okay, guys. It looks like you prepared really well. Um but this is so important to me this operations that it goes smoothly.

I want to make sure that you're treating this like a critical mission operations. This is a treat this as if you have 300 passengers on a commercial airline flight. I want a critical operations handoff protocol and scripts." So even our CEO at the end of the day. So we developed a script for them.

We had a primary and secondary understanding that for every single role whether this went for 10 hours, 20 hours, or 30 hours would always have somebody sort of at the helm. Um you've got a primary pilot, you've got a secondary pilot on the plane. There's always somebody there to safely fly the plane. Um and we used the script with great success. Um it was definitely needed for the duration of the day.

So at the end of the day this was looked like one transaction um but back in underneath the back end um behind the blockchain you know, there were all these moving pieces and parts. We successfully moved 800,000 Bitcoin worth approximately $67 billion um market value at the time. 4.2 billion ETH um worth approximately $11 billion value on that time. This was the largest 24-hour transfer of value movement of value on these on the Bitcoin blockchain since the genesis block in 2009.

Um, and we did all of this for about $30,000 in gas fees. Which is an incredible, um, if you think about sort of like the fees that would be coming out of this in the trad fi environment. And most importantly, because we were able to do this successfully, I still had a job the next day. Um, I've I've got to say like at the at the end of the day, um, to execute this is not about bravado. It's all about systematic, methodical, planning and thinking, right?

Um, confidence is built in all the days and months leading up to the actual mission execution. Um, when when the, uh, when the engineers were first estimating some of the enhancements that we had to do from existing services and a couple of the new services we had to build. They're like, "Oh, you know, this is pretty straightforward. You know, we know these services. This is part of our day-to-day operations.

We can finish and be code complete in a month." I said, "Fantastic. Then I want you to test for two more months afterwards." And that's exactly what we did. We tested.

We did every thing in the kitchen sink in terms of failure cases we could throw at the system. Um, we tested, um, on we tested with our dev systems. We tested in staging. And then we finally moved to doing testing in production. So, if you actually followed our, uh, testing that we did all the way up and leading to the day of the mission, you would actually see we did our first large, um, transaction batch the day before.

I remember going through, uh, the testing that day before we were actually doing the mission. We're going through the scripts that made were designed to make the actual mission day look like as interesting as like watching paint dry. He said, "Yo Andre, I have never in my life done so much testing on a system I put into prod." I was like, "Well, but you've never worked with me." And on the day of full mission execution, you know, before things are getting started, you know, people are well rested, we're going to making sure we're loading up on our coffee, we're coming back from like the coffee machine walking down the hall, another engineer said, "Are you nervous?"

And I was like, "Andrew, if I was nervous, we would not be starting this at all. Everybody has to have pure confidence that we've planned it, we've tested it. If it doesn't go smoothly, we've got the right engineers, we've got the right operators on deck to be able to investigate, to be able to solve. Let's have faith. Let's know that we've planned this correctly.

And that we're going to be really pushing the boundaries of what's been done in this ecosystem. So, I want to say like everybody here who's coming to this conference, you're here because you're probably attracted by the opportunity to do work that has never been done before, irrespective of the risk and the unknowns [clears throat] ahead of you, right? But if you use a system systems design and engineering and operations planning approach, you can actually effectively sort of like chart these new territories and really enhance and advance the ecosystem. I think in many ways like the town of Quincy has done with, you know, being the first municipality to actual issue blocks blockchain based uh, bonds. So.

[applause]

Thank you very much, thank you.