Alphanets: Stable Testnets

• Designed for user/dev exploration and testing.

• Features low frequency of breaking changes.

• Provides a more reliable environment for developers and users to interact with Load Network.

Devnets: Experimental Testnets

• Acts as a testing ground for the Alphanets.

• Characterized by frequent breaking changes and potential instability.

• Playground for testing new features, EIPs, and experimental concepts.

Abstract

Load Network is a high performance blockchain for onchain data storage - cheaply and verifiably store and access any data .

As a high-performance data-centric EVM network, Load Network maximizes scale and transparency for L1s, L2s and data-intensive dApps. Load Network is dedicated to solving the problem of onchain data storage. Load Network offloads storage to Arweave, and achieve high performance computation -decoupled from the EVM L1 itself- by utilizing ao-hyperbeam custom devices, giving any other chain a way to easily plug in a robust permanent storage layer powered by a hyperscalable network of EVM nodes with bleeding edge throughput capacity.

Load Network is ex-WeaveVM Network

Before March 2025, Load Network (abbreviations: LOAD or LN) was named WeaveVM Network (WVM). All existing references to WeaveVM (naming, links, etc.) in the documentation should be treated as Load Network.

Let's explore the key features of Load Network:

Beefy Block Producer

Load Network achieves enterprise-like performance by limiting block production to beefy hardware nodes while maintaining trustless and decentralized block validation.

What this means, is that anyone with a sufficient amount of $AO tokens (read more about $AO security below in this page) meeting the PoS staking threshold, plus the necessary hardware and internet connectivity (super-node, enterprise hardware), can run a node. This approach is inspired by Vitalik Buterin's work in "The Endgame" post.

Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented.

These "super nodes" producing Load Network blocks result in a high-performance EVM network.

Large Block Size

Raising the gas limit increases the block size and operations per block, affecting both History growth and State growth (mainly relevant for our point here).

Load Network Alphanet raises the gas limit to 500M gas (doing 500 mg/s), and lowers the gas per non-zero byte to 8. These changes have resulted in a larger max theoretical block size of 62 MB, and consequently, the network data throughput is ~62 MBps.

This high data throughput can be handled thanks to block production by super nodes and hardware acceleration.

High-Throughput DA

Up until now, there's been no real-world, scalable DA (altDA) layer ready to handle high data throughput with permanent storage. Load Alphanet reaches a maximum throughput of 62 MBps, with a projection of 125 MBps in mainnet.

Modular EVM Node Components Design

Building on HyperBEAM and ao network enables us to package modules of the EVM node stack as HyperBEAM NIF (Native Implemented Function) devices.

This horizontally scalable and parallel architecture allows Load Network EVM nodes to be modularly composable in a totally new paradigm. For example, a node run by Alice might not implement the JSON-RPC component but can pay fees (compute paid in $AO) for its usage from Bob, who has this missing EVM component.

With this model, we will be achieving ao network synergy and interoperability. To read more about the rationale behind this, check the "" blog post

Programmable EVM data & Arweave Permanence

Load Network uses a set of Reth execution extensions (ExExes) to serialize each block in Borsh, then compress it in Brotli before sending it to Arweave. These computations ensure a cost-efficient, permanent history backup on Arweave. This feature is crucial for other L1s/L2s using Load Network for data settlement, aka LOADing [ ^^].

In the , we show the difference between various compression algorithms applied to Borsh-serialized empty block (zero transactions) and JSON-serialized empty block. Borsh serialization combined with Brotli compression gives us the most efficient compression ratio in the data serialization-compression process.

At the time of writing, and since the data protocol's inception, Load Network Arweave ExEx is the largest data protocol on top of Arweave in terms of the number of settled dataitems.

The Load Network interface with Arweave with more than just block data settling. We have developed the first precompiles that achieve a native bidirectional data pipeline with the Arweave network. In other words, with these precompiles (currently supported by Load Network testnet), you can read data from Arweave and send data to Arweave trustlessly and natively from a Solidity smart contract, creating the first ever programmable scalable EVM data, backed with Arweave permanence.

Cost Efficient Data Settling

Load's hyper computation, supercharged hardware, and interface with Arweave results in significantly cheaper data settlement costs on Load Network, which include the Arweave fees to cover the archiving costs. .

Even compared to temporary blob-based solutions, Load Network still offers a significantly cheaper permanent data solution (calldata).

Alien Stack, Alien Network Security

The Load Network is the first EVM L1 to leverage Arweave storage and interoperability natively inside the EVM, and obviously, the first EVM L1 to adopt the modular evm node components paradigm powered by HyperBEAM devices.

To align this alien tech stack, we needed an alien security model. On Load Network, users will pay gas in Load's native gas token, $LOAD. On the node operator side, a node that is not running the full stack of EVM components, is required to buy compute from other nodes offering the missing component by paying $AO.

Additionally, as Load is built on top of HyperBEAM (ao network) and Arweave, it's logical to inherit the network security of AO and reinforce Load's self-DA security. For these reasons, Load node operators stake $AO in order to join the EVM L1 block production.

The table below does not include the list of minor releases between major Alphanet releases. For the full changelogs and releases, check them out here: https://github.com/weaveVM/wvm-reth/releases

Let's make it easy to get going with Load Network. In this doc, we'll go through the simplest ways to use Load across the most common use cases:

The eth_getArweaveStorageProof JSON-RPC method

This JSON-RPC method lets you retrieve the Arweave storage proof for a given Load Network block number

curl -X POST https://alphanet.load.network \
-H "Content-Type: application/json" \
--data '{
 "jsonrpc":"2.0",
 "method":"eth_getArweaveStorageProof",
 "params":["8038800"],
 "id":1
}'

The eth_getWvmTransactionByTag JSON-RPC method

For Load Network L1 tagged transactions, the eth_getWvmTransactionByTag lets you retrieve a transaction hash for a given name-value tag pair.

What is Load Network?

Load is a high-performance blockchain built towards the goal of solving the EVM storage dilemma with and ao . It gives the coming generation of high-performance chains a place to settle and store onchain data, without worrying about cost, availability, or permanence.

Load Network offers scalable and cost-effective permanent storage by using Arweave as a decentralized hard drive, both at the node and smart contract layer, HyperBEAM as modular stack of EVM node components, and ao network for compute and network security. This makes it possible to store large data sets and run web2-like applications without incurring EVM storage fees.

About HyperBEAM

HyperBeam is a client implementation of the AO-Core protocol, written in Erlang. It can be seen as the 'node' software for the decentralized operating system that AO enables; abstracting hardware provisioning and details from the execution of individual programs.

HyperBEAM node operators can offer the services of their machine to others inside the network by electing to execute any number of different devices, charging users for their computation as necessary.

Each HyperBEAM node is configured using the [email protected] device, which provides an interface for specifying the node's hardware, supported devices, metering and payments information, amongst other configuration options. For more details, check out the HyperBEAM codebase:

load_hb: Load Network HyperBEAM node with custom devices

The repository is our HyperBEAM fork with custom devices such as , , and

Our development motto is driven by the manifesto initiated during Arweave Day Berlin 2025.

Our main hyperbeam development is hosted on

About

we have developed a custom fork of (an Ethereum Execution Environment that seamlessly integrates RISCV smart contracts alongside traditional EVM smart contracts) to input and return the resulted computed EVM db.

About

The [email protected] device is an EVM/Ethereum consensus light client built into the HyperBEAM devices stack. With helios, node operators can trustlessly connect to EVM RPCs with a very lightweight, multichain and secure setup, and no historical syncing overhead. With this device, every hyperbeam node can turn into a verifiable EVM RPC endpoint.

Combining the Load EVM with custom HyperBEAM devices enables a wide range of options, from smart contracts to WASM workers to serverless GPU functions.

In this page we will briefly go over the different options within the extended Load Network ecosystem.

Native EVM compute

The Load EVM offers native EVM compute with typical smart contracts, blobs and calldata standards that are all 1:1 compatible with Ethereum and other EVM networks. As a specialized storage and DA chain, the Load L1 is optimized for to enable data-intensive dApps. .

EVM compatibility

Load Network EVM is built on top of Reth, making it compatible as a network with existing EVM-based applications. This means you can run your current Ethereum-based projects on LN without significant modifications, leveraging the full potential of the EVM ecosystem.

Load Network EVM doesn't introduce new opcodes or breaking changes to the EVM itself, but it uses ExExes and adds custom precompiles:

The stores Ethereum's blobs temporarily on the , serialized as . Based on need/demand, DataItems can be deterministically pushed to Arweave while maintaining integrity and provenance.

DataItems stored on the [email protected] device can be retrieved from the Hybrid Gateway as if they are Arweave txs:

Agent Server Methods

Retrieve blob versioned hash and the associated ANS-104 dataitem id by versioned hash

About

This ExEx is the first data upload pipeline between an Ethereum client (reth) and Arweave, the permanent data storage network. The ExEx uses to bundle data and send it to Arweave. .

Rust Proxy

Run Locally

About

This introduces a new DA interface for EVM rollups that doesn't require changes to the sequencer or network architecture. It's easily added to any Reth client with just 80 lines of code by importing the DA ExEx code into the ExExes directory, making integration simple and seamless. Get the code here & installing setup guide here

ExEx is a framework for building performant and complex off-chain infrastructure as post-execution hooks.

Reth ExExes can be used to implement rollups, indexers, MEV bots and more with >10x less code than existing methods. Check out the Reth ExEx announcement by Paradigm https://www.paradigm.xyz/2024/05/reth-exex

In the following pages we will list the ExExes developed and used by Load Network.

About

Borsh stands for Binary Object Representation Serializer for Hashing and is a binary serializer developed by the NEAR team. It is designed for security-critical projects, prioritizing consistency, safety, and speed, and comes with a strict specification.

The ExEx utilizes Borsh to serialize and deserialize block objects, ensuring a bijective mapping between objects and their binary representations. Get the ExEx code

About

ExEx.rs is an open source directory for Reth's ExExes. You can think of it as an "chainlist of ExExes".

We believe that curating ExExes will accelerate their development by making examples and templates easily discoverable. Add you ExEx today!

In the following section you will explore the Execution Extensions developed by our team to power WeaveVM

About load://

Load Network Data Retriever (load://) is a protocol for retrieving data from the Load Network (EVM). It leverages the LN DA layer and Arweave’s permanent storage to provide trustless access LN transaction data through both networks, whether that’s data which came from LN itself, or L2 data that was settled to LN.

Many chains solve this problem by providing query interfaces to archival nodes or centralized indexers. For Load Network, Arweave is the archival node, and can be queried without special tooling. However, the data LN stores on Arweave is also encoded, serialized and compressed, making it cumbersome to access. The load:// protocol solves this problem by providing an out-of-the-box way to grab and decode Load Network 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 Load Network transaction, it passes through at least one DA check (currently through LN's self-DA).

It then retrieves the transaction block from Arweave, published by LN ExExes, decodes the block (decompresses Brotli and deserializes Borsh), and scans the archived sealed block transactions within LN to locate the requested transaction ID, ultimately returning the calldata (input) associated with it.

Try it out

Currently, the load:// gateway server provides two methods: one for general data retrieval and another specifically for transaction data posted by the load-archiver nodes. To retrieve calldata for any transaction on Load Network, you can use the following command:

The second method is specific to load-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 load-archiver data is known to include an additional layer of Borsh-Brotli encoding before the data is settled on LN.

Benchmarks

Latency for /calldata

The latency includes the time spent fetching data from LN EVM RPC and the Arweave gateway, as well as the processing time for Brotli decompression, Borsh deserialization, and data validity verification.

Check out the load:// data protocol protocol

load0 is Bundler's Large Bundle on steroids -- a cloud-like experience to upload and download data from Load Network using the Bundler's 0xbabe2 transaction format powered with SuperAccount & S3 under the hood.

Technical Architecture

First, the user sends data to the load0 REST API /upload endpoint -- the data is pushed to load0's S3 bucket and returns an optimistic hash (keccak hash) which allows the users to instantly retrieve the object data from load0.

After being added to the load0 bucket, the object gets added to the orchestrator queue that uploads the optimistic cached objects to Load Network. Using Large Bundle & SuperAccount, the S3 bucket objects get sequentially uploaded to Load and therefore, permanently stored while maintaining very fast uploads and downloads. Object size limit: 1 byte -> 2GB.

REST API

1- Upload object

2- Download object (browser)

Also, to have endpoints similiarity as in bundler.load.rs, you can do:

3- Retrieve Bundle metadata using optimistic hash or bundle txid (once settled)

Returns:

An object data can be accessed via:

• optimistic caching: https://load0.network/resolve/{Bundle.optimistic_hash}

• from Load Network (once settled): https://bundler.load.rs/v2/resolve/{Bundle.bundle_txid}

Source code:

How to get load_acc API keys

First, you have to create a bucket from the cloud.load.network dashboard if the bucket you want to create scoped keys for does not already exist.

After creating the bucket, navigate to the "API Keys" tab and create a new load_acc key with a label, then scope it to the desired bucket.

load_acc in action

After creating a bucket and load_acc API key, you can now interact with the Load S3 storage layer via S3-compatible SDKs, such as the official AWS S3 SDK. Here is the S3 client configuration as it should be:

And that's it, that's all you need to start interacting with your HyperBEAM-powered S3 temporary storage!

About

The @evm1.0 device: an EVM bytecode emulator built on top of Revm (version v22.0.1).

The device not only allows evaluation of bytecode (signed raw transactions) against a given state db, but also supports appchain creation, statefulness, EVM context customization (gas limit, chain id, contract size limit, etc.), and the elimination of the block gas limit by substituting it with a transaction-level gas limit.

Technical Architecture

eval_bytecode() takes 3 inputs, a signed raw transaction (N.B: chain id matters), a JSON-stringified state db and the output state path (here in this device it's in )

References

• device source code:

• hb device interface:

• nif tests:

• ao process example:

All storage chains have the same issue: even if the data storage is decentralized, retrieval is handled by a centralized gateway. A solution to this problem is just to provide a way for anyone to easily run their own gateway – and if you’re an application building on Load Network, that’s a great way to ensure content is rapidly retrievable from the blockchain.

When – a photo sharing dApp that uses LN bundles for storage – started getting traction, the default LN gateway became a bottleneck for the Relic team. The way data is stored inside bundles (hex-encoded, serialized, compressed) can make it resource-intensive to decode and present media on demand, especially when thousands of users are doing so in parallel.

In response, we developed two new open source gateways: one , and .

The LN Gateway Stack introduces a powerful new way to access data from Load Network bundles, combining high performance with network resilience. At its core, it’s designed to make bundle data instantly accessible while contributing to the overall health and decentralization of the LN.

What is the x402 protocol?

The x402 protocol is an open framework that enables machine-to-machine payments on the web by standardizing how clients and services exchange value over HTTP. Building on the HTTP 402 "Payment Required" status code, x402 establishes a clear transaction flow where a server responds to resource requests with payment instructions (including amount and recipient), the client provides payment authorization, a payment facilitator verifies and settles the transaction, and the server delivers the requested resource along with payment confirmation.

This protocol allows automated agents, crawlers, and digital services to conduct transactions programmatically without requiring traditional accounts, subscriptions, or API keys. By creating a common language for web-based payments, x402 enables new monetization models such as pay-per-use access, micropayments for AI agents purchasing from multiple merchants, and flexible payment schemes including immediate settlement via stablecoins or deferred settlement through traditional payment rails like credit cards and bank accounts.

About

Load Network have precompiled contracts that push data directly to Arweave as ANS-104 data items. One such precompile is the precompile (arweave_upload).

About

Adding a DA layer usually requires base-level changes to a network’s architecture. Typically, DA data is posted either by sending calldata to the L1 or through blobs, with the posting done at the sequencer level or by modifying the rollup node’s code.

This ExEx introduces an emerging, non-traditional DA interface for EVM rollups. No changes are required at the sequencer level, and it’s all handled via the ExEx, which is easy to add to any Reth client in just 80 lines of code.

About

The Load S3 storage layer is built on top of HyperBEAM as a device, and ao network for data programmability. At its core, the [email protected] device – a HyperBEAM s3 object-storage provider – is the heart of the storage layer.

The HyperBEAM S3 device offers maximum flexibility for HyperBEAM node operators, allowing them to either spin up MinIO clusters in the same location as the HyperBEAM node and rent their available storage, or connect to existing external clusters, offering native integration between hb’s s3 and devs existing storage clusters. For instance, Load’s S3 device is co-located with the MinIO clusters.

Erasure-coded redundancy, fault tolerance, and data availability

Load S3’s MinIO cluster, forming the storage layer, runs on 4 nodes with erasure coding enabled. Data is split into data and parity blocks, then striped across all nodes. This allows the system to tolerate the loss of up to two nodes without data loss or service interruption. Unlike full replication, which stores complete copies of each object on multiple nodes, erasure coding provides redundancy with lower storage overhead, ensuring durability while keeping capacity usage efficient.

A four-node configuration also enables automatic data healing. When a failed node comes back online or a new node replaces it, missing blocks are rebuilt from the remaining healthy nodes in real-time, without taking the cluster offline. Object integrity is verified using per-object checksums, and data availability can be asserted using S3 metadata, such as size, timestamp, and ETag – ensuring each object is present, intact, and retrievable.

The Load S3 layer inherits these guarantees by offloading them to a battle-tested distributed object storage system, in this implementation, MinIO. In the future, the Load S3 decentralized network, consisting of multiple S3 HyperBEAM nodes, will have these properties available out of the box, without the need to re-engineer them from scratch.

[email protected] & ANS-104 DataItems

The [email protected] device has been designed with a built-in data protocol to natively handle ANS-104 DataItems offchain temporary storage. This approach translates our rationale: HyperBEAM s3 nodes can store signed & valid ANS-104 DataItems temporarily, that can be pushed anytime, when needed, to Arweave, while maintaining the DataItem’s provenance and determinism (e.g. ID, signature, timestamp, etc). Learn more about data provenance, lineage and governance here.

Hybrid Gateway

Given the S3 device’s native integration with objects serialized and stored as ANS-104 DataItems, we considered DataItem accessibility, such as resolving via Arweave gateways.

Being an S3 device, we were able to benefit from HyperBEAM’s modular architecture, so we extended HyperBEAM’s gateway: we built the module and extended the by integrating the hb_gateway_s3 store module as a fallback extension to the Arweave’s GraphQL API.

Additionally, hb_opts.erl Stores orders have been modified to add s3 offchain dataitems retrieval as a fallback after HyperBEAM’s cache module, Arweave gateway then S3 (offchain) – offchain DataItems should have the Data-Protocol : Load-S3 tag to be recognized by the subindex.

Building these extension components, a hb node running the ~ device, benefit from the Hybrid Gateway that can resolve both onchain and offchain dataitems.

Load S3 Trust Assumptions, Optimismo

In the current release, Load S3 is a storage layer consisting of a single centralized yet verifiable storage provider (HyperBEAM node running the [email protected] device components).

This early-stage testing layer offers similar trust assumptions offered by other centralized services in the Arweave ecosystem such as ANS-104 Bundlers. Load S3’s gradual evolution from a layer to decentralized network built on top of ao network will remove the centralized and trust-based components, one by one, to reach a trustless, verifiable and incentivized temporal data storage network.

Blazingly Fast ANS-104 DataItems streaming sidecar

Besides the Hybrid Gateway, nodes like s3-node-1 support a highly optimized low-level dataitems streaming leveraging precomputed dataitem data start-byte offset and range streaming from the S3 cluster directly.

The sidecar bypasses the technical need to deserialize the dataitem in order to extract useful information such as tags and dataitem's data, reducing dramatically the latency for resolving.

On s3-node-1 — the sidecar is available under https://gateway.s3-node-1.load.network/resolve/:offchain-dataitemid

And to download the full LS3 DataItem binary (the .ans104 file), you can use the following endpoint: https://gateway.s3-node-1.load.network/binary/:offchain-dataitemid

Developer Guide

Load’s HyperBEAM node running the [email protected] device is available the following endpoint: – developers looking to use the HyperBEAM node as S3 endpoint, can use the official S3 SDKs as long as the used S3 commands are supported by [email protected] - (1:1 parity)

Available Endpoints

To learn how to start using Load S3 today, check out the following

About

The kernel-em NIF (kernel execution machine - [email protected] device) is a HyperBEAM Rust device built on top of wgpu to offer a general GPU-instructions compute execution machine for .wgsl functions (shaders, kernels).

With wgpu being a cross-platform GPU graphics API, hyperbeam node operators can add the KEM device to offer a compute platform for KEM functions. And with the ability to be called from within an ao process through ao.resolve ([email protected] device), KEM functions offer great flexibility to run as GPU compute sidecars alongside ao processes.

KEM Technical Architecture

KEM function source code is deployed on Arweave (example, double integer: ), and the source code TXID is used as the KEM function ID.

A KEM function execution takes 3 parameters: function ID, binary input data, and output size hint ratio (e.g., 2 means the output is expected to be no more than 2x the size of the input).

The KEM takes the input, retrieves the kernel source code from Arweave, and executes the GPU instructions on the hyperbeam node operator's hardware against the given input, then returns the byte results.

On Writing Kernel Functions

As the kernel execution machine (KEM) is designed to have I/O as bytes, and having the shader entrypoint standardized as main, writing a kernel function should have the function's entrypoint named main, the shader's type to be @compute, and the function's input/output should be in bytes; here is an example of skeleton function:

Uniform Parameters

Uniform parameters have been introduced as well, allowing you to pass configuration data and constants to your compute shaders. Uniforms are read-only data that remains constant across all invocations of the shader.

Here is an example of a skeleton function with uniform parameters:

Example: Image Glitcher

Using the image glitcher kernel function -

References

• device source code:

• hb device interface:

• nif tests:

• ao process example:

About

The LN-ExEx data protocol on Arweave is responsible for archiving Load Network's full block data, which is posted to Arweave using the Arweave Data Uploader Execution Extension (ExEx).

Protocol Specifications

The data protocol transactions follow the ANS-104 data item specifications. Each Load Network block is posted on Arweave, after borsh-brotli encoding, with the following tags:

LN-ExEx Data Items Uploaders

• Reth ExEx Archiver Address:

• Arweave-ExEx-Backfill Address:

About

Load Network Archiver is an ETL archive pipeline for EVM networks. It's the simplest way to interface with LN's permanent data feature without smart contract redeployments.

Load Network Archiver Usage

LN Archiver is the ideal choice if you want to:

• Interface with LN's permanent data settlement and high-throughput DA

• Maintain your current data settlement or DA architecture

• Have an interface with LN without rollup smart contract redeployments

• Avoid codebase refactoring

Run An Instance

To run your own node instance of the load-archiver tool, check out the detailed setup guide on github:

Networks Using LN Archiver

About the OP Stack

The is a generalizable framework spawned out of Optimism’s efforts to scale the Ethereum L1. It provides the tools for launching a production-quality Optimistic Rollup blockchain with a focus on modularity. Layers like the sequencer, data availability, and execution environment can be swapped out to create novel L2 setups.

The goal of optimistic rollups is to increase L1 transaction throughput while reducing transaction costs. For example, when Optimism users sign a transaction and pay the gas fee in ETH, the transaction is first stored in a private mempool before being executed by the sequencer. The sequencer generates blocks of executed transactions every two seconds and periodically batches them as call data submitted to Ethereum. The “optimistic” part comes from assuming transactions are valid unless proven otherwise.

In the case of Laod Network, we have modified OP Stack components to use LN as the data availability and settlement layer for L2s deployed using this architecture.

About

The quantum_runtime_nif is the foundation of the [email protected] device: a quantum computing runtime built on top of roqoqo simulation framework. This hyperbeam device enables serverless quantum function execution, positioning hyperbeam nodes running this device as providers of serverless functions compute.

The device supports quantum circuit execution, measurement-based quantum computation, and provides a registry of pre-built quantum functions including superposition states, quantum random number generation, and quantum teleportation protocols.

What is Quantum Computing?

Quantum computing make use of quantum mechanical phenomena such as superposition and entanglement to process information in fundamentally different ways than classical computers.

Unlike classical bits that exist in definite states (0 or 1), quantum bits (qubits) can exist in superposition of both states simultaneously, enabling parallel computation across multiple possibilities.

[email protected] device

The [email protected] device, as per its current implementation, provides a serverless quantum function execution environment. It uses the roqoqo simulation backend for development and testing, but can be adapted to real quantum computation using services like or other quantum cloud providers such as IBM Quantum Platform, with minimal device code changes.

The device supports quantum circuits with up to 32 qubits and provides a registry of whitelisted quantum functions that can be executed through HTTP calls or via ao messaging.

Available Quantum Functions (in simulation mode)

• superposition: creates quantum superposition state on a single qubit

• quantum_rng: quantum (pseuo)random number generator using multiple qubits

• bell_state: creates entangled Bell states between qubits

• quantum_teleportation: implements quantum teleportation protocol

Quantum Runtime Technical Architecture

The compute() function takes 3 inputs: the number of qubits to initialize, a function ID from the serverless registry, and a list of qubit indices to measure. It returns a HashMap containing the measurement results.

Device API Examples

Generate Quantum Random Numbers

References

• hb device interface:

• nif interface:

• quantum functions registry:

• runtime core:

Understanding the World State Trie

The World State Trie, also known as the Global State Trie, serves as a cornerstone data structure in Ethereum and other EVM networks. Think of it as a dynamic snapshot that captures the current state of the entire network at any given moment. This sophisticated structure maintains a crucial mapping between account addresses (both externally owned accounts and smart contracts) and their corresponding states.

Each account state in the World State Trie contains several essential pieces of information:

• Current balance of the account

• Transaction nonce (tracking the number of transactions sent from this account)

• Smart contract code (for contract accounts)

• Hash of the associated storage trie (linking to the account’s persistent storage)

This structure effectively represents the current status of all assets and relevant information on the EVM network. Each new block contains a reference to the current global state, enabling network nodes to efficiently verify information and validate transactions.

The Dynamic Nature of State Management

An important distinction exists between the World State Trie database and the Account Storage Trie database. While the World State Trie database maintains immutability and reflects the network’s global state, the Account Storage Trie database remains mutable with each block. This mutability is necessary because transaction execution within each block can modify the values stored in accounts, reflecting changes in account states as the blockchain progresses.

Reconstructing the World State with Load Network Archivers

The core focus of this article is demonstrating how Load Network Archivers’ data lakes can be leveraged to reconstruct an EVM network’s World State. We’ve developed a proof-of-concept library in Rust that showcases this capability using a customized Revm wrapper. This library abstracts the complexity of state reconstruction into a simple interface that requires just 10 lines of code to implement.

Here’s how to reconstruct a network’s state using our library:

The reconstruction process follows a straightforward workflow:

1. The library connects to the specified Load Network Archive network

2. Historical ledger data is retrieved from the Load Network Archiver data lakes

3. Retrieved blocks are processed through our custom minimal EVM execution machine

4. The EVM StateManager applies the blocks sequentially, updating the state accordingly

This proof-of-concept implementation is available on GitHub:

has evolved beyond its foundation as a decentralized archive node. This proof of concept demonstrates how our comprehensive data storage enables full EVM network state reconstruction - a capability that opens new possibilities for network analysis, debugging, and state verification.

We built this PoC to showcase what’s possible when you combine permanent storage with proper EVM state handling. Whether you’re analyzing historical network states, debugging complex transactions, or building new tools for chain analysis, the groundwork is now laid.

Add Load Network Alphanet to MetaMask

Before deploying, make sure the Load Network network is configured in your MetaMask wallet. Check the Network Configurations.

ERC20 Contract

For this example, we will use the ERC20 token template provided by the smart contract library.

Deployment

Now that you have your contract source code ready, compile the contract and hit deploy with an initial supply.

After deploying the contract successfully, check your EOA balance!

Links

Key Details

Hyper-x402

is an fork with custom ao network support, that works alongside the rest of the supported networks (EVMs, Solana, Avalanche, Sei, etc), meaning you can not only run the facilitator with those network, but also with ao tokens support.

Uploading data onchain shouldn’t be any more difficult than using Google Drive. The reason tools like Google Drive are popular is because they just work and are cheap/free. Their hidden downsides? You don’t own your data, it’s not permanent, and – especially for blockchain projects – it’s not useful for application developers.

Users just want to put their data somewhere and forget about the upkeep. Developers just want a permanent reference to their data that resolves in any environment. Whichever you are, we built cloud.load.network for you.

The Load Cloud is an all-in-one tool to interact with various Load Network storage interfaces and pipelines: one UI, one API key, various integrations, with web2 UX.

It has been a few months since the . Since the initial alpha, we have been working towards a more complete dashboard for the onchain data center.

This builds towards our vision of the – meeting developers where they are, with familiar devex and 1:1 parallels with the web2 tools they already use. The decentralized compute layer is in place via Load’s EVM/AO layers, and storage via the HyperBEAM-powered S3 device.

The V2 release of the Load Cloud Platform (LCP) introduces several, highly-requested features:

• private ANS-104 DataItems

• DataItems as first-class s3 objects

• access controlled DataItems (s3 objects)

• [email protected] device upgrades

The foundation: a universal API key system for Load

V2 introduces the concept of Load accounts and API keys. A unified auth layer finally enables us to provision scoped access to Load’s HyperBEAM S3 layer and build access control for data.

Under the hood, Load Cloud email login uses to create an EVM wallet. This wallet’s keys have access to the Load authentication API and generate keys in the dashboard that can read and write from S3.

This approach enables API access to offchain services with a wallet address as the primary identity, leaving the system open in the future for offchain components to handle things like payments and native integration with onchain compute.

Private, access-controlled ANS-104 DataItems

Private data and access control are 2 of the most requested features we ever got since we started working with the onchain data center roadmap.

How can I access my data without necessarily encrypting it and storing the encrypted data onchain? How can I gate access to my data?

Private DataItems

Private ANS-104 Dataitems are possible today through the introduction of private buckets along load_acc gated JWT tokens. Before private dataitems, all of Load S3 dataitems were public, and stored according to the `offchain-dataitems` data protocol. However, as of today, any LCP user can:

• Create a private bucket and select which LCP users (load_acc api keys) can access the bucket’s objects

• Upload data to the private bucket and have it stored as ANS-104 Dataitems

• Generate expirable pre-signed URLs for the private data sharing

• Control the access to the private bucket’s dataitems by adding/removing load_acc API keys

Therefore, LCP & Load S3 users can now store DataItems privately in their private S3 buckets and control the access to the s3 objects, with zero cryptography (encryption/decryption) overhead to keep the data private as if it was pushed to Arweave. Access to Load S3 dataitems can be controlled via signed auto-expiring sharing URLs, or by making the data permanently public on Arweave via Load’s Turbo integration.

Access Control

As mentioned above, LCP V2 allows its users to control the access over the privately stored offchain DataItems. The access is gated by the uploader’s master load_acc api key - in the next patch release, we will allow the users to add other LCP users via their registered email address.

With this upgrade, private offchain ANS-104 DataItems are now the first-class data format for S3 objects in Load S3’s LCP.

[email protected] HyperBEAM device upgrades

In order to make the private offchain DataItems accessible to their rightful whitelisted users, we had to upgrade the HyperBEAM device’s sidecar and make it possible to:

• Generate presigned URLs (JWT-gated) for private dataitems given private bucket name, dataitem s3 key, a user’s load_acc and expiry timestamp. The device then generates a presigned URL, by validating the requester’s correct ownership of the bucket and the dataitem.

• Data streaming of the private dataitem’s data field directly from the S3 cluster, without deserializing the ANS-104 dataitem, to the user’s browser, after JWT validation.

These features have been released under s3_nif v0.3.1 which are live under s3-node-1.load.network. To check the s3 device sidecar’s upgrades, visit the source code .

load-s3-agent v4

The Load S3 HTTP API and ANS-104 data orchestrator is now in v4 with several necessary features for the functionality of the LCP backend, and Load S3 clients. One of the most tangent features to this blog post, in the agent’s v4 release, is the /upload/private HTTP POST method that lets LCP users to programmatically push raw data to their LCP’s private bucket, auth’d with the load_acc API keys, and with the final data format as ANS-104 dataitem, that’s prepared and signed by the agent’s wallet.

For more examples, check out the

Start Using LCP Today

Today you can use the LCP platform to create buckets, folders and temporarily store data privately in object-storage format. The LCP uses Load's S3 HyperBEAM data storage layer for hotcache storage.

Links

EigenDA proxy: repository

About EigenDA Side Server Proxy

LN-EigenDA wraps the , exposing endpoints for interacting with the EigenDA disperser in conformance to the , and adding disperser verification logic. This simplifies integrating EigenDA into various rollup frameworks by minimizing the footprint of changes needed within their respective services.

About LN-EigenDA Side Server Proxy Integration

It's a Load Network integration as a secondary backend of eigenda-proxy. In this scope, Load Network provides an EVM gateway/interface for EigenDA blobs on Arweave's Permaweb, removing the need for trust assumptions and relying on centralized third party services to sync historical data and provides a "pay once, save forever" data storage feature for EigenDA blobs.

Key Details

• Current maximum encoded blob size is 8 MiB (8_388_608 bytes).

• Load Network currently operating in public testnet (Alphanet) - not recommended to use it in production environment.

Prerequisites and Resources

1. Review the configuration parameters table and .env file settings for the Holesky network.

2. Obtain test tLOAD tokens through our for testing purposes.

3. Monitor your transactions using the

Usage Examples

Please double check .env file values you start eigenda-proxy binary with env vars. They may conflict with flags.

Start eigenda proxy with LN private key:

POST command:

GET command:

Examples using Web3signer as a remote signer

Web3 signer

is a tool by Consensys which allows remote signing.

Warnings

Using a remote signer comes with risks, please read the web3signer docs. However this is a recommended way to sign transactions for enterprise users and production environments. Web3Signer is not maintained by Load Network team. Example of the most simple local web3signer deployment (for testing purposes):

start eigenda proxy with signer:

start web3signer tls:

About

This ExEx is an Extract-Transform-Load (ETL) process of the JSON-serialized blocks into Google BigQuery.

Get the ExEx code

About 0xbabe2 Transaction Format

0xbabe2 is the newest data transaction format from the Bundler data protocol. Also called "Large Bundle," it's a bundle under version 0xbabe2 (address: 0xbabe2dCAf248F2F1214dF2a471D77bC849a2Ce84) that exceeds the Load Network L1 and 0xbabe1 transaction input size limits, introducing incredibly high size efficiency to data storage on Load Network.

For example, with Alphanet v0.4.0 metrics running at 500 mgas/s, a Large Bundle has a max size of 246 GB. However, to ensure a smooth DevX and optimal finalization period (aka "safe mode"), we have limited the 0xbabe2 transaction input limit to 2GB at the Bundler SDK level. If you want higher limits, you can achieve this by changing a simple constant!

Architecture design TLDR

In simple terms, a Large Bundle consists of n smaller chunks (standalone bundles) that are sequentially connected tail-to-head and then at the end the Large Bundle is a reference to all the sequentially related chunks, packing all of the chunks IDs in a single 0xbabe2 bundle and sending it to Load Network.

To dive deeper into the architecture design behind 0xbabe2 and how it works, check out the 0xbabe2 section in the .

0xbabe2 Broadcasting

Broadcasting an 0xbabe2 to Load Network can be done via the Bundler Rust SDK through 2 ways: the normal 0xbabe2 broadcasting (single-wallet single-threaded) or through the multi-wallet multi-threaded method (using SuperAccount).

Single-Threaded Broadcasting

Uploading data via the single-threaded method is efficient when the data isn't very large; otherwise, it would have very high latency to finish all data chunking then bundle finalization:

Multi-Threaded Broadcasting

Multi-Threaded 0xbabe2 broadcasting is done via a multi-wallet architecture that ensures parallel chunks settlement on Load Network, maximizing the usage of the network's data throughput. To broadcast a bundle using the multi-threaded method, you need to initiate a SuperAccount instance and fund the Chunkers:

A Super Account is a set of wallets created and stored as keystore wallets locally under your chosen directory. In Bundler terminology, each wallet is called a "chunker". Chunkers optimize the DevX of uploading Large Bundle's chunks to LN by allocating each chunk to a chunker (~4MB per chunker), moving from a single-wallet single-threaded design in data uploads to a multi-wallet multi-threaded design.

0xbabe2 Data Retrieval

0xbabe2 transaction data retrieval can be done either using the Rust SDK or the REST API. Using the REST API to resolve (chunk reconstruction until reaching final data) is faster for user usage as it does chunks streaming, resulting in near-instant data usability (e.g., rendering in browser).

Rust SDK

REST API

What you can fit in a 492GB 0xbabe2 transaction

Modern LLMs

Blockchain Data

Media Files

Other Data

Alphanet V5

• RPC URL: https://alphanet.load.network

• Chain ID: 9496

• Alphanet Faucet:

• Testnet Currency Symbol: tLOAD

• Explorer:

• Chainlist:

Add to MetaMask

Click on Networks > Add a network > Add a network manually

About

The is the first -compliant, offchain, s3-based, on HyperBEAM upload service. With this new upload service, Turbo and the broader Arweave ecosystem users can start using temporary storage directly via the official Turbo SDK: a simple -one line- endpoint change.

Thanks to the Turbo SDK’s clear open standards, it was possible to develop a layer on top Load S3 that acts as a upload service that inherits the storage features of Load S3, while maintaining interoperability and integrity with Arweave’s ANS-104 data standard. Load’s upload service inherits the offered by the Load S3 client.

What Are Precompiled Contracts?

Ethereum uses precompiles to efficiently implement cryptographic primitives within the EVM instead of re-implementing these primitives in Solidity.

The following precompiles are currently included: ecrecover, sha256, blake2f, ripemd-160, Bn256Add, Bn256Mul, Bn256Pairing, the identity function, modular exponentiation, and point evaluation.

Ethereum precompiles behave like smart contracts built into the Ethereum protocol. The ten precompiles live in addresses 0x01 to 0x0A. Load Network supports all of these 10 standard precompiles and adds new custom precompiles starting at the 23rd byte representing the letter "W" position (index) in the alphabet. Therefore, Load Network precompiles start at address 0x17 (23rd byte).

Load Network Precompiles List

Outlining Load Network New Precompiles

1- Precompile 0x17: upload data from Solidity to Arweave

The LN Precompile at address 0x17 (0x0000000000000000000000000000000000000017) enables data upload (in byte format) from Solidity to Arweave, and returns the data TXID (in byte format). In Alphanet V4, data uploads are limited to 100KB. Future network updates will remove this limitation and introduce a higher data cap.

Solidity code example:

2- Precompile 0x18: read Arweave data from Solidity

This precompile, at address 0x18 (0x0000000000000000000000000000000000000018), completes the data pipeline between LN and Arweave, making it bidirectional. It enables retrieving data from Arweave in bytes for a given Arweave TXID.

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

Solidity code example:

3- Precompile 0x20: Access to LN' historical blocks

This precompile, at address 0x20(0x0000000000000000000000000000000000000020), lets smart contract developers not access only the most recent 256 blocks, but any block data starting at genesis. To explain how to request block data using the 0x20 precompile, here is a code example:

As you can see, for the query variable we have three “parameters” separated by a semicolon ”;” (gateway;load_block_id;block_field format)

• An Arweave gateway (optional and fallback to arweave.net if not provided):

• Load Network's block number to fetch, target block: 141550

• The field of the block struct to access, in this case: hash

Only the gateway is an optional parameter, and regarding the field of the block struct to access, here is the Block struct that the 0x20 precompile uses:

4- Precompile 0x21: Native access to archived Ethereum blobs

This precompile, at address 0x21 (0x0000000000000000000000000000000000000021), is a unique solution for native access to blobs data (not just commitments) from the smart contract layer. This precompile fetches from the the blobs data that KYVE archives for their supported networks.

Therefore, with 0x21, KYVE clients will have, for the first time, the ability to fetch their archived blobs from an EVM smart contract layer instead of wrapping the Trustless API in oracles and making expensive calls.

0x21 lets you fetch KYVE's Ethereum blob data starting at Ethereum's block - the first block with a recorded EIP-4844 transaction. To retrieve a blob from the Trustless API, in the 0x21 staticcall you need to specify the Ethereum block number, blob index in the transaction, and the blob field you want to retrieve, in this format: block_number;blob_index.field N.B: blob_index represents the blob index in the KYVE’s Trustless API JSON response:

The eip-4844 transaction fields that you can access from the 0x21 query are:

• blob (raw blob data, the body)

• kzg_commitment

• kzg_proof

• slot

Advantages of 0x21 (use cases)

• Native access to blob data from smart contract layer

• Access to permanently archived blobs

• Opens up longer verification windows for rollups using KYVE for archived blobs and LN for settlement layer

• Enables using blobs for purposes beyond rollups DA, opening doors for data-intensive blob-based applications with permanent blob access

Check out the 0x21 precompile source code .

Since and launch, we advise using them instead of EVM Bundler for several reasons:

• Arweave's ANS-104 compatibility

• S3 object-storage compatibility

• Highly-scalable, cost-efficient temporary storage

About

s3-load-agent is a data agent built on top of HyperBEAM [email protected] temporal data storage device. This agent orchestrates the location of the data moving it from temporal to permanent (Arweave).

N.B: beta testing release, unstable and subject to breaking changes, use in testing enviroments only.

Agent API

• GET / : agent info

• GET /stats : storage stats

• GET /:dataitem_id : generate a presigned get_object URL to access the ANS-104 DataItem data - DEPRECATED since v0.7.0 - use gateway.s3-node-1.load.network/resolve/$DATAITEM_ID instead

Upload data and return an agent public signed DataItem

Or optionally add custom tags KVs that will be included in the ANS-104 DataItem construction

Optional: have the agent publish an offchain provenance record for the uploaded DataItem (the API returns the provenance transaction id in offchain_provenance_proof):

• onchain provenance example: https://viewblock.io/arweave/tx/b6kTeJISHCmKTqaq_GK5g6hCGPWmMgfR7W4FcJwBwGU

• offchain dataitem: https://gateway.s3-node-1.load.network/resolve/qvnTWVz4QqVAa7DsiiPER3HMArN88clg_SZc1BIS63s

Upload data and return an agent private signed DataItem

*** N.B: any private DataItem does not have the tags indexed nor is queryable ***

Upload signed dataitem to a private bucket (private dataitem)

Upload a signed DataItem and store it in Load S3

Tags are extracted from the ANS-104 DataItem, indexed and queryable

Post offchain DataItem to Arweave

example: for offchain dataitem = eoNAO-HlYasHJt3QFDuRrMVdLUxq5B8bXe4N_kboNWs

Querying DataItems by Tags

all dataitems pushed after agent's v0.6.0 release are queryable by the dataitem's tags KVs:

• Pagination follows Arweave's GQL schema: optional first (default 25, max 100) and a cursor after.

• full_metadata flag (Optional<bool>) to return the full tags associated with a query's dataitem

• created_after /

if page_info.has_next_page returns true, reuse the page_info.next_cursor string as the next after.

count reflects the number of items returned in the current page, while total_count includes every dataitem that matches the filters across all pages.

Load S3 Agent library

Adding load-s3-agent library

Example

Setup

1- add s3_device.config

in the root level of the hyperbeam codebase, touch s3_device.config and add the creds to connect to your S3 cluster

connecting to external s3 cluster (./build.sh)

connecting to local minio s3 cluster (./s3_device.sh)

build and run the hyperbeam node

configurting the local minio cluster

if you choose the local minio cluster route, you can configure (set) your access key id and secret access key by creating .env file here:

N.B: your local minio cluster access keys values should be also set equally in the s3_device.config config file

Supported methods

Use the [email protected] device

After running the hyperbeam node with the [email protected] device, you can use the node_endpoint/[email protected] url as a S3 compatible API endpoint.

N.B (regarding access authorization): using the [email protected] as end user (client) you only have to pass the accessKeyId in the request's credentials, and secretAccessKey value doesn't matter. This is due to the design of [email protected] access authorization where the device check's the S3 request's access_key_id of Authorization Header, and validate its parity with the access_key_id defined in s3_device.config -> Keep the access_key_id secret and use it as access API key.

1- create s3 client

2- create bucket

3- get object (with range)

4- put object (with expiry)

5- Generate presigned get_object url

The returned URL uses the preset public_endpoint (in s3_device.config) as base url.

Cache layer

The NIF implements an LRU cache with size-based eviction (in-memory). The following cache endpoints are available under the hyperbeam http api (intentionally not compatible with the S3 API spec):

1- get cached object

Note: This endpoint requires no authentication

cache vs S3 API GetObjectCommand : curl "http://localhost:8734/[email protected]/BUCKET_NAME/OBJECT_KEY"

Hybrid gateway

The hybdrid gateway is an extension to the hb_gateway_client.erl that makes it possible for the hyperbeam node to retrieve both of onchain (Arweave) posted ANS-104 dataitems, and offchain (in dev_s3.erl) object-storage temporal dataitems.

Workflow

• hb_store_gateway.erl -> calls hb_gateway_client:read() -> it tries to read from local cache then Arweave (onchain dataitem) -> incase not found onchain, check the offchain dataitems s3 bucket

• offchain dataitems retrieval route : hb_gateway_s3:read() -> calls dev_s3:handle_s3_request() -> retrieve the dataitem.asn104 from the dev_s3 bucket

Test it

1- create & set the offchain bucket

Make hyperbeam aware of the dev_s3 bucket that is storing your ANS-104 offchain dataiems, here (s3_bucket in default_message)

2- add test data

Make sure to create the [email protected] bucket as you defined the name in hb_opts.erl then add a fake offchain dataitem. If you want to test using existing signed offchain ans-104 dataitems, checkout the test-dataitems directory and store it in your [email protected] bucket.

Otherwise, you can generate a signed valid ANS-104 dataitem using the hyperbeam erlang shell:

3- test retrieving dataitems

• offchain: http://localhost:8734/ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA

• onchain: http://localhost:8734/myb2p8_TSM0KSgBMoG-nu6TLuqWwPmdZM5V2QSUeNmM

Verify dataitem integrity

Expected Response:

For more examples & ao processes interactions, check the directory

Source code:

About

A Rust SDK for creating, signing, managing and posting ANS-104 dataitems.

Warning: this repository is actively under development and could have breaking changes until reaching full API compatibility in v1.0.0.

Installation

Add to your Cargo.toml:

Dev setup

Supported Signers

Regarding Tags

This ANS-104 dataitems client fully implements the ANS-104 specification as-is

Usage Examples

Quick start

Or for basic signed dataitem

Working with signers

N.B: use random signer generation for testing purposes only

Arweave Signer

Ethereum Signer

Solana Signer

Ed25519Core Signer

Verification

Manual

With Signer

Deep hash

Upload to Bundling services over HTTP (e.g. )

bundler crate

bundler crate is Rust SDK to interact with Arweave (ANS-104) bundling services. This crate is designed to be backward compatible with existing bundling services and fine tuned for

Installation

Imports

Usage Example

Send Transaction (Solana)

Send Transaction (Turbo)

Get Default Client Info

Get Turbo Client Info

Get Price for Bytes (Turbo)

Get Rates (Turbo)

Check Transaction Status (Turbo)

Turbo API References:

• upload api: https://upload.ardrive.io/api-docs

• payment api: https://payment.ardrive.io/api-docs

SDK source code: