Bitcoin block 867,867, October 29, 2024. The Nakamoto consensus rules activated on Stacks mainnet, and for about forty minutes, I forgot how to breathe normally. Cheering this extraordinary moment with the core devs and leads over a glass of bubbly in the small hours, forty-eight hours deep into no sleep, is forever etched in my memory.
We’d tested it relentlessly, but this was the biggest consensus change since mainnet launch, and it added entirely new surface area to the protocol: a signer network, new block production mechanics, new roles and infrastructure that hadn’t existed before. Months of testnets, audits, and fuzz testing don’t fully prepare a team for activating on a live network with real value, because the reality is that chain stalls are possible, consensus splits are possible, and when something goes sideways in Web3 there’s no rollback. We weren’t patching a service behind a load balancer; we were changing the rules of a system where every failure has immediate, irreversible financial consequences. So even with champagne in hand, those bleary-eyed hours still felt like holding my breath.
One year later, I want to talk about what the Nakamoto upgrade actually took, what we got right, and where I’d course-correct if I could do it again.
What Nakamoto Changed
Before Nakamoto, Stacks produced one block per Bitcoin block, which meant roughly ten-minute block times inherited directly from Bitcoin’s cadence. It was functional, but it made real-time applications nearly impossible, because building DeFi when every transaction confirmation takes ten minutes is an exercise in user frustration.
Nakamoto decoupled Stacks block production from Bitcoin’s pace by introducing a signer network that produces Stacks blocks in under five seconds, whilst Bitcoin anchor blocks still provide finality checkpoints. The result is fast local consensus with periodic settlement to the most secure chain in existence.
Architecturally, block production moved from a miner-only model to a miner-plus-signer model, where miners win tenures and signers validate and produce blocks within those tenures. What used to be one Stacks block per Bitcoin block became many Stacks blocks per Bitcoin block, with the same finality guarantees. The change went far beyond a feature flag or config toggle, requiring a fundamental rewrite of how the network reaches consensus.
Protocol Upgrades Are Not Product Launches
I’ve shipped a lot of product updates over the years, across trading platforms, payments infrastructure, and blockchain tooling, and the thing that’s always true about a product deploy is that I control it. I own the servers, I pick the release window, my on-call team can revert if metrics look wrong.
A protocol upgrade is a categorically different problem because we control nothing. Every participant in the network, from miners and signers to exchanges, node operators, wallet providers, and dApp developers, has to independently decide to adopt the new rules. We can’t force it, and we can’t even strongly encourage it beyond publishing good code and clear documentation.
Exchanges needed to upgrade their nodes and adapt to new API behaviors, miners needed to update their commit transaction logic, and signers were an entirely new role that required building infrastructure from scratch. Node operators had to reindex, and dApp developers needed to test their contracts against the new consensus rules. All of this had to happen in a coordinated sequence without anyone having the authority to mandate that sequence, because we can’t exactly send a Slack message to the Bitcoin network.
In my experience, the social coordination layer of a protocol upgrade ends up being harder than the technical layer. Getting the code right is necessary but insufficient; getting dozens of independent operators to trust the work and move in sync, on their own timelines, with their own risk tolerances, is the part that no architecture diagram captures.
The Testing Gauntlet
Testing a consensus change is different in kind from testing application code. App code mostly defends against accidental bugs, whilst consensus code has to withstand adversaries with millions of dollars of economic incentive actively trying to break it, and that difference in threat profile demands a completely different level of rigor.
We ran multiple testnet phases, each more adversarial than the last: controlled testnets where we could observe behavior in isolation, public testnets where anyone could take their best shot at breaking things, and practice forks that simulated the exact mainnet activation sequence. Then came the security gauntlet with independent audits from multiple firms, each examining different aspects of the system, along with fuzz testing to surface edge cases we hadn’t imagined and penetration testing to validate our assumptions about the threat model.
Every phase had a go/no-go gate, and the question at each gate was the same: “Are we confident this won’t break a live network with real money on it?” If the answer was anything short of yes, we waited. We delayed more than once, and every delay was the right call, because the timeline has to serve the quality when the consequences are irreversible.
The Phased Rollout
We split the upgrade into two distinct phases, instantiation and activation, as a risk management strategy for an irreversible change rather than complexity for its own sake.
Instantiation, triggered at Bitcoin block 867,867, activated the new Nakamoto consensus rules and enabled signer registration, but it didn’t immediately switch to fast block production. Instead, the network ran with the new rules in a transitional state, giving everyone time to verify that the consensus change was stable before we turned on the full feature set.
Activation came later, enabling the signer-driven fast blocks that were the whole point of the upgrade. By the time we flipped that switch, we’d had weeks of the new consensus rules running cleanly on mainnet, weeks of watching and monitoring and resisting the urge to move faster than the data warranted.
A single cutover would have compressed all the risk into one moment, but the phased approach gave us observation windows between irreversible steps. Pre-launch testing tells us what we expected to find; observation windows on a live network show us what we missed. I didn’t fully appreciate that distinction myself until I was the one responsible for a network carrying real value.
What I’d Do Differently
Zero security incidents during the biggest protocol change since mainnet launch is something I’m proud of, but a clean security record doesn’t mean everything went perfectly, and the honest version of this story is more useful than the victory lap.
Exchange communication was too reactive. We had documentation, we had channels, we had support, but we should have embedded dedicated integration engineers with our top exchange partners months before activation rather than weeks. When Coinbase or Kraken pings about our consensus change in the middle of the night, the answer needs to come from someone who already has deep context rather than someone ramping up on the ticket. That’s a staffing decision I should have made earlier.
Node operator documentation could have been sharper. The upgrade required a reindex, which is a significant operational commitment, and whilst we documented it, we underestimated how many different infrastructure configurations existed in the wild. More runbooks, more edge case coverage, and more specific guidance for specific setups would have saved a lot of people a lot of friction.
Community communication could have been more structured. We provided updates, but the cadence was inconsistent, and a regular, predictable communication rhythm would have reduced uncertainty for stakeholders trying to plan their own upgrade timelines. Consistency builds trust in ways that even good-but-sporadic updates can’t.
These are execution gaps rather than strategy failures, but execution is where credibility lives, and I don’t get a pass on that just because the overall strategy was sound.
One Year Later
Sub-five-second block times opened up an entire category of applications that didn’t work before: DeFi protocols that need real-time price feeds, applications where user experience depends on fast confirmation, and smart contracts that can interact with each other within a reasonable time window instead of waiting ten minutes per step.
The Nakamoto upgrade laid a foundation that the ecosystem is still building on. It proved that a Bitcoin Layer 2 can achieve fast execution without sacrificing the security guarantees that make Bitcoin valuable in the first place, and one year of production traffic has validated that thesis.
But the deeper lesson for me has more to do with the kind of patience that protocol work demands than any specific technical insight. Product timelines measure in sprints, whilst protocol timelines measure in readiness rather than calendar dates. The best infrastructure is the kind you never notice because it just works, and getting there requires a type of coordination that no project management framework fully captures: a willingness to let the timeline bend around the quality rather than the other way around, and the discipline to hold that line when everyone, myself included, wants to ship faster.
A year on, the signer network is humming along and the ecosystem is building things that weren’t possible before Nakamoto. Whether the next protocol change will go as cleanly is an open question, because the network is bigger now, the stakes are higher, and the coordination surface has grown with every new signer and every new application depending on fast blocks. We proved it can be done; we haven’t yet proved it scales.