# Avail Markdown version of https://l2beat.com/data-availability/projects/avail/no-bridge ## Summary - Type: Public Blockchain - Total Value Secured: $7.08 M (Total value secured (TVS) is the sum of the total value secured across all L2s & L3s that use this DA layer and are listed on L2BEAT. It does not include the TVS of sovereign rollups.) - Economic security: $0.00 (The assets that are slashable in case of a data withholding attack. For public blockchains, it is equal to 2/3 of the total validating stake.) - Secured by: 70 validators - Duration of storage: — - Max throughput: 0.2 MiB/s - DA Bridge: No DA Bridge - Used by: Sophon, Lens - Other DA bridge: [Vector](https://l2beat.com/data-availability/projects/avail/vector.md) (TVS $7.08 M; used by Sophon, Lens; risks: Committee security: Validator set (sentiment: good), Upgradeability: No delay (sentiment: bad), Relayer failure: No mechanism (sentiment: bad)) ### Risks - Economic security (DA layer Avail): Staked assets (sentiment: bad) - Fraud detection (DA layer Avail): DAS (sentiment: warning) - DA Bridge: No bridge (sentiment: neutral) ### Links - Website: https://www.availproject.org/ - Bridge: https://bridge.availproject.org/ - Docs: https://docs.availproject.org/, https://docs.succinct.xyz/ - Explorer: https://explorer.avail.so/#/explorer, https://avail.subscan.io/ - Repository: https://github.com/availproject/, https://github.com/succinctlabs/sp1-vector - Social: https://x.com/AvailProject, https://t.me/AvailCommunity, https://discord.com/invite/AvailProject, https://www.linkedin.com/company/availproject/ ## Throughput **Warning:** No throughput data since 2026 October 07, 08:00 UTC. The chart shows the actual size of data posted to the DA Layer per day for the selected time period, as well as the maximum possible throughput per day. The interactive throughput chart and its past day stats are shown on [the HTML page](https://l2beat.com/data-availability/projects/avail/no-bridge#throughput). ## Milestones & Incidents - 2025-02-18: [Block size increase](https://avail.subscan.io/tech/27). Avail doubles the block size to 4 MB. - 2024-07-23: [Mainnet Launch](https://blog.availproject.org/avail-da-mainnet-is-live/). Avail mainnet and the AVAIL token launch. ## Risk summary ### Avail risks #### Funds can be lost if 1. a dishonest supermajority of Avail validators finalizes an unavailable block, and there aren't light nodes on the network verifying data availability, or they fail at social signaling unavailable data, 2. a dishonest supermajority of Avail validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block. ## Avail Avail is a public blockchain and data availability network combining erasure coding, KZG polynomial commitments, and data availability sampling. ### Risk analysis #### Economic security Staked assets (sentiment: bad) There are staked assets on the DA layer that can be slashed in case of a data withholding attack. A dishonest supermajority of validators must collude to finalize a block with missing or invalid data. The invalid block would be added to the chain but rejected by honest full nodes. #### Fraud detection DAS (sentiment: warning) The DA layer uses data availability sampling (DAS) to protect against data withholding attacks. However, the block reconstruction protocol, which enables the minimum number of light nodes to collectively reconstruct the block, is still under development. ### Technology #### Architecture ![Avail architecture](https://l2beat.com/images/da-layer-technology/avail/architecture.png#center) #### Consensus Avail implements a Nominated Proof-of-Stake (NPoS) Sybil resistance mechanism, combined with the BABE/GRANDPA consensus protocol. BABE handles block production by assigning block production slots according to validators' stake and using a Verifiable Random Function (VRF). At the start of each epoch, nodes run the Block-Production-Lottery algorithm to assign block production slots and share the results with other nodes. Slots are randomly assigned, meaning multiple validators might be selected for the same slot (with a 'race' determining who gets to propose the block) and some slots may remain empty. To ensure liveness, secondary block producers are pre-determined and can step in if necessary, preventing any slot from being skipped. Finality is achieved through GRANDPA, a GHOST-based finality gadget that provides finality through consecutive rounds of validators voting. #### Blobs Data submitted to the Avail blockchain through submitData transactions is organized into a data matrix, with each block data divided into equal-sized cells. This matrix is erasure coded using Reed-Solomon (RS) codes and committed using Kate-Zaverucha-Goldberg (KZG) polynomial commitments. Each block header on Avail includes two types of attestations: KZG polynomial commitments of the submitted data and the root of a Merkle tree, where the leaves represent the data blobs. #### Data Availability Sampling (DAS) Avail ensures data availability through a data availability sampling (DAS) mechanism, which involves both Light clients and App clients. Light clients sample the data matrix by requesting data cells, and for each cell they then check the KZG polynomial openings against the commitments in the block header. Light clients first attempt to fetch cells using a Kademlia-based Distributed Hash Table (DHT) within a light clients peer-to-peer (P2P) network. If the randomly selected cells are not available via DHT, the light client resorts to RPC calls to the Avail node(s) to obtain the data. Cells retrieved this way are then shared back into the DHT network, enhancing the overall availability of block data. After gathering the data, the light client verifies the cells and calculates a confidence level, which is stored locally for reference. App clients focus on data specific to a given application ID. They reconstruct entire rows of the data matrix by requesting and assembling any missing cells from the network. #### Erasure Coding Proof Avail uses Kate-Zaverucha-Goldberg (KZG) polynomial commitments as validity proofs of erasure-coded data. Light clients verify the commitments by checking the KZG polynomial openings against the commitments in the block header. #### L2s Data Availability L2s can post application-specific data blobs to the Avail blockchain through submitData transactions. Each transaction contains an application ID that identifies the L2 and adheres to a size limit based on the Avail blockchain’s block size. App-specific data can be reconstructed by app clients, which request and assemble missing cells from the network to complete the data reconstruction process. **Risks** - Funds can be lost if a dishonest supermajority of Avail validators finalizes an unavailable block, and there aren't light nodes on the network verifying data availability, or they fail at social signaling unavailable data. - Funds can be lost if a dishonest supermajority of Avail validators finalizes an unavailable block, and the light nodes on the network cannot collectively reconstruct the block. **References** - [Avail Documentation](https://docs.availproject.org/docs/welcome-to-avail-docs) - [Avail Light Client - Source Code](https://github.com/availproject/avail-light/blob/main/core/src/light_client.rs) - [Avail App Client - Source Code](https://github.com/availproject/avail-light/blob/a9e1741a6c7579d6ab1988eb409808b33f999180/core/src/app_client.rs) ## No DA Bridge The risk profile in this page refers to L2s that do not integrate with a data availability bridge. Projects not integrating with a functional DA bridge rely only on the data availability attestation of the sequencer. ### Risk analysis #### DA Bridge No bridge (sentiment: neutral) Without a DA Bridge, Ethereum has no proof of data availability for this project. ### Technology No DA bridge is selected. Without a DA bridge, Ethereum has no proof of data availability for this project.