Stateless Clients for Everyone: Trustless Blockchain Access Without Full Nodes

EDCON 2025 · 16 Sept 2025 · 19:40

Jork Werner Leonhardt presents Colibri, a stateless client designed to verify execution and consensus data without storing blockchain state. His EDCON 2025 talk covers its architecture, zero-knowledge roadmap and uses on Ethereum, Layer 2s and other EVM networks, including access from mobile, web and IoT applications.

Speakers

Topics

From EDCON 2025, hosted by EDCON.

Transcript

Now we'd like to invite our next speaker, Mr. York Ver Leon Hart. Mr. York Vera Leonart, the floor is yours. Good morning and thank you all for staying with me. I know it's lunchtime, so you're probably hungry. But before you head out for lunch, here's some food for thought. And uh hopefully sprinkled with some inspiration for dessert.

But yeah, after I'm done, you're allowed to leave. Um I don't know how good the translation is. I always have the uh I always get get the thought that the faster the speaker is uh the worse the translation gets. So I'll try to speak slowly and uh if I go too fast just wave me down. Okay. So I I'll try to um stick to to my um to my prep. Okay. So here we go. So when I first got involved in the Ethereum ecosystem, um it was actually the ethos that

captured me. So it's stuff like trustlessness, you know, that there are no intermediaries, that we have smart contracts that actually enforce rules, that the blockchain is open and unstoppable. also that anybody could build that you didn't have to ask anybody for permission that what we built the the code is public it's forkable um it's composable and also that it's not a walled garden it's more like I don't know a a big box of Lego bricks and that anybody can take

out some of the bricks and put them together whatever you like and it you can build new stuff from it. This is stuff that I liked also that in this ecosystem there is no single party to control access or rules or the infrastructure that the validators are spread out globally that the technology is built to survive resistance from governments or corporations. What I really liked is that the early deafs were not in for the money.

They were here because they wanted to build something new. The next internet to be used by anybody, totally open and free. Ethereum is supposed to take no sides and to play no favorites. It's to be used by anybody. It could be a bank or just the DAO. It's a protocol that anybody can use to transact, interact, cooperate, and innovate. Banking the unbanked was a very strong narrative in the early beginning.

I'm now OG. I only started full-time in the space in 2018, but I have seen some changes since then. Let's be honest, how many of us actually rely on centralized RPCs for everyday use? So, we built an ecosystem that celebrates trustlessness and then we quietly inserted a black a black box right in the middle. Doesn't this contradiction bother you? RPCs aren't evil. They're useful, but they reintroduce the very risk that we try to remove. Single point of failure, censorship,

data manipulation, opaque failure modes. If Ethereum is the operating system for a credible neutral internet, why are we outsourcing truth to third party servers? Vitalic tried to invigorate us all to step up and make Ethereum a cipher punk again or in his own words to make at least a part of the Ethereum ecosystem actually be the permissionless decentralized censorship resistance open-source ecosystem that we originally came to build.

I won't be able to fix the ecosystem in a 20-minute talk today, but at least we'll explore one important building block for the ecosystem that we originally came to build. So, you probably remember the part of the ethos that um resonated with your innermost values. But what realities are we actually confronted with each day? We all keep seeing the same patterns. There are teams that preach decentralization and then they show products that depend entirely on centralized RPCs or data from index servers.

We have wallets that ask an RPC what's the balance or you have deps that ask did transaction land what's the receipt what's the log there are analytics notifications is final checks and that's all offloaded to endpoints that we don't control and then when it breaks we say the blockchain is down when actually we mean that our pipeline to it is broken.

Here's the honest truth. For many users, our PC responses are the defacto blockchain. That's not evil, but it's just too fragile. It's a classic convenience trade-off, but it collides head-on with with Ethereum's original promise. So, naturally, what would you do? You'd explore the obvious temptation and just whether it would be easil clients even lighter to make it possible for more use cases to just spin up a client.

That helps, but it doesn't erase the core problem of continuous sync network chatter and it's still too heavy to run on constrained environments like mobile embedded browsers or IoT. And it doesn't address the human reality. Devs still reach out for the easiest solution in a JSON RPC call if there's no drop alternative. And guys, you know, that's just the truth. You probably do it yourself. Well, then we have to pivot our thinking. If we don't want to think smaller, we should prove smarter.

What if the device doesn't hold history, doesn't gossip, and doesn't download the state of the whole entire world? What if it pulls cryptographic proofs on demand from any source, even an untrusted one, and verifies it locally? You can fetch data from a CDN, a friend's laptop, even a hostile server or random RPC provider, as long as you verify the proof yourself. That flips the model. The remote server is then just a dumb data career. Truth comes from the math on your device.

A couple there are a couple of hard questions that we have to answer though. How do we verify execution um without a trusted full node? Or how do we establish consensus truth that a given block is actually valid without replaying long committee transitions? How do we make this run in the real world in a wallet, a browser tab or a microcontroller? Well, these thoughts and the answers to that actually led us to Collibri with proof-based execution verification, succinct consensus verification, and a tiny embeddible core.

What's at stake is more than convenience. It's about restoring user agency, making verify locally the default, not an exception. Imagine a world where every wallet, every DEP, every IoT device can say we don't ask you to trust our back end. We ship proofs that you can check yourself. That's the world that we are building towards. That's why we built Kibbri. So Cibbri in a oneliner. It is a stateless proofbased ultra light client that runs anywhere mobile IoT or browser. So wallets and apps never have

to trust RPCs. So we ask you to don't trust verify. Ethereum was originally designed so that your app would connect directly into the network of nodes. You can fetch your data directly from the chain and by doing that it would be decentralized. It would be trustless. There's no censorship involved and you have full verification.

This is the ideal world. That's what we actually think is going on. But then we have the reality. Most wallets and apps don't do that. But they go through a centralized RPC and the RPC then becomes the bottleneck one service to rule them all. However, if the RPC lies, if it censors, if it fails, your app is totally blind. What can we do about that? The way forward is not to get rid of RPCs, but to change the role. Instead of asking RPCs to be the source of truth, they become just data providers.

Alongside them, you would add a proof provider. Your app then checks information plus proofs. The result, the whole thing becomes trustless again and the verification happens on device. Or you could also put the prover locally on the device. Either way, the key is this. You're no longer trusting RPC responses, but you're verifying cryptographic proofs. So in the end, don't trust, verify. To run such a stateless client, you don't need to interact with a peer-to-peer network or to store the ch

the state of the chain. However, you need to talk to an RPC provider to fetch the blockchain data itself. And then you'd also need proofs of the execution and of the consensus layer. And in case of an L2, you would also need a roller proof. And these proofs would either be also provided by an RPC or by a standalone proof provider or you could also create those proofs on your device itself. Collibri on your device would then verify those proofs locally. So the device, not the RPC, decides what is true and what is not.

So to wrap this up, Collibri offers you an ultra lightweight, stateless, trustless, proof-based multi-chain client that enables you to not trust but verify. So why does it matter? Now, this is not a whiteboard fantasy. Collibri is already running where it needs to run. We're going operational on Ethereum mainet and Nosis with other EVM chains and L2s in scope. The pieces exist. The UX is ready. The gap, the verifiability gap can finally be closed.

Don't trust. Verify. Now zoom out with me. A world where every device, phones, browsers, hardware wallets, IoT devices microcontrollers or even AI agents. They're able to do the verification themselves. IoT, for example, would stop phoning home for permission. IoT checks cryptographically facts locally. Web applications become truly trustless, not because your back end is truly honest, but because users don't have to trust you anymore.

Mobile devices, by the way, would never be able to run a client that needs to stay in sync. But with Kolibri, you fetch data only on demand. This is the next step in decentralization. Not just decentralized consensus among validators, but decentralized verification among users. In that world, you can still run RPCs and indexers, but the role has changed. They become data providers and not auditors of truth. If they lie, your device can detect it. If they censor, you fetch from somewhere else. If they

go down, you're not stranded because proofs can come from anywhere. Collibri is not another server you have to trust. If the missing client layer that makes don't trust verify a default experience for wallets, for deps and devices. That's the future I want to live in. And hopefully that's also the future that that you can live with. That's why we're building it. Okay, let's talk about some examples.

what it would actually look like. Let's take for example a wallet. Today, the wallet would ask an RPC for balances and recent transactions. With Collibri, you request proofs along with the data independent of their source. Your app verifies them locally. The user doesn't just see a balance, but a verified balance dive derived from proofs tied to real block headers that you validated through consensus proofs. The UX might be the same, but the security model is not. You're no longer saying trust my RPCs, bro, but trust the proofs that your device just checked.

Or think about Yeah, here you go. Or think about last week's npm incident. A malicious package slips into your pipeline and suddenly your wallet's signing flow touches code you did not expect. With Collibri in the loop, you can simulate and verify a proofbacked state before the user signs. And most importantly, you can compare the signed transaction with the original before you publish the transaction to the meool. If anything is off, if there's a difference in storage slots, if the allowance changed or if the send address has changed, and that's what unfortunately happened last week, you

don't publish the transaction anymore. So, don't trust verify. Defi front ends today mostly say trust us. This is your APY the TVL your position value. With Collibri a front end can say don't trust us verify the app ships proofs for position balances receipts events and the users divi their device verifies them locally.

This doesn't just protect users, it diff differentiates products. A verifiable UI out competes trust me UI. And the whole thing extends beyond phones or laptops. A smart lock, a smart lock could check on onchain access without an an onchain access list without trusting a gateway. A smart meter can verify a pricing update before acting.

A machine can accept a payment or a Q revocation only if the proof checks out on board. An AI agent can check balances, prices, and simulated outcomes before acting in your behalf or fully autonomous. No cloud required, no RPC assumptions, just cryptographic ver verification at the edge. Ethereum was never about trust me. It was always about don't trust verify. Let's bring that back together.

Now, if you want to dive deeper, if you want to dive deeper, everything is open. Yes, the white paper, the spec, and the GI GitHub repo. be so free and scan the QRS, review the docs, and try out Calibri yourself. We're asking for your feedback from wallet builders, from dev teams, and infravs. We'd love to hear back from you, get your feedback, your experience, and see what interesting use cases you want to secure by real proofs. And also, please join the conversation.

Follow me, follow the official Collibri account, or if you prefer the spicy takes, just follow Collibri's illtempered cousin with an attitude. Collibro. By the way, if you want to learn more about last week's npm attack, my friend and colleague Stefan right here also in the yellow shirt up front uh will talk about that attack on Friday 11:00 a.m. also here on Mainstage. and he'll also talk about trustless Ethereum also on Friday on main stage at 11:50. So please also join the conversation right then.

Now thank you for listening. We'd love to work with teams who want to make verifiability a firstass UX feature. Talk to us after the session or also somewhere around here you'll see us with the yellow shirts and let's build apps that don't rely on blind RPC trust anymore. Thank you.