Building for Core Devs: How OP Labs Accelerates Protocol Engineering

All right, hi everyone, thanks for coming. I'm Tess, I'm a product manager at OPLabs, which is one of the core dev teams behind Optimism and the OPStack. And the OPStack powers many of the leading L2s, including Base, Unichain, and Worldchain. And it's built by a group of core dev protocol teams. So these are engineering teams at OPLabs and other partner teams who ship features like fault proofs or interoperability.

And when you picture blockchain engineering, you might think mostly of this kind of direct protocol work. But at OPLabs, we realized that we could really accelerate that work by standing up a dedicated platform engineering team. An idea that we borrowed from Web2, but that's still relatively new in crypto. So I lead product for this new platform's org. We own the shared tooling that protocol engineers lean on to ship safely and fast.

So today I'll give you a pretty honest experience report on launching this team at OPLabs, the processes we tried, the tools we built, and the lessons you can borrow for your own org. Oh, is this the clicker? Okay, cool. So every change to the OPStack travels the same path, from being sacked to being deployed. Our mission with the platform's team is to smooth out and speed up that whole journey so that OPStack contributors can focus on protocol logic and not yak shaving.

We call this focus Protocol DevX, and our North Star goal is to shrink the time and the pain between I have an idea and it's running safely on every OP chain. When the platform's org spun up late last year, one idea shaped all of our plans. Treat protocol engineers like customers. And that mindset shift triggered two concrete actions. First, we did dedicated user research.

We booked real discovery sessions. No pitching, no assumptions, just listening. And as a PM, I could kind of play this role as, like, the naive outsider, right? Asking the questions that my engineering colleagues might have skipped because they could assume more shared context. Next, we took on customer-level accountability.

So we grade ourselves on protocol engineer success with regular satisfaction surveys and clear metrics like weekly active users for all of our test suites and test frameworks. If adoption stalls, that means that we're not doing our job. So what did this look like in practice? Well, I sat down with each protocol squad inside and outside of OPLabs, and I did this in small, familiar groups so that people could feel comfortable venting. Afterwards, I distilled everything into a key takeaways deck that guided the platform's team's planning and focus areas.

And this problem discovery work is really never done. So we also keep an ongoing public channel called RAGE, where any protocol engineer can log new annoyances as soon as they run into them. What came out of this? Well, across the board, we heard two of the same pain points over and over again. First, testing.

Engineers had low confidence that they were writing tests that accurately modeled real-world scenarios, especially for unhappy path end-to-end test scenarios. Next, our release process, which many protocol engineers saw as complex, unnecessarily manual, and honestly kind of scary. So to start addressing these challenges, we borrowed quite liberally from the East Panda Ops team. And here I want to give a big shout-out to East Panda Ops and their crew, because their public tooling, DevNets, processes, all of that really helped show us what good could look like here. The first idea that we borrowed was around many different DevNets.

So previously, we had just one long-lived DevNet, which was upgraded by hand and torn down, really, only when something went catastrophically wrong. But this meant that we had limited scenario coverage, and there was always this pressure to delay the DevNet and just get one more feature in. This created churn, it left engineering teams in limbo, and it ultimately delayed releases. So in our new world, we have two predictable DevNet trains that never wait for late passengers. The first train is the Alphanet.

It spins up every four weeks from scratch, and it contains all the code-complete features at Genesys, so we're not going through the extra work of upgrading that network. The Alphanet ensures that these features are stable in isolation. The next train is the Betanet, and so as we get close to a real upgrade, we take the latest unreleased features and test the upgrade itself by actually upgrading that last Betanet. The new network then serves as the release candidate for whatever upgrade we're going to be pushing to Sepolia or to Mainnet. For feature devs, the rules are now crystal clear.

Make the train or wait for the next one. And this reduces churn around feature discussions and just overall increases our reliability. Both DevNet trains also run through our acceptance test suite, which is driven by a tool called OP Acceptor. OP Acceptor hits every DevNet, Alphanet, and Betanet with a set of acceptance tests to prove that the network is healthy, feature-complete, and ready to be promoted. The tests exercise real-world workflows, like load testing, deposits and withdrawals, cross-client consensus checks, and checks our uptime SLOs.

And any failure here can block the release train until it's fixed. But acceptance tests are really just one part of our overall testing strategy. A good test framework helps development shift left so bugs can be caught earlier in the development cycle. In other words, the idea here is that developers should be able to have confidence in their changes as early as possible, catching and fixing bugs locally before they submit a PR or execute a network upgrade. So, to enable this, we added Kurtosis and the Optimism package, again from the East Panda Ops team, to our testing stack so that anyone can spin up a full DevNet on a laptop ASAP.

In addition to the DevNets and the acceptance tests, we also created DevNet SDK, which is this abstraction layer over any network backend. So, this means that developers can now write a test once and point it anywhere. And protocol teams can use this abstraction layer to build their own test helpers and libraries to handle common flows like funding accounts or simulating reorgs. And I want to call out here that we initially thought that platforms might own that piece of it too, but we discovered pretty quickly that actually feature teams can iterate most quickly on their own test helpers and libraries. So, zooming out, all of this means that the OP testing stack now covers a variety of target environments and can be used to create a pretty wide variety of test types, ranging from unit tests to these full-on end-to-end acceptance tests.

So, where we're at today. It's still early days. We have a lot of work ahead of us to really compress that development timeline. But our initial progress, I think, is pretty promising. Protocol engineers are adopting these frameworks and running more and more tests every week.

And they've told us that these tools are giving them new levels of confidence in their releases and features. And of course, along the way, we have learned a lot. So, here are some of the things that you can also keep in mind if you're thinking about applying any of this within your own org. First, treat protocol engineers like customers. When you call someone a customer, you implicitly promise to listen to them first, ship only what solves their problems, and then measure their satisfaction.

So, instead of saying, here's a hammer, go use it on all your nails, you're really saying, show me your nails, show me what problems you're seeing, and we'll bring you the right tool to solve it. Second, prototype early and prototype ugly. Protocol engineers can't always describe the tool that they need, but they will always recognize the one that they don't. A scrappy CLI or a quick config file will generate 10 times the actionable feedback that a perfect design doc would create. These low-cost prototypes de-risk direction and keep momentum and morale high.

Third, own the plumbing, but let feature teams own the fixtures. So, the platform team maintains the generic layers like DevNet SDK and Kurtosis spin-up because that complexity is common to everyone. On the other hand, protocol squads own their domain-specific helpers and tests because they know their edge cases, and they can iterate faster than a central team. Fourth, instrument success up front and be ready to invest in setting up these metrics. Success metrics are really important for demonstrating impact to your leadership team, and without numbers, you're kind of just flying blind, but it can also take real time to select and then really instrument the right metrics.

So, you need to leave engineering time for this. Finally, be patient. Our first quarterly survey, honestly, it landed with a little bit of a thud. Devs were still skeptical, but a quarter later, that feedback is flipping. New tools have an adoption curve, and it takes time to iron out the kinks.

So, that's all I've got. I think we're probably just about at time, but I want to say big thanks again to the PandaOps team and the Kurtosis team for blazing the trail, and of course, to all the engineers on the platform team at OPLabs. Yeah, I don't know if there's time for questions, but I'm also happy to jam on this stuff in the hallway track, and I'd love to hear from you if you're thinking about spinning any of this up in your own org. How are we doing on time? We don't really have time.

All good, all good. But I did see one question pop up at the very end, so maybe that person can find you and ask at the end. Okay. Find me in the hallway. Thanks again.

Thanks again, Tess. And next up, we have Ekaterina, who's an Ethereum Protocol alumni and Lowestar contributor and also focused a lot on metrics and data. Please welcome her on the stage.