> For the complete documentation index, see [llms.txt](https://docs.lumia.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lumia.org/ecosystem/lumia/architecture/data-availability/how-data-availability-sampling-scales.md).

# How data availability sampling scales

**Who this is for:** developers who want the mechanism behind Avail's throughput, not just that it exists. **You should already know:** [Where Lumia's transaction data lives](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/data-availability/where-lumia-transaction-data-lives).

### The scaling problem this solves

A naive data-availability guarantee ("every node downloads and stores everything") doesn't scale: throughput is capped by the weakest node's bandwidth and storage. Avail's scaling approach is built to let data volume grow without every participant needing to handle the full load.

### Data availability sampling

The core mechanism is **data availability sampling (DAS)**. Data submitted to Avail is erasure-coded, split and redundantly encoded so that the original data can be reconstructed from any sufficiently large subset of the pieces, not all of them, and committed to using polynomial commitments (KZG commitments). A light client then samples a small number of random pieces of that encoded data rather than downloading it in full. If enough independent samples come back successfully, the client can be statistically confident the full data is available, without ever holding all of it itself. As more light clients sample, the guarantee gets stronger, not weaker. That's the opposite of a model that gets more centralized as it scales.

This decouples data-availability throughput from any single node's capacity: because verification is sampling-based rather than full-download-based, Avail can support growing data volume by adding more light clients and validators sampling in parallel, rather than requiring every node to scale its own bandwidth and storage in lockstep with total throughput.

### Why it matters on Lumia

For a validium (see [Validium](https://app.gitbook.com/s/chmhPiVNAafGw48c4oU2/ecosystem/lumia/architecture/data-availability/validium)), the data-availability layer's own scalability directly caps how much transaction volume the validium can support without that layer becoming the bottleneck. A sampling-based DA layer is what lets a validium's data-availability guarantee scale roughly independently of its execution throughput, rather than the DA layer becoming the limiting factor as usage grows. This describes how Avail's mechanism works in general.