Today we’re releasing the wvm:// data retrieval protocol along with a gateway to fetch WeaveVM data from Arweave in an availability-secure manner with frictionless developer experience.
Developers using wvm:// means:
- No more reliance on centralized indexers or unincentivized archival nodes to retrieve onchain data
- No need to write custom code to fetch and decode Arweave-stored data from WeaveVM
- A way to guarantee that WeaveVM data exists on Arweave and vice versa, providing verifiable DA
About wvm://
WeaveVM Data Retriever (wvm://) is a protocol for retrieving data from the WeaveVM network. It leverages the WeaveVM DA layer and Arweave’s permanent storage toprovide trustless access WeaveVM transaction data through both networks, whether that’s data which came from WeaveVM itself, or L2 data that was settled to WeaveVM.
Many chains solve this problem by providing query interfaces to archival nodes or centralized indexers. For WeaveVM, Arweave is the archival node, and can be queried without special tooling. However, the data WeaveVM stores on Arweave is also encoded, serialized and compressed, making it cumbersome to access. The wvm:// protocol solves this problem by providing an out-of-the-box way to grab and decode WeaveVM data while also checking it has been DA-verified.
How it works
The data retrieval pipeline ensures that when you request data associated with a WeaveVM transaction, it passes through at least one DA check (currently through WeaveVM’s self-DA, and soon AO).
It then retrieves the transaction block from Arweave, published by WeaveVM ExExes, decodes the block (decompresses Brotli and deserializes Borsh), and scans the archived sealed block transactions within WeaveVM to locate the requested transaction ID, ultimately returning the calldata (input) associated with it.
Therefore, when you request WeaveVM transaction data through the wvm:// protocol, you can trust that the returned data is retrieved from both the WeaveVM network and Arweave’s Permaweb. These multi-onchain data retrieval processes ensure that the data is secured by WeaveVM’s DA and also exists on Arweave (included in the transaction’s archived block). This approach contrasts with the current standard, which typically relies on archive nodes (for historical data) or centralized third-party indexers for transaction data retrieval.
Try it out
Currently, the wvm:// gateway server provides two methods: one for general data retrieval and another specifically for transaction data posted by the wvm-archiver nodes. To retrieve calldata for any transaction on WeaveVM, you can use the following command:
The second method is specific to wvm-archiver nodes because it decompresses the calldata and then deserializes its Borsh encoding according to a predefined structure. This is possible because the data encoding of wvm-archiver data is known to include an additional layer of Borsh-Brotli encoding before the data is settled on WeaveVM.
Deploy your own wvm:// instance
Conclusion
The wvm:// data retrieval protocol is the ideal solution for securely accessing data from WeaveVM. It simplifies the process, eliminating the need to navigate complex retrieval and decoding steps from Arweave and the WeaveVM DA layer.