Why we're building ChainFoundry
Every year, tens of billions of dollars move across blockchains. Not one, not two — seven fundamentally different architectures, each with its own encoding, each with its own idea of what a “transaction” or “event” even is. And every team building on top of them pays the same tax: rebuild the plumbing, chain by chain, until they run out of money or patience.
It's the most expensive copy-paste problem in the industry. A wallet team bolting on Solana rewrites the retry logic they already had for Ethereum. A compliance team licenses a $100K/yr SaaS because open-source correlation “doesn't exist.” An AI agent startup gives up on Cosmos because decoding Protobuf in their stack is too painful. Every single one of them solves the same problem in isolation, and the work never compounds.
We think this is a missing standard-library problem. Rust has one. Python has one. The web has libcurl and libssl. Blockchains have… a graveyard of chain-specific SDKs and a handful of walled SaaS providers. That's what ChainFoundry exists to fix — not another framework to learn, but the quiet, boring, reliable substrate underneath whatever you're trying to build.
Our bet is simple: the next decade of on-chain software gets built by teams who don't have time to reinvent RPC middleware. Give them a decode layer, a transport layer, an indexer, and a correlator — four crates, one API, open-source — and the work starts to compound across an entire industry instead of disappearing into repo after private repo.
Origin story
How Darsh got here
Twenty-five years ago, Darsh Kumar was writing Java for early-internet banks, watching transactions clear through half-a-dozen message formats that nobody could agree on. A decade later he was deep in Oracle, DB2, and Postgres internals, wiring data out of systems that were never meant to talk to each other. A decade after that he was doing cybersecurity architecture for EU institutions, auditing the same kind of multi-system data flows — except now the stakes were public-sector healthcare and critical infrastructure.
He went on-chain in 2017, and the pattern felt oddly familiar. Different encodings, different assumptions, different failure modes. And the same lazy industry response: “just pick one chain and stay there.” Except real money — and soon, real regulation — wasn't going to respect that.
The tipping point came while working on EU public-sector data infrastructure. Watching MiCA and NIS2 land, it was obvious that the compliance side of crypto was about to collide with the fragmented tooling side at full speed — and there was no open, embeddable primitive that could hold both up. You could rent intelligence from Chainalysis for $100K a year, or you could rebuild it yourself and fail. That was the whole menu.
So he started writing one. In Rust, because performance and memory safety aren't optional when you're decoding a million events a second. With bindings in TypeScript, Python, Go, Java, and WASM, because no real team lives in a single language. Open-source, because the mistake of the last decade was locking this layer behind contracts. And with a specific bias toward EU builders — regulated exchanges, law firms, RegTech startups, public-sector teams — who have been underserved by a US-centric tooling market.
That's what ChainFoundry is. A 25-year engineering career, pointed at one deeply unglamorous problem: making blockchain data infrastructure boring, reliable, and free.