Data availability
A rollup's real safety property is not the state root — it is that everyone can get the data behind it. ZUL publishes its full transaction data to Solana itself, the cheapest way to make the chain's history as public as the chain it settles to.
Mechanism
block txs (non-empty slots in the batch range)
→ serialize
→ zstd compress
→ chunk to fit Solana transaction size
→ submit as instruction data to the da_log program
→ da_hash over the whole payload, stored in the
settlement record- The da_log program is a noop: it deliberately does nothing with the bytes. Its only job is to get data into the Solana ledger, signed and timestamped.
- The da_hash in the settlement record binds the batch — a root whose data was withheld or altered fails the hash check.
- Empty slots are skipped; only blocks with transactions are batched.
Reconstruction
To rebuild the chain from L1 alone: walk the da_log program's transactions in order, concatenate and decompress the chunks, re-execute through the SVM from genesis, and compare your computed SMT roots against the settled records. Disagreement means the sequencer posted an invalid root — the basis of the stage-0 procedural challenge in Trust model.
Solana RPC providers prune old ledger history; very old DA chunks may not be fetchable from a random public RPC. v1 accepts this — the node itself also serves batch data over RPC, and archival is a post-v1 item. The settlement records (roots + hashes) are account state and remain queryable regardless.
Why not an external DA layer
Posting to the settlement chain itself keeps the trust surface at exactly one system — Solana — instead of adding a second network with its own validators and liveness story. At ZUL's scale, zstd-compressed batches in ledger space are cheap enough that the simplicity wins.