The Road to RPCh — Part 1
This is the story of how the whole HOPR team came together to identify an important missing piece of the web3 stack, and how a wonderful new RPCh team was born to turn it from an idea into a real product.
This series isn’t going to focus on the technology behind RPCh — you’ll hear a lot more about that as we get closer to launch. Instead I want to share something we don’t hear much about in crypto: the experience of creating RPCh from a product development angle. Forming the idea, designing the product, and building and training a team to get the product off the drawing board and in front of real users.
Step 1: The Shape of an Idea
The first step in creating a product is identifying a need.
We’ve been building privacy at HOPR for three years now. I joined the mission early, before the HOPR Association was even founded. I know everyone in crypto says they care deeply about privacy, but I really have always cared deeply about privacy. I felt early on that crypto and web3 provide the tools we need here, but you also don’t have to work long in crypto to see just how far we have to go.
Values are essential, but they’re just the catalyst for the real hard work of getting things built. But you have to always keep those values on the horizon, because when the realities of coding and business kick in, it’s easy to lose sight of why you started in the first place.
You run into unexpected problems, you start to cut corners, you rely too much on the way things have always been done. Everyone who’s spent any time coding recognizes this, but in crypto it has serious consequences.
Creating full stack privacy is hard, but without it web3 is worthless. A blockchain is only as strong as its weakest link.
And as we continued to build the HOPR protocol, it became clear that web3’s weakness was at the base: in the infrastructure layer. We’d always thought we were adding an extra layer of privacy to something that was already pretty good, what we found was that web3 infrastructure has even more privacy issues than Web2.0.
The real eye opener here was DERP, our Dumb Ethereum RPC Provider. DERP doesn’t do anything clever — it certainly isn’t a privacy solution — it just takes what’s hidden and makes it visible, showing all the RPC calls your wallet makes.
And the sheer number of privacy issues was staggering. Redundant calls, calls which linked previously unlinked addresses, calls which exposed asset holdings just to fulfill a simple UI request.
It’s clear why this happened. When people talk about privacy they can get paranoid. But it’s not malice, or data harvesting. It’s just what I said before: the reality of coders with too much work, too short deadlines, and needing to hack their way to a solution.
But an explanation isn’t an excuse. It was clear we’d identified a huge problem. And one thing really stood out: all that device metadata, including your IP address. We’d initially built DERP as an educational tool, a way to explain the realities of privacy to users and projects. But here was something we could fix. It’s what the HOPR protocol is for.
And so the idea was born: a service on top of HOPR that provided truly private RPC calls.
Step 2: The Bounty
But what to do with this idea? HOPR is growing rapidly, but we’re still a small team. All our tech resources go towards building the core protocol. And that protocol itself is just a base for building other applications on top.
“Send the RPC calls over HOPR” is a good tl;dr of the solution, but from a tech perspective it’s meaningless.
How do you connect the wallet to the HOPR network, and then HOPR to the RPC provider? Once the RPC call is served by the provider, how do you get the response back? How do you do it without breaking privacy?
And this is just for the test case of a single transaction. The questions only multiply when you imagine this as a product, serving countless RPC calls simultaneously for different wallets, all of which will have different integration requirements. And that’s without considering the UX side. Or the tokenomic implications. Or…
But all that could wait. For now it was important to identify the key issue.
We’d need to bring in more people.
We had already signed up to co-organize the Genesis Edition of the Infinite Hackathon in Bogota in October 2022, a few days before Devcon. There wasn’t a particular plan. We just had a general strategy to attract more devs to build on top of HOPR, and attending a high profile event seemed a good way to achieve that.
This new private RPC idea seemed like a great fit for bounty work: unusual, challenging, and separate enough from the core HOPR protocol that it would be possible for an external dev to get started.
Going into the hackathon, I knew we needed to make a really specific bounty. I’ve got a lot of experience of bounty hunting from both sides: my first years in crypto were spent as a bounty hunter, and that’s actually how I joined HOPR in the first place. Then more recently I headed HOPR’s own bounty program. And the constant lesson is that bounty hunters need a very clear brief or they’ll find something else to work on.
So we narrowed it down as far as we could go while still actually leaving room for creativity for the bounty hunters. What started as “Build something cool on top of HOPR” became “Build a solution for private wallet transactions over HOPR.”
But that was still too broad. HOPR is complex tech, and the format of hackathons means that lots of projects would be competing for hunter attention. Hunters aren’t afraid of a challenge, but time is short and they want to win something. No-one wants to spend half a day figuring out what a bounty even requires before having to give up and pick a new one.
So we iterated even further: we’d build a prototype, so the key questions were already settled, and ask people to hack on top of that to improve it.
Step 3: The Prototype
This was obviously the right approach. There was just one problem: the hackathon began on October 5th and it was already late September. In fact I had already started my journey to Bogota via Spain with my friend and colleague Rich, the HOPR DAO master.
We had to come up with the simplest possible proof of concept, and then build and document it. We also wanted to make sure the whole thing could be downloaded and run locally, because WiFi at these events is notoriously bad. It’s these practical details that can make all the difference between bounty hunters doing a great job and giving up through frustration.
With the planning done, in the end there was barely a week for the actual coding.
It was a tough week of really long hours, but we got it built, along with a demo and clear documentation. By the end we had the prototype, a wallet integration guide and a video demonstration. Huge thanks to Rich for being there to bounce ideas off and helping me debug.
It’s impossible to predict what will happen in a hackathon, but I was happy that we were going into it with a clear brief and an intriguing hook. And we did still find some time to see the sights.
But there was something else. It was genuinely exciting to run that first test transaction through the prototype. In amongst the stress of getting everything ready, the focus had narrowed onto the work of coding and testing, and I’d lost sight of the bigger goal.
But there it was: the first time using the HOPR protocol to send an actual wallet transaction. It was just a prototype in a test environment, but it held the promise of huge things to come.
Steven Noni
RPCh Product Lead
Website: https://rpch.net
Run RPCh Alpha for free: https://access.rpch.net/
Twitter: https://twitter.com/RPC_h_
Discord: https://discord.gg/VRyTQTNBTy
Powered by HOPR: https://hoprnet.org/
