Skip to main content
Erasure coding is why files stored through Cascade on Lumera Protocol stay available even when many SuperNodes go offline. Understanding it explains Cascade’s durability guarantees and the layout IDs that appear in every upload.

​
Why erasure coding beats replication

Simple replication stores N full copies of a file. That is wasteful. If your data must survive half the nodes going offline, replication needs 2x the storage. Erasure coding reaches the same reliability with only about 1.5x overhead. Cascade uses RaptorQ, a fountain code standardized in RFC 6330. A fountain code generates a practically unlimited stream of encoded symbols from a source file. RaptorQ has three properties that matter for permanent storage.
  • It encodes a file into N symbols where any K symbols (K < N) reconstruct the original.
  • Its decoding failure probability is near zero.
  • It operates efficiently on large files.

​
Encoding during upload

RaptorQ Encoding Flow
  1. The SDK loads the file into the RaptorQ WASM module (rq-library-wasm).
  2. The encoder produces a layout that describes source blocks and encoding parameters.
  3. Encoded symbols are distributed across SuperNodes.
  4. Each SuperNode stores a subset of the symbols.
SuperNodes run the same encoding through rq-go, the official RaptorQ Go library.

​
Decoding during download

  1. The SN-API, the HTTP API served by SuperNodes, gathers available symbols from responsive SuperNodes.
  2. As long as at least K symbols are available, the original file is reconstructed.
  3. The BLAKE3 hash of the reconstructed file is verified against the on-chain record.

​
LEP-1 layout and ID derivation

LEP-1 (Lumera Enhancement Proposal 1) defines the deterministic algorithm that derives layout IDs from the encoding layout.

​
Layout generation

rq_ids_ic is a random counter seed. rq_ids_max sets how many layout IDs are derived. The layout JSON is compacted (no whitespace) before hashing so every implementation produces identical bytes.

​
ID derivation algorithm

Each layout ID is derived deterministically so the on-chain Go implementation can independently verify it.

​
Why determinism matters

  • Determinism. The same file, signer, and seed always produce the same layout IDs.
  • Verifiability. The chain can check that the claimed layout IDs match the submitted layout.
  • Uniqueness. Each symbol gets a globally unique identifier.

​
The LEP-1 index file

The index file aggregates the layout IDs and the layout signature.
The index file is itself signed with ADR-036, the Cosmos standard for signing arbitrary data, and included in the MsgRequestAction transaction.

​
Next steps

Upload lifecycle

Where layout generation and ID derivation fit in an upload.

Interchain accounts

Store to Cascade from any IBC-connected Cosmos chain.

JavaScript SDK reference

Full method reference for uploads, downloads, and task options.