Layer 1 blockchain
Avail ticker AVAIL
Summary
Avail DA mainnet launched on 2024-07-23. Its node is built with Substrate: AVAIL holders nominate validators under nominated proof of stake, and each 24-hour era an election picks the active set. BABE assigns 20-second block slots by a private lottery, with secondary slots so none go empty, and GRANDPA validators vote to finalize chains of blocks. Chains submit data in submitData transactions tagged with an App ID. Each block's data is laid out as a matrix; every row is extended with Reed-Solomon erasure coding and committed with a KZG polynomial commitment, and the header carries these commitments and a Merkle root of the data. Validators attest that data is correctly packaged but do not execute it. Light clients sample random cells and check them against the header's commitments. 112161920242534
Design
- System
- Layer 1 blockchainAvail DA has its own nominated proof-of-stake validator set, produces and finalizes its own blocks, and does not settle to another chain, so it is classed as a layer 1. Its job is specific: it orders data that rollups and other chains submit, commits to it in block headers and keeps it available for sampling, without executing it. Its runtime handles balances, staking, proxies, multisig, identity and the Vector bridge, with no general smart contracts. Avail Nexus, a separate cross-chain product, is not part of this chain's consensus. The package hint was kept.
- Settlement family
- Its own design
- Scarce resource
- Stake (proof of stake)
- State model
- Accounts
- Finality
- Economic finality
- Who makes blocks
- Elected validators hold BABE slots: a lottery assigns primary slots and secondary slots fill the rest. Nominators can back up to 16 validators, and the Avail Foundation also nominates validators it picks through a KYC-gated program run by an internal committee. The active set size is a governance parameter: after a mainnet halt on 31 August 2026 the Technical Committee cut it to 10 and then 15, and a read on 2026-09-29 returned 70. Offences such as equivocation are slashable; slashes are deferred for 27 eras and can be cancelled by the committee, as it did for the outage eras.
- Fork choice
- Before finality, BABE builds on the fork after the last finalized block with the most primary (lottery-won) blocks, so short forks can occur and resolve. GRANDPA validators then vote to finalize chains of blocks; AIP 7 and node release v2.3.4.0 set finality one block behind the best block, about 20 seconds. AIP 7's proposed rise in primary slots from one in four to one in three was not in force: the chain's BABE configuration read one in four on 2026-09-29. Light-client sampling checks separately whether a finalized header's data is available.
Qualifications
- Execution · Not applicable. Avail DA has no general execution layer: validators do not execute submitted data, and rollups and other chains that post to it run their own execution and settlement.
- Tps · Not applicable. Transactions per second is a poor fit for a data availability chain; its capacity is a data size per block set by governance. The figures are kept only as classified claims, which are not comparable across chains.
- Settlement family · Partial. Recorded as other. Avail's own terms: a Substrate-based chain, Avail DA, secured by nominated proof of stake with BABE block production and GRANDPA finality, whose runtime adds data availability (App IDs, KZG commitments and a data root in each header) and the Vector bridge module.
- Upgrade authority · Partial. Changes are proposed as AIPs (on Avail's forum until its announced closure in August 2026, now in a GitHub repository), but no token vote exists: a seven-member Technical Committee drawn from Avail's team dispatches upgrades and parameter changes with five of seven signatures through the Mandate module. Standard proposals wait three days; the emergency path skips that and reports afterwards, as in the August 2026 outage recovery. The Mandate module also accepts root authority. The members read on chain on 2026-09-29 match Avail's list after its March 2026 change.
- Sudo key · Applies. The runtime includes a sudo module whose key can dispatch calls with root authority; root can also pause chosen calls through the transaction-pause module. A storage read through Avail's public RPC on 2026-09-29 returned a set key for an account that Avail's governance docs do not name, that is not one of the seven Technical Committee members read on chain, and that Avail's published mainnet chain specification sets as the sudo key at genesis. Who controls it and whether it has been used were not verified.
- Validator set size · Partial. The active set grew from 40 to 50 validators at launch to 105 in March 2025 (Transparency Report 15), and AIP 9 (May 2026) proposed 80. During recovery from the 31 August 2026 outage the Technical Committee cut the set to 10, made some validators invulnerable, then raised it to 15, and said further proposals would restore the earlier size (Transparency Report 21). A read on 2026-09-29 returned 70 with no invulnerable validators set, as L2BEAT also shows; the steps from 15 to 70 were not found. The Avail Foundation nominates validators it selects, so part of the stake is foundation-directed.
- Data retention · Unknown. Avail's docs describe checking that data was published, and Avail's blog says data availability is not data storage; how long nodes keep old block data is not documented, so long-term retrieval may depend on archive operators or the posting chain.
- Avail nexus · Partial. Avail Nexus, live since December 2025, moves assets between other chains through intents: users lock funds in vault contracts, solvers (run by Avail today) deliver on the destination chain, and Nexus validators sign settlements with threshold signatures. Avail says Nexus became a sovereign rollup on Avail DA in August 2026. None of this changes Avail DA's own consensus or how it publishes data, and this profile describes Avail DA alone.
- Avail fusion · Not applicable. Avail Fusion, a multi-asset staking layer Avail has described for restaking ETH, ERC-20 tokens and BTC to add security, was still described as coming soon in July 2025, and no live deployment was found. This profile describes the chain without it.
- Turbo da · Partial. TurboDA is an Avail-run service in private beta that gives a fast pre-confirmation and posts the data to Avail DA later; until it is posted and finalized, users rely on the operator, not on the chain.
Tradeoffs
- Emphasizes
- Scalability and Security
- Gives up
- Execution and open control. Avail DA runs no general smart contracts, so applications execute elsewhere. Runtime upgrades and parameter changes are signed by a seven-member Technical Committee drawn from Avail's own team, five of seven being enough, and a chain read on 2026-09-29 found a sudo key set for an account outside that committee, the one Avail's chain specification sets at genesis. The active validator set is a governance parameter (cut to 10 during the August 2026 outage recovery, 70 at review), and part of validator stake comes from Avail Foundation nominations.The security emphasis rests on light clients checking availability by sampling cells against KZG commitments instead of trusting a validator majority; it assumes enough light clients sample and share cells, and L2BEAT reports that block reconstruction by light nodes is still under development. The scalability emphasis refers to data capacity per block, not executed transactions.
- Full node at home
- Practical at home 56734Avail's node page lists 8 GB RAM (16 GB recommended), 4 CPU cores (8 recommended) and 20 to 40 GB of SSD (200 to 300 GB recommended), and says storage needs grow with the network; archive size is not stated and the figures may be dated. A light client needs 512 MB to 1 GB RAM and two to four cores, and an experimental light client runs in a browser. Validating needs bonded AVAIL (the docs say 50,000 AVAIL to join the waiting list, and the chain's minimum validator bond read 50,000 AVAIL on 2026-09-29) and an elected slot.
- Throughput claims
- Theoretical peak: 4 252631Theoretical peak; not comparable across chains or with observed load.Megabytes of data per block, the maximum block size set by governance, with a block about every 20 seconds; not transactions.Scheduled for block 989,865 by Transparency Report 14 (February 2025); L2BEAT's maximum throughput at review matches this size per 20-second block; the parameter was not re-read.A ceiling set by a governance parameter, not observed use; how full recent blocks were was not measured. AIP 7 raised the block size the node software can handle, but its authors say that does not change consensus rules, so it is not the on-chain limit. Erasure coding doubles each row, so the data validators and samplers handle is larger than the submitted data. A data size per block, not executed transactions; not comparable across chains.
- Lab benchmark: 128 21Controlled benchmark; not observed network behavior.Megabytes of data per block in Avail's own benchmarks; not transactions.Undated benchmarks described in Avail's July 2025 year-one post.The post gives no method, hardware, network size or duration for the benchmarks. A test result, not mainnet behaviour; the mainnet parameter was far lower at the time. Ignores downstream execution and storage on the chains that post data.
- Theoretical peak: 10 21Theoretical peak; not comparable across chains or with observed load.Gigabytes per block with a 600 ms block time: a stated long-term target, not a current parameter.Named as the ultimate destination in Avail's July 2025 year-one post.A stated goal: the cited post gives no date, method or test for it. The same post reports the mainnet block size at the time as a small fraction of this target. No measurement exists; not comparable with any observed rate.
Scaling layers
No scaling layer recorded in this profile.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; Avail DA has no smart contracts and its runtime module list has no swap or hash-time-locked module, but a module list does not show whether two parties can exchange assets in one transaction, which was not reviewed. Moving AVAIL over the Avail bridge is a transfer between chains, not a swap. 15 |
| Authenticated data publication | Built into the protocolLimited scope | Publishing data is Avail DA's core job, done by the protocol: a submitData transaction places data under an App ID, the block header commits to the whole block with KZG row commitments and a Merkle data root, applications fetch their App ID's data through a node or light client, and cells can be checked against the header. Limits: anyone can post under any App ID, so readers must filter by sender, and how long nodes keep block data is not documented. 12613 |
| Light clients | Built into the protocolLimited scope | Consensus puts KZG commitments in every header and GRANDPA produces finality justifications; Avail's light client follows finalized headers, samples random cells over its peer-to-peer network (falling back to node RPC) and checks each against the commitments, and an experimental version runs in a browser. Limits: by default it does not re-check finality from genesis and trusts the starting point of the node it connects to, it needs enough light clients sharing cells, and L2BEAT reports block reconstruction by light nodes is still under development. 161831 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | None found Earlier definition | No payment or state channel layer anchored to Avail DA was found, and without a general execution layer the chain cannot host dispute logic for one. 3 |
| Programmable spending | Partial (layer not stated) Earlier definition | Accounts can use built-in multisig, typed proxies (for example staking-only or non-transfer) and keyless pure proxies controlled by other accounts, but Avail DA has no general execution layer, so users cannot write their own spend conditions. 3815 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Built into the protocolLimited scope | Time-delayed proxies in the runtime's proxy module: an account adds a proxy with a delay, the proxy must announce a call that runs only after the delay, and the account can reject it meanwhile, so a delayed transfer can be cancelled. Mainnet runtime metadata read on 2026-09-29 lists the calls to announce, reject an announcement and run an announced call. Limits: part (a) only, set up in advance; Avail's guides do not describe delayed proxies; there is no recovery module, and a completed transfer cannot be reversed. 8151733 |
| Rollups | Partial (layer not stated) Earlier definition | Rollups and validiums post their transaction data to Avail DA through integrations the docs list for OP Stack, Arbitrum Nitro, Polygon CDK, ZKsync and Madara chains, and L2BEAT lists Sophon and Lens as users. Avail orders and keeps that data available but does not execute it; those chains execute and settle elsewhere. Avail also describes Avail Nexus as a sovereign rollup on Avail DA since August 2026. 3142231 |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under this row's current definition; Avail DA has no smart contracts or order module, and no maker-signed offer format was found. |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | None found | Avail DA cannot host an automated market maker: it has no general execution layer and no exchange module. Venues on other chains that handle AVAIL are not Avail DA products and were not reviewed. 3 |
| Issuer-native stablecoins | None found | Circle's USDC address list and Tether's supported-protocol list do not include Avail, and Avail DA has no contract platform for an issuer token. Nexus moves USDC and USDT between other chains, not on Avail DA. 33940 |
| Algorithmic stablecoins | None found | No algorithmic stablecoin can run on Avail DA because it has no general execution layer. 3 |
| Bridges | First-partyAvail Bridge: Vector (Avail DA and Ethereum), Avail Bridge route between Avail DA and Base | Avail's Vector bridge combines a runtime module with Ethereum contracts: Avail data roots are proved to an Ethereum contract with SP1 zero-knowledge proofs, Ethereum headers reach Avail through SP1 Helios proofs, and users claim bridged AVAIL by hand, usually after one to two hours. The same bridge site runs an Avail to Base route that Avail called a beta with lower limits. Nexus moves assets between other chains and does not carry AVAIL to Avail DA. Risk: L2BEAT reports that a 4-of-7 Avail multisig can upgrade the Vector contract on Ethereum with no delay, upgrade the token bridge contract after a one-day timelock, freeze Vector and change its relayers, that a 3-of-5 multisig can pause the bridge, and that relayers are permissioned, so the bridge halts if they fail. Avail's reports record faults: in March 2025 bridge sends made through multisig or proxy calls were left out of the bridge root and funds were lost, and a May 2026 emergency upgrade rejected wrapped bridge sends. The Base route's trust model is not documented. 11132327282932 |
| Block explorers | Established in the ecosystemSubscan, Avail Apps explorer, Cumulo Avail explorer | Avail's networks page lists Subscan, a third-party explorer, and the Avail Apps explorer, which Avail runs and which is forked from Polkadot JS Apps; Cumulo, which runs Avail infrastructure services, announced its own mainnet explorer on Avail's forum in July 2026. Listing is not a quality check, and explorer data is provider-indexed. 3430 |
| Hardware wallets | ThinLedger (Avail device app through Avail Apps explorer, SubWallet or Talisman) | See custody rows: Avail documents a Ledger device app used through its own explorer or third-party extension wallets, while Ledger's published currency list has no Avail entry; Trezor's Avail page lists AVAIL only as a token on Base, Ethereum and BNB Smart Chain, and its firmware has no Avail signing. 9353638 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Through an intermediaryAvail Apps explorer, SubWallet or Talisman, signing with the Avail Ledger device app (by Zondax) installed through Ledger LiveSame as native: Unknown | Can: Install the Avail app on a Ledger device from Ledger Live's app catalog and sign Avail DA transfers through the Avail Apps explorer, per Avail's Ledger guide Can: Attach the Ledger account to SubWallet or Talisman and sign there, per the same guide Can: Reach funds sent to addresses derived with the Polkadot Ledger app through the Avail Recovery app, offered in Ledger Live's developer mode Cannot: Find AVAIL in Ledger's published Ledger Wallet currency list (@ledgerhq/cryptoassets 13.56.0) Cannot: Use the Polkadot Ledger app to sign Avail DA transactions, per Avail's recovery guideAvail's guides treat Ledger Live only as the place to install device apps; balances and signing live in the explorer or extension wallet. Ledger's coin page tried for Avail returned not found. The Avail app derives different addresses from the Polkadot Ledger app for the same seed, which is why the recovery app exists. 9103637 |
| Trezor | None foundSame as native: No | Cannot: Sign Avail DA transactions or control an Avail DA account: Trezor's Avail page lists only Base, Ethereum and BNB Smart Chain as networks, and Trezor's firmware support data has no Avail entry Cannot: Treat AVAIL held as a token on those networks as custody on Avail DATrezor supports AVAIL only as a token copy on Base, Ethereum and BNB Smart Chain, which a Trezor can hold through Trezor Suite, MetaMask or Rabby; under the shared custody rule a token copy on another network does not count as custody on Avail DA. Assets held on Avail DA itself need a different signer; third-party routes were not checked. 3538 |
Public data
iKnow Blockchain has no public-data lookups for Avail yet. This is a limit of the service, not a statement about the network.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Not available yet | Public-data lookups for this chain are not built yet. |
| Tokens and assets | Not available yet | Public-data lookups for this chain are not built yet. |
| NFTs | Not available yet | Public-data lookups for this chain are not built yet. |
| Transactions | Not available yet | Public-data lookups for this chain are not built yet. |
Sourced developments
Developments: Reviewed Sep 29, 2026 Next review due Oct 9, 2026, 12:00 UTC.
Publication date · newest first
-
Mainnet halt after a faulty emergency runtime upgrade, and the Technical Committee's recovery
Avail's incident report says that on 31 August 2026 an emergency runtime upgrade for a privately reported vulnerability, applied at block 3,403,608, broke production of the next epoch-transition block. Block production stopped for about three hours and 45 minutes until validators ran an earlier runtime through an override (release 2.3.6.0-hotfix). Slashing during the halt changed the validator set and stalled finality until 04:58 UTC on 1 September. Transparency Report 21 lists the emergency proposals: slashes cancelled, the set cut to 10 and then 15, and the earlier runtime and then a corrected one applied on chain.
- Proposal:emergency Technical Committee proposals, starting with proposal 44
- Implementation:runtime override for validators; earlier runtime v55, then corrected runtime v56, applied on chain; code substitute in node v2.4.0.0
- Release:hotfix published 2026-08-31, node v2.4.0.0 on 2026-09-02, reports on 2026-09-03
- Activation:block production and finality restored by 1 September 2026; validator set still being rebuilt at the time of the reports
Sources: Avail Project (GitHub governance repository) — Avail DA Mainnet Incident Report (Mainnet Liveness and Finality Incident) (external site) · Avail Project (GitHub governance repository) — Transparency Report 21: Technical Committee Actions During Mainnet Recovery (external site) · Avail Project (GitHub) — Avail Validator Hotfix 2.3.6.0-hotfix (external site) · Avail Project (GitHub) — Avail node v2.4.0.0 release notes (external site) · Avail Project (GitHub) — Avail DA mainnet chain specification (raw) (external site)
-
AIP 9 proposes shrinking the active validator set to 80
AIP 9 proposed cutting the active validator set from about 105 to 80 by changing the validatorCount staking parameter, to strengthen validator incentives; it says the change is not a runtime upgrade and does not change consensus, slashing or emissions. No transparency report records it being applied. The set was later cut to 10 during the August 2026 outage recovery and then raised in steps; a read of the parameter on 2026-09-29 returned 70.
- Proposal:AIP posted on the forum 2026-05-25
- Implementation:parameter change only; no code needed
- Release:no transparency report for 80 found
- Activation:not confirmed; the set was cut to 10 and then 15 in the outage recovery, and on-chain validatorCount read 70 on 2026-09-29
Sources: Avail Forum — AIP 9: Reduce Mainnet Active Validator Set to 80 (external site) · Avail Project (GitHub governance repository) — Transparency Report 21: Technical Committee Actions During Mainnet Recovery (external site) · OnFinality (Avail-listed public endpoint) — Avail mainnet RPC (OnFinality public endpoint): Staking.ValidatorCount storage read and runtime metadata read (external site) · L2BEAT — Avail data availability (no bridge) (external site)
-
Emergency runtime upgrade rejects wrapped bridge sends
The Technical Committee used its emergency path to apply a runtime upgrade that rejects Avail-to-Ethereum bridge sends wrapped inside proxy, multisig, scheduler or batch calls, after finding that such wrappers could produce bridge data for a send that did not execute or leave funds stuck. Direct bridge sends keep working. A related fault in March 2025 had caused losses for bridge sends made through multisig or proxy calls.
- Implementation:runtime upgrade changing bridge transaction validation
- Release:executed through the emergency proposal path
- Activation:applied at block 2,920,735 per the report
Sources: Avail Forum — Transparency Report 20: Avail Bridge Wrapped Transaction Safety Fix (external site) · Avail Forum — Transparency Report 16: Critical Runtime Upgrade - Filtering VectorX Bridge transactions (external site) · Avail Docs — Bridge AVAIL between Avail DA and Ethereum (external site) · Avail Docs — Governance on Avail (external site)
-
Ideal staking ratio lowered from 75% to 50% by runtime upgrade
After AIP 8 was posted on 15 December 2025, the Technical Committee approved, by four of seven signers, a runtime upgrade lowering the ideal_stake parameter of the staking reward curve from 75% to 50%, scheduled for block 2,329,375. The same AIP raised the commission the Avail Foundation accepts for its nominations from 15% to 20%, a policy change rather than a protocol one.
- Proposal:AIP 8 posted on the forum 2025-12-15
- Implementation:in node release v2.3.4.2; the runtime reward curve now reads 50%
- Release:runtime upgrade approved by the Technical Committee
- Activation:scheduled for block 2,329,375 per Transparency Report 19; the current runtime source keeps 50%
Sources: Avail Forum — AIP 8: Change Ideal Staking Ratio to 50% and Update to Foundation Delegation Commission Policy (external site) · Avail Forum — Transparency Report 19: Change ideal_stake to 50% (external site) · Avail Project (GitHub) — Avail node v2.3.4.2 release notes (external site) · Avail Project (GitHub) — runtime/src/constants.rs (main branch) (external site)
-
Avail Nexus launched on mainnet as an intent-based cross-chain service
Avail announced that Avail Nexus is live on mainnet. Nexus takes one signed request (an intent) from a user, collects funds in vault contracts on several source chains and has a solver deliver the result on a destination chain. It runs between other chains, not on Avail DA itself, and the launch post said unified verification backed by Avail DA was still coming.
- Implementation:live on mainnet per Avail
- Release:announced as live on 2025-12-09
- Activation:in use on supported chains; Avail DA consensus unchanged
Sources: Avail Blog — Avail Nexus Mainnet is Live: New Era for Web3 Apps (external site) · Avail Docs — What are Solvers? (Avail Nexus) (external site) · Avail Docs — How Intents are Processed (Avail Nexus) (external site)
Topics your AI can explain
Your AI can explain these topics for Avail through the connection, with sources.
Known gaps
What this profile's review did not establish:
- Who controls the sudo key that a storage read showed set on 2026-09-29, and whether it has been used since launch, was not verified; Avail's governance docs do not mention it, the account is not one of the seven committee members on chain, and it matches the sudo key in the genesis state of Avail's published mainnet chain specification.
- The active set parameter read 70 on 2026-09-29. Transparency Report 21 records the outage cut to 10 and the rise to 15, but the later increases to 70 were not found, and whether AIP 9's 80 was ever applied is unknown. How stake is spread across validators, and how much comes from Avail Foundation nominations, was not measured.
- Transparency Report 19 records four of seven Technical Committee signers, while the runtime's Mandate path needs five of seven. The committee is configured so that, when more than half of the members have voted yes, members who did not vote are counted as yes once the vote's five-day period ends, which can lift four approvals past five of seven; the on-chain record of that vote was not read.
- Node release v2.3.4.0 shipped AIP 7's one-block finality gap, but how far finality lags on mainnet was not measured, and Avail's TurboDA page still describes finality as two to three blocks. AIP 7's primary-slot change had not been applied at review.
- Avail's incident report and Transparency Report 21 say an emergency runtime upgrade for a privately reported vulnerability halted block production on 31 August 2026 and that the committee cancelled the resulting slashes; the vulnerability itself has not been described, and the report's promised change to the slashing logic was not checked.
- How long nodes keep block data, and who serves old data, is not documented.
- How many light clients sample on mainnet, and whether light clients can rebuild a withheld block today, was not verified; L2BEAT says reconstruction is under development.
- The trust model of the Avail to Base bridge route is not documented; Avail called it a beta with lower limits in April 2025.
- The Vector bridge's upgrade multisigs, timelock and relayers come from L2BEAT, a third party; Avail's networks page lists a timelock contract but does not describe these roles.
- Delayed proxies were assessed from the runtime code and mainnet metadata; whether transaction pausing is applied to any proxy call was not checked.
- Which rollups currently post data to Avail comes from L2BEAT and Avail's docs, not from each project.
- Nexus solvers are run by Avail today; the identity and number of Nexus validators that sign settlements were not verified.
- Avail's blog announced Avail Atomic in September 2026, a service that routes swap orders to outside trading venues; which chains it runs on was not reviewed, nothing reviewed places it on Avail DA, and it is not treated here as an Avail DA swap feature.
- Avail Fusion has no live deployment in reviewed sources; its design and timing are not published.
- Avail's full-node storage figures may be dated, and archive size is not stated.
- The light client API listed in Avail's reference data returned an error when checked on 2026-09-29.
- Trezor lists AVAIL only as a token on other networks; whether any third-party wallet signs Avail DA transactions with a Trezor was not checked.
Sources
Oldest dated source check: Source checked Sep 29, 2026 Next check due Oct 29, 2026.
- How Avail DA Works (external site)
- What are App IDs? (external site)
- Glossary (external site)
- Networks and endpoints (external site)
- Run a full node: system requirements (external site)
- Run a light client: overview (external site)
- Stake your validator (external site)
- Proxies on Avail (external site)
- Use a Ledger with Avail DA (external site)
- Avail funds recovery (Avail Recovery Ledger app) (external site)
- Bridge AVAIL between Avail DA and Ethereum (external site)
- Transparency Report 21: Technical Committee Actions During Mainnet Recovery (published 2026-09-03) (external site)
- VectorX: data attestation bridge (external site)
- Deploy a rollup on Avail DA (external site)
- runtime/src/lib.rs (main branch): runtime module list (external site)
- runtime/src/constants.rs (main branch): block time, epochs, staking and reward curve (external site)
- runtime/src/impls.rs (main branch): sudo, Mandate, proxy and fee configuration (external site)
- Avail light client README (modes and finality sync) (external site)
- Proof of Stake Consensus: BABE, GRANDPA and fork choice (the protocol description Avail's glossary points to) (external site)
- Avail DA Mainnet Is Live (2024-07-23) (external site)
- Breaking Modular Myths: What Avail Proved in Year One (2025-07-23) (external site)
- Make Your App Liquid. Nexus Rising Is Live. (2026-08-23) (external site)
- Instantly Bridge AVAIL Tokens Between Base & Avail Network (2025-04-22) (external site)
- AIP 4: Mainnet Nomination Program (external site)
- AIP 7: Network Parameter Updates for Faster Finality, Larger Blocks, and Improved Authoring Resilience (external site)
- Avail Transparency Report 14: Increased Block Size to 4MB & Max DA tx size to 1MB (external site)
- Transparency Report 16: Critical Runtime Upgrade - Filtering VectorX Bridge transactions (external site)
- Transparency report 17: Runtime Upgrade - Bridge changes (external site)
- Transparency Report 20: Avail Bridge Wrapped Transaction Safety Fix (external site)
- Introducing the Avail Mainnet Explorer by Cumulo (external site)
- Avail data availability (no bridge) (external site)
- Avail data availability: Vector DA bridge (external site)
- Avail mainnet RPC (OnFinality public endpoint): Staking.ValidatorCount storage read and runtime metadata read, 2026-09-29 (external site)
- Avail mainnet RPC: storage reads of Sudo.Key, Staking.ValidatorCount, Staking.MinValidatorBond, Staking.Invulnerables, Technical Committee members and BABE epoch configuration, 2026-09-29 (external site)
- Trezor firmware coin support data (common/defs/support.json, main branch) (external site)
- @ledgerhq/cryptoassets 13.56.0 currency list (external site)
- ledger-avail: Avail app for Ledger devices (external site)
- Avail wallet (external site)
- USDC contract addresses (external site)
- Supported protocols (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding