Irys Blog
IrysVM is Irys's EVM-compatible smart contract execution environment. Its planned Programmable Data extension would let contracts read stored bytes directly during execution.
Programmable Data is in development and is not live yet; the native-read interface below describes the intended design.
The planned stored-data precompile would add a native read path to IrysVM. A contract could receive bytes from Irys's storage layer without a separate retrieval service supplying them to execution. This is the abstraction that makes a datachain programmable.
What makes IrysVM different from the EVM
EVM-compatible means Solidity smart contracts written for Ethereum deploy and run on IrysVM with no code changes. The Ethereum gas model, the opcode set, the ABI, and the standard tooling all carry over. What changes is what smart contracts can do once they are running.
A vanilla EVM smart contract has access to onchain storage limited to what it has written to its own storage slots, plus the public state of other smart contracts. To use large data items or files, the smart contract has to fetch them through an oracle, a retrieval service, or by trusting an off-chain signed message.
Programmable Data would add another read path: a precompile providing stored bytes from Irys's storage layer to a running contract. The application would identify the transaction and byte range it needs, and the contract could use those bytes as inputs.
The intended benefit: applications could be designed around large or shared onchain data without leaving the smart contract execution environment to fetch it. Storage and smart contract execution live in the same protocol.
The planned precompile interface
The planned precompile interface would be exposed through a Solidity library called ProgrammableData. A smart contract that needs to read stored data would inherit from this library and call methods like readBytes() to pull bytes into execution. The Irys whitepaper describes IrysVM as a runtime that "extends the EVM with precompiles that stream chunk ranges into contracts."
The reference to the stored data would be built client-side, before the transaction is submitted. The application would use the Irys client SDK to construct an access list: a transaction ID (the onchain identifier of the data) plus a byte range, specified as a start offset and a length. The access list would carry along with the transaction calling the smart contract, and IrysVM would use it to fetch the specific chunks the precompile call needs.
When the smart contract called readBytes(), the precompile would return the requested bytes from Irys's storage layer to the smart contract's execution environment as input parameters. A contract could apply logic to the returned bytes and update its own state. Uploading a file is a separate storage operation, and an application must still evaluate the source and meaning of the data it uses.
See Programmable Data status for availability and the execution model for architectural context.
EVM compatibility in practice
For a developer migrating from Ethereum, the practical implications:
Smart contracts. Solidity smart contracts compiled for Ethereum deploy on IrysVM without modification. The same source code, the same compiler output, the same deployment bytecode.
Tooling. Standard Ethereum developer tools work. Hardhat for project structure and tests. Foundry for compilation, testing, and deployment. MetaMask for wallet connection. ethers.js and viem for client libraries. The Ethereum JSON-RPC interface continues to apply.
Gas model. IrysVM uses Ethereum's gas model for smart contract execution. Storage operations on Irys's data layer (the Submit Ledger and Publish Ledger) are priced separately, so writing a large file does not consume execution gas. Both fees are paid in the network's native token, IRYS, in a single fee market.
Differences from Ethereum. The planned precompile for stored data access is the main new interface. The Submit Ledger and Publish Ledger are the storage-side primitives the smart contract is reading from. The underlying chain runs on Useful Proof of Work, the storage-tied component of Irys's hybrid consensus.
How IrysVM fits into the Irys protocol
IrysVM is one half of the Irys design. The other half is the storage layer: data transactions, the Submit Ledger, and the Publish Ledger. The two halves share the same chain.
When a developer writes data to Irys, it enters through a data transaction, is held in the Submit Ledger for initial validation, and is promoted to the Publish Ledger after meeting promotion requirements. The planned Programmable Data interface would make eligible stored bytes available to IrysVM contracts through a precompile.
The same consensus mechanism that secures block production also secures storage. Miners earn rewards for both block production and storage proofs, slashing applies to storage failures, and the chain's economic incentives align around keeping the data available. From IrysVM's perspective, the storage layer would supply verified bytes to contracts through the planned interface.
This integration is what makes Irys a programmable datachain. The storage layer and the execution layer are designed together as one protocol.
IrysVM compared to other smart contract environments
A few comparisons help place IrysVM.
| Property | IrysVM (Irys) | Vanilla EVM (Ethereum) | AO (Arweave) | FVM (Filecoin) |
|---|---|---|---|---|
| Smart contract language | Solidity, EVM bytecode | Solidity, EVM bytecode | Lua-based (AOS), actor-model | Solidity, WASM |
| Smart contract reads stored data during execution | Planned through Programmable Data; not yet available. | Only own contract state and other contracts' state | Through message-passing in actors | Through retrieval from a storage provider |
| Tooling | Hardhat, Foundry, ethers.js, viem (full EVM compatibility) | Hardhat, Foundry, ethers.js, viem | aoconnect SDK, AOS | Hardhat, Foundry (with FVM-specific extensions) |
| Primary chain | Irys (programmable datachain) | Ethereum (execution-first L1) | Arweave (storage-first L1, AO as compute layer) | Filecoin (storage marketplace L1) |
In prose:
vs Vanilla EVM (Ethereum). IrysVM keeps the language, the tooling, and the deployment flow. The planned change would add a precompile for stored data access. Developers moving from Ethereum get full source-code compatibility.
vs AO (Arweave). AO is a parallel actor-model network for computation that uses Arweave for messaging and storage. Smart contract logic on AO runs as Lua-based actors that pass messages, separate from Arweave's storage layer. IrysVM keeps the smart contract execution model that the EVM ecosystem already runs and would add protocol-level access to stored data through the planned precompile.
vs FVM (Filecoin). FVM runs Solidity and WASM smart contracts that reference stored data by content identifier (CID). Accessing the underlying bytes during execution typically goes through retrieval from a storage provider. IrysVM would expose stored bytes through a precompile call inside the execution environment.
FAQ
Is IrysVM EVM-compatible?
Yes. IrysVM runs Solidity smart contracts compiled for the EVM, uses the same opcode set and gas model, and exposes the standard Ethereum JSON-RPC interface. Developer tools like Hardhat, Foundry, MetaMask, ethers.js, and viem work without modification. The planned extension on top of the standard EVM is a precompile that would stream stored data on Irys into smart contract execution.
Can I deploy my existing Ethereum smart contracts on IrysVM?
Yes. Solidity smart contracts written for Ethereum deploy on IrysVM with no code changes. The same source code, the same compiler output, the same deployment bytecode. You can deploy an existing smart contract to take advantage of Irys's lower storage costs and consensus-level storage incentives, then add native data reads when Programmable Data becomes available.
What tools work with IrysVM?
The standard EVM toolchain: Hardhat for project structure and tests, Foundry for compilation and deployment, ethers.js and viem for client libraries, MetaMask and other Ethereum-compatible wallets, the Ethereum JSON-RPC interface. Programmable data access list construction is planned as an addition to the Irys client SDK on top of the standard EVM tooling.
How does IrysVM read stored data?
The planned Programmable Data interface would use a precompile to return stored bytes to a running contract. A client-side access list would identify the transaction and byte range. This feature is in development; see current status.
What smart contract languages does IrysVM support?
IrysVM supports Solidity and any other language that compiles to EVM bytecode. Because IrysVM is EVM-compatible, smart contracts that run on Ethereum run on IrysVM. The Irys client SDK is available in TypeScript for application-side code; access list construction for Programmable Data is planned alongside the feature.
IrysVM, in one paragraph
IrysVM is Irys's EVM-compatible smart contract execution environment. The planned Programmable Data extension would add native access to stored bytes through a precompile, giving contracts another way to work with shared onchain data. Storage and execution are designed together within the same Layer-1 architecture.
Explore the Irys docs, Programmable Data status, and the storage upload quickstart.