Today we’re thrilled to introduce the first ever EVM precompiles (precompiled contracts) that will be used in the WeaveVM network to achieve bidirectional data communication (read/write) between WeaveVM and Arweave. In simple terms, developers will be able to upload data to Arweave and read data from Arweave natively from the EVM smart contract layer (Solidity smart contracts).
This unlocks new use cases by lifting the EVM storage barrier. With Arweave as a native data store inside Solidity contracts, developers can now build dApps fit for data-rich, real world purposes. This integration effectively bridges the gap between Ethereum’s smart contract capabilities and Arweave’s decentralized, permanent storage, allowing developers to store large amounts of data on a dedicated storage chain and interface with that data inside of the EVM environment.
In this article we’ll examine the technicals behind precompiles and go deeper into what this data pipeline with Arweave enables for Solidity developers.
What Are Precompiled Contracts?
In Ethereum, a contract is code deployed on the Ethereum network and executed on the Ethereum Virtual Machine (EVM). When deploying a contract, it’s compiled from a high-level language like Solidity into EVM bytecode that the EVM can execute.
A precompiled contract is a special contract pre-installed on the Ethereum network, usable by other contracts without separate deployment. These contracts typically handle computationally expensive operations, like cryptographic functions, that would be too costly to perform on-chain within a regular contract. Precompiled contracts are written in low-level languages and are already compiled and optimized for EVM execution.
The fixed addresses of precompiles start from 1 (0x01) and increment for each contract. New hardforks may introduce new precompiled contracts. They’re called from opcodes like regular contracts, using instructions like CALL. Currently, there are 10 precompiled contracts on the Ethereum mainnet, which are also supported within the WeaveVM network (0x01 -> 0x0A): ecrecover, sha256, blake2f, ripemd-160, Bn256Add, Bn256Mul, Bn256Pairing, the identity function, modular exponentiation, and point evaluation. Learn more details about Ethereum Precompiles here
WeaveVM Precompiles
As mentioned earlier, WeaveVM supports all Ethereum precompiles from address 0x01 to 0x0A. WeaveVM network precompiles start at decimal 23 (0x17). We didn’t choose 23 randomly, but to keep 12 addresses (0x0B -> 0x16) reserved for possible future Ethereum hardforks introducing new precompiles, and also because “W” (initial of WeaveVM) is the 23rd letter of the alphabet. In the following section, we’ll outline the two new precompiles developed by the WeaveVM team to create the first ever bidirectional data pipeline between the EVM smart contract layer and Arweave’s Permaweb.
1- Precompile 0x17: upload data from Solidity to Arweave
The WeaveVM Precompile at address 0x17 enables data upload (in byte format) from Solidity to Arweave, and returns the data TXID (in byte format). In Testnet V0, data uploads are limited to 100KB. Future network updates will remove this limitation and introduce a higher data cap.
Precompile information and code example
2- Precompile 0x18: read Arweave data from Solidity
This precompile, at address 0x18, completes the data pipeline between WeaveVM and Arweave, making it bidirectional. It enables retrieving data from Arweave in bytes for a given Arweave TXID. The table below outlines the max Arweave transaction size that can be read in WeaveVM smart contracts for each testnet release (Note: these are theoretical numbers based on network metrics calculations).
Precompile information and code example
The 0x18 precompile allows user input to choose their Arweave gateway for resolving a TXID. If no gateway URL is provided, the precompile defaults to arweave.net.
The format of the precompile bytes input (string representation) should be as follows: gateway_url;arweave_txid
Check out WeaveVM Precompile source code here.
New use cases for an EVM-Arweave data pipeline
Storing data onchain with Solidity-based applications has typically been very expensive and subject to tight limitations. Lifting these limitations makes it possible to new app types that were previously only viable on web2.
Content-rich apps
Fully onchain social media, governance discussion, content monetization, document management, and more is possible thanks to full files now being accessible via a Solidity interface. Current EVM solutions typically offload large files to temporary or centralized storage layers, breaking the guarantee of permanence and trustless verifiability.
NFT metadata storage
Most NFTs aren’t onchain. On the EVM side, typically the only data stored immutably is the ‘ownership certificate’ and a log of past owners. Most NFTs use temporary or centralized services to store the actual media and metadata. WeaveVM’s EVM-Arweave data pipeline allows Solidity contracts to push NFT metadata to Arweave as part of the minting process, ensuring that centralized server outages can’t render NFTs useless.
“I’ve used Arweave a good amt in the past for nft metadata dev. I could imagine it (WeaveVM Precompiles) becomes an sstore alternative if cheap enough. Which could be pretty cool as evm storage still requires devs to be kinda thrifty rn” – Owen, Sudoswap founder, on WeaveVM precompiles
Interoperability with ao applications
Any data posted to the Arweave L1 is able to be picked up and computed by the ao layer thanks to oracles like 0rbit and Redstone. WeaveVM’s precompiles make it easy to post granular and easily-surfaceable data to the L1, unlocking direct interoperability to ao applications. On the ao side, dApps can listen for data from WeaveVM and trigger actions for anything from minting atomic assets to executing a trade.
Conclusion
The WeaveVM team is Arweave-aligned and building towards data and asset interoperability between EVM networks and Arweave. With these two precompiles, WeaveVM achieves, for the first time as an EVM network, full native bidirectional communication with Arweave. And as AO is a data protocol specification on top of Arweave, WeaveVM begins to tackle EVM-AO native communication within this pipeline as well.