Disclaimer: rustock is a personal experiment exploring how far today’s AI coding tools can go. It is not an official Rootstock client, has not been security reviewed, and should never be used in production.
One of the biggest long-term challenges for any blockchain is client diversity. Independent implementations make networks more resilient by reducing reliance on a single codebase. But building a second client is difficult, especially when the existing implementation effectively serves as the protocol specification.
That’s the situation on Rootstock today. Unlike Ethereum, Rootstock doesn’t have a formal consensus specification. In practice, rskj is the specification. A second client has to reproduce its behaviour exactly, down to edge cases that have accumulated over years of development. Get a consensus rule wrong and the network forks. Get the Bridge implementation wrong and the consequences can be even more serious.
For years, the idea of building another Rootstock client remained just that: an idea. Then I started wondering whether AI had changed the economics. Instead of using coding assistants as a smarter autocomplete, I decided to see how far they could really go. The experiment was simple: could I build a Rootstock client in Rust without writing a single line of code myself?
Starting with a light client
The code is available on GitHub
Rather than attempting a full node from day one, I started with a light client that could validate every Rootstock block header from genesis. The AI agent used rskj as its reference implementation and followed a few simple rules: build in small increments, stay fully compatible with rskj, keep the Rust code idiomatic, and write tests continuously.
What surprised me wasn’t how quickly code appeared. It was how often that code looked perfectly reasonable while being subtly wrong. The implementation compiled cleanly and passed unit tests, but bugs only surfaced once it started validating the real blockchain. Running against Mainnet became the ultimate source of truth. Every divergence exposed another assumption the model had made or another edge case it had missed.
After many rounds of debugging, the client finally validated every Rootstock header from genesis. At that point, the obvious question was whether it could become a full node.
From light client to full node
Moving from headers to full execution turned out to be far harder than building the light client. Execution meant transaction processing, state management, receipts, gas accounting, and support for Rootstock’s unique precompiles, including the Bridge and REMASC, which are among the most consensus-critical parts of the protocol.
As the tooling improved, so did the development process. Instead of asking the model to generate individual functions, I increasingly delegated entire debugging loops. The agent would compile the client, attempt a sync, analyse the failure, write tests, fix the issue, and start again. The blockchain itself became the feedback loop.
Every newly executed block exercised different parts of the code, exposing bugs that earlier blocks had never touched. Many weren’t obvious programming mistakes. They were tiny behavioural differences between Rust and Java that had quietly become part of Rootstock’s consensus over time.
That ended up being one of the most interesting lessons from the project. Without a formal protocol specification, consensus doesn’t just live in the design. It lives in the implementation. Reproducing Rootstock meant reproducing not only the intended behaviour, but also every consensus-relevant detail of rskj.
Eventually, after many iterations, the Rust client synced the entire Rootstock blockchain and continued following new blocks.
What AI was good at, and what it wasn’t
The project completely changed my view of AI-assisted software development. AI was remarkably effective at repetitive engineering work such as porting existing code, generating tests, identifying implementation differences, and iterating quickly against real-world feedback.
Planning was a different story. Large, loosely defined tasks often resulted in incomplete implementations with hidden gaps. The better the initial architecture and the smaller the individual tasks, the better the results.
Just as importantly, AI didn’t remove the need for validation. If anything, it made validation even more important. A blockchain offers an unusually powerful development environment because every block provides deterministic ground truth. Without that constant feedback, I don’t think this project would have been possible.
Why this matters
This experiment wasn’t about proving that AI can replace protocol engineers. If anything, it showed the opposite. Building the client became dramatically faster, but reviewing, validating, and testing the result remained essential. Consensus software leaves almost no room for approximation.
What has changed is the cost of experimentation. Projects that once required significant engineering investment can now begin as side projects. That makes it much easier to explore new tooling, alternative implementations, and, ultimately, greater client diversity across the Rootstock ecosystem.
rustock is nowhere near production-ready. It still needs extensive auditing, security review, and long-term testing before anyone should trust it with real value. But that’s not really the point.
The point is that something which previously felt unrealistic, building a second Rootstock client from scratch, became achievable as an experiment. Whether AI ultimately saves engineering effort or simply shifts more of the work into review and verification remains an open question. What feels much less uncertain is that the barrier to experimenting with blockchain infrastructure has fallen dramatically. For an ecosystem that benefits from independent implementations and open experimentation, that’s an exciting place to be.
