Friday, February 27, 2026

I’ve been building chaincodec + Chainkit because multichain dev tooling is a real pain — What am I missing?

Over the past year been building chaincodec, a universal multi-chain decoding layer that aims to unify how blockchain data is parsed, normalized, and consumed across different ecosystems.

Right now, if you’re building anything multichain, you’re stuck writing 10+ custom parsers:

EVM ABI decoding via ethers/web3/viem

Solana Borsh parsing

Cosmos SDK Protobuf

Aptos/Sui BCS

Polkadot SCALE

Near Borsh

StarkNet felt/cairo ABI

Tron quirks

Bitcoin UTXO parsing

etc.

This fragmentation makes building bridges, indexers, relayers, analytics systems, cross-chain apps, dashboards, explorers, bots, and monitoring tools a huge engineering burden.

It’s not just about talking to RPCs — it’s about consistently interpreting raw chain data in a way your tooling can reuse without writing endless translation layers.

Every chain feels like reinventing the same parsing + normalization logic.

What I’m building (Chainkit -https://github.com/DarshanKumar89/chainkit)

chaincodec is just the first piece. The broader idea is a modular toolkit:

v0.1 – chaincodec

Core multi-chain decoder (Rust + npm + Python + WASM) so it’s usable everywhere.

v0.2 – chainerrors

Standardized cross-chain error decoding (because debugging across chains is painful and inconsistent).

v0.3 – chainrpc

Reliability layer with provider integrations + automatic failover.

v0.4 – chainindex

Lightweight, reorg-safe indexing engine (SQLite/Postgres).

v1.0 – Full multi-chain support

Solana + Cosmos + beyond.

The idea is not to build “another SDK,” but a unified decoding + reliability foundation for multichain infrastructure.

I genuinely don’t want to over-engineer something no one needs.

What’s the most painful part of multichain development for you?

Would a canonical normalized transaction/event format actually help?

Is decoding even the real problem — or is something else worse?

Would you prefer this as a library, CLI tool, or hosted service?

What would make you actually adopt something like this?

I’ve been deep in this for a while and I don’t want to lose the usage perspective.

If this is solving the wrong problem, I’d rather hear it now.


No comments:

Post a Comment