◆Data availability

The component that decides everything

If batch data is published, the whole security argument works. If it is withheld, none of it does — regardless of what the contracts say.

Data availability is the quietest component and the one that decides whether Solieum is a Layer 2 at all. If batch data is published, anyone can rebuild the chain and check the operator. If it is withheld, nobody can prove fraud, nobody can exit without permission, and the security argument collapses regardless of what the contracts say.

01Failure chain

Why withheld data breaks everything

  1. 01

    The operator publishes a state root but not the transactions behind it.

  2. 02

    Nobody can recompute the state, so nobody can show the root is wrong.

  3. 03

    The fraud proof system has nothing to prove against — it is present but inert.

  4. 04

    Users cannot construct a withdrawal proof, because they cannot prove their own balance.

  5. 05

    What is left is a system where you trust the operator. That may be acceptable, but it should be called what it is.

02Mechanism

How data gets published and checked

  • Compression

    In progress

    Batches are compressed before publication. Repeated account keys dominate raw transaction bytes, so the compression ratio directly sets the cost per transaction. First measured figures, from the codec in the protocol repository rather than an estimate: 53% of raw on modeled sustained traffic (4,000 transfers over 128 recurring accounts), and 79% on twelve recorded mainnet transactions that share almost no accounts — the low end, because compression here pays for repetition and unrelated transactions have little. A production codec should beat both.

  • Commitment

    In progress

    Published data is committed to so that any chunk can be proven to belong to the batch a state root refers to. Without that binding, an operator could publish one thing and settle another. Implemented in the data-availability program on devnet: a batch is opened with its commitment, chunks are posted, and sealing succeeds only if the published bytes fold to that commitment. An opened batch that cannot be sealed can be abandoned by its poster; a sealed one never can — history is not rewritable.

  • Sampling

    Planned

    Light clients check random chunks rather than downloading everything. Sampling only gives a real guarantee alongside erasure coding and enough independent samplers — the security bound will be published with the parameters, not asserted.

  • Retention

    Planned

    Data must remain available for longer than any withdrawal path. A withdrawal that becomes unprovable because data expired is a permanent loss of funds, not a degraded experience. Today: Solana's ledger holds the posting transactions and the node keeps its own append-only log of every published batch. An archive service with a stated retention period is the missing piece.

Where the data lives decides what this is

This is the single decision that determines Solieum's category, and it is worth stating plainly rather than in a footnote. Solieum's answer is on Solana, recorded as ADR-0001, and the devnet deployment does exactly that. The one pre-authorised exception is per-market validium, disclosed on the affected market's own page if it ever happens — never silently.

  • Rollup

    On Solana

    Data availability inherits Solana's guarantees. Costs the most, and is the only option where "secured by Solana" is accurate without qualification.

  • Validium / optimium

    External DA layer

    Cheaper and higher bandwidth, but the DA provider becomes a trust assumption of its own with its own failure mode. Legitimate — as long as it is disclosed on the front page rather than discovered.

  • Not a Layer 2

    Operator-held

    If only the operator has the data, users depend entirely on the operator. Included here for completeness, not as an option.

The cost calculation that bounds throughput

Data availability, not execution, is almost always what caps a rollup's real throughput. Solana has no separate blob market, so batch data competes in the same fee market as everything else. The arithmetic below is what any honest throughput figure has to start from.

bytes per transaction (compressed)
  × target transactions per second
  = data availability bandwidth required

bandwidth required × cost per byte at p99 L1 fees
  = cost per second to operate

… which sets both the floor on user fees
  and the ceiling on honest throughput.

Solieum will publish this derivation with real figures alongside its first benchmark, rather than a throughput number with no cost model behind it.

◆First measured figuresmeasured

Solana charges a base fee per posting transaction rather than a per-byte data fee, so compression pays by fitting a batch into fewer posting transactions. Running the protocol repository's codec over a modeled batch of 4,000 transfers across 128 recurring accounts: 416,000 raw bytes compress to 222,768 (53%), which at ~1,000 payload bytes per posting transaction is 416 posting transactions down to 223 — and at 5,000 lamports each, 522 down to 280 lamports of data-availability cost per Layer 2 transaction. These are measured outputs of code that ships in the repository, not projections, and they are a floor rather than a target: the codec is a plain general-purpose compressor with no dictionary priming or signature-aware encoding. On devnet, the first block's batch was 226 published bytes in one chunk — one posting transaction, visible on Solana.

How Solieum reports throughput →

03Explainer

Erasure coding, in plain language

The mechanism behind sampling guarantees, without the algebra.

  1. 01

    Split the batch data into k chunks. As published, you need all k to reconstruct — lose one, lose everything.

  2. 02

    Erasure-code them into n chunks (n > k), any k of which reconstruct the original. Now the data survives losing up to n−k chunks.

  3. 03

    This flips the withholder's problem: to hide anything, they must withhold more than n−k chunks — a large, visible fraction, not a quiet one.

  4. 04

    Samplers each fetch a few random chunks. Every successful fetch is evidence the data is there; a withholder now fails random spot-checks in proportion to what they hide.

  5. 05

    With enough independent samplers, the probability that large-scale withholding goes undetected drops toward zero — and that probability is the security bound worth publishing, with its assumptions.

Retention is a promise about the future

Publication answers "can anyone verify now?" Retention answers "can you still construct your withdrawal proof next year?" The rule is simple and strict: data must remain retrievable for longer than any path that could need it, with archive nodes as the backstop. Today Solana's ledger holds the posting transactions and the node keeps every published batch in its own append-only log, which it re-executes on restart; an archive service with a stated retention period is to be published before mainnet. If retention and the exit path ever disagree, that is not a storage-cost discussion — it is a fund-loss bug filed against the design.

Building something the base layer can't hold?

Tell us the workload. If Solieum is the wrong answer for it, we would rather say so early than have you find out at launch.

Get in touchRead the architecture