A Three-Layer DePIN Architecture Built for Real-Time Sync
A Rust DePIN protocol splitting validation, synchronization, and clients into three layers so existing Croquet-based apps get trustless sync with zero code changes.
Forerunner Protocol is my attempt to close the performance gap between traditional finance systems and blockchain infrastructure without asking application developers to rewrite anything. It is a DePIN, a decentralized physical infrastructure network, built in Rust, and the whole design hangs on splitting the system into three layers that each do one job. The project lives at forerunnerprotocol.xyz.
Three Layers, One Job Each
The Validator Layer is a high-performance consensus network using BFT, tolerant of up to 33% malicious validators. The Synchronizer Layer handles real-time session synchronization, the moving state that a live multiplayer or multi-user app depends on. The Client Layer is the part I am most attached to: it requires zero changes from existing Croquet-based clients.
That last constraint drove a lot of the architecture. It is easy to design a fast protocol that demands everyone adopt your SDK. It is much harder to slot underneath applications that already exist and give them trustless synchronization for free. Keeping the client layer a drop-in replacement means the interesting complexity has to stay contained in the validator and synchronizer layers, where the users never have to see it.
The Transport and Storage Choices
Two engineering decisions stand out. The first is a transport hierarchy: WebTransport, falling back to WebRTC, then WebSocket, then TCP. Real-world networks are hostile in specific ways, and a single transport always loses somewhere. Degrading gracefully through four of them means a session survives conditions that would drop a naive WebSocket-only client.
The second is storage modeled on BitTorrent: 256KB chunks with 3x replication. Chunked, replicated storage is a well-understood way to get durability without a central store, and borrowing the shape from BitTorrent means leaning on a design that has already survived adversarial networks at scale. Ed25519 signatures run throughout, and the protocol includes built-in MEV protection and fair ordering.
The README is honest about where the numbers actually sit. The throughput target is 1M+ TPS and the current measured figure is 800K TPS. The latency target is under 200ms and it currently runs at 180ms. Finality is one block. Those are real measurements against real targets, not launch copy, and the gap between target and current is the roadmap.
The Takeaway
The design lesson I keep coming back to on this project is that "zero changes required from existing clients" is a brutal but clarifying constraint. It forces every hard problem, consensus, sync, transport failure, into the layers the user cannot see, and it keeps the surface they do touch boring on purpose. Boring at the edge is what makes adoption possible.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →