# Podcast - Your Web3 App Isn't Trustless. It Never Was.

> The stateless client quietly fixing it. Colibri founder Steffen Kux on building the missing layer between decentralized networks and the apps that claim to use them.

**Published by:** [BuildBetter by BFG](https://paragraph.com/@buildbetter/)
**Published on:** 2026-03-26
**Categories:** privacy, podcast, trustless, colibri, steffen, kux, gtm, builders
**URL:** https://paragraph.com/@buildbetter/podcast-your-web3-app-isnt-trustless-it-never-was

## Content

In this conversation with Steffen Kux from Corpus Core, I learn how far ahead they are with building a trustless, stateless Colibri client with pragmatic privacy. It seems they're almost done with v1.0, now being integrated into the Kohaku wallet.TLDREvery wallet and dApp you use today likely pulls data from a centralized RPC endpoint — and never verifies it. Colibri is a stateless client that changes that.Steffen Kux built it because the problem was obvious, the solution was technically feasible, and nobody was doing it. Self-funded, open source, first integration dropping at EthCC.The deeper insight: privacy maximalism kills privacy. His PAP (Pragmatic Adaptive Privacy) framework matches the level of privacy to the sensitivity of each request — instead of making everything expensive and unusable.Full Episode ShareSummaryThere’s a gap in almost every Web3 app you’ve ever used. You built it to be decentralized. Trustless. Permissionless. Then you plugged in an RPC endpoint and moved on. Most teams never look at that decision again. It works. The DeFi logic is clean. The UX feels fine. Ship it. Steffen Kux and his team looked at it again.The problem nobody talks aboutWhen Ethereum launched, Mist browser ran a full node locally. You had to wait for sync. It was painful, but the data was verified. Then the chain grew. Mist became unusable. Light clients existed since 2016, but they were too heavy for real apps. Centralized RPC providers filled the gap — and they never left. It's ironic with repeated calls for “trustless” dApps. You built on a decentralized network. You wrote trustless smart contracts. Then you handed your data layer to a company running servers you don’t control, returning values your app never checks.Steffen’s framing: “Most applications are not able — and not doing it at all — to verify the information they receive from these RPC endpoints.”That’s not a critique. That’s just the state of things.What Colibri actually doesStateless client. No synchronization. No stored state. You get two things alongside your data: an execution layer proof (this data belongs to a specific block) and a consensus proof (that block is part of the canonical chain). Both together let any device — smartphone, IoT door lock, air-gapped wallet — verify blockchain data locally. The interface is the same as an RPC. Drop Colibri in, nothing else changes. Trustless by default. Proof-of-stake made this finally feasible. With PoW you needed a network of nodes to generate proofs. With PoS, validator committee data is in the protocol — the signatures are there, verifiable directly. They shipped the production version for Ethereum in November. Gnosis chain shortly after. Optimism-based L2s in MVP. First real integration: Kohaku wallet (a fork of Ambire), demoing at EthCC.SubscribeThe adoption problem nobody wants to say out loudHere’s the part that’s harder to solve than the tech. When Steffen talks to teams, they get it. They agree it’s essential. Some say they’ll test it. Then they go back to their RPC provider.“It’s not the top priority right now because it works.”That sentence should sting a little. It’s not unique to Web3. Security infrastructure, observability, data verification — anything that prevents a problem that hasn’t happened yet will always lose to the feature that ships this sprint. Until it doesn’t. The Trustless Manifesto from the Ethereum Foundation got a lot of applause when it dropped. Lots of “yes, exactly, this is what we need.” Then everyone went back to their trusted endpoints. Awareness isn’t the problem. Convenience is.The synthesizer interludeBefore the privacy section of the conversation, Steffen went somewhere unexpected. He grew up in East Germany. Loved electronic music. Moog synthesizers cost multiple monthly salaries — completely out of reach. So he went to the university trash bin a few times a week and collected discarded electronic parts. Transistors. Resistors. Whatever he could find. Then he adapted circuits from books to use what he had. Three or four years later, he had a working synthesizer. The point wasn’t the hardware. The point was: stop waiting for the perfect tool. Build with what you have. Be pragmatic. That story leads directly into their pragmatic privacy framework (PAP).Privacy maximalism kills privacyThis is the contrarian take that holds up under scrutiny. When people think about Web3 privacy, they think Tornado Cash. Railgun. Shielded transactions. Full obfuscation. Steffen’s argument: that framing is too narrow — and the cost of maximalist approaches kills adoption before it starts. There are two problems. First, private reads. Before you ever send a transaction, you’re reading balances and contract state. Your RPC provider sees every one of those reads. They can infer exactly what you’re about to do. “Sometimes these reads are even more revealing than the transaction itself.”Second, the privacy-verifiability tension. If you try to fully obfuscate your reads using protocols like ORAM, you either verify too much (expensive) or reveal your actual interest (no longer private). They contradict each other in naive implementations. The PAP paper (Pragmatic Adaptive Privacy) is their answer. The core idea: not every request needs the same level of privacy. A dashboard pulling USDC balances? Low risk, low obfuscation needed. Preparing a Railgun transaction? Shield it — the request pattern alone reveals intent. Instead of one setting, a matrix. Transport layer vs. content layer. Per-request sensitivity. Pragmatic defaults with developer control. It’s not as private as a pure ORAM approach. It’s dramatically more private than what exists today — and actually usable.The three things every app needsBy the end of the conversation, Steffen had summarized the whole stack cleanly:Trustless reads — verify every piece of data you pull from the chainLocal simulation — simulate every transaction before signing, locally, in the clientPragmatic privacy — match privacy level to request sensitivityPoint two is worth pausing on. Colibri can simulate a transaction outcome inside the client before it’s signed. This isn’t just a UX convenience. In September last year, injected Node.js library code tried to manipulate the transaction signing process. If Colibri had been in place, it would have caught it — by re-verifying the signed transaction before broadcast. These aren’t three separate products. They’re one stack. One client. One drop-in replacement for the RPC call you’re already making.Lessons Pragmatic sequence - from self-funding, to community grants, to future Licensed products.Distribution challenge - even good infrastructure dies when it’s more convenient to do nothing or to do the “other thing.” Steffen’s closing line stuck with me:“If you are using an RPC in your application, don’t do it in the future. Start using trustless data. The time is now. There’s no excuse because we don’t have the information. We have it now. It’s available. It works. It’s productive. Just do it.”It won’t happen all at once. It rarely does.Resources & LinksColibri StatelessWebsite: corpuscore.tech Colibri Whitepaper: GitbookFollow Steffen Kux: https://x.com/SteffenKux BuildBetterNewsletter: buildbetterhq.substack.comX/Twitter: BuildBetter HQYouTube: BuildBetter HQIt was a bit more technical. I hope you enjoyed it. Give Steffen a follow and Colibri a try if you're building something in the decentralized Web3 space. Till next time, build better! Pete (aka BFG) Subscribe

## Publication Information

- [BuildBetter by BFG](https://paragraph.com/@buildbetter/): Publication homepage
- [All Posts](https://paragraph.com/@buildbetter/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@buildbetter): Subscribe to updates
- [Twitter](https://twitter.com/aka_BFG): Follow on Twitter