In the U protocol proposal we plan to include a major upgrade to the Data-Availability Layer (DAL), raising its usable bandwidth from today’s ~0.66 MB/s to 10 MB/s.
This completes another milestone on the Tezos X roadmap and allows a new tier of data-intensive, high-throughput apps to be deployed on Etherlink and Tezlink without concerns about data publication becoming a bottleneck.
Note for bakers: Our tests involving sustained full utilization of the DAL (10 MB/s) have led to minor revisions of the hardware recommendations. For most bakers, existing infrastructure remains sufficient, but the largest bakers (>2% of the stake) should consider additional CPU cores for future-proofing their setup.
Why DAL bandwidth matters
- Unlocks higher L2 throughput: Before transaction data can be executed, it must be published securely and verifiably. At 10 MB/s, hundreds of thousands of transactions can be published on the Tezos network each second at a very low cost. While it doesn’t directly increase throughput (currently constrained by execution), it prevents network bandwidth becoming a bottleneck.
- Enables the next generation of Tezos applications: With abundant, affordable data publication, developers can build much more data-intensive dApps – such as games, high-frequency DeFi, and other demanding on-chain systems – on Tezos.
- Strengthens Tezos’ position: Offering 10 MB/s bandwidth with a fully decentralized and protocol-native data availability solution makes Tezos stand out in the broader market.
How the DAL reaches 10 MB/s
The increased bandwidth is made possible by a combination of software-level optimizations and protocol parameter updates, without weakening the security guarantees of the DAL.
On the software side, shard verification has been significantly optimized by batching cryptographic checks for shards belonging to the same publication and by parallelizing validation across multiple CPU cores. These changes allow DAL nodes to make efficient use of multi-core hardware, drastically increasing the amount of data that can be verified per block.
On the protocol side, DAL constants are updated — in particular the number of slots and the size of each slot — to expose this additional capacity to the network. Importantly, the security model remains unchanged: the same proportion of attestations is required for a slot to be accepted by the protocol, baker rewards are still tied to the same attestation thresholds, and the redundancy factor is unchanged, meaning that the amount of data needed to reconstruct a slot remains the same as today.
As a result, DAL bandwidth increases by 15x (from today’s level to 10 MB/s), while preserving the trust assumptions and economic incentives that bakers and rollups rely on.
Impact on hardware recommendations
The above changes involve slightly revised hardware recommendations for bakers.
These hardware recommendations are based on worst-case measurements: a single machine running a baker, an L1 node, and a DAL node, with the DAL operating at sustained peak capacity throughout the experiments. This intentionally conservative setup provides clear safety margins.
In practice, bakers with less than ~2% stake can continue using their current setups.
Meanwhile, bakers in the 5–10% stake range are encouraged to move toward 8-core or 16-core desktop-class or server-grade CPUs. While moderate DAL usage can be handled by today’s setups, the decentralized nature of the network makes future load peaks inherently unpredictable. Aligning with the updated recommendations allows bakers to avoid reactive upgrades and reduces the risk of temporary reward loss if usage increases suddenly.
The updated hardware recommendations for bakers participating in the DAL are the following:
| Up to 1% of the stake | 2% of the stake | 5% of the stake | 10% of the stake | |
|---|---|---|---|---|
| Cores | 4 cores | 4 cores | 8 cores | 16 cores |
| CPU perf. tier (*) | low-end | mid-range | high-end | high-end |
| RAM | 16 GB | 16 GB | 16 GB | 16 GB |
| Bandwidth (upload) | 250 KB/s | 250 KB/s | 250 KB/s | 250 KB/s |
| Bandwidth (download) | 1 MB/s | 2 MB/s | 5 MB/s | 10 MB/s |
(*): Low-end covers low-power or entry-level CPUs, mid-range targets modern desktop and entry-level server CPUs with mid-range clock speed, and high-end addresses recent high-performance CPUs with high clock speed.
For bakers with less than 1% of the stake – which is about 90% of individual baker operations – the only difference from the general baking hardware recommendations is the utilization of four cores. This is already part of most low-spec setups such as Raspberry Pi. Bakers with around 2% of the stake would need slightly higher CPU performance for extreme scenarios.
Operating hardware below these specifications may result in degraded DAL participation in case of peak DAL load. In practice, this means:
- partial failure to attest DAL slots,
- the loss of the corresponding DAL-related rewards for the affected cycles.
This upgrade introduces no new slashing conditions, and does not affect baker safety beyond the existing reward mechanics.
Bottom line
The DAL improvements described here intentionally balance ambition and practicality: it brings Tezos into the multi-MB/s era while preserving decentralization and keeping hardware requirements as low as possible.
When builders come looking for affordable data availability at scale, Tezos will be ready — and bakers will benefit from the increased utility, activity, and long-term strength of the ecosystem.
