Straight answers, no ratio inflation.

The one measured figure we cite is "up to 60:1 on archival workloads with the MaxCompression preset" (Zstd level 19). It is the top of the range, not the median, and it assumes the input has the repetitive byte structure typical of account snapshots or batched archival data. Every other ratio on this site — the 15–40:1 for accounts, 10–30:1 for transactions, and so on — is an illustrative preset range, not a guaranteed result on your data.

State bloat is fundamentally a storage-and-bandwidth problem: high-throughput chains add state every slot and never reclaim it, so full history grows without bound. Compression does not shrink live consensus state, but it dramatically shrinks the archival and historical copies that archive nodes, indexers, and storage networks are paid to keep. On repetitive archival Solana data the MaxCompression preset reaches up to 60:1, which turns a storage line that tracks block height into a much flatter one.

Yes — that is one of the strongest fits. DePIN storage and RPC networks are billed on what they hold and what they replicate across peers, so fewer bytes on disk and on the wire directly lowers cost. Because the library is a pure Rust crate with no node or network dependency, it drops into a replication or ingest pipeline as a byte-in, byte-out step. Round-trip verification guarantees every peer reconstructs the exact original data.

The shipping preset is SolanaCompressor, which builds its dictionary from common Solana program IDs, instruction discriminators, and lamport amounts. The core trait layer is chain-agnostic — you can build your own dictionary for other chains — but the README only ships Solana presets. A random EVM payload will not compress like Solana-shaped data.

Yes. Round-trip equality is enforced by tests on every preset. The README states "100% lossless — rigorous roundtrip validation on every operation." If decompress(compress(data)) != data, the library is failing a unit test.

Use the zstd feature for the Solana presets. DEFLATE (the default) and LZ4 are available as alternative backends behind their own feature flags, but the dictionary-driven presets that achieve the headline ratios require zstd.

No. The dictionary is hardcoded from a fixed list of common Solana byte patterns and built at compressor construction. Decompression is deterministic and the binary is self-contained — there is no online training loop and no per-customer state.

No. It is a pure compression library. You hand it bytes, it returns smaller bytes. No RPC, no validator, no network dependency.

It scales with the Zstd level behind the preset. FastCompression (level 3) is cheap enough for the hot path; MaxCompression (level 19) trades CPU for ratio and is meant for write-once archival data you compress a single time.

It is not a chain client, a node, or a lossy codec. It does no online dictionary training and ships no per-customer model. For non-Solana data it degrades to roughly vanilla Zstandard — the dictionary neither helps nor hurts.