Input Output Researcher Outlines Cardano Data Availability Needs

Input Output researcher Giorgos Panagiotakos has submitted a document describing the need for a dedicated data availability capability on Cardano’s base layer.

The proposed Layer 1 Data Availability problem statement examines how projects could publish information that others can retrieve and verify without necessarily making it part of the ledger’s permanent transaction history. It draws on requirements discussed at an IO Research technical workshop on September 3.

Why Cardano Projects Need Access to Published Data

Some blockchain applications need information to remain available only long enough for participants to verify an action or respond to a problem. Others need records to be accessible long after they were created.

For certain Layer 2 protocols, participants may need published state information to reconstruct their positions and withdraw funds if the protocol stalls or an operator goes offline. Optimistic rollups need transaction data to remain accessible long enough for a participant to construct a fraud proof when challenging an asserted state.

The document also lists large zero-knowledge proofs, governance ballots, audit records and applications that group many small operations into batches. Their retention requirements differ: some information may be needed for hours, other data for days, and records used for later audits potentially for years.

Panagiotakos describes several existing options. Projects can publish data directly to the Cardano ledger, rely on an external system such as Celestia, or use a trusted operator. According to the document, posting large volumes to the ledger can be too costly for some applications, while an external service introduces separate security and availability assumptions.

The CPS also discusses IPFS, which identifies content using information derived from the data itself. That approach lets a recipient check retrieved content, but it does not guarantee that another participant will continue storing and serving it.

What a Cardano Data Availability Layer Would Need

The problem statement sets out five goals for a potential solution. Its availability guarantees should rely on Cardano’s existing security assumptions rather than an independently trusted storage operator or a separate external validator set.

Published information should also be retrievable for a defined period. A proposed solution would need to specify when publication is accepted, when retention begins and ends, and the assumptions under which participants can obtain the data.

The third goal is data integrity: anyone retrieving the information should be able to verify its correctness. The fourth is support for membership and non-membership proofs, which would allow Plutus smart contracts to check whether particular data belongs to a published set.

The final goal covers cost and performance. The CPS calls for a substantially lower cost per byte than publishing equivalent data directly to the base layer, higher throughput and publication latency comparable to Layer 1. It asks future proposals to state figures against which those requirements can be measured.

The document illustrates the range of needs through individual projects. It lists a retention period of one hour to five days for Gummiworm, while Midgard, an optimistic rollup, is described as needing seven-day storage and support for membership and non-membership proofs.

For governance applications, the CPS points to previous Project Catalyst voting rounds when discussing a potential capacity of 100,000 to one million votes. It also notes that some post-quantum zero-knowledge proofs can exceed 100 kilobytes, increasing the amount of data that applications may need to publish.

Permanent archival storage and confidentiality are outside the proposed scope. For governance records that need to remain available for audits years later, the document identifies a separate archival mechanism as necessary.

[NEWSBREAK]

Costs, Timing and Open Technical Questions

Panagiotakos has not selected an architecture or announced a completed network upgrade. The CPS asks which proof system could support the required throughput and how Plutus scripts would reference it.

It also leaves open who should pay for retaining data: the publisher, the party retrieving it or the protocol. Any pricing model would need to account for both occasional small publications and applications generating sustained high-volume traffic.

For stake pool operators, the document asks how a solution would affect hardware requirements and operating costs, and what incentives would encourage participation. It also calls for a first phase that is simple enough to deliver a useful capability for at least one of the identified applications.

The problem statement includes a timing constraint. According to the document, a solution more than roughly eight months away could arrive too late for some projects planning to launch within the year. A later alternative would need a significant throughput improvement or another clear advantage to replace infrastructure a project had already integrated.

Post-quantum security is listed as desirable rather than mandatory. The proposed CPS remains open in the Cardano Improvement Proposals repository and has not yet been assigned a number.