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.

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 V2 (formerly WeaveVM V2) has raised the gas limit to 500M gas (doing 500 mg/s), and lowered 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 the approach of beefy block production by super nodes and hardware acceleration.

High-Throughput DA

Up until now, there's been no real-world, scalable DA layer ready to handle high data throughput with permanent storage. In LOAD Alphanet V2, we've already reached 62 MBps with a projection to hit 125 MBps in mainnet.

Parallel Execution

To reduce the gas fees consumed by EVM opcode execution, we're aiming to use a parallel execution EVM client for the Reth node in mainnet.

EVM interface for Arweave Data: Permanent History

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 for data settling (LOADing).

And we can see that Borsh serialization combined with Brotli compression gives us the most efficient compression ratio in the data serialization-compression process.

Cost Efficient Data Settling

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

Load is L0 for EVM L1s/L2s

Load Network can be used as either a DA solution or for data settlement (like Ethereum). Since storing data on Load Network is very cheap compared to other EVM solutions, the network can be labeled as an L0 for other L1s or L2s.

Bidirectional data pipeline with Arweave

What is Load Network?

Decentralized Full Data Storage Stack

Load Network mainnet is being built to be the highest performing EVM blockchain focusing on data storage, having the largest baselayer transaction input size limit (~16MB), the largest ever EVM transaction (~0.5TB 0xbabe transaction), very high network data throughput (multi-gigagas per second), high TPS, decentralization, full data storage stack offering (permanent and temporal), decentralized data gateways and data bundlers.

Load Network achieves high decentralization by using Arweave as decentralized hard drive, hyperbeam as decentralized cloud stack & extended consensus, and allowing network participation (nodes) . Load Network will offer both of permanent data storage and temporal data storage while maintaining decentralized and censorship-resistant data retrieval & ingress (gateways, bundling services, etc).

Use Cases and How to Integrate

Ledger Data Storage

High-Throughput Data Availability (DA)

Storage Heavy dApps

Load Network offers scalable and cost-effective storage by using Arweave as a decentralized hard drive, and hyperbeam as a decentralized cloud. This makes it possible to store large data sets and run web2-like applications without incurring EVM storage fees.

Foundational Layer (L1) For Rollups

Load Network is an EVM compatible blockchain, therefore, rollups can be deployed on LN as same as the rollups state on Ethereum. In contrast to Ethereum or other EVM L1s, rollups deployed on top of LN benefit out-of-the-box from the data-centric features provided by LN (for rollup data settlement and DA).

Rollups deployed on Load Network use the native LN gas token (tLOAD on Alphanet), similar to how ETH is used for OP rollups on Ethereum.

Explore Load Network Ecosystem Dapps (Evolving)

Useful Links

Abstract

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

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.

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.

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:

Upload data

The easiest way to upload data to Load Network is to use a bundling service. Bundling services cover upload costs on your behalf, and feel just like using a web2 API.

The recommended testnet bundling service endpoints are:

API_KEY=d025e132382aea412f4256049c13d0e92d5c64095d1c88e1f5de7652966b69af

Full upload example

import { BundlerSDK } from 'bundler-upload-sdk';
import { readFile } from 'fs/promises';
import 'dotenv/config';

const bundler = new BundlerSDK('https://upload.onchain.rs/', process.env.API_KEY);

async function main() {
  try {
    const fileBuffer = await readFile('files/hearts.gif');
    const txHash = await bundler.upload([
      {
        file: fileBuffer,
        tags: {
          'content-type': 'image/gif',
        }
      }
    ]);
    console.log(`https://resolver.bot/bundle/${txHash}/0`);
  } catch (error) {
    console.error('Upload failed:', error.message);
    process.exit(1);
  }
}

main().catch(error => {
  console.error('Unhandled error:', error);
  process.exit(1);
});

Need to upload a huge amount of data?

The above example demonstrates posting data in a single Load Network base layer tx. This is limited by Load's blocksize, so tops out at about 8mb.

For practically unlimited upload sizes, you can use the large bundles spec to submit data in chunks. Chunks can even be uploaded in parallel, making large bundles a performant way to handle big uploads.

Integrating ledger storage

Chains like Avalanche, Metis and RSS3 use Load Network as a decentralized archive node. This works by feeding all new and historical blocks to an archiving service you can run yourself, pointed to your network's RPC.

Using Load DA

With 125mb/s data throughput and long-term data guarantees, Load Network can handle DA for every known L2, with 99.8% room to spare.

Right now there are 4 ways you can integrate Load Network for DA:

4. DIY

Migrate from another storage layer

If your data is already on another storage layer like IPFS, Filecoin, Swarm or AWS S3, you can use specialized importer tools to migrate.

AWS S3

Filecoin / IPFS

The load-lassie import tool is the recommended way to easily migrate data stored via Filecoin or IPFS.

Just provide the CID you want to import to the API, e.g.:

https://lassie.load.rs/import/<CID>

Swarm

Switching from Swarm to Load is as simple as changing the gateway you already use to resolve content from Swarm.

The first time Load's Swarm gateway sees a new hash, it uploads it to Load Network and serves it directly for subsequent calls. This effectively makes your Swarm data permanent on Load while maintaining the same hash.

About 0xbabe2 Transaction Format

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.

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:

use bundler::utils::core::large_bundle::LargeBundle;

async fn send_large_bundle_single_thread() -> Result<String, Error> {
    let private_key = String::from("");
    let content_type = "text/plain".to_string();
    let data = "~UwU~".repeat(4_000_000).as_bytes().to_vec();
    let large_bundle = LargeBundle::new()
        .data(data)
        .private_key(private_key)
        .content_type(content_type)
        .chunk()
        .build()?
        .propagate_chunks()
        .await?
        .finalize()
        .await?;
    Ok(large_bundle_hash)
}

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:

use bundler::utils::core::super_account::SuperAccount;
// init SuperAccount instance
let super_account = SuperAccount::new()
    .keystore_path(".bundler_keystores".to_string())
    .pwd("weak-password".to_string()) // keystore pwd
    .funder("private-key".to_string()) // the pk that will fund the chunkers
    .build();
// create chunkers
let _chunkers = super_account.create_chunkers(Some(256)).await.unwrap(); // Some(amount) of chunkers
// fund chunkers (1 tWVM each)
let _fund = super_account.fund_chunkers().await.unwrap(); // will fund each chunker by 1 tWVM
// retrieve chunkers
let loaded_chunkers = super_account.load_chunkers(None).await.unwrap(); // None to load all 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.

async fn send_large_bundle_multi_thread() -> Result<String, Error> {
    // will fail until a tLOAD funded EOA (pk) is provided, take care about nonce if same wallet is used as in test_send_bundle_with_target
    let private_key =
        String::from("6f142508b4eea641e33cb2a0161221105086a84584c74245ca463a49effea30b");
    let content_type = "text/plain".to_string();
    let data = "~UwU~".repeat(8_000_000).as_bytes().to_vec();
    let super_account = SuperAccount::new()
        .keystore_path(".bundler_keystores".to_string())
        .pwd("test".to_string());
    let large_bundle = LargeBundle::new()
        .data(data)
        .private_key(private_key)
        .content_type(content_type)
        .super_account(super_account)
        .chunk()
        .build()
        .unwrap()
        .super_propagate_chunks()
        .await
        .unwrap()
        .finalize()
        .await
        .unwrap();
    println!("{:?}", large_bundle);
    Ok(large_bundle)
}

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

async fn retrieve_large_bundle() -> Result<Vec<u8>, Error> {
    let large_bundle = LargeBundle::retrieve_chunks_receipts(
        "0xb58684c24828f8a80205345897afa7aba478c23005e128e4cda037de6b9ca6fd".to_string(),
    )
    .await?
    .reconstruct_large_bundle()
    .await?;
    Ok(large_bundle)
}

REST API

curl -X GET https://bundler.load.rs/v2/resolve/$0xBABE2_TXID

What you can fit in a 492GB 0xbabe2 transaction

Modern LLMs

Blockchain Data

Media Files

Other Data

Alphanet V5

• Chain ID: 9496

• Testnet Currency Symbol: tLOAD

Add to MetaMask

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

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.

curl https://alphanet.load.network \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "eth_getWvmTransactionByTag",
    "params": [{
        "tag": ["name", "value"]
    }]
  }'

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:

pragma solidity ^0.8.0;

contract ArweaveUploader {
    function upload_to_arweave(string memory dataString) public view returns (bytes memory) {
        // Convert the string parameter to bytes
        bytes memory data = abi.encodePacked(dataString);

        // pc address: 0x0000000000000000000000000000000000000017
        (bool success, bytes memory result) = address(0x17).staticcall(data);

        return result;
    }

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:

pragma solidity ^0.8.0;

contract ArweaveReader {
    function read_from_arweave(string memory txIdOrGatewayAndTxId) public view returns (bytes memory) {
        // Convert the string parameter to bytes
        bytes memory data = abi.encodePacked(txIdOrGatewayAndTxId);

        // pc address: 0x0000000000000000000000000000000000000018
        (bool success, bytes memory result) = address(0x18).staticcall(data);

        return result;
    }
}

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:

pragma solidity ^0.8.0;

contract LnBlockReader {
    function read_block() public view returns (bytes memory) {
        // Convert the string parameter to bytes
        string memory blockIdAndField = "141550;hash";
        bytes memory data = abi.encodePacked(blockIdAndField);

        (bool success, bytes memory result) = address(0x20).staticcall(data);

        return result;
    }
}

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

• 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:

#[serde(rename_all = "camelCase")]
pub struct Block {
    pub base_fee_per_gas: Option<String>,         // "baseFeePerGas"
    pub blob_gas_used: Option<String>,            // "blobGasUsed"
    pub difficulty: Option<String>,               // "difficulty"
    pub excess_blob_gas: Option<String>,          // "excessBlobGas"
    pub extra_data: Option<String>,               // "extraData"
    pub gas_limit: Option<String>,                // "gasLimit"
    pub gas_used: Option<String>,                 // "gasUsed"
    pub hash: Option<String>,                     // "hash"
    pub logs_bloom: Option<String>,               // "logsBloom"
    pub miner: Option<String>,                    // "miner"
    pub mix_hash: Option<String>,                 // "mixHash"
    pub nonce: Option<String>,                    // "nonce"
    pub number: Option<String>,                   // "number"
    pub parent_beacon_block_root: Option<String>, // "parentBeaconBlockRoot"
    pub parent_hash: Option<String>,              // "parentHash"
    pub receipts_root: Option<String>,            // "receiptsRoot"
    pub seal_fields: Vec<String>,                 // "sealFields" as an array of strings
    pub sha3_uncles: Option<String>,              // "sha3Uncles"
    pub size: Option<String>,                     // "size"
    pub state_root: Option<String>,               // "stateRoot"
    pub timestamp: Option<String>,                // "timestamp"
    pub total_difficulty: Option<String>,         // "totalDifficulty"
    pub transactions: Vec<String>,                // "transactions" as an array of strings
}

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

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.

pragma solidity ^0.8.0;

contract KyveBlobsTrustlessApi {
    function getBlob
() public view returns (bytes memory) {
        // Convert the string parameter to bytes
        string memory query = "20033081;0.blob";
        bytes memory data = abi.encodePacked(query);

        (bool success, bytes memory result) = address(0x21).staticcall(data);

        return result;
    }
}

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

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:

Alphanet V0.5.3

• gas per non-zero byte: 8

• gas limit: 500_000_000

• block time: 1s

• gas/s: 500 mg/s

• data throughput: ~62 MBps

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:

curl -X GET https://gateway.load.network/calldata/$LN_TXID

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.

curl -X GET https://gateway.load.network/war-calldata/$LN_TXID

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.

About

Bundler as data protocol and library is still in PoC (Proof of Concept) phase - not recommended for production usage, testing purposes only.

Advantages of Load Network bundled transactions

• Reduces transaction overhead fees from multiple fees (n) per n transaction to a single fee per bundle of envelopes (n transactions)

• Enables third-party services to handle bundle settlement on LN (will be decentralized with LOAD1)

• Maximizes the TPS capacity of LN without requiring additional protocol changes or constraints

• Supports relational data grouping by combining multiple related transactions into a single bundle

Protocol Specification

Nomenclature

• Bundler: Refers to the data protocol specification of the EVM bundled transactions on Load Network.

• Envelope: A legacy EVM transaction that serves as the fundamental building block and composition unit of a Bundle.

• Bundle: An EIP-1559 transaction that groups multiple envelopes (n > 0), enabling efficient transaction batching and processing.

• Large Bundle: A transaction that carries multiple bundles.

• Bundler Lib: Refers to the Bundler Rust library that facilitates composing and propagating Bundler's bundles.

1. Bundle Format

A bundle is a group of envelopes organized through the following process:

1. Envelopes MUST be grouped in a vector

2. The bundle is Borsh serialized according to the BundleData type

3. The resulting serialization vector is compressed using Brotli compression

4. The Borsh-Brotli serialized-compressed vector is added as input (calldata) to an EIP-1559 transaction

5. The resulting bundle is broadcasted on Load Network with target set to 0xbabe addresses based on bundle version.

pub struct BundleData {
    pub envelopes: Vec<TxEnvelopeWrapper>,
}

Bundles Versioning

Bundles versioning is based on the bundles target address:

2. Envelope Format

An envelope is a signed Legacy EVM transaction with the following MUSTs and restrictions.

pub struct Tag {
    pub name: String,
    pub value: String,
}

pub struct EnvelopeSignature {
    pub y_parity: bool,
    pub r: String,
    pub s: String,
}

pub struct TxEnvelopeWrapper {
    pub chain_id: u64,
    pub nonce: u64,
    pub gas_price: u128,
    pub gas_limit: u64,
    pub to: String,
    pub value: String,
    pub input: String,
    pub hash: String,
    pub signature: EnvelopeSignature,
    pub tags: Option<Vec<Tag>>,
}

1. Transaction Fields

   • nonce: MUST be 0

   • gas_limit: MUST be 0

   • gas_price: MUST be 0

   • value: MUST be 0

2. Size Restrictions

   • Total Borsh-Brotli compressed envelopes (Bundle data) MUST be under 9 MB

   • Total Tags bytes size must be <= 2048 bytes before compression.

3. Signature Requirements

   • each envelope MUST have a valid signature

4. Usage Constraints

   • MUST be used strictly for data settling on Load Network

   • MUST only contain envelope's calldata, with optional target setting (default fallback to ZERO address)

   • CANNOT be used for:

     • tLOAD transfers

     • Contract interactions

     • Any purpose other than data settling

3. Transaction Type Choice

The selection of transaction types follows clear efficiency principles. Legacy transactions were chosen for envelopes due to their minimal size (144 bytes), making them the most space-efficient option for data storage. EIP-1559 transactions were adopted for bundles as the widely accepted standard for transaction processing.

4. Notes

• Envelopes exist as signed Legacy transactions within bundles but operate under distinct processing rules - they are not individually processed by the Load Network as transactions, despite having the structure of a Legacy transaction (signed data with a Transaction type). Instead, they are bundled together and processed as a single onchain transaction (therefore the advantage of Bundler).

• Multiple instances of the same envelope within a bundle are permissible and do not invalidate either the bundle or the envelopes themselves. These duplicate instances are treated as copies sharing the same timestamp when found in a single bundle. When appearing across different bundles, they are considered distinct instances with their respective bundle timestamps (valid envelopes and considered as copies of distinct timestamps).

• Since envelopes are implemented as signed Legacy transactions, they are strictly reserved for data settling purposes. Their use for any other purpose is explicitly prohibited for the envelope's signer security.

Large Bundle

About

SuperAccount

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 LB chunks to LN by splitting 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.

use bundler::utils::core::super_account::SuperAccount;
// init SuperAccount instance
let super_account = SuperAccount::new()
    .keystore_path(".bundler_keystores".to_string())
    .pwd("weak-password".to_string()) // keystore pwd
    .funder("private-key".to_string()) // the pk that will fund the chunkers
    .build();
// create chunkers
let _chunkers = super_account.create_chunkers(Some(256)).await.unwrap(); // Some(amount) of chunkers
// fund chunkers (1 tWVM each)
let _fund = super_account.fund_chunkers().await.unwrap(); // will fund each chunker by 1 tWVM
// retrieve chunkers
let loaded_chunkers = super_account.load_chunkers(None).await.unwrap(); // None to load all chunkers

Architecture design

Large Bundles are built on top of the Bundler data specification. 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.

Large Bundle Size Calculation

Determining Number of Chunks

To store a file of size S (in MB) with a chunk size C, the number of chunks (N) is calculated as:

N = ⌊S/C⌋ + [(S mod C) > 0]

Special case: if S < C then N = 1

Maximum Theoretical Size

The bundling actor collects all hash receipts of the chunks, orders them in a list, and uploads this list as a LN L1 transaction. The size components of a Large Bundle are:

• 2 Brackets [ ] = 2 bytes

• EVM transaction header without "0x" prefix = 64 bytes per hash

• 2 bytes for comma and space (one less comma at the end, so subtract 2 from total)

• Size per chunk's hash = 68 bytes

Therefore: Total hashes size = 2 + (N × 68) - 2 = 68N bytes

Maximum Capacity Calculation

• Maximum L1 transaction input size (C_tx) = 4 MB = 4_194_304 bytes

• Maximum number of chunks (Σn) = C_tx ÷ 68 = 4_194_304 ÷ 68 = 61_680 chunks

• Maximum theoretical Large Bundle size (C_max) = Σn × C_tx = 61_680 × 4 MB = 246,720 MB ≈ 246.72 GB

Load Network Bundles Limitation

Bundler Library

Import Bundler in your project

bundler = { git = "https://github.com/weaveVM/bundler", branch = "main" }

0xbabe1 Bundles

Build an envelope, build a bundle

use bundler::utils::core::envelope::Envelope;
use bundler::utils::core::bundle::Bundle;
use bundler::utils::core::tags::Tag;


// Envelope
let envelope = Envelope::new()
    .data(byte_vec)
    .target(address)
    .tags(tags)
    .build()?;

// Bundle
let bundle_tx = Bundle::new()
    .private_key(private_key)
    .envelopes(envelopes)
    .build()
    .propagate()
    .await?;

Example: Build a bundle packed with envelopes

async fn send_bundle_without_target() -> eyre::Result<String> {
    // will fail until a tLOAD funded EOA (pk) is provided
    let private_key = String::from("");
    
    let mut envelopes: Vec<Envelope> = vec![];
    
    for _ in 0..10 {
        let random_calldata: String = generate_random_calldata(128_000); // 128 KB of random calldata
        let envelope_data = serde_json::to_vec(&random_calldata).unwrap();
        
        let envelope = Envelope::new()
            .data(Some(envelope_data))
            .target(None)
            .build()?;
            
        envelopes.push(envelope);
    }
    
    let bundle_tx = Bundle::new()
        .private_key(private_key)
        .envelopes(envelopes)
        .build()
        .propagate()
        .await?;
        
    Ok(bundle_tx)
}

Example: Send tagged envelopes

    async fn send_envelope_with_tags() -> eyre::Result<String> {
        // will fail until a tLOAD funded EOA (pk) is provided
        let private_key = String::from("");

        let mut envelopes: Vec<Envelope> = vec![];
        
        // add your tags to a vector
        let tags = vec![Tag::new(
            "Content-Type".to_string(),
            "text/plain".to_string(),
        )];

        for _ in 0..1 {
            let random_calldata: String = generate_random_calldata(128_000); // 128 KB of random calldata
            let envelope_data = serde_json::to_vec(&random_calldata).unwrap();
            let envelope = Envelope::new()
                .data(Some(envelope_data))
                .target(None)
                .tags(Some(tags.clone())) // add your tags
                .build()
                .unwrap();
            envelopes.push(envelope);
        }

        let bundle_tx = Bundle::new()
            .private_key(private_key)
            .envelopes(envelopes)
            .build()
            .expect("REASON")
            .propagate()
            .await
            .unwrap();
        
        Ok(bundle_tx)
    }

0xbabe2 Large Bundle

Example: construct and disperse a Large Bundle single-threaded

use bundler::utils::core::large_bundle::LargeBundle;

    async fn send_large_bundle_without_super_account() -> eyre::Result<String> {
        let private_key = String::from("");
        let content_type = "text/plain".to_string();
        let data = "~UwU~".repeat(4_000_000).as_bytes().to_vec();

        let large_bundle = LargeBundle::new()
            .data(data)
            .private_key(private_key)
            .content_type(content_type)
            .chunk()
            .build()?
            .propagate_chunks()
            .await?
            .finalize()
            .await?;

        Ok(large_bundle_hash)
    }

Example: construct and disperse a Large Bundle multi-threaded

    async fn send_large_bundle_with_super_account() {
        // will fail until a tLOAD funded EOA (pk) is provided, take care about nonce if same wallet is used as in test_send_bundle_with_target
        let private_key = String::from("");
        let content_type = "text/plain".to_string();
        let data = "~UwU~".repeat(8_000_000).as_bytes().to_vec();
        let super_account = SuperAccount::new()
            .keystore_path(".bundler_keystores".to_string())
            .pwd("test".to_string());

        let large_bundle = LargeBundle::new()
            .data(data)
            .private_key(private_key)
            .content_type(content_type)
            .super_account(super_account)
            .chunk()
            .build()
            .unwrap()
            .super_propagate_chunks()
            .await
            .unwrap()
            .finalize()
            .await
            .unwrap();

        println!("{:?}", large_bundle);
    }

Example: Retrieve Large Bundle data

    async fn retrieve_large_bundle() -> eyre::Result<Vec<u8>> {
        let large_bundle = LargeBundle::retrieve_chunks_receipts(
            "0xb58684c24828f8a80205345897afa7aba478c23005e128e4cda037de6b9ca6fd".to_string(),
        )
        .await?
        .reconstruct_large_bundle()
        .await?;
        
        Ok(large_bundle)
    }

HTTP API

Retrieve full envelopes data of a given bundle

GET /v1/envelopes/:bundle_txid

Retrieve full envelopes data of a given bundle (with from's envelope property derived from sig)

GET /v1/envelopes-full/:bundle_txid

Retrieve envelopes ids of a given bundle

GET /v1/envelopes/ids/:bundle_txid

N.B: All of the /v1 methods (0xbabe1) are available under /v2 for 0xbabe2 Large Bundles.

Resolve the content of a Large Bundle (not efficient, experimental)

GET /v2/resolve/:large_bundle_txid

Cost Efficiency: some comparisons

SSTORE2 VS LN L1 calldata

SSTORE2 VS LN L1 Calldata VS LN Bundler 0xbabe1

LN L1 Calldata VS LN Bundler 0xbabe1

Table data sources

Source Code

Code Example: Retrieve Address Balance

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.

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.

Why we built the Load Network gateway stack

The gateway stack solves several critical needs in the LN ecosystem:

Rapid data retrieval

Through local caching with SQLite, the gateway dramatically reduces load times (4-5x) for frequently accessed bundled data. No more waiting for remote data fetches – popular content is served instantly from the gateway node.

Network health

By making it easy to run your own gateway, the stack promotes a more decentralized network. Each gateway instance contributes to network redundancy, ensuring data remains accessible even if some nodes go offline.

Running a Load Network gateway

Running your own LN gateway is pretty straightforward. The gateway stack is designed for easy deployment, directly to your server or inside a Docker container.

With Docker, you can have a gateway up and running in minutes:

The technical side

Under the hood, the gateway stack features:

• SQLite-backed persistent cache

  • Content-aware caching with automatic MIME type detection

  • Configurable cache sizes and retention policies

  • Application-specific cache management

  • Automatic cache cleanup based on age and size limits

  • Health monitoring and statistics

The gateway exposes a simple API for accessing bundle data:

GET /bundle/:txHash/:index

This endpoint handles the job of data retrieval, caching, and content-type detection behind the scenes.

Towards scalability & decentralization

The Load Network gateway stack was built in response to problems of scale – great problems to have as a new network gaining traction. LN bundle data is now more accessible, resilient and performant. By running a gateway, you’re not just improving your own access to LN data – you’re contributing to a more robust, decentralized network.

Test the gateways:

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.

load_hb: Load Network HyperBEAM node with custom devices

Run Locally

git clone https://github.com/weavevm/proxy-rpc.git

cd proxy-rpc

npm install && npm run start

Try it!

curl -X POST http://localhost:3000 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Run Locally

git clone https://github.com/weavevm/wvm-proxy-rpc.git

cd wvm-proxy-rpc

cargo build && cargo shuttle run --port 3000

Try it!

curl -X POST http://localhost:3000 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

About

About

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 (kem@1.0 device), KEM functions offer great flexibility to run as GPU compute sidecars alongside ao processes.

KEM Technical Architecture

fn execute_kernel(
    kernel_id: String,
    input_data: rustler::Binary,
    output_size_hint: u64,
) -> NifResult<Vec<u8>> {
    let kernel_src = retrieve_kernel_src(&kernel_id).unwrap();
    let kem = pollster::block_on(KernelExecutor::new());
    let result = kem.execute_kernel_default(&kernel_src, input_data.as_slice(), Some(output_size_hint));
    Ok(result)
}

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:

// SPDX-License-Identifier: GPL-3.0

// input as u32 array
@group(0) @binding(0)
var<storage, read> input_bytes: array<u32>;

// output as u32 array
@group(0) @binding(1)
var<storage, read_write> output_bytes: array<u32>;

// a work group of 256 threads
@compute @workgroup_size(256)
// main compute kernel entry point
fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
}

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:

// SPDX-License-Identifier: GPL-3.0

// input as u32 array
@group(0) @binding(0)
var<storage, read> input_bytes: array<u32>;

// output as u32 array
@group(0) @binding(1)
var<storage, read_write> output_bytes: array<u32>;

// uniform parameters for configuration
@group(0) @binding(2)
var<uniform> params: vec2<u32>; // example: param1, param2

// a work group of 256 threads
@compute @workgroup_size(256)
// main compute kernel entry point
fn main(@builtin(global_invocation_id) global_id: vec3<u32>) {
    // Access uniform parameters
    let param1 = i32(params.x);
    let param2 = i32(params.y);
    
    // your kernel logic here
}

Example: Image Glitcher

References

About

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

#[rustler::nif]
fn eval_bytecode(signed_raw_tx: String, state: String, cout_state_path: String) -> NifResult<String> {
    let state_option = if state.is_empty() { None } else { Some(state) };
    let evaluated_state: (String, String) = eval(signed_raw_tx, state_option, cout_state_path)?;
    Ok(evaluated_state.0)
}

#[rustler::nif]
fn get_appchain_state(chain_id: &str) -> NifResult<String> {
	let state = get_state(chain_id);
    Ok(state)
}

References

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.

The Load Network 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.

The Rationale

Since we started Load Network, we’ve had the vision of an onchain data center – a decentralized network of high performance, cost effectiveness, high-liveness, fault tolerance, low latency and fast finalization, data-centric features and availability.

Building a cloud platform, similar to Google Cloud Platform, means abstracting the robust infrastructure of the (onchain) data center into a single UI, providing a smooth – as straightforward as using Google Cloud Platform to interface with their several services, that are built on top of their robust infrastructure of data centers and what comes along it.

In today’s web3 world, too many teams relies on third-party hosted-IPFS pinning services (e.g. pinata, nft.storage), AWS S3 object storage and its alternatives (Google Cloud Bucket, etc), and other centralized data storage solutions – they are compromising the decentralization and liveness needed for permanent apps for ephemeral unsustainable short-term solutions.

Other teams are already using battle-tested web3 native solutions such as Arweave and Filecoin, however these protocols lack the unification of a single cloud platform that lets developers use them like they’d use AWS S3. This creates engineering overhead for teams to integrate with web3 native solutions, keeping web3 devs in the web2 trap. We’re solving this with the Load Cloud.

Introducing Load Network Cloud Platform: Going Onchain

As a response to the lack of web3 storage solution abstraction and interoperability with the web2 standard interfaces, we have worked on the Load Cloud, a one stop solution to use existing data storage standards, without compromising the core features of web3 data storage provided by Load Network.

About

The ~helios@1.0 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.

What is Helios?

Helios is a trustless, efficient, and portable multichain light client written in Rust.

Helios converts an untrusted centralized RPC endpoint into a safe unmanipulable local RPC for its users. It syncs in seconds, requires no storage, and is lightweight enough to run on mobile devices.

Helios has a small binary size and compiles into WebAssembly. This makes it a perfect target to embed directly inside wallets and dapps.

~helios@1.0 device

The ~helios@1.0 as per its current implementation, initiates the helios client (and JSON-RPC server) at the start of the hyperbeam node run. The JSON-RPC server is spawned as a separate process running in parallel behind the 8545 port (standard consensus rpc port).

Endpoint

Example

local

using rpc.rs

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

Networks Using LN Archiver

About

Load.Network provides an S3 implementation which enables developers to store files permanently in a decentralized manner by using the common AWS S3 Patterns with minimal change.

Installation

Load.Network is compatible with the S3 SDKs, because of this, you are able to use existing libraries.

NodeJS

To install the official S3 library in NodeJS, run the following command

Initialization

In order to initialize the S3 client connected to Load Network, you can do the following:

• • It looks similar to load_acc_*******

• forcePathStyle set to true is always necessary.

Rust Examples

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:

use evm_state_reconstructing::utils::core::evm_exec::StateReconstructor;  
use evm_state_reconstructing::utils::core::networks::Networks;  
use evm_state_reconstructing::utils::core::reconstruct::reconstruct_network;  
use anyhow::Error;

async fn reconstruct_state() -> Result<StateReconstructor, Error> {  
    let network: Networks = Networks::metis();  
    let state: StateReconstructor = reconstruct_network(network).await?;  
    Ok(state)  
}  

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

5. The final result is a complete reconstruction of the network’s World State

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.

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

curl -X POST "https://load0.network/upload" \
  --data-binary "@./video.mp4" \
  -H "Content-Type: video/mp4" \
  -H "X-Load-Authorization: $YOUR_LNCP_AUTH_TOKEN"

2- Download object (browser)

GET https://load0.network/download/{optimistic_hash}

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

GET https://load0.network/resolve/{optimistic_hash}

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

GET https://load0.network/bundle/optimistic/{op_hash}

GET https://load0.network/bundle/load/{bundle_txid}

Returns:

pub struct Bundle {
    pub id: u32,
    pub optimistic_hash: String,
    pub bundle_txid: String,
    pub data_size: u32,
    pub is_settled: bool,
    pub content_type: String
}

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}

About

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.

Integration Tutorial

First, you’ll need to add the following environment variables to your Reth instance:

The archiver_pk refers to the private key of the LN wallet, which is used to pay gas fees on the LN for data posting. The network variable points to the path of your network configuration file used for the ExEx. A typical network configuration file looks like this:

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

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

About

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

About

Add Load Network Alphanet to MetaMask

ERC20 Contract

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

/// @title Useless Testing Token
/// @notice Just a testing shitcoin
/// @dev SupLoad gmgm
/// @author pepe frog
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract WeaveGM is ERC20 {
    constructor(uint256 initialSupply) ERC20("supLoad", "LOAD") {
        _mint(msg.sender, initialSupply);
    }
}

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!

About

About

About

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

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

About

Protocol Specifications

The data protocol transactions follow the ANS-104 data item specifications. Each LN precompile transaction is posted on Arweave, after brotli compression, with the following tags:

Load Network Precompile Data Items Uploaders

Links

Key Details

• Load Network provides a gateway for Arweave's permanent with its own (LN) high data throughput of the permanently stored data into .

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

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

Prerequisites and Resources

1. Understand how to boot basic Dymension RollApp and how to configure it.

How it works

and to enable tls next fields should be add to the json file:

web3_signer_tls_cert_file web3_signer_tls_key_file web3_signer_tls_ca_cert_file Web3 signer

Warnings

in rollap-evm log you will eventually see something like this:

Links

About EigenDA Side Server Proxy

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.

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:

./bin/eigenda-proxy \
    --addr 127.0.0.1 \
    --port 3100 \
    --eigenda.disperser-rpc disperser-holesky.eigenda.xyz:443 \
    --eigenda.signer-private-key-hex $PRIVATE_KEY \
    --eigenda.max-blob-length 8Mb \
    --eigenda.eth-rpc https://ethereum-holesky-rpc.publicnode.com \
    --eigenda.svc-manager-addr 0xD4A7E1Bd8015057293f0D0A557088c286942e84b \
    --weavevm.endpoint https://alphanet.load.network/ \
    --weavevm.chain_id 9496 \
    --weavevm.enabled \
    --weavevm.private_key_hex $WVM_PRIV_KEY \
    --storage.fallback-targets weavevm \
    --storage.concurrent-write-routines 2 

POST command:

curl -X POST "http://127.0.0.1:3100/put?commitment_mode=simple" \
      --data-binary "some data that will successfully be written to EigenDA" \
      -H "Content-Type: application/octet-stream" \
      --output response.bin

GET command:

COMMITMENT=$(xxd -p response.bin | tr -d '\n' | tr -d ' ')
curl -X GET "http:/127.0.0.1:3100/get/0x$COMMITMENT?commitment_mode=simple" \
     -H "Content-Type: application/octet-stream"

Examples using Web3signer as a remote signer

Web3 signer

Warnings

start eigenda proxy with signer:

./bin/eigenda-proxy \
    --addr 127.0.0.1 \
    --port 3100 \
    --eigenda.disperser-rpc disperser-holesky.eigenda.xyz:443 \
    --eigenda.signer-private-key-hex $PRIVATE_KEY \
    --eigenda.max-blob-length 8MiB \
    --eigenda.eth-rpc https://ethereum-holesky-rpc.publicnode.com \
    --eigenda.svc-manager-addr 0xD4A7E1Bd8015057293f0D0A557088c286942e84b \
    --weavevm.endpoint https://alphanet.load.network/ \
    --weavevm.chain_id 9496 \
    --weavevm.enabled \
    --weavevm.web3_signer_endpoint http://localhost:9000 \
    --storage.fallback-targets weavevm \
    --storage.concurrent-write-routines 2 

start web3signer tls:

./bin/eigenda-proxy \
    --addr 127.0.0.1 \
    --port 3100 \
    --eigenda.disperser-rpc disperser-holesky.eigenda.xyz:443 \
    --eigenda.signer-private-key-hex $PRIVATE_KEY \
    --eigenda.max-blob-length 8MiB \
    --eigenda.eth-rpc https://ethereum-holesky-rpc.publicnode.com \
    --eigenda.svc-manager-addr 0xD4A7E1Bd8015057293f0D0A557088c286942e84b \
    --weavevm.endpoint https://testnet-rpc.wvm.dev/ \
    --weavevm.chain_id 9496 \
    --weavevm.enabled \
    --weavevm.web3_signer_endpoint https://localhost:9000 \
    --storage.fallback-targets weavevm \
    --storage.concurrent-write-routines 2 \
    --weavevm.web3_signer_tls_cert_file $SOME_PATH_TO_CERT \
    --weavevm.web3_signer_tls_key_file $SOME_PATH_TO_KEY \
    --weavevm.web3_signer_tls_ca_cert_file $SOME_PATH_TO_CA_CERT

About the OP Stack

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.

OP Stack Rollups on Load Network

As a result, OP Stack rollups using LN for data settlement and data availability (DA) will benefit from the cost-effective, permanent data storage offered by Load Network and Arweave. Rollups deployed on LN use the native network gas token (tLOAD on Alphanet), similar to how ETH is used for OP rollups on Ethereum.