One decoding discipline across every Solana program

The goal: one query shape, many programs

A team that studies flow should not need one parser for Meteora, another for Raydium, and a third for Pump.fun. Every table in the catalog shares the same envelope — block_time, slot, signature, transaction and instruction index — so ordering, joining, and replaying work identically across every program in the catalog.

That sounds obvious. The design work is in deciding what not to unify.

What normalizes cleanly

The envelope normalizes perfectly: when something happened and exactly where in the block it happened mean the same thing for a Meteora swap, an OpenBook fill, and a Kamino liquidation.

Account roles also normalize: signer and writable flags are decoded uniformly, so questions like "which wallet initiated this" have one answer shape everywhere.

What deliberately does not

Bin ids on Meteora DLMM, bonding-curve accounts on Pump.fun, order books on OpenBook — these are program-native concepts, and flattening them into generic columns destroys exactly the information a specialist needs. Instruction args and event fields keep their IDL-derived names and types, table by table.

The rule: the envelope is shared; the payload is native. Every table documents both, and nothing is projected away.

Practical notes for consumers

Raw integer amounts are preserved exactly as the chain recorded them — u64s stay u64s, nothing is lost to floats. And schema versions are pinned per partition, so a query that worked on v1.0 files will keep working on v1.0 files forever.