What Is Programmable Data?

Programmable Data is Irys's planned capability for making stored data available directly to smart contracts during execution. A contract would be able to read and reference those bytes, then apply logic to them within the same network that stores the data.

Irys calls this category a programmable datachain, the next evolution of the datachain category that includes Arweave and Filecoin. Irys defines the programmable variant: a data-first base layer where storage, execution, and verifiability are designed together.

Status: Programmable Data is in development and is not live yet. This article explains the intended design. See current status for availability.

What makes programmable data programmable

Most blockchains can store small amounts of data and run smart contracts, but the two systems sit at arm's length. Onchain storage is expensive, so developers move data off-chain to IPFS, S3, or a separate decentralized storage network and feed it back through an oracle or a fetch call. The smart contract's trust assumption sits in that bridge.

Programmable data closes that gap. The same protocol that holds the bytes also runs the smart contract that reads them. The smart contract sees the data as protocol-verified network state.

Data is the information. Storage is the mechanism that holds it. Programmable data is a property of data: specifically, that smart contracts can use it during their own execution. The storage mechanism remains separate, doing the job of keeping the bytes available and verifiable.

The category ladder for L1s goes: execution chains, then datachains, then programmable datachains. Execution chains optimize for running code and treat storage as a side effect. Datachains treat storage as a primary resource. Programmable datachains add native execution on top, so the stored data becomes usable by the smart contracts running on the same chain.

The planned design on Irys

Irys brings storage, verification and execution into one Layer-1 architecture. Its planned Programmable Data interface would use an IrysVM precompile to provide stored bytes directly to a running smart contract.

Data enters Irys through a data transaction. It first arrives in the Submit Ledger, where miners storing the data generate ingress proofs confirming receipt and storage responsibility. Once it satisfies promotion requirements, the data moves to the Publish Ledger, and its Merkle root becomes part of network state. From that point on, storage responsibility is subject to ongoing verification: random sampling, partition replicas, and Useful Proof of Work tie miner rewards to honest, available storage.

In the proposed interface, a Solidity contract would use the ProgrammableData library to request stored bytes through methods such as readBytes(). A client-side access list would identify the transaction and byte range required for execution. These names describe the published design; the supported interface will be documented with the feature's release. The Irys whitepaper frames the goal precisely: smart contracts that "read and act on onchain bytes at hot-access latency."

The planned interface would reference data by its onchain identifier and verify the requested bytes against the stored commitment. The contract could then branch on those bytes and update its state. Contract-state changes and uploads to the storage layer are separate operations; verification of the bytes does not establish that their original source supplied truthful information.

Storage fees and execution fees are accounted for separately. Storing a large file does not pay for executing a smart contract that reads it, and vice versa. This separation lets applications hold meaningful volumes of data on Irys without inflating the cost of smart contract execution, and it lets smart contract execution stay independent of the file sizes the smart contract happens to reference.

Both fees are paid in the network's native token (IRYS), in a single fee market. This is different from split-token designs where storage and execution use different tokens. Walrus, for example, prices storage in WAL while execution happens on Sui. On Irys, one token covers both lanes, so applications do not have to manage two fee balances or two issuance schedules.

What programmable data could enable

The following examples illustrate potential uses of the planned native-data interface.

AI provenance. A model published to Irys carries verifiable structured metadata: the training set hash, the fine-tuning recipe, the evaluation results. An inference smart contract could read that metadata directly from storage and verify it against the Publish Ledger before signing off on inference output. The contract could verify the stored record; the application would still need to assess the source and meaning of the model's claims.

DePIN (Decentralized Physical Infrastructure Networks) coordination. Sensor networks generate high-frequency telemetry. With programmable data, telemetry would live on Irys, and a payment smart contract could read the most recent window of measurements when it computes operator rewards. The data source and the payment logic would share one protocol. Native reads would connect the stored measurements to payment logic; authenticating the sensor readings remains an application responsibility.

Autonomous agent smart contracts. An onchain agent makes decisions over time. Each decision and the inputs that produced it are written to Irys. The next time the agent's smart contract executes, it could read its own prior decision history from storage and use that history as a verified input. The agent's record of itself would become part of network state.

These examples share one shape. The smart contract would read stored data during its own execution. The data would be verified by the protocol that holds it. The smart contract's behavior could depend on data that the chain itself can prove.

Programmable data compared to nearby concepts

The table compares Irys's planned Programmable Data interface with other approaches to supplying data to contracts.

In prose:

Programmable data versus data on a decentralized storage network. Storage networks like IPFS or Arweave hold the bytes. A separate execution chain runs the smart contract. The smart contract talks to the storage network across a bridge or a pinning service. Programmable data removes that bridge by putting storage and execution in the same protocol.

Programmable data versus oracle-fed data. An oracle is an off-protocol service that posts external data onchain on a schedule. The smart contract trusts the oracle. Programmable data is the smart contract reading data the chain already holds and verifies. Verifying stored bytes and trusting the information supplied by their source are separate questions.

Programmable data versus data availability (DA) layers. A DA layer like Celestia makes blob data retrievable for rollups. It does not give a smart contract a way to read that data as part of its execution. DA solves a different problem.

Where this fits in the bigger picture

Programmable data is the abstraction that makes a programmable datachain different from a generic blockchain. Once data is verified and directly readable by smart contracts on the same protocol, applications can be designed around shared, reusable, verified onchain data. This replaces architectures that stitch together private databases with bridges. The result is a smaller trust surface and an application architecture where multiple smart contracts can read the same verified onchain data.

For a developer, the practical change is in where data lives and what gets to read it. In the planned design, files could live on Irys and be read directly by a smart contract, bringing the application's data and execution into the same protocol. Verification stops being something the application has to assemble out of independent services and becomes a property of the chain itself.

FAQ

What is the difference between programmable data and stored data?

Stored data sits in storage and waits to be retrieved by an application. Programmable data has been verified by the protocol and is directly readable by a smart contract during that smart contract's execution. Programmable data is data that participates in execution.

How is programmable data different from data stored in an Ethereum smart contract?

Ethereum smart contracts can store data using SSTORE, but each storage slot write is expensive in gas, and large data items are impractical to keep in contract state. In Irys's planned design, programmable data uses a separate storage system with its own fee accounting, designed to hold large data items. A smart contract would read that data through a precompile call, separate from the standard EVM storage opcodes.

Do I need to learn a new VM or a new language to use programmable data?

No. IrysVM is EVM-compatible. Solidity smart contracts deploy the same way they do on Ethereum. The planned addition is a ProgrammableData precompile for native access to stored bytes. Existing Ethereum tooling, including Hardhat, Foundry, and the broader EVM toolchain, continues to apply.

Is programmable data live yet?

Not yet. Programmable Data is in development. See current status.

What kind of data can I write to Irys?

Any byte stream that fits the DataItem format: files, datasets, model artifacts, sensor records, structured metadata, application records. Supported data formats and limits for native contract reads will be specified in the Programmable Data release documentation. Tutorials and reference examples live in the docs.

Programmable data, in one paragraph

Programmable Data is Irys's planned native connection between stored data and smart contract execution. A precompile would make eligible stored bytes available to a contract, allowing application logic to operate on shared onchain data within the same network.

Explore the IrysVM design and Programmable Data status, or start uploading with the storage quickstart.