Repository: loadnetwork/gitbook-sync Directory: .gitbook Directory: .gitbook/assets File: .gitbook/assets/ELF (1).png (139.10 KB) --------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/ELF%20(1).png File: .gitbook/assets/ELF.png (133.27 KB) ----------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/ELF.png File: .gitbook/assets/EVM scale (1).png (1.35 MB) --------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/EVM%20scale%20(1).png File: .gitbook/assets/EVM scale.png (1.52 MB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/EVM%20scale.png File: .gitbook/assets/Frame 6 (1).png (192.09 KB) ------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/Frame%206%20(1).png File: .gitbook/assets/WeaveVM architecture (1).png (1.93 MB) -------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/WeaveVM%20architecture%20(1).png File: .gitbook/assets/Wordmark_lg.png (34.68 KB) ------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/Wordmark_lg.png File: .gitbook/assets/alphanet-mm.png (16.97 KB) ------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/alphanet-mm.png File: .gitbook/assets/big_logo_banner.png (373.09 KB) ----------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/big_logo_banner.png File: .gitbook/assets/big_logo_banner_bk.png (22.10 KB) -------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/big_logo_banner_bk.png File: .gitbook/assets/cost-comparison.jpg (44.57 KB) ----------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/cost-comparison.jpg File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png (693.48 KB) --------------------------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png (693.48 KB) ----------------------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png (1.94 MB) ------------------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png (560.05 KB) --------------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1) (1).png (36.83 KB) ----------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1) (1).png (13.52 KB) ------------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1) (1).png (159.66 KB) --------------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1) (1).png (76.53 KB) ----------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1) (1).png (76.53 KB) ------------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1) (1).png (424.94 KB) --------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1) (1).png (54.26 KB) ----------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1) (1).png (73.38 KB) ------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1)%20(1).png File: .gitbook/assets/image (1) (1).png (126.01 KB) --------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1)%20(1).png File: .gitbook/assets/image (1).png (98.42 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(1).png File: .gitbook/assets/image (10).png (43.41 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(10).png File: .gitbook/assets/image (11).png (41.81 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(11).png File: .gitbook/assets/image (12).png (49.45 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(12).png File: .gitbook/assets/image (13).png (455.07 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(13).png File: .gitbook/assets/image (14).png (294.28 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(14).png File: .gitbook/assets/image (15).png (326.33 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(15).png File: .gitbook/assets/image (16).png (44.11 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(16).png File: .gitbook/assets/image (17).png (45.02 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(17).png File: .gitbook/assets/image (18).png (658.24 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(18).png File: .gitbook/assets/image (19).png (50.00 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(19).png File: .gitbook/assets/image (2) (1) (1) (1) (1).png (171.79 KB) --------------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (2) (1) (1) (1).png (1.94 MB) ----------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(2)%20(1)%20(1)%20(1).png File: .gitbook/assets/image (2) (1) (1).png (151.77 KB) ------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(2)%20(1)%20(1).png File: .gitbook/assets/image (2) (1).png (424.94 KB) --------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(2)%20(1).png File: .gitbook/assets/image (2).png (55.77 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(2).png File: .gitbook/assets/image (20).png (642.31 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(20).png File: .gitbook/assets/image (21).png (13.40 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(21).png File: .gitbook/assets/image (22).png (24.96 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(22).png File: .gitbook/assets/image (23).png (70.96 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(23).png File: .gitbook/assets/image (24).png (70.96 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(24).png File: .gitbook/assets/image (25).png (85.72 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(25).png File: .gitbook/assets/image (26).png (62.58 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(26).png File: .gitbook/assets/image (27).png (23.66 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(27).png File: .gitbook/assets/image (28).png (19.71 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(28).png File: .gitbook/assets/image (29).png (49.29 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(29).png File: .gitbook/assets/image (3) (1).png (26.71 KB) --------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(3)%20(1).png File: .gitbook/assets/image (3).png (48.11 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(3).png File: .gitbook/assets/image (30).png (46.26 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(30).png File: .gitbook/assets/image (31).png (279.88 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(31).png File: .gitbook/assets/image (32).png (140.27 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(32).png File: .gitbook/assets/image (33).png (103.99 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(33).png File: .gitbook/assets/image (34).png (33.24 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(34).png File: .gitbook/assets/image (35).png (167.22 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(35).png File: .gitbook/assets/image (36).png (9.29 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(36).png File: .gitbook/assets/image (37).png (73.13 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(37).png File: .gitbook/assets/image (38).png (62.47 KB) ------------------------------------ Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(38).png File: .gitbook/assets/image (4).png (217.30 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(4).png File: .gitbook/assets/image (5).png (11.02 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(5).png File: .gitbook/assets/image (6).png (10.85 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(6).png File: .gitbook/assets/image (7).png (10.18 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(7).png File: .gitbook/assets/image (8).png (153.46 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(8).png File: .gitbook/assets/image (9).png (43.99 KB) ----------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image%20(9).png File: .gitbook/assets/image.png (160.03 KB) ------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/image.png File: .gitbook/assets/wvm-req (2).png (6.94 MB) ------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/wvm-req%20(2).png File: .gitbook/assets/wvm_network_flow (1).png (94.20 KB) ---------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/wvm_network_flow%20(1).png File: .gitbook/assets/wvm_network_flow (3).png (96.43 KB) ---------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/wvm_network_flow%20(3).png File: .gitbook/assets/wvm_network_flow (5).png (73.84 KB) ---------------------------------------------- Binary file, content not included. Download URL: https://raw.githubusercontent.com/loadnetwork/gitbook-sync/main/.gitbook/assets/wvm_network_flow%20(5).png File: README.md (471 B) --------------- --- description: >- Load Network is a high performance blockchain for data storage - cheaply and verifiably store, access, and compute with any data. --- # Load Network

Load Network ≈ The onchain data center

{% hint style="info" %} The Load Network fair launch is now live. [Learn how to get $LOAD](https://blog.load.network/fair-launch-tokenomics) {% endhint %} File: SUMMARY.md (4.07 KB) ---------------- # Table of contents * [Load Network](README.md) * [Quickstart](quickstart.md) ## About Load Network * [Overview](about-load-network/overview.md) * [Network Releases Nomenclature](about-load-network/network-releases-nomenclature.md) * [Load Network Alphanets](about-load-network/load-network-alphanets.md) * [Key Features ](about-load-network/key-features.md) * [ELI5](about-load-network/eli5.md) ## Using Load Network * [Compatibility & Performance](using-load-network/compatibility-and-performance.md) * [Network configurations](using-load-network/network-configurations.md) * [Supported Precompiles](using-load-network/supported-precompiles.md) * [JSON-RPC Methods](using-load-network/json-rpc-methods.md) * [Compute](using-load-network/compute.md) * [EVM Bundler (legacy)](using-load-network/evm-bundler-legacy/README.md) * [Load Network Bundler](using-load-network/evm-bundler-legacy/load-network-bundler.md) * [0xbabe2: Large Data Uploads](using-load-network/evm-bundler-legacy/0xbabe2-large-data-uploads.md) * [Bundlers Gateways](using-load-network/evm-bundler-legacy/bundlers-gateways.md) * [Miscellaneous ](using-load-network/miscellaneous/README.md) * [Self Hosted RPC Proxies](using-load-network/miscellaneous/self-hosted-rpc-proxies.md) * [Deploying an ERC20](using-load-network/miscellaneous/deploying-an-erc20.md) * [load:// Data Protocol](using-load-network/miscellaneous/load-data-protocol.md) * [Arweave's ANS-104 Rust SDK](using-load-network/miscellaneous/arweaves-ans-104-rust-sdk.md) * [load0 data layer](using-load-network/miscellaneous/load0-data-layer.md) ## Load Cloud Platform (LCP) * [Cloud Platform (LCP)](load-cloud-platform-lcp/cloud-platform-lcp.md) * [Load S3 Layer (LS3)](load-cloud-platform-lcp/load-s3-layer-ls3.md) * [LS3 with load\_acc](load-cloud-platform-lcp/ls3-with-load_acc.md) * [Turbo Offchain Upload Service](load-cloud-platform-lcp/turbo-offchain-upload-service.md) * [x402 Protocol Integration](load-cloud-platform-lcp/x402-protocol-integration.md) * [Load S3 Agent (HTTP API)](load-cloud-platform-lcp/load-s3-agent-http-api.md) * [Load S3 DataItems Gateway](load-cloud-platform-lcp/load-s3-dataitems-gateway.md) ## load hyperbeam * [About Load HyperBEAM](load-hyperbeam/about-load-hyperbeam.md) * [\~s3@1.0 device](load-hyperbeam/s3-1.0-device.md) * [\~x402@1.0 device](load-hyperbeam/x402-1.0-device.md) * [\~evm@1.0 device](load-hyperbeam/evm-1.0-device.md) * [\~kem@1.0 device](load-hyperbeam/kem-1.0-device.md) * [\~riscv-em@1.0 device](load-hyperbeam/riscv-em-1.0-device.md) * [\~helios@1.0 device](load-hyperbeam/helios-1.0-device.md) * [\~quantum-rt@1.0 device](load-hyperbeam/quantum-rt-1.0-device.md) ## Load Network for evm chains * [Ledger Archiver (any chain)](load-network-for-evm-chains/ledger-archiver-any-chain.md) * [Ledger Archivers: State Reconstruction](load-network-for-evm-chains/ledger-archivers-state-reconstruction.md) * [DA ExEx (Reth-only)](load-network-for-evm-chains/da-exex-reth-only.md) * [Deploying OP-Stack Rollups](load-network-for-evm-chains/deploying-op-stack-rollups.md) ## Load Network ExEx * [About ExExes](load-network-exex/about-exexes.md) * [ExEx.rs](load-network-exex/exex.rs.md) * [Load Network ExExes](load-network-exex/load-network-exexes/README.md) * [Google BigQuery ETL](load-network-exex/load-network-exexes/google-bigquery-etl.md) * [Borsh Serializer](load-network-exex/load-network-exexes/borsh-serializer.md) * [Arweave Data Uploader](load-network-exex/load-network-exexes/arweave-data-uploader.md) * [Load Network DA ExEx](load-network-exex/load-network-exexes/load-network-da-exex.md) * [Load Network WeaveDrive ExEx](load-network-exex/load-network-exexes/load-network-weavedrive-exex.md) ## Load Network Arweave Data Protocols * [LN-ExEx Data Protocol](load-network-arweave-data-protocols/ln-exex-data-protocol.md) * [Load Network Precompiles Data Protocol](load-network-arweave-data-protocols/load-network-precompiles-data-protocol.md) ## DA Integrations * [LN-EigenDA Proxy Server](da-integrations/ln-eigenda-proxy-server.md) * [LN-Dymension: DA client for RollAP](da-integrations/ln-dymension-da-client-for-rollap.md) Directory: about-load-network File: about-load-network/eli5.md (6.22 KB) -------------------------------- --- description: ELI5 Load Network --- # ELI5 ### What is Load Network? Load is a high-performance blockchain built towards the goal of solving the EVM storage dilemma with [Arweave](https://arweave.org) and ao [HyperBEAM](https://github.com/permaweb/HyperBEAM). 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.

Load Network Highlights

### 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 a compute marketplace of EVM node components, and permissionless block production participation (running a node). Load Network will offer both permanent and temporary data storage while maintaining decentralized and censorship-resistant retrieval & ingress (gateways, bundling services, etc). ### Use Cases and How to Integrate #### Ledger Data Storage Chains like Metis, RSS3 and Dymension use Load Network to permanently store onchain data, acting as a decentralized archival node. If you look at the common problems that are flagged up on [L2Beat](https://l2beat.com/scaling/summary), a lot of it has to do with centralized sources of truth and data that can’t be independently audited or reconstructed in a case where there’s a failure in the chain. Load adds a layer of protection and transparency to L2s, ruling out some of the failure modes of centralization. Learn more about the [wvm-archiver tool here](../load-network-for-evm-chains/ledger-archiver-any-chain.md). #### High-Throughput Data Availability (DA) Load Network can plug in to a typical EVM L2's stack as a DA layer that's 10-15x cheaper than solutions like [Celestia and Avail](https://wvm.dev/calculator), and guarantees data permanence on Arweave. LN was built to handle DA for the coming generation of supercharged rollups. With a throughput of \~62MB/s, it could handle DA for [every major L2](https://rollup.wtf) and still have 99%+ capacity left over. You can check out the custom [DA-ExEx](../load-network-for-evm-chains/da-exex-reth-only.md) to make use of LOAD-DA in any Reth node in less than 80 LoCs, also the [EigenDA-LN Sidecar Server Proxy](../da-integrations/ln-eigenda-proxy-server.md) to use EigenDA's data availability along with Load Network securing its archiving. #### 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. We have developed the first-ever Reth precompiles to natively facilitate a [bidirectional data pipeline with Arweave](https://blog.wvm.dev/weavevm-arweave-precompiles/) from the smart contract API level. Check out the full list of Load precompiled contracts [here](../using-load-network/supported-precompiles.md). #### Foundational Layer (L1) For Rollups Load Network is an EVM compatible blockchain, therefore, rollups can be deployed on Load the same as rollups on Ethereum. In contrast to Ethereum or other EVM L1s, rollups deployed on top of Load benefit out-of-the-box from the data-centric features provided by Load (for rollup data settlement and DA). Rollups deployed on Load Network use the native Load gas token (tLOAD on Alphanet), similar to how ETH is used for OP rollups on Ethereum. For example, we released a technical guide for developers interested in deploying OP-Stack rollups on Load. [Check it out here](https://github.com/weaveVM/developers/blob/main/guides/op-rollup-deployment.md). #### The Onchain Data Center Load network is being built with the vision of being the onchain data center. To accomplish this vision, we have started working on several web2 and web3 data pipelines into Load and Arweave, with web2 cloud experience. [Start using Load Cloud now](../load-cloud-platform-lcp/cloud-platform-lcp.md)! ### Explore Load Network Ecosystem Dapps (Evolving) * [Load Network Cloud Platform](../load-cloud-platform-lcp/cloud-platform-lcp.md) — The UI of the onchain data center * [Permacast](https://permacast.app) — A decentralized media platform on Load Network * [Tapestry Finance ](https://www.tapestry.fi/)— Uniswap V2 fork * [shortcuts.bot ](https://shortcuts.bot/)— short links for Load Network txids * [load.yachts](https://www.load.yachts/) — subdomain resolver for Load Network content * [onchain.rs ](https://onchain.rs)— Dropbox onchain alternative * [relic.bot ](https://relic.bot)— Onchain Instagram * [fairytale.sh ](https://fairytale.sh)— onchain publishing toolkit * [tokenize.rs ](https://app.gitbook.com/s/z2gd4Irh30FSnal6SJnL/)— Tokenize any data on Load Network * [bridge.load.network ](https://bridge.load.network)— Hyperlane bridge (Load Alphanet <> Ethereum Holesky) * [mediadao.xyz](https://mediadao.xyz) — a club for permanent content preservation. * [Dymension.xyz Roll-Apps ](https://portal.dymension.xyz/rollapps)— deploy a Dymension roll-app using Load DA Useful Links * [Documentation](overview.md) * [GitHub Organization](https://github.com/weaveVM) * [Blog](https://blog.wvm.dev) * [Twitter](https://x.com/weavevm) * [Discord](https://dsc.gg/wvm) * [Explorer](https://explorer.wvm.dev) * [Data storage price calculator](https://wvm.dev/calculator) * [Alphanet faucet](https://wvm.dev/faucet)
File: about-load-network/key-features.md (5.48 KB) ---------------------------------------- --- description: Exploring Load Network key features --- # Key Features 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"](https://vitalik.eth.limo/general/2021/12/06/endgame.html) 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 "[mission π](https://blog.decent.land/mission-pi/)" 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 [diagrams & benchmarks here](https://github.com/weaveVM/wvm-research), 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. [Learn more about Load Network precompiles in this section.](../using-load-network/supported-precompiles.md)
### 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. [Check the comparison calculator for realtime data](https://www.wvm.dev/calculator).

Data LOADing cost comparison

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. File: about-load-network/load-network-alphanets.md (1.87 KB) -------------------------------------------------- --- description: A list of Load Network Alphanet Releases --- # Load Network Alphanets 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](https://github.com/weaveVM/wvm-reth/releases) | Alphanet | Blog Post | Changelogs | | --------------------- | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ | | `v1` | [https://blog.wvm.dev/testnet-is-live/](https://blog.wvm.dev/testnet-is-live/) | [https://github.com/weaveVM/wvm-reth/releases/tag/v0.1.0](https://github.com/weaveVM/wvm-reth/releases/tag/v0.1.0) | | `v2` | [https://blog.wvm.dev/alphanet-v2/](https://blog.wvm.dev/alphanet-v2/) | [https://github.com/weaveVM/wvm-reth/releases/tag/v0.2.2](https://github.com/weaveVM/wvm-reth/releases/tag/v0.2.2) | | `v3` | [https://blog.wvm.dev/alphanet-v3/](https://blog.wvm.dev/alphanet-v3/) | [https://github.com/weaveVM/wvm-reth/releases/tag/v0.3.0](https://github.com/weaveVM/wvm-reth/releases/tag/v0.3.0) | | `v4 (LOAD Inception)` | [https://blog.wvm.dev/alphanet-v4/](https://blog.wvm.dev/alphanet-v4/) | [https://github.com/weaveVM/wvm-reth/releases/tag/v0.4.0](https://github.com/weaveVM/wvm-reth/releases/tag/v0.4.0) | | `v5` | [https://blog.load.network/alphanet-v5/](https://blog.load.network/alphanet-v5/) | [https://github.com/weaveVM/wvm-reth/releases/tag/v0.5.3](https://github.com/weaveVM/wvm-reth/releases/tag/v0.5.3) | File: about-load-network/network-releases-nomenclature.md (770 B) --------------------------------------------------------- --- description: 'Load Network Releases: Understanding Our Testnets' --- # Network Releases Nomenclature {% hint style="info" %} Both Alphanets and Devnets are testnet networks with no monetary value tied to the Load Network mainnet. They serve different purposes in our development pipeline {% endhint %} ### 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. File: about-load-network/overview.md (1.03 KB) ------------------------------------ --- description: Defining Load Network --- # Overview ### 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](https://arweave.org/), and achieve high performance computation -decoupled from the EVM L1 itself- by utilizing [ao-hyperbeam](../load-hyperbeam/about-load-hyperbeam.md) 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. Directory: da-integrations File: da-integrations/ln-dymension-da-client-for-rollap.md (6.52 KB) ---------------------------------------------------------- --- description: >- Description of Laod Network integration as a Data Availability client for Dymension RollApps --- # LN-Dymension: DA client for RollAP #### Links [https://dymension.xyz](https://dymension.xyz) {% embed url="https://github.com/dymensionxyz/rollapp-evm" %} {% embed url="https://github.com/dymensionxyz/dymint/" %} #### 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. 2. Obtain test tLOAD tokens through our [faucet](https://wvm.dev/faucet) for testing purposes. 3. Monitor your transactions using the [Load Network explorer](https://explorer.load.network). _**How it works**_ You may choose to use Load Network as a DataAvailability layer of your RollApp. We assume that you know how to boot and configure basics of your dymint RollApp. As an example you may use \ [https://github.com/dymensionxyz/rollapp-evm](https://github.com/dymensionxyz/rollapp-evm) repository. \ \ Example uses "mock" DA client. To use Load Network you should simply set next environment variable \ before config generation step using init.sh\ `export DA_CLIENT="weavevm" # This is the key change`\ `export WVM_PRIV_KEY="your_hex_string_wvm_priv_key_without_0x_prefix"`\ \ init.sh will generate basic configuration for `da_config.json` in `dymint.toml` which should look like.\ \ `da_config = '{"endpoint":"https://alphanet.load.network","chain_id":9496,"timeout":60000000000,"private_key_hex":"your_hex_string_load_priv_key_without_0x_prefix"}'`\ \ In this example we use `PRIVATE_KEY` of your LN address. It's not the most secure way to handle transaction signing and that's why we also provide an ability to use web3signer as a signing method. To enable web3signer you will need to change init.sh script and add correspondent fields or change `da_config.json` in `dymint.toml` directly. \ e.g\ \ `da_config = '{"endpoint":"https://alphanet.load.network","chain_id":9496,"timeout":"60000000000","web3_signer_endpoint":"http://localhost:9000"}'`
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 [Web3Signer](https://docs.web3signer.consensys.net/en/latest/) 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): [https://github.com/allnil/web3signer\_test\_deploy](https://github.com/allnil/web3signer_test_deploy) \ \ Example of used configuration: ``` # Set environment variables export DA_CLIENT="weavevm" # This is the key change export WVM_PRIV_KEY="your_hex_string_wvm_priv_key_without_0x_prefix" export ROLLAPP_CHAIN_ID="rollappevm_1234-1" export KEY_NAME_ROLLAPP="rol-user" export BASE_DENOM="arax" export MONIKER="$ROLLAPP_CHAIN_ID-sequencer" export ROLLAPP_HOME_DIR="$HOME/.rollapp_evm" export SETTLEMENT_LAYER="mock" # Initialize and start make install BECH32_PREFIX=$BECH32_PREFIX export EXECUTABLE="rollapp-evm" $EXECUTABLE config keyring-backend test sh scripts/init.sh # Verify dymint.toml configuration cat $ROLLAPP_HOME_DIR/config/dymint.toml | grep -A 5 "da_config" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "max_idle_time" -v "2s" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "max_proof_time" -v "1s" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "batch_submit_time" -v "30s" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "p2p_listen_address" -v "/ip4/0.0.0.0/tcp/36656" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "settlement_layer" -v "mock" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "node_address" -v "http://localhost:36657" dasel put -f "${ROLLAPP_HOME_DIR}"/config/dymint.toml "settlement_node_address" -v "http://127.0.0.1:36657" # Start the rollapp $EXECUTABLE start --log_level=debug \ --rpc.laddr="tcp://127.0.0.1:36657" \ --p2p.laddr="tcp://0.0.0.0:36656" \ --proxy_app="tcp://127.0.0.1:36658" ```
in rollap-evm log you will eventually see something like this: ```log INFO[0000] weaveVM: successfully sent transaction[tx hash 0x8a7a7f965019cf9d2cc5a3d01ee99d56ccd38977edc636cc0bbd0af5d2383d2a] module=weavevm INFO[0000] wvm tx hash[hash 0x8a7a7f965019cf9d2cc5a3d01ee99d56ccd38977edc636cc0bbd0af5d2383d2a] module=weavevm DEBU[0000] waiting for receipt[txHash 0x8a7a7f965019cf9d2cc5a3d01ee99d56ccd38977edc636cc0bbd0af5d2383d2a attempt 0 error get receipt failed: failed to get transaction receipt: not found] module=weavevm INFO[0002] Block created.[height 35 num_tx 0 size 786] module=block_manager DEBU[0002] Applying block[height 35 source produced] module=block_manager DEBU[0002] block-sync advertise block[error failed to find any peer in table] module=p2p INFO[0002] MINUTE EPOCH 6[] module=x/epochs INFO[0002] Epoch Start Time: 2025-01-13 09:21:03.239539 +0000 UTC[] module=x/epochs INFO[0002] commit synced[commit 436F6D6D697449447B5B3130342038203131302032303620352031323920393020343520313633203933203235322031352031343320333920313538203131342035382035352031352038322038203939203132392032333520313731203230382031392032343320313932203139203233352036355D3A32337D] DEBU[0002] snapshot is skipped[height 35] INFO[0002] Gossipping block[height 35] module=block_manager DEBU[0002] Gossiping block.[len 792] module=p2p DEBU[0002] indexed block[height 35] module=txindex DEBU[0002] indexed block txs[height 35 num_txs 0] module=txindex INFO[0002] Produced empty block.[] module=block_manager DEBU[0002] Added bytes produced to bytes pending submission counter.[bytes added 786 pending 15719] module=block_manager INFO[0003] data available in weavevm[wvm_tx 0x8a7a7f965019cf9d2cc5a3d01ee99d56ccd38977edc636cc0bbd0af5d2383d2a wvm_block 0xe897eab56aee50b97a0f2bd1ff47af3c834e96ca18528bb869c4eafc0df583be wvm_block_number 5651207] module=weavevm DEBU[0003] Submitted blob to DA successfully.[] module=weavevm ``` File: da-integrations/ln-eigenda-proxy-server.md (4.95 KB) ------------------------------------------------ --- description: Permanent EigenDA blobs --- # LN-EigenDA Proxy Server ### Links EigenDA proxy: [repository](https://github.com/weaveVM/wvm-eigenda-proxy/tree/feat/eigenda-wvm-code-integration) ### About EigenDA Side Server Proxy LN-EigenDA wraps the [high-level EigenDA client](https://github.com/Layr-Labs/eigenda/blob/master/api/clients/eigenda_client.go), exposing endpoints for interacting with the EigenDA disperser in conformance to the [OP Alt-DA server spec](https://specs.optimism.io/experimental/alt-da.html), 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 [faucet](https://wvm.dev/faucet) for testing purposes. 3. Monitor your transactions using the [Load Network explorer.](https://explorer.load.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 [Web3Signer](https://docs.web3signer.consensys.net/en/latest/) 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): [https://github.com/allnil/web3signer\_test\_deploy](https://github.com/allnil/web3signer_test_deploy) 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 ``` Directory: load-cloud-platform-lcp File: load-cloud-platform-lcp/cloud-platform-lcp.md (6.99 KB) --------------------------------------------------- --- description: About Load Cloud Platform --- # Cloud Platform (LCP)
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](http://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. {% hint style="info" %} Using the API keys generated on cloud.load.network - you can access other features such as load0 and Load S3 storage. {% endhint %} It has been a few months since the [first release](https://blog.load.network/load-cloud/). 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 [decentralized AWS](https://blog.load.network/the-onchain-data-center/) – 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) * s3@1.0 device upgrades * native integration of s3@1.0 with the MinIO cluster. ### The foundation: a universal API key system for Load
V2 introduces the concept of Load accounts and [load\_acc](ls3-with-load_acc.md) 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 [Magic](http://magic.link/) 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. ### s3@1.0 HyperBEAM device upgrades In order to make the private offchain DataItems accessible to their rightful whitelisted users, we had to upgrade the [s3@1.0](mailto:s3@1.0) 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 [here](https://github.com/loadnetwork/load_hb/tree/s3-node-1/native/s3_nif/src/sidecar). ### 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. ```bash echo -n "hello private world" | curl -X POST https://load-s3-agent.load.network/upload/private \ -H "Authorization: Bearer $load_acc_api_key" \ -H "x-bucket-name: $bucket_name" \ -H "x-folder-name": $folder_name" \ -H "x-dataitem-name: $object_friendly_name" \ -F "file=@-;type=text/plain" \ -F "content_type=text/plain" ``` For more examples, check out the [S3 agent repository](https://github.com/loadnetwork/load-s3-agent%20) ### 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. [Start using Load Network Cloud Platform today](https://cloud.load.network) File: load-cloud-platform-lcp/load-s3-agent-http-api.md (6.85 KB) ------------------------------------------------------- --- description: The LCP data agent --- # Load S3 Agent (HTTP API) ### About `load-s3-agent` is a data agent built on top of HyperBEAM `~s3@1.0` 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 `/provenance/{id}` : return the onchain provenance proof of an offchain ANS-104 dataitem (only for dataitems that enabled the onchain provenance flag at upload). * 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 * POST `/tags/query` : query dataitems for a given tags KV pairs. * POST `/query/dataitem` : fetch full metadata for a specific `dataitem_id`. * POST `/upload` : post data (or signed dataitem) to store a public offchain DataItem on `~s3@1.0` * POST `/upload/private` : post data (or signed dataitem) to store a private offchain DataItem on `~s3@1.0` * POST `/post/:dataitem_id` : post an `~s3@1.0` public DataItem to Arweave via Turbo (N.B: Turbo covers any dataitem cost with size <= 100KB). #### Upload data and return an agent public signed DataItem ```bash echo -n "hello world" | curl -X POST https://load-s3-agent.load.network/upload \ -H "Authorization: Bearer $load_acc_api_key" \ -F "file=@-;type=text/plain" \ -F "content_type=text/plain" ``` Or optionally add custom tags KVs that will be included in the ANS-104 DataItem construction ```bash echo -n "hello custom tagged world" | curl -X POST https://load-s3-agent.load.network/upload \ -H "Authorization: Bearer $load_acc_api_key" \ -F "file=@-;type=text/plain" \ -F 'tags=[{"key":"tag1","value":"tag1"},{"key":"tag2","value":"tag2"}]' ``` Optional: have the agent publish an offchain provenance record for the uploaded DataItem (the API returns the provenance transaction id in `offchain_provenance_proof`): ```bash echo -n "hello provenance world" | curl -X POST https://load-s3-agent.load.network/upload \ -H "Authorization: Bearer $load_acc_api_key" \ -H "offchain-provenance: true" \ -F "file=@-;type=text/plain" ``` offchain provenance data protocol tags on Arweave (per provenance proof): * `Storage-Provider: Load-S3` * `Agent-Version: ${VERSION}` * `Dataitem-Record: ${OFFCHAIN_LS3_DATAITEM_ID}` * `Version:$PROVENANCE_PROTOCOL_VERSION` * `Data-Protocol: Load-S3-Offchain-Provenance` Examples: * onchain provenance example: https://viewblock.io/arweave/tx/fnmmd6pqOOQFFpscH8AB4CyGDsGSt\_fG5VCPJioBG3c * offchain dataitem: https://gateway.s3-node-1.load.network/resolve/gT03XTtL0GCfb2AxJFjg8OVkhMuLQvwQVi7KvrbKYF8 * provenance receipt (including settlement): https://load-s3-agent.load.network/provenance/gT03XTtL0GCfb2AxJFjg8OVkhMuLQvwQVi7KvrbKYF8 #### Upload data and return an agent private signed DataItem \*\*\* N.B: any private DataItem does not have the tags indexed nor is queryable \*\*\* ```bash echo -n "hello world" | curl -X POST https://load-s3-agent.load.network/upload/private \ -H "Authorization: Bearer $load_acc_api_key" \ -H "x-bucket-name: $bucket_name" \ -H "x-dataitem-name: $dataitem_name" \ -H "x-folder-name": $folder_name" \ -H "signed: false" \ -F "file=@-;type=text/plain" \ -F "content_type=text/plain" ``` #### Upload signed dataitem to a private bucket (private dataitem) ```bash curl -X POST https://load-s3-agent.load.network/upload/private \ -H "Authorization: Bearer $load_acc_api_key" \ -H "signed: true" \ -H "bucket_name: $bucket_name" \ -H "x-dataitem-name: $dataitem_name" \ -H "x-folder-name": $folder_name" \ -F "file=@path-signed-dataitem.ans104" \ -F "content_type=application/octet-stream" ``` #### Upload a signed DataItem and store it in Load S3 Tags are extracted from the ANS-104 DataItem, indexed and queryable ```bash curl -X POST https://load-s3-agent.load.network/upload \ -H "Authorization: Bearer $load_acc_api_key" \ -H "signed: true" \ -F "file=@your-signed-dataitem.bin" ``` #### Post offchain DataItem to Arweave example: for offchain dataitem = `eoNAO-HlYasHJt3QFDuRrMVdLUxq5B8bXe4N_kboNWs` ```bash curl -X POST \ "https://load-s3-agent.load.network/post/eoNAO-HlYasHJt3QFDuRrMVdLUxq5B8bXe4N_kboNWs" \ -H "Authorization: Bearer REACH_OUT_TO_US" \ -H "Content-Type: application/json" ``` #### Querying DataItems by Tags all dataitems pushed after agent's `v0.6.0` release are queryable by the dataitem's tags KVs: ```bash curl -X POST https://load-s3-agent.load.network/tags/query \ -H "Content-Type: application/json" \ -d '{ "filters": [ { "key": "tag1", "value": "tag1" }, { "key": "tag2", "value": "tag2" } ] }' ``` * Pagination follows Arweave's GQL schema: optional `first` (default 25, max 100) and a cursor `after`. * `full_metadata` flag (`Optional`) to return the full tags associated with a query's dataitem * each returned item includes `dataitem_size` (bytes) when available (v0.9.1 and onwards) * `created_after` / `created_before` (ISO-8601/RFC3339 strings) filter items by their `created_at` timestamp (inclusive bounds). ```bash curl -X POST https://load-s3-agent.load.network/tags/query \ -H "Content-Type: application/json" \ -d '{ "filters": [ { "key": "tag1", "value": "tag1" } ], "full_metadata": true, "created_after": "2025-12-01T00:00:00Z", "created_before": "2025-12-05T00:00:00Z", "first": 25, "after": null }' ``` 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. #### Querying a DataItem by ID Retrieve the latest indexed metadata (content type, size, tags, timestamps) for a single dataitem: ```bash curl -X POST https://load-s3-agent.load.network/query/dataitem \ -H "Content-Type: application/json" \ -d '{ "dataitem_id": "ig0_Hw1VW2uQRJFV-RPQ2SRpiougpJ4JkWEtr6kP_Fc" }' ``` ### Load S3 Agent library **Adding load-s3-agent library** ```toml [dependencies] load-s3-agent = { git = "https://github.com/loadnetwork/lcp-uploader-api.git", branch = "main" } ``` **Example** ```rust use load_s3_agent::create_dataitem; use load_s3_agent::{get_dataitem_provenance_record, DataItemProvenanceRecord}; fn build_item() -> anyhow::Result<()> { // ensure UPLOADER_JWK is available in the environment (or .env) std::env::set_var("UPLOADER_JWK", include_str!("../wallet.json")); let item = create_dataitem( b"hello world".to_vec(), "text/plain", &[("My-Tag".into(), "tag-value".into())], )?; println!("Signed data item id: {}", item.id()); Ok(()) } ``` File: load-cloud-platform-lcp/load-s3-dataitems-gateway.md (828 B) ---------------------------------------------------------- --- description: Accessing the Load S3 data via HyperBEAM gateways --- # Load S3 DataItems Gateway The easiest way to access Load S3 stored dataitems is the HyperBEAM gateway sidecar, that works over HTTP — endpoint: https://gateway.s3-node-1.load.network ### Gateway Methods #### Resolving public dataitem data `GET /resolve/{dataitem_key}` #### Downloading full dataitem object (.ans104 binary) `GET /binary/{dataitem_key}` For entreprise Load S3 clients, the methods above are both available under the gateway, but for the load s3-fast cluster * `GET /resolve/fast/{dataitem_key}` * `GET /binary/fast/{dataitem_key}` Source code: [https://github.com/loadnetwork/load\_hb/tree/s3-node-1/native/s3\_nif/src/sidecar](https://github.com/loadnetwork/load_hb/tree/s3-node-1/native/s3_nif/src/sidecar) File: load-cloud-platform-lcp/load-s3-layer-ls3.md (7.95 KB) -------------------------------------------------- --- description: Explore the first temporal data storage layer on AO HyperBEAM --- # Load S3 Layer (LS3) ### 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 `~s3@1.0` 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. {% hint style="success" %} To start using the Load S3 temporary storage layer today, checkout the [LCP](cloud-platform-lcp.md), [LS3 with load\_acc](ls3-with-load_acc.md) and the [Turbo upload service](turbo-offchain-upload-service.md) sections. {% endhint %} ### 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. ### \~s3@1.0 & ANS-104 DataItems The \~s3@1.0 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 [xANS-104](https://blog.load.network/xans-104/) data provenance, lineage and governance here. ### Hybrid Gateway {% hint style="success" %} For a direct low level ANS-104 DataItem data streaming from LS3, use the HyperBEAM [sidecar](https://app.gitbook.com/u/9f5jQHFG1jWXf1Txd6jCIxFWKHD2) gateway instead — access the offchain dataitem under: [https://gateway.s3-node-1.load.network/resolve/:dataitem\_id](https://gateway.s3-node-1.load.network/resolve/:dataitem_id) {% endhint %} 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 [`hb_gateway_s3.erl`](https://github.com/loadnetwork/load_hb/blob/s3-edge/src/hb_gateway_s3.erl) module and extended the [`hb_gateway_client.erl`](https://github.com/loadnetwork/load_hb/blob/s3-edge/src/hb_gateway_client.erl) 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 \~[s3@1.0](mailto:s3@1.0) device, benefit from the Hybrid Gateway that can resolve both onchain and offchain dataitems. #### Load S3 Trust Assumptions, Optimismo {% hint style="success" %} For a higher level trust assumption, upload data to LS3 using the Turbo-compliant [upload service](turbo-offchain-upload-service.md) which comes with a built-in system of signed receipts. {% endhint %} In the current release, Load S3 is a storage layer consisting of a single centralized yet verifiable storage provider (HyperBEAM node running the \~s3@1.0 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 \~s3@1.0 device is available the following endpoint: [https://s3-node-1.load.network](https://s3-node-1.load.network/) – 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 `~s3@1.0 - (1:1 parity)` #### Available Endpoints | Node Name | Endpoint | Features | | --------------------------- | ---------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | S3 Node 1 (current testnet) | [https://s3-node-1.load](https://s3-node-1.load/) | | | ~~S3 Node 0 (deprecated)~~ | [~~https://s3-node-0.load.network~~ ](https://s3-node-0.load.network/) | | To learn how to start using Load S3 today, check out the following [page](ls3-with-load_acc.md) File: load-cloud-platform-lcp/ls3-with-load_acc.md (1.76 KB) -------------------------------------------------- --- description: Learn how to use Load S3 storage layer along LCP's load_acc api keys --- # LS3 with load\_acc {% hint style="info" %} As of October 1st, 2025, it's no longer required to directly contact us to acquire Load S3 access keys to interact with the LS3's `drive.load.network` HyperBEAM cluster. Interacting with the Load S3 storage layer now has programmatic access with `load_acc` access keys and a new cluster endpoint: `https://api.load.network/s3` {% endhint %} ### 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: ```javascript import { S3Client } from "@aws-sdk/client-s3"; const endpoint = "https://api.load.network/s3"; // LS3 HyperBEAM cluster const accessKeyId = "load_acc_YOUR_LCP_ACCESS_KEY"; // get yours from cloud.load.network const secretAccessKey = ""; // Initialize the S3 client const s3Client = new S3Client({ region: "us-east-1", endpoint, credentials: { accessKeyId, secretAccessKey, }, forcePathStyle: true, // required }); ``` And that's it, that's all you need to start interacting with your HyperBEAM-powered S3 temporary storage! File: load-cloud-platform-lcp/turbo-offchain-upload-service.md (10.55 KB) -------------------------------------------------------------- --- description: Learn about the ARIO's Turbo-compliant offchain upload service --- # Turbo Offchain Upload Service ### About The [loaded-turbo-api](https://github.com/loadnetwork/loaded-turbo-api) is the first [Turbo](https://turbo.ar.io/)-compliant, offchain, s3-based, on HyperBEAM upload service. With this new upload service, Turbo and the broader Arweave ecosystem users can start using [Load S3 ](load-s3-layer-ls3.md)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 [SLA](https://arweave.net/ZKpbKFbF-F-Yu3Dk9_YCY3klp20PNgBa7JGFtqTYeWs) offered by the Load S3 client. {% hint style="warning" %} The upload service limits and features are subject to change, to stay up to date, always check the service’s public configs [here](https://loaded-turbo-api.load.network/) and follow the docs on [GitHub](https://github.com/loadnetwork/loaded-turbo-api). {% endhint %} ### Compatibility | Endpoint | Status | | :--------------------------------------------: | :---------------------------------------------------------------------------------------------------------------------------------: | | `GET /` `GET /info` | ✅ | | `GET /bundler_metrics` | ✅ (placeholder) | | `GET /health` | ✅ | | `GET /v1/tx/{dataitem_id}/offsets` | ✅ (placeholder) | | `POST /v1/tx/{token}` (<= 10MB uploads) | ✅ | | `GET /v1/tx/{dataitem_id}/status` | ✅ | | `GET /v1/chunks/{token}/-1/-1` | ✅ | | `GET /v1/chunks/{token}/{upload_id}/-1` | ✅ | | `GET /v1/chunks/{token}/{upload_id}/status` | ✅ | | `POST /v1/chunks/{token}/{upload_id}/{offset}` | ✅ | | `POST /v1/chunks/{token}/{upload_id}/finalize` | ✅ | | `GET /account/balance/:id` | not supported, [deprecated](https://github.com/ardriveapp/turbo-upload-service/blob/main/src/router.ts#L48) in turbo-upload-service | | `GET /price/:token/:byteCount?` | not supported, deprecated in turbo-upload-service | ### Service Limits & Specs The offchain LS3-powered ANS-104 upload service match the services standards set by the Turbo service, such as: * 4GB dataitem max size * return service-signed receipts * match the multipart upload biz logic, including chunking strategy (min/max/default chunk size) * it does not bundle dataitems as they are stored on LS3, it leaves the bundling logic for the onchain upload service that requires onchain fees fine tuning (e.g. Turbo) * comes along fast finality indexes & data caches, a LS3 dataitem streaming gateway powered by HyperBEAM: [https://gateway.s3-node-1.load.network](https://gateway.s3-node-1.load.network/) * service AR address: `2BBwe2pSXn_Tp-q_mHry0Obp88dc7L-eDIWx0_BUfD0` * offchain -> onchain dataitems anchoring is supported via the [load-s3-agent](https://github.com/loadnetwork/load-s3-agent?tab=readme-ov-file#post-offchain-dataitem-to-arweave) ### Endpoints: * loaded-turbo-api (offchain, Load S3 bundler endpoint): [https://loaded-turbo-api.load.network](https://loaded-turbo-api.load.network/) * data cache / fast finality index: [https://gateway.s3-node-1.load.network](https://gateway.s3-node-1.load.network/) ### Examples #### Small uploads (<= 10 MB) ```js import { TurboFactory, developmentTurboConfiguration, } from '@ardrive/turbo-sdk/node'; import Arweave from 'arweave'; import fs from 'fs'; (async () => { // Create a test file const testData = 'Hello from loaded-turbo-api S3 bundler!'; fs.writeFileSync('test-file.txt', testData); // Create an Arweave key for testing const arweave = new Arweave({}); const jwk = await Arweave.crypto.generateJWK(); const address = await arweave.wallets.jwkToAddress(jwk); console.log('Test wallet address:', address); const customTurboConfig = { ...developmentTurboConfiguration, uploadServiceConfig: { url: 'https://loaded-turbo-api.load.network', // loaded-turbo-api endpoint }, }; // Create authenticated client const turboAuthClient = TurboFactory.authenticated({ privateKey: jwk, ...customTurboConfig, }); try { // Test upload console.log('Uploading file loaded-turbo-api'); const uploadResult = await turboAuthClient.uploadFile({ fileStreamFactory: () => fs.createReadStream('test-file.txt'), fileSizeFactory: () => fs.statSync('test-file.txt').size, dataItemOpts: { tags: [ { name: 'Content-Type', value: 'text/plain' } ] }, signal: AbortSignal.timeout(30_000), }); console.log('Upload successful!'); console.log(JSON.stringify(uploadResult, null, 2)); // Verify the response structure console.log('\n=== Response Validation ==='); console.log('ID:', uploadResult.id); console.log('Owner:', uploadResult.owner); console.log('Winc:', uploadResult.winc); console.log('Data Caches:', uploadResult.dataCaches); console.log('Fast Finality Indexes:', uploadResult.fastFinalityIndexes); } catch (error) { console.error('Upload failed:', error); if (error.response) { console.error('Response status:', error.response.status); console.error('Response data:', error.response.data); } } finally { fs.unlinkSync('test-file.txt'); } })(); ``` Example offchain uploaded DataItem fast indexer access: [https://gateway.s3-node-1.load.network/resolve/Y11-TiVivfQpcg7eDV8ouxJfQl2UHvFFPgs-NJ\_HC2k](https://gateway.s3-node-1.load.network/resolve/Y11-TiVivfQpcg7eDV8ouxJfQl2UHvFFPgs-NJ_HC2k) #### Large multipart resumable uploads ```js import { TurboFactory, developmentTurboConfiguration, } from '@ardrive/turbo-sdk/node'; import Arweave from 'arweave'; import fs from 'fs'; (async () => { // Create large file to force multipart upload (>10MB) const largeTestData = 'A'.repeat(15 * 1024 * 1024); // 15MB fs.writeFileSync('large-test-file.txt', largeTestData); console.log('Created 15MB test file'); // Generate test wallet const arweave = new Arweave({}); const jwk = await Arweave.crypto.generateJWK(); const address = await arweave.wallets.jwkToAddress(jwk); console.log('Test wallet address:', address); const customTurboConfig = { ...developmentTurboConfiguration, uploadServiceConfig: { url: 'https://loaded-turbo-api.load.network', }, }; const turboAuthClient = TurboFactory.authenticated({ privateKey: jwk, ...customTurboConfig, }); try { console.log('Starting multipart upload...'); const uploadResult = await turboAuthClient.uploadFile({ fileStreamFactory: () => fs.createReadStream('large-test-file.txt'), fileSizeFactory: () => fs.statSync('large-test-file.txt').size, dataItemOpts: { tags: [{ name: 'Content-Type', value: 'text/plain' }] }, events: { onProgress: ({ totalBytes, processedBytes, step }) => { const percent = ((processedBytes / totalBytes) * 100).toFixed(1); console.log(`${step.toUpperCase()} Progress: ${percent}% (${processedBytes}/${totalBytes})`); }, onUploadProgress: ({ totalBytes, processedBytes }) => { console.log(`Upload: ${((processedBytes / totalBytes) * 100).toFixed(1)}%`); }, }, }); console.log('Result:', uploadResult); } catch (error) { console.error('\nUpload failed:', error.message); if (error.response) { console.error('Status:', error.response.status); console.error('Data:', error.response.data); } } finally { fs.unlinkSync('large-test-file.txt'); } })(); ``` Example signed receipt: [https://loaded-turbo-api.load.network/v1/chunks/arweave/541a7043-6706-47e3-be73-907bffb17a80/status](https://loaded-turbo-api.load.network/v1/chunks/arweave/541a7043-6706-47e3-be73-907bffb17a80/status) Check out the upload service v1.0.0 release [here](https://github.com/loadnetwork/loaded-turbo-api/releases/tag/v1.0.0) ### Uploading data using AWS S3 SDK / Load Agent vs Turbo SDK This Turbo-compliant upload service, along the load-s3-agent, form the main 2 data objects ingress as ANS-104 DataItems. The main difference between [load-s3-agent](load-s3-agent-http-api.md) and Turbo-SDK is access control. Uploading data via Turbo SDK default to the `offchain-dataitems` data protocol where all uploaded data items sit in the protocol’s public bucket, while using the load s3 agent, it’s possible to upload object -dataitems- to [private buckets](https://github.com/loadnetwork/load-s3-agent?tab=readme-ov-file#upload-data-and-return-an-agent-private-signed-dataitem) and control the access and have expireable shareable download links. However in both cases, the outcome is equal: ANS-104 formatted S3 objects along its data provenance guarantees and Arweave alignment. File: load-cloud-platform-lcp/x402-protocol-integration.md (4.18 KB) ---------------------------------------------------------- --- description: The first ever temporary, private, payment-gated ANS-104 Dataitems --- # x402 Protocol Integration ### 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. {% hint style="info" %} [The x402 Foundation](https://blog.cloudflare.com/x402/) is a collaborative initiative being established by Cloudflare and Coinbase with the mission of encouraging widespread adoption of the x402 protocol. {% endhint %} ### x402 and xANS-104 DataItems We are proud to be the first team that has worked on the intersection of [x402 micropayments protocol and Arweave's ANS-104 data format](https://402.load.network/). We have integrated the x402 protocol in Load's custom HyperBEAM device ([\~s3@1.0 device](../load-hyperbeam/s3-1.0-device.md)), resulting in the first ever expirable, paywalled, privately shareable ANS-104 DataItems. The x402 micropayments have been integrated on the ANS-104 gateway sidecar level of the s3 device. [check out source code](https://github.com/loadnetwork/load_hb/tree/s3-node-1/native/s3_nif/src/sidecar). ### Creating x402 paywalled private dataitems There are two ways to create an x402 paywalled private expireable ANS-104 DataItem, the first is user friendly via the LCP dashboard, and the second is programmatic yet DIY, let's explore both methods. #### x402 on Load Cloud Platform (LCP) x402 has been integrated on LCP, making it possible for LCP users to create x402 paywalled, expirable links for their private objects (ANS-104 DataItems) on Load S3. The process is pretty simple and straightforward: fill in the parameters of the **Create Payment Link** request (set expiry , payee EOA, and USDC amount) and the dashboard will generate a ready-to-use x402 expirable DataItem URL.

#### x402 DIY The DIY method means doing what the LCP dashboard abstracts, first you need to create a private LS3 ANS-104 Dataitem and upload it to your LCP bucket (load-s3-agent [reference](https://github.com/loadnetwork/load-s3-agent)): ```bash curl -X POST https://load-s3-agent.load.network/upload/private \ -H "Authorization: Bearer $load_acc_api_key" \ -H "signed: true" \ -H "bucket_name: $bucket_name" \ -H "x-dataitem-name: $dataitem_name" \ -H "x-folder-name: $folder_name" \ -F "file=@path-signed-dataitem.ans104" \ -F "content_type=application/octet-stream" ``` After that you have to generate the x402 signed shareable receipt using the HyperBEAM LS3 sidecar: ```bash curl -X POST https://gateway.s3-node-1.load.network/sign/402 \ -H "Authorization: Bearer $CONTACT_US" \ -H "x-bucket-name: $bucket_name" \ -H "x-load-acc: $load_acc_api_key" \ -H "x-dataitem-key: $dataitem_key.ans104" \ -H "x-402-address: $payee_eoa" \ -H "x-402-amount: $usdc_amount" \ -H "x-expires-minutes: $set_expiry" ``` this curl request will return a base64 string, you use it to share the x402 paywalled ANS-104 DataItem as following: `https://402.load.network/$base64_string`
Directory: load-hyperbeam File: load-hyperbeam/about-load-hyperbeam.md (1.54 KB) -------------------------------------------- --- description: Load Network custom HyperBEAM devices --- # About Load HyperBEAM

hb.load.rs

### 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 `~meta@1.0` 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: [https://github.com/permaweb/HyperBEAM](https://github.com/permaweb/HyperBEAM) ### load\_hb: Load Network HyperBEAM node with custom devices The [load\_hb](https://github.com/loadnetwork/load_hb) repository is our HyperBEAM fork with custom devices such as [\~evm@1.0](evm-1.0-device.md), [\~kem@1.0](kem-1.0-device.md), and [\~riscv-em@1.0](riscv-em-1.0-device.md) Our development motto is driven by the [Hyperbeam Accelerationism (hb/acc) ](https://blog.decent.land/hb-acc/)manifesto initiated during Arweave Day Berlin 2025. Our main hyperbeam development is hosted on [hb.load.rs](https://hb.load.rs/) File: load-hyperbeam/evm-1.0-device.md (2.06 KB) -------------------------------------- --- description: The first Revm EVM device on HyperBEAM --- # \~evm@1.0 device ## About The `@evm1.0` device: an EVM bytecode emulator built on top of Revm (version [v22.0.1](https://github.com/bluealloy/revm/releases/tag/v69)). 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. {% hint style="warning" %} _**This device is experimental, in PoC stage**_ Live demo at [ultraviolet.load.network](https://github.com/loadnetwork/load_hb/blob/main/native/load_revm_nif/ultraviolet.load.network) {% endhint %} ## 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 [./appchains](https://github.com/loadnetwork/load_hb/blob/main/native/load_revm_nif/appchains)) ```rust #[rustler::nif] fn eval_bytecode(signed_raw_tx: String, state: String, cout_state_path: String) -> NifResult { 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 { let state = get_state(chain_id); Ok(state) } ```
### References * device source code: [native/load\_revm\_nif](https://github.com/loadnetwork/load_hb/tree/main/native/load_revm_nif) * hb device interface: [dev\_evm.erl](https://github.com/loadnetwork/load_hb/blob/main/src/dev_evm.erl) * nif tests: [load\_revm\_nif\_test.erl](https://github.com/loadnetwork/load_hb/blob/main/src/load_revm_nif_test.erl) * ao process example: [evm-device.lua](https://github.com/loadnetwork/load_hb/blob/main/test/evm-device.lua) File: load-hyperbeam/helios-1.0-device.md (2.05 KB) ----------------------------------------- --- description: The EVM consensus light client --- # \~helios@1.0 device ### 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. Check out the official repository [here](https://github.com/a16z/helios) ### \~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). The device supports all of the methods supported by helios. Check the full list [here](https://github.com/a16z/helios/blob/master/rpc.md) #### Endpoint As this device is supported on the [hb.load.rs](https://hb.load.rs) hyperbeam node, it's explicitly assigned the `eth.rpc.rs` endpoint for the Ethereum mainnet network. #### Example **local** ```bash curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' http://127.0.0.1:8545 ``` **using rpc.rs** ```bash curl -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' https://eth.rpc.rs ``` device source code: [https://github.com/loadnetwork/load\_hb/tree/main/native/helios\_nif](https://github.com/loadnetwork/load_hb/tree/main/native/helios_nif) File: load-hyperbeam/kem-1.0-device.md (4.72 KB) -------------------------------------- --- description: The Kernel Execution Machine device --- # \~kem@1.0 device ## About The `kernel-em` NIF (kernel execution machine - `kem@1.0` device) is a HyperBEAM Rust device built on top of [wgpu](https://github.com/gfx-rs/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` (`kem@1.0` device), KEM functions offer great flexibility to run as GPU compute sidecars alongside ao processes. {% hint style="warning" %} _**This device is experimental, in PoC stage**_ {% endhint %} ### KEM Technical Architecture KEM function source code is deployed on Arweave (example, double integer: [btSvNclyu2me\_zGh4X9ULVRZqwze9l2DpkcVHcLw9Eg](https://arweave.net/btSvNclyu2me_zGh4X9ULVRZqwze9l2DpkcVHcLw9Eg)), and the source code TXID is used as the KEM function ID. ```rust fn execute_kernel( kernel_id: String, input_data: rustler::Binary, output_size_hint: u64, ) -> NifResult> { 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.

Technical Architecture Diagram

### 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: ```wgsl // SPDX-License-Identifier: GPL-3.0 // input as u32 array @group(0) @binding(0) var input_bytes: array; // output as u32 array @group(0) @binding(1) var output_bytes: array; // a work group of 256 threads @compute @workgroup_size(256) // main compute kernel entry point fn main(@builtin(global_invocation_id) global_id: vec3) { } ``` ### 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: ```wgsl // SPDX-License-Identifier: GPL-3.0 // input as u32 array @group(0) @binding(0) var input_bytes: array; // output as u32 array @group(0) @binding(1) var output_bytes: array; // uniform parameters for configuration @group(0) @binding(2) var params: vec2; // 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) { // Access uniform parameters let param1 = i32(params.x); let param2 = i32(params.y); // your kernel logic here } ``` ### Example: Image Glitcher Using the image glitcher kernel function - [source code](https://github.com/loadnetwork/load_hb/blob/main/native/kernel_em_nif/src/kernels/glitch-berlin.wgsl)

original image

glitched via the kernel function - minted as AO NFT on Bazar https://bazar.arweave.net/#/asset/0z8MNwaRpkXhEgIxUv8ESNhtHxVGNfFkmGkoPtu0amY

### References * device source code: [native/kernel\_em\_nif](https://github.com/loadnetwork/load_hb/tree/main/native/kernel_em_nif) * hb device interface: [dev\_kem.erl](https://github.com/loadnetwork/load_hb/blob/main/src/dev_kem.erl) * nif tests: [kem\_nif\_test.erl](https://github.com/loadnetwork/load_hb/blob/main/src/kem_nif_test.erl) * ao process example: [kem-device.lua](https://github.com/loadnetwork/load_hb/blob/main/test/kem-device.lua) File: load-hyperbeam/quantum-rt-1.0-device.md (3.79 KB) --------------------------------------------- --- description: Serverless quantum functions runtime (simulation) --- # \~quantum-rt@1.0 device ### About The `quantum_runtime_nif` is the foundation of the `~quantum-rt@1.0` 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. {% hint style="warning" %} _**This device is currently simulation-based using roqoqo-quest backend - for educational purposes only**_ {% endhint %} #### 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. ### \~quantum-rt@1.0 device The `~quantum-rt@1.0` 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 [AQT.eu](https://aqt.eu) 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 ```rust #[rustler::nif] fn hello() -> NifResult { Ok("Hello world!".to_string()) } #[rustler::nif(schedule = "DirtyCpu")] fn compute( num_qubits: usize, function_id: String, measurements: Vec, ) -> NifResult> { let runtime = Runtime::new(num_qubits); match runtime.execute_serverless(function_id, measurements) { Ok(result) => Ok(result), Err(_) => Err(rustler::Error::Term(Box::new("execution failed"))), } } ``` 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.

execution flow

### Device API Examples **Generate Quantum Random Numbers** ```bash curl -X POST "https://hb.load.rs/~quantum-rt@1.0/compute" \ -H "Content-Type: application/json" \ -d '{ "function_id": "quantum_rng", "num_qubits": 4, "measurements": [0, 1, 2, 3] }' ``` ### References * hb device interface: [dev\_quantum.erl](https://github.com/loadnetwork/load_hb/blob/main/src/dev_quantum.erl) * nif interface: [quantum\_runtime\_nif.erl](https://github.com/loadnetwork/load_hb/blob/main/src/quantum_runtime_nif.erl) * quantum functions registry: [registry.rs](https://github.com/loadnetwork/load_hb/blob/main/native/quantum_runtime_nif/src/core/registry.rs) * runtime core: [runtime.rs](https://github.com/loadnetwork/load_hb/blob/main/native/quantum_runtime_nif/src/core/runtime.rs) File: load-hyperbeam/riscv-em-1.0-device.md (1.05 KB) ------------------------------------------- --- description: The RISC-V Execution Machine device --- # \~riscv-em@1.0 device {% hint style="danger" %} This device is in a very Proof Of Concept stage {% endhint %} ## About we have developed a custom fork of [R55](https://github.com/loadnetwork/r55) (an Ethereum Execution Environment that seamlessly integrates RISCV smart contracts alongside traditional EVM smart contracts) to [handle signed raw transaction](https://github.com/loadnetwork/r55/blob/main/r55/src/exec.rs#L27) input and return the resulted computed EVM db. After getting R55 to work with the OOTB interpretation of signed raw transaction, we built on top of it a hyperbeam device offering RISC-V compatible Ethereum appchains.\ For example, this erc20.rs Rust smart contract was deployed on a hb risc-v appchain: [github.com/loadnetwork/r55](https://github.com/loadnetwork/r55/blob/main/examples/erc20/src/lib.rs) RISC-V custom device source code: [https://github.com/loadnetwork/load\_hb/tree/main/native/riscv\_em\_nif](https://github.com/loadnetwork/load_hb/tree/main/native/riscv_em_nif) File: load-hyperbeam/s3-1.0-device.md (11.87 KB) ------------------------------------- --- description: S3 object storage in hyperbeam --- # \~s3@1.0 device {% hint style="warning" %} Device status: WIP MVP {% endhint %} ### 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`)** ```config {endpoint, <<"https://drive.load.network">>}. {public_endpoint, <<"https://drive.load.network">>}. {access_key_id, <<"your_access_key_id">>}. {secret_access_key, <<"your_access_key">>}. {region, <<"eu-west-2">>}. ``` **connecting to local minio s3 cluster (`./s3_device.sh`)** ```config {endpoint, "http://localhost:9001"}.% Internal MinIO - dev {public_endpoint, "https://your.hyperbeam-s3-cluster-endpoint.com"}. % Public-facing URL, used for presigned URLs {access_key_id, <<"value">>}. {secret_access_key, <<"value">>}. {region, <<"value">>}. ``` #### build and run the hyperbeam node ```bash ./s3_device.sh # build the s3_nif device & run local minio cluster # if you want to connect to external s3 cluster, run ./build.sh instead rebar3 compile erl -pa _build/default/lib/*/ebin 1> application:ensure_all_started(hb). ``` #### 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: ```.env MINIO_ROOT_USER=access_key_id MINIO_ROOT_PASSWORD=secret_access_key ``` > N.B: your local minio cluster access keys values should be also set equally in the `s3_device.config` config file ### Supported methods | Supported | | :-----------------------------------------: | | `create_bucket` | | `head_bucket` | | `put_object` (support `expiry: 1-365 days`) | | `get_object` (support `range`) | | `delete_object` | | `delete_objects` | | `head_object` | | `list_objects` | ### Use the \~s3@1.0 device After running the hyperbeam node with the `~s3@1.0` device, you can use the `node_endpoint/~s3@1.0` url as a S3 compatible API endpoint. {% hint style="info" %} HyperBEAM node running the S3 device (testing enviroment): [https://s3-node-0.load.network ](https://s3-node-0.load.network/) {% endhint %} > _**N.B (regarding access authorization): using the**** ****`~s3@1.0`**** ****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**** ****`~s3@1.0`**** ****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 ```js import { S3Client } from "@aws-sdk/client-s3"; const accessKeyId = "your-access-key"; const secretAccessKey = ""; // intentionally empty const s3Client = new S3Client({ region: "eu-west-2", endpoint: "http://localhost:8734/~s3@1.0", credentials: { accessKeyId, secretAccessKey, }, forcePathStyle: true, }); ``` #### 2- create bucket ```js async function createBucket(bucketName) { try { const command = new CreateBucketCommand({ Bucket: bucketName }); const result = await s3Client.send(command); console.log("Bucket created:", result.Location || bucketName); } catch (error) { console.error("Error creating bucket:", error); } } ``` #### 3- get object (with range) ```js async function getObject(bucketName, key) { try { console.log(`Getting object: ${bucketName}/${key}`); const command = new GetObjectCommand({ Bucket: bucketName, Key: key, Range: "bytes=-1", }); const result = await s3Client.send(command); const bodyContents = await result.Body.transformToString(); console.log("Object retrieved successfully!"); console.log("Content:", bodyContents); console.log("Metadata:", { ContentType: result.ContentType, ContentLength: result.ContentLength, ETag: result.ETag, LastModified: result.LastModified, }); return result; } catch (error) { console.error("Error getting object:", error.name, error.message); throw error; } } ``` #### 4- put object (with expiry) ```js async function PutObject(bucketName, fileName, body, expiryDays) { try { const command = new PutObjectCommand({ Bucket: bucketName, Key: fileName, Body: body, Metadata: { "expiry-days": expiryDays.toString(), }, }); const result = await s3Client.send(command); console.log("Object created:", fileName, "with expiry:", expiryDays); return result; } catch (error) { console.error("Error creating object", error); } } ``` #### 5- Generate presigned get\_object url ```bash curl -X POST http://localhost:8734/~s3@1.0/get-presigned -H "Content-Type: application/json" -H "Authorization: AWS4-HMAC-SHA256 Credential=YOUR-ACCESS-KEY-ID/20230101/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=dummy" -d '{"bucket": "BUCKET-NAME", "key": "OBJECT-KEY", "duration": DURATION_IN_SECONS}' # 1s-7days ``` 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**_ ```bash curl "http://localhost:8734/~s3@1.0/cache/BUCKET_NAME/OBJECT_KEY" ``` > cache vs S3 API `GetObjectCommand` : `curl "http://localhost:8734/~s3@1.0/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`) ```erlang s3_bucket => <<"offchain-dataitems">> % you can change the name ``` **2- add test data** Make sure to create the `~s3@1.0` 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 `~s3@1.0` bucket. ```bash curl -X PUT "http://localhost:8734/~s3@1.0/offchain-dataitems/dataitems/ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA.ans104" \ -H "Content-Type: application/octet-stream" \ -H "Authorization: AWS4-HMAC-SHA256 Credential=YOUR_ACCESS_KEY_ID/20250119/us-east-1/s3/aws4_request, SignedHeaders=host;x-amz-date, Signature=dummy" \ --data-binary @ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA.ans104 ``` Otherwise, you can generate a signed valid ANS-104 dataitem using the hyperbeam erlang shell: ```erlang 1> rr("src/ar_tx.erl"). % load tx record definition 2> TX = #tx{data = <<"Hello Load S3">>, tags = [{<<"Content-Type">>, <<"text/plain">>}], format = ans104}. 3> SignedTX = ar_bundles:sign_item(TX, hb:wallet()). 4> ANS104Binary = ar_bundles:serialize(SignedTX). 5> DataItemID = hb_util:encode(hb_tx:id(SignedTX, signed)). 6> file:write_file("TheDataItemId.ans104", ANS104Binary). % After that, store the dataitem on s3 as we did previously or using the s3 sdk/client of your choice. ``` #### 3- test retrieving dataitems * offchain: `http://localhost:8734/ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA` * onchain: `http://localhost:8734/myb2p8_TSM0KSgBMoG-nu6TLuqWwPmdZM5V2QSUeNmM` **Verify dataitem integrity** ```bash curl -I "http://localhost:8734/ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA" ``` **Expected Response:** ```bash HTTP/1.1 200 OK Content-Type: text/plain Data-Protocol: ao Device-Test: ~s3@1.0 access-control-allow-methods: GET, POST, PUT, DELETE, OPTIONS access-control-allow-origin: * access-control-expose-headers: * ao-body-key: data ao-types: status="integer" content-digest: sha-256=:9WV5g4vLNkDev2JHfurtl5OE4XrCfKwjf4zE9SceHyg=: date: Fri, 18 Jul 2025 15:24:11 GMT id: ysAGgm6JngmOAxmaFN2YJr5t7V1JH8JGZHe1942mPbA owner: q4VxGIPsOoT2ce5OsF0eSErdxuMtFexE9tUvY_Gl1tE-w3p6YRy6REuc4t2gDFUFE233PP8l5B-db6a2IzRw8FrEc7eFeu_-sWi-FTnkh3EQ3ExE6D9VpBaocSwlPJmVXGMfC64kkxy1hrh44qpQl-RwI52IP15J5YTLWN_XOzGqPCL94VPRFQtwhiK2FQkAx1iCDCtC_FUWC9CitUnNygTUAt2X5I1oD_e9zoyWyUuEp14TLM0-JDnBzGW1t0BbZZKUw8nvmjkqyErQXOHU4AbSevp7rmb3kmi0qFEqb85flF11sHvl1ABJ9i84cmYOM4Az87Gw5beVdzIwe_1tnlUOdX42-skOuNwNPoSOOrUOXh78_meoHCWk5iwYXCnFIWOdlXl-i9Ts2MCf1Ub0v7UPeLT4mtbdhRyG6iK6nokFGHs6A5t1nce0ItGAO1wpBs_4zK3qwfxKvNwoIHpJARyBof8IKnrr28-RpkNJyhVCRvNueUusANnWNk8zIjWseNF3zLg2w_IxZKrDb7a7u1RDQGHSxDvX8mHNHZKAUcqUVeQau8pyfOcDw7hRPKLPkcoCv28ZusAeS0hibdIXA0CJ0HXzleNLIJhCBGwEmo_n1Fa1_hIEekGKnztkNwtLbhyfLtFuqbT6o_r9LdQ81glhAccc-_OJeTvG-fsYD3s server: Cowboy signature: sig-ahm9fs6tg1al3sq0w-ttpxaba2ztt2by1xnq1f4ih6w=:HGS0k2orTq+gA8t7zNx3ykTwn/lyagXlIB3yWX9AGu+yrLK1klrXo2mbySD3Kglmxw2Wyolj42CiGx4yYqAtvhN9AtS3HwVqf47E2FhmcQYk6dcfdAxaJcEz1lXncSyDAAwT7R/ecqJHHNWqOGHiP/9I9V4gCH6qz+kxXI6y/Z5Nnf9IWuJ8xv8XY37TICHlU8oPnPuLPFuvOVPCUXrzCxR6jP8JaVmx5kAHhMMC60+3CDKc3auoe9uxhMQlshnCShD1J/EzycwVqbfXV7TprqVRJoox/Z9EYdd36QKe303dgb3hO/s2aH/Z8TwLJEz6X0c9Miyt31pRQK+31Ev9QwAeXUbE48KljS/knfpTvNA0gjNIQ6xoz9paLWoHhZ+Ntzp/6fC0amzRZcXD1d5cZ5wxRUp1PUSnkexdi73adYV6UKL9pG4NRtDXpx1rP8H33qV5a7JKnTUrcg7TTuwgtieoB+ZKgAGPPtZUYsTRehSkW3gHFujpO+DsNko3UfhveXk5FpONKm2J+22LoOmLp13/yHdiRoHOIr+W/iPD7ueM3iSxtJFO68Wx6qIWp5PV0L+/trU/nHnDYxCgFNE/lZQvINeBSR8mKfE6ws1MJqoGdOC4ZdcRK11Bk75bjlWZUoz4r9JJGQgaA92xwqGzpWRQzAjGWs4rxhCib8YXLqE=:, sig-iq1nxhxgfzszd_rdcs-qwa_csljm7qwvdxmjr3mca7g=:f4/xQHH6IHbhDg3xIGKd7IRIXmwsrUd4a8XaBmKIRco=: signature-input: sig-ahm9fs6tg1al3sq0w-ttpxaba2ztt2by1xnq1f4ih6w=("Content-Type" "Data-Protocol" "Device-Test" "ao-body-key" "ao-types" "content-digest" "id" "owner" "signature" "signature-input" "status" "tags+link");alg="rsa-pss-sha512";keyid="q4VxGIPsOoT2ce5OsF0eSErdxuMtFexE9tUvY/Gl1tE+w3p6YRy6REuc4t2gDFUFE233PP8l5B+db6a2IzRw8FrEc7eFeu/+sWi+FTnkh3EQ3ExE6D9VpBaocSwlPJmVXGMfC64kkxy1hrh44qpQl+RwI52IP15J5YTLWN/XOzGqPCL94VPRFQtwhiK2FQkAx1iCDCtC/FUWC9CitUnNygTUAt2X5I1oD/e9zoyWyUuEp14TLM0+JDnBzGW1t0BbZZKUw8nvmjkqyErQXOHU4AbSevp7rmb3kmi0qFEqb85flF11sHvl1ABJ9i84cmYOM4Az87Gw5beVdzIwe/1tnlUOdX42+skOuNwNPoSOOrUOXh78/meoHCWk5iwYXCnFIWOdlXl+i9Ts2MCf1Ub0v7UPeLT4mtbdhRyG6iK6nokFGHs6A5t1nce0ItGAO1wpBs/4zK3qwfxKvNwoIHpJARyBof8IKnrr28+RpkNJyhVCRvNueUusANnWNk8zIjWseNF3zLg2w/IxZKrDb7a7u1RDQGHSxDvX8mHNHZKAUcqUVeQau8pyfOcDw7hRPKLPkcoCv28ZusAeS0hibdIXA0CJ0HXzleNLIJhCBGwEmo/n1Fa1/hIEekGKnztkNwtLbhyfLtFuqbT6o/r9LdQ81glhAccc+/OJeTvG+fsYD3s=", sig-iq1nxhxgfzszd_rdcs-qwa_csljm7qwvdxmjr3mca7g=("Content-Type" "Data-Protocol" "Device-Test" "ao-body-key" "ao-types" "content-digest" "id" "owner" "signature" "signature-input" "status" "tags+link");alg="hmac-sha256";keyid="ao" status: 200 tags+link: 24Xx7HqIQkRzm3CtNQxfht5RbHTz12N1Ihwm1B0IIFE transfer-encoding: chunked ``` For more examples & ao processes interactions, check the [test-dataitems](https://github.com/loadnetwork/load_hb/tree/s3-edge/test-dataitems) directory Source code: [https://github.com/loadnetwork/load\_hb/tree/s3-edge/native/s3\_nif](https://github.com/loadnetwork/load_hb/tree/s3-edge/native/s3_nif) File: load-hyperbeam/x402-1.0-device.md (7.25 KB) --------------------------------------- --- description: The first ao token x402 facilitator --- # \~x402@1.0 device {% hint style="warning" %} Thjs was a demo for educational purposes only, for a production ready x402 facilitator on ao, checkout the hyper-x402 section {% endhint %} ## Hyper-x402 [hyper-aos](https://github.com/loadnetwork/x402-ao-facilitator) is an [x402-rs](https://github.com/x402-rs/x402-rs) 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. The hyper-x402 ao facilitator is hosted under [hyper-x402.load.network](https://hyper-x402.load.network/) (supports base & ao) and the best example to showcase it, is via the [axum example](https://github.com/loadnetwork/x402-ao-facilitator/tree/main/examples/x402-axum-example) ### Axum Middleware Example This [example repository](https://github.com/loadnetwork/x402-ao-facilitator/tree/main/examples/x402-axum-example) comes with a tailored axum example that works with the ao network ($AO as payment token). the changes made to `main.rs` are: * fallback to our hosted facilitator if the ENV doesn't set the local facilitator (running at port 8080) * creates a `PriceBuilderTag` set to pay the `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA` address: ```rust let ao_token = USDCDeployment::by_network(Network::Ao).pay_to(MixedAddress::Offchain( "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA".to_string(), )); ``` it's also possible to define a token struct instance on ao without being tied to $AO as payment token (default instance), by using the `by_ao_network` function, at the moment only `AO`, `ARIO` and `USDA` are supported ```rust let usda_token = USDCDeployment::by_ao_network("USDA").pay_to(MixedAddress::Offchain( "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA".to_string(), )); ``` * the route `/protected-route` is protected with a cost of `0.000000000001` $AO * it's required to have a wallet JWK saved in the `./wallet.json` file location (gitignored - use burner!!) in order to complete the test flow (required balance >= 0.000000000001 AO) ### Run the test In order to GET the `/protected-route` and pay to access its gated content, you need to: * run the axum server binaries: `cargo run --bin x402-axum-example` * run the script that automates accessing the protected endpoint and handles the payment creation and submission: `cargo run --bin ao_payment_helper` Expected result: ```bash status=200 OK body=This is a VIP content! ``` onchain proof: https://www.ao.link/#/message/\_zrmkURCLrHOKWzsErmFTEdXzcUEur1iWGErepju3w0 ## \[OLD] \~x402@1.0 device ### About The `~x402@1.0` device is the first x402-compliant facilitator implemented with native ao token support, built as a HyperBEAM device (NIF). This facilitator's API follows the spec used in [x402-rs](https://github.com/x402-rs/x402-rs). > **N.B:** The `~x402@1.0` is an early WIP facilitator with partial x402-standard API compatibility. Promising work is being done, but treat it as a PoC for now - endpoint: https://x402-node-1.load.network/\~x402@1.0/supported ### The Why Following the x402 hype mid-October 2025 and its adoption within the ai agents stack, we asked ourselves: is there any better compute platform for ai agents than ao? Unbiasedly speaking, no. ao's alien compute enables functionalities like onchain verifiable LLMs (already live on the network), API-keyless autonomous trading agents, permissionless access to Arweave's datalake (WeaveDrive), etc. So following that hype, we thought, if a network should be supported in the x402 stack, it's the ao network (and its token standard). Additionally, the encapsulation of the `~x402@1.0` device in the HyperBEAM OS exposes the facilitator natively to the ao canonical stack. To put it shortly: this device can be integrated into an existing EVM/SOL/\* x402 facilitator, adding ao support (maintaining the API schema compatibility) AND offering additional routes for trustless compute infra for ai agents. ### Advantages Compared to EVM-based facilitators, this HyperBEAM device offers: * \~270ms total latency for the complete request lifecycle * native payment history storage via ao's Arweave settlement (GraphQL, state lookup) * potential native route to offer ao's compute alongside the payments railway through a single facilitator * partial-compatibility with the x402 facilitator API standard * micropayments support with near-zero gas fees * no reliance on API keys to function (no JSON-RPC API keys needed) * support for AR/ETH/SOL ANS-104 signatures ### Roadmap | feature | description + status | | :--------------------------------------: | :-----------------------------------------------------------------------------------------------------------------: | | x402-rs API schema minimal compatibility | done | | Client Library | done | | ao tokens support | done | | payments storage | done (native feature via ao) | | server middleware | provide ready-to-use integration for Rust web frameworks such as axum and tower (also /settle /verify routes) - wip | | integration in an x402-rs fork | routing ao requests to `~x402@1.0` from an EVM/SOL facilitator - wip | ### Technical Overview On HyperBEAM’s `~x402@1.0` device, the client’s X-Payment\` header is an AO message, signed by the user serialised as base64 string but not posted to Arweave – technically speaking, a signed ANS-104 dataitem that follows the ao protocol. The HTTP request received by the dev\_x402\_facilitator.erl module is handed to the Rust NIF (x402), where the NIF reconstructs and verifies the dataitem integrity (payment token, transfer amount, Recipient, ao protocol tags, etc), then posts it to the signed dataitem to Arweave and make AO scheduler aware of the message (payment settlement); on success, the erlang device’s counterpart returns the ao message ID along with the unlocked payload data, the whole process takes under a 300ms with near-zero fees, beating the EVM counterpart on speed and price. For an in-practice example, check out the complete flow test here and this [onchain proof](https://www.ao.link/#/message/RoaOrXQZjG7446LrO-EJ1kAybcYDAjQBvw65Jom4H5c) On the other hand, EVM facilitators (e.g. x402-rs) have the same HTTP schema but the payment is an [ERC‑3009](https://eips.ethereum.org/EIPS/eip-3009) `transferWithAuthorization`: the client signs EIP‑712 typed data, the facilitator’s server parses the payload, talks to the target target chain via JSON-RPC (in most cases requires API keys to not get rate limited), and spends gas to execute the transfer on-chain before responding. Directory: load-network-arweave-data-protocols File: load-network-arweave-data-protocols/ln-exex-data-protocol.md (2.75 KB) ------------------------------------------------------------------ --- description: About LN-ExEx Data Protocol on Arweave --- # LN-ExEx Data Protocol ### 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).](../load-network-exex/load-network-exexes/arweave-data-uploader.md) {% hint style="warning" %} After the rebrand from WeaveVM to Load Network, all the data protocol tags have changed the "\*WeaveVM\*" onchain term (Arweave tag) to "\*LN\*" {% endhint %} ### 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: | Tag Name | Tag Value | Description | | ---------------- | -------------------------- | ---------------------------------------------------------------------------------------------------- | | `Protocol` | `LN-ExEx` | Data protocol identifier | | `ExEx-Type` | `Arweave-Data-Uploader` | The Load Network ExEx type | | `Content-Type` | `application/octet-stream` | Arweave data transaction MIME type | | `LN:Encoding` | `Borsh-Brotli` | Transaction's data encoding algorithms | | `Block-Number` | `$value` | Load Network block number | | `Block-Hash` | `$value` | Load Network block hash | | `Client-Version` | `$value` | Load Network Reth client version | | `Network` | `Alphanet vx.x.x` | Load Network Alphanet semver | | `LN:Backfill` | `$value` | Boolean, if the data has been posted by a backfiller (true) or archiver (false or not existing data) | ### LN-ExEx Data Items Uploaders * Reth ExEx Archiver Address: [5JUE58yemNynRDeQDyVECKbGVCQbnX7unPrBRqCPVn5Z](https://viewblock.io/arweave/address/5JUE58yemNynRDeQDyVECKbGVCQbnX7unPrBRqCPVn5Z?tab=items) * Arweave-ExEx-Backfill Address: [F8XVrMQzsHiWfn1CaKtUPxAgUkATXQjXULWw3oVXCiFV](https://viewblock.io/arweave/address/F8XVrMQzsHiWfn1CaKtUPxAgUkATXQjXULWw3oVXCiFV?tab=items) File: load-network-arweave-data-protocols/load-network-precompiles-data-protocol.md (1.92 KB) ----------------------------------------------------------------------------------- --- description: About the Data Protocol of Load Network Precompile Contracts --- # Load Network Precompiles Data Protocol ### About Load Network have precompiled contracts that push data directly to Arweave as ANS-104 data items. One such precompile is the [`0x17`](https://docs.wvm.dev/using-weavevm/weavevm-precompiles#id-1-precompile-0x17-upload-data-from-solidity-to-arweave) precompile (`arweave_upload)`. {% hint style="warning" %} After the rebrand from WeaveVM to Load Network, all the data protocol tags have changed the "\*WeaveVM\*" onchain term (Arweave tag) to "\*LN\*" {% endhint %} #### 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: | Tag Name | Tag Value | Description | | ----------------------- | -------------------------- | ------------------------------------------------------------------ | | `LN:Precompile` | `true` | Data protocol identifier | | `Content-Type` | `application/octet-stream` | Arweave data transaction MIME type | | `LN:Encoding` | `Brotli` | Transaction's data encoding algorithms | | `LN:Precompile-Address` | `$value` | The decimal precompile number (e.g. 0x17 have the Tag Value of 23) | #### Load Network Precompile Data Items Uploaders * Load Network Reth Precompiles Address: [5JUE58yemNynRDeQDyVECKbGVCQbnX7unPrBRqCPVn5Z](https://viewblock.io/arweave/address/5JUE58yemNynRDeQDyVECKbGVCQbnX7unPrBRqCPVn5Z?tab=items) Directory: load-network-exex File: load-network-exex/about-exexes.md (523 B) --------------------------------------- --- description: About Reth Execution Extensions (ExEx) --- # About ExExes 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](https://www.paradigm.xyz/2024/05/reth-exex) In the following pages we will list the ExExes developed and used by Load Network. File: load-network-exex/exex.rs.md (424 B) ---------------------------------- --- description: An open source directory of Reth ExExes --- # ExEx.rs ### About [ExEx.rs](https://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!](https://github.com/weaveVM/exex.rs?tab=readme-ov-file#add-an-exex-object) Directory: load-network-exex/load-network-exexes File: load-network-exex/load-network-exexes/README.md (195 B) ----------------------------------------------------- --- description: Explore Load Network developed ExExes --- # Load Network ExExes In the following section you will explore the Execution Extensions developed by our team to power WeaveVM File: load-network-exex/load-network-exexes/arweave-data-uploader.md (425 B) -------------------------------------------------------------------- --- description: Reth -> Arweave data pipeline --- # Arweave Data Uploader ### About This ExEx is the first data upload pipeline between an Ethereum client (reth) and Arweave, the permanent data storage network. The ExEx uses [AR.IO Turbo Bundler](https://ardrive.io/turbo-bundler/) to bundle data and send it to Arweave. [Get the ExEx code](https://github.com/weaveVM/wvm-reth/tree/main/wvm-apps/wvm-exexed/crates/irys). File: load-network-exex/load-network-exexes/borsh-serializer.md (649 B) --------------------------------------------------------------- --- description: Borsh binary serializer ExEx --- # Borsh Serializer ### About [Borsh](https://github.com/near/borsh) stands for Binary Object Representation Serializer for Hashing and is a binary serializer developed by the [NEAR](https://near.org) 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](https://github.com/weaveVM/wvm-reth/tree/main/wvm-apps/wvm-exexed/crates/wevm-borsh) File: load-network-exex/load-network-exexes/google-bigquery-etl.md (291 B) ------------------------------------------------------------------ --- description: Load Network GBQ ETL ExEx --- # Google BigQuery ETL ### About This ExEx is an Extract-Transform-Load (ETL) process of the JSON-serialized blocks into Google BigQuery. [Get the ExEx code](https://github.com/weaveVM/wvm-reth/tree/main/wvm-apps/wvm-exexed/crates/bigquery) File: load-network-exex/load-network-exexes/load-network-da-exex.md (551 B) ------------------------------------------------------------------- --- description: LN-DA plugin ExEx --- # Load Network DA ExEx ### 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](https://github.com/weaveVM/wvm-reth/tree/dev/wvm-apps/wvm-exexed/crates/exex-wvm-da) & [installing setup guide here](../../load-network-for-evm-chains/da-exex-reth-only.md) File: load-network-exex/load-network-exexes/load-network-weavedrive-exex.md (436 B) --------------------------------------------------------------------------- --- description: Load Network AO's WeaveDrive ExEx --- # Load Network WeaveDrive ExEx Load Network has created the first Reth ExEx that attest data to AO network following the WeaveDrive data protocol specification — check [code integration](https://github.com/weaveVM/wvm-reth/blob/main/wvm-apps/wvm-exexed/crates/reth-exexed/src/exex/ar_actor.rs#L299) & learn more about [WeaveDrive (AOP-5)](https://hackmd.io/@ao-docs/H1JK_WezR) Directory: load-network-for-evm-chains File: load-network-for-evm-chains/da-exex-reth-only.md (1.61 KB) ------------------------------------------------------ --- description: Plug Load Network high-throughput DA into any Reth node --- # DA ExEx (Reth-only) ### 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:

.env

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:

network.json

For a more detailed setup guide for your network, check out this [guide](https://github.com/weaveVM/wvm-archiver?tab=readme-ov-file#add-your-network). Finally, to implement the Load Network DA ExEx in your Reth client, simply import the DA ExEx code into your ExExes directory and it will work off the shelf with your Reth setup. [Get the code here](https://github.com/weaveVM/wvm-reth/tree/dev/wvm-apps/wvm-exexed/crates/exex-wvm-da). File: load-network-for-evm-chains/deploying-op-stack-rollups.md (2.28 KB) --------------------------------------------------------------- --- description: Guidance on How To Deploy OP-Stack Rollups on Load Network --- # Deploying OP-Stack Rollups ### About the OP Stack The [OP Stack](https://docs.optimism.io/stack/getting-started) 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. ### OP Stack Rollups on Load Network We’ve built on top of the [Optimism Monorepo](https://github.com/ethereum-optimism/optimism) to enable the deployment of optimistic rollups using LN as the L1. The key difference between deploying OP rollups on Load Network versus Ethereum is that when you send data batches to LN, your rollup data is also permanently archived on Arweave via to [LN’s Execution Extensions (ExExes).](../load-network-exex/exex.rs.md) 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. **We’ve released a detailed technical guide on GitHub for developers looking to deploy OP rollups on Load Network. Check it out** [**here**](https://github.com/weaveVM/developers/blob/main/guides/op-rollup-deployment.md) **and the** [**LN’s fork of Optimism Monorepo here**.](https://github.com/weaveVM/optimism/tree/deploy-op-stack-rollup-on-wvm-l1) File: load-network-for-evm-chains/ledger-archiver-any-chain.md (3.18 KB) -------------------------------------------------------------- --- description: Connect any EVM network to Load Network --- # Ledger Archiver (any chain) ### 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: [https://github.com/WeaveVM/wvm-archiver](https://github.com/WeaveVM/wvm-archiver) ### Networks Using LN Archiver | Network | Archiver Repo | Archiver Endpoint | | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- | | [Metis](https://metis.io) | [https://github.com/WeaveVM/wvm-archiver ](https://github.com/WeaveVM/wvm-archiver) | [https://metis.load.rs/v1/info ](https://metis.load.rs/v1/info) | | [RSS3](https://rss3.io) | [https://github.com/WeaveVM/rss3-wvm-archiver ](https://github.com/WeaveVM/rss3-wvm-archiver) | [https://rss3.load.rs/v1/info ](https://rss3.load.rs/v1/info) | | [GOAT Network](https://goat.network) | [https://github.com/WeaveVM/goat-wvm-archiver ](https://github.com/WeaveVM/goat-wvm-archiver) | [https://goat.load.rs/v1/info ](https://goat.load.rs/v1/info) | | [Avalanche c-chain](https://subnets.avax.network/c-chain) | [https://github.com/WeaveVM/avalanche-wvm-archiver](https://github.com/WeaveVM/avalanche-wvm-archiver) | [https://avalanche.load.rs/v1/info ](https://avalanche.load.rs/v1/info) | | [Dymension L1 Hub](https://dymension.xyz) | [https://github.com/WeaveVM/dymension-wvm-archiver](https://github.com/WeaveVM/dymension-wvm-archiver) | [https://dymension.load.rs/v1/info](https://dymension.load.rs/v1/info) | | [Humanode EVM](https://humanode.io/) | [https://github.com/weaveVM/humanode-wvm-archiver](https://github.com/weaveVM/humanode-wvm-archiver) | [https://humanode.load.rs/v1/info](https://humanode.load.rs/v1/info) | | [Scroll Mainnet](https://scroll.io/) | [https://github.com/weaveVM/scroll-wvm-archiver](https://github.com/weaveVM/scroll-wvm-archiver) | [https://scroll.load.rs/v1.info](https://scroll.load.rs/v1.info) | | [phala-mainnet-0](https://hub.conduit.xyz/phala-mainnet-0) | [https://github.com/weaveVM/phala-wvm-archiver](https://github.com/weaveVM/phala-wvm-archiver) | [https://phala.load.rs/v1.info](https://phala.load.rs/v1.info) | File: load-network-for-evm-chains/ledger-archivers-state-reconstruction.md (4.13 KB) -------------------------------------------------------------------------- --- description: Reconstruction an EVM network using using its load-archiver node instance --- # Ledger Archivers: State Reconstruction ### **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. ![EVM Tries](https://gateway.wvm.network/bundle/0x675c3ee485cdc7e8a87b7cf3b109eb0b7558785855f503b42fc7c9ac46093cbb/0) #### **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: ```rust 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 { 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 This proof-of-concept implementation is available on GitHub: [https://github.com/weaveVM/evm-state-reconstructing](https://github.com/weaveVM/evm-state-reconstructing) ![LN State Reconstuction Flow](https://gateway.wvm.network/bundle/0x675c3ee485cdc7e8a87b7cf3b109eb0b7558785855f503b42fc7c9ac46093cbb/1) [Load Network Archivers](ledger-archiver-any-chain.md) 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. File: quickstart.md (5.83 KB) ------------------- --- description: Get set up with the onchain data center icon: bolt --- # Quickstart {% hint style="info" %} To easily feed Load Network docs to your favourite LLM, access the compressed knowledge (aka LLM.txt) file from Load Network: [llmtxt.xyz/g/loadnetwork/gitbook-sync/25](https://llmtxt.xyz/g/loadnetwork/gitbook-sync/25) (last update: 22/12/2025, 10:00:00 UTC) {% endhint %} 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: * [Uploading data](quickstart.md#upload-data) * [Using ARIO's Turbo SDK](quickstart.md#using-arios-turbo-sdk) * [Integrating ledger storage](quickstart.md#integrating-ledger-storage) * [Using Load DA](quickstart.md#using-load-da) * [Migrate from another storage layer](quickstart.md#migrate-from-another-storage-layer) ### Upload data #### As a non-developer: LCP The easiest way to interface with Load Network storage capabilities is through the cloud web app: [cloud.load.network](https://cloud.load.network/), Load Cloud Platform. The LCP platform is powered by HyperBEAM's LS3 storage layer and offer programmatic access through load\_acc API keys.
#### As a developer #### Load S3 Temporary Data Storage Layer (highly recommended) The best data pipeline for massive uploads is to use the Load \~s3@1.0 HyperBEAM powered [storage layer](load-cloud-platform-lcp/load-s3-layer-ls3.md). The LS3 storage layer, run through a special set of HyperBEAM nodes, have the S3 objects serialized as ANS-104 DataItems by default, maintaining provenance and integrity when the uploader wishes to move the S3 object from the temporal storage layer to Arweave in a single [HTTP API request](load-cloud-platform-lcp/load-s3-agent-http-api.md). #### Highly scalable bundling service To load huge amount of data to Load Network EVM L1 without being tied to the technical network limitations (tx size, block size, network throughput), you can use the load0 bundling service. It's a straightforward REST-based bundling service that let you upload data and retrieve it instantly, at scale: ```bash curl -X POST "https://load0.network/upload" \ --data-binary "@./video.mp4" \ -H "Content-Type: video/mp4" ``` For more examples, check out the [load0 documentation](using-load-network/miscellaneous/load0-data-layer.md) ### Using ARIO's Turbo SDK One of the coolest features offered by the LS3 layer's compatibility with the ANS-104 data standard is the out-of-the-box compatibility with the Arweave ecosystem despite being an offchain temporary storage layer. For that reason, we have built an ANS-104 upload service on top of LS3, compatible with ARIO's Turbo standard, meaning you can use the Turbo official SDK along with Load's custom upload service endpoint to store temporary Arweave dataitems. [check out how to use it ](load-cloud-platform-lcp/turbo-offchain-upload-service.md) and learn more about `xANS-104` data provenance, lineage and governance [here](https://blog.load.network/xans-104/). ### 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. [Clone the archiver repo here](https://github.com/WeaveVM/wvm-archiver) As well as storing all real-time and historical data, Load Network can be used to reconstruct full chain state, effectively replicating exactly what archive nodes do, but with a decentralized storage layer underneath. Read [here](https://blog.load.network/state-reconstruction/) to learn how. ### 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: 1. [As a blob storage layer for EigenDA](da-integrations/ln-eigenda-proxy-server.md) 2. [As a DA layer for Dymension RollApps](da-integrations/ln-dymension-da-client-for-rollap.md) 3. [As an OP-Stack rollup](load-network-for-evm-chains/deploying-op-stack-rollups.md) 4. DIY DIY docs are a work in progress, but the [commit](https://github.com/dymensionxyz/dymint/commit/0140460c75bce6dc1cdcaf15527792734a0f7501) to add support for Load Network in Dymension can be used as a guide to implement Load DA elsewhere. {% hint style="info" %} Work with us to use Load DA for your chain - get onboarded [here](https://calendly.com/decentlandlabs/founders-chat). {% endhint %} ### 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. #### Load S3 Storage Layer The [HyperBEAM Load S3 node](load-cloud-platform-lcp/load-s3-layer-ls3.md) provides a 1:1 compatible development interface for applications using AWS S3 for storage, keeping method names and parameters in tact so the only change should be one line: the endpoint. #### Filecoin The load-lassie import tool is the recommended way to easily migrate data stored via Filecoin. Just provide the CID you want to import to the API, e.g.: `https://lassie.load.rs/import/` The importer is also self-hostable and further documented [here](https://github.com/weaveVM/wvm-lassie). #### Swarm Switching from Swarm to Load is as simple as changing the gateway you already use to resolve content from Swarm. * before: [https://api.gateway.ethswarm.org/bzz/](https://api.gateway.ethswarm.org/bzz/)\ * after: [https://swarm.load.rs/bzz/](https://swarm.wvm.network/bzz/)\ 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. Directory: using-load-network File: using-load-network/compatibility-and-performance.md (685 B) --------------------------------------------------------- --- description: Load Network Compatibility with the standards --- # Compatibility & Performance ### 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 File: using-load-network/compute.md (1.82 KB) ----------------------------------- --- description: Explore compute options available with Load Network --- # Compute 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 [high throughput](../about-load-network/key-features.md) to enable data-intensive dApps. [Connect to Load Alphanet RPC here](network-configurations.md). #### Lua / WASM compute Load Network is a hybrid of the EVM and AO's HyperBEAM. The Load Network team runs HyperBEAM instances (permissionless nodes running the AO compute canonical stack), therefore it's possible to leverage the highly scalable AO compute (processes, hyper-aos, Lua serverless functions) within the Load stack. [Connect to a node here](../). Additionally, we have developed an EVM compute layer (bytecode calculator) as a HyperBEAM device. [Learn more](../load-hyperbeam/evm-1.0-device.md). #### GPU compute More over in HyperBEAM land, the Kernel Execution Machine ([\~kem@1.0 device](../load-hyperbeam/kem-1.0-device.md)) allows for quasi-arbitrary GPU-instructions compute execution for `.wgsl` functions (shaders, kernels). [Get started](../load-hyperbeam/kem-1.0-device.md). #### Reth Execution Extensions (ExEx) Although this is not compute for the user/consumer level, Load maintains several Reth execution extensions (post block-execution compute logic) that can benefits the Reth and the wider EVM developers set. [Learn more](../load-network-exex/about-exexes.md). Directory: using-load-network/evm-bundler-legacy File: using-load-network/evm-bundler-legacy/0xbabe2-large-data-uploads.md (9.29 KB) ------------------------------------------------------------------------- --- description: >- Using Load Network's 0xbabe2 transaction format for large data uploads - the largest EVM transaction in history --- # 0xbabe2: Large Data Uploads ### 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](https://explorer.wvm.dev/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 ](/broken/pages/34Pcu1DGTIgvEMBj7DfH)level. If you want higher limits, you can achieve this by changing a simple constant! {% hint style="success" %} If you have 10 hours to spare, make several teas and watch this 1 GB video streamed to you onchain from the Load Network!\ \ 0xbabe2 txid: [https://bundler.load.rs/v2/resolve/0x45cfaff6c3a507b1b1e88ef502ce32f93e7f515d9580ea66c340dc69e9d47608](https://bundler.load.rs/v2/resolve/0x45cfaff6c3a507b1b1e88ef502ce32f93e7f515d9580ea66c340dc69e9d47608) {% endhint %} ### 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 [Bundler documentation](https://github.com/weaveVM/bundler?tab=readme-ov-file#architecture-design). {% hint style="info" %} with the upcoming Load Network network release (Alphanet v0.5.0) reaching 1 gigagas/s – 0xbabe2 data size limit will double to 492GB, almost 0.5TB EVM transaction. {% endhint %} ### 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: ```rust use bundler::utils::core::large_bundle::LargeBundle; async fn send_large_bundle_single_thread() -> Result { 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: ```rust 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. ```rust async fn send_large_bundle_multi_thread() -> Result { // 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** ```rust async fn retrieve_large_bundle() -> Result, Error> { let large_bundle = LargeBundle::retrieve_chunks_receipts( "0xb58684c24828f8a80205345897afa7aba478c23005e128e4cda037de6b9ca6fd".to_string(), ) .await? .reconstruct_large_bundle() .await?; Ok(large_bundle) } ``` **REST API** ```bash curl -X GET https://bundler.load.rs/v2/resolve/$0xBABE2_TXID ``` ### What you can fit in a 492GB 0xbabe2 transaction #### Modern LLMs | Model | What Can Fit in one 0xbabe2 transaction | | -------------------------------- | -------------------------------------------- | | Claude 3 Haiku (70B params) | 3.51 models (16-bit) or 14.06 models (4-bit) | | Claude 3 Sonnet (175B params) | 1.41 models (16-bit) or 5.62 models (4-bit) | | Claude 3 Opus (350B params) | 0.70 models (16-bit) or 2.81 models (4-bit) | | Claude 3.5 Sonnet (250B params) | 0.98 models (16-bit) or 3.94 models (4-bit) | | Claude 3.7 Sonnet (300B params) | 0.82 models (16-bit) or 3.28 models (4-bit) | | GPT-4o (1500B params est.) | 0.16 models (16-bit) or 0.66 models (4-bit) | | GPT-4 Turbo (1100B params est.) | 0.22 models (16-bit) or 0.89 models (4-bit) | | Llama 3 70B | 3.51 models (16-bit) or 14.06 models (4-bit) | | Llama 3 405B | 0.61 models (16-bit) or 2.43 models (4-bit) | | Gemini Pro (220B params est.) | 1.12 models (16-bit) or 4.47 models (4-bit) | | Gemini Ultra (750B params est.) | 0.33 models (16-bit) or 1.31 models (4-bit) | | Mistral Large (123B params est.) | 2.00 models (16-bit) or 8.00 models (4-bit) | #### Blockchain Data | Data Type | What Can Fit in one 0xbabe2 transaction | | -------------------------------------------- | --------------------------------------- | | Solana's State Snapshot (\~70GB) | \~7 instances | | Bitcoin Full Ledger (\~625 GB) | \~78% of the ledger | | Ethereum Full Ledger (\~1250 GB) | \~40% of the ledger | | Ethereum blobs (\~2.64 GB per day) | \~186 days worth of blob data | | Celestia's max throughput per day (112.5 GB) | 4.37× capacity | #### Media Files | File Type | What Can Fit in one 0xbabe2 transaction | | ---------------------------------- | --------------------------------------- | | MP3 Songs (4MB each) | 123,000 songs | | Full HD Movies (5GB each) | 98 movies | | 4K Video Footage (2GB per hour) | 246 hours | | High-Resolution Photos (3MB each) | 164,000 photos | | Ebooks (5MB each) | 100,000 books | | Documents/Presentations (1MB each) | 492,000 files | #### Other Data | Data Type | What Can Fit in one 0xbabe2 transaction | | ------------------------------------ | --------------------------------------- | | Database Records (5KB per record) | 98 billion records | | Virtual Machine Images (8GB each) | 61 VMs | | Docker container images (500MB each) | 1,007 containers | | Genome sequences (4GB each) | 123 genomes | File: using-load-network/evm-bundler-legacy/README.md (631 B) ----------------------------------------------------- # EVM Bundler (legacy) **Since** [**Load S3** ](../../load-cloud-platform-lcp/load-s3-layer-ls3.md)**and**[ **Load Cloud Platform**](../../load-cloud-platform-lcp/cloud-platform-lcp.md) **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 * Powered by AO and HyperBEAM * Equipped with a bigger set of dev tools and APIs, offering higher stability However, we will keep this legacy section for EVM Bundlers in the docs for backward compatibility - soon it will enter sunsetting phase. File: using-load-network/evm-bundler-legacy/bundlers-gateways.md (3.79 KB) ---------------------------------------------------------------- --- description: 'The Load Network Gateway Stack: Fast, Reliable Access to Load Network Data' --- # Bundlers Gateways 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 [relic.bot](https://relic.bot) – 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 [JavaScript-based cache-enabled gateway](https://github.com/weaveVM/resolver.bot), and [one written in Rust](https://github.com/weaveVM/rusty-gateway/tree/main). 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. For [relic.bot](http://relic.bot/), this slashed feed loading times from 6-8 seconds to near-instant. **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: ```bash git clone https://github.com/weavevm/bundles-gateway.git cd bundles-gateway docker compose up -d ``` For rustaceans, rusty-gateway is deployable on a Rust host like [shuttle.dev](http://shuttle.dev/) – get the repo [here](https://github.com/WeaveVM/rusty-gateway) and Shuttle deployment docs [here](https://docs.shuttle.dev/introduction/docs). ### **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: * [gateway.wvm.rs](http://gateway.wvm.rs/) - [gateway.load.rs](https://gateway.load.rs) * [gateway.wvm.nerwork](https://gateway.wvm.nerwork) * [resolver.bot](http://resolver.bot/) File: using-load-network/evm-bundler-legacy/load-network-bundler.md (24.81 KB) ------------------------------------------------------------------- --- description: >- The LN Bundler is the fastest, cheapest and most scalable way to store EVM data onchain --- # Load Network Bundler ### :zap: Quickstart To upload data to Load Network with the alphanet bundling service, see [here](https://docs.load.network/quickstart#upload-data) in the quickstart docs for the [upload SDK](https://github.com/weaveVM/bundler-upload-sdk) and [example repository](https://github.com/weaveVM/bundler-upload-example). ### About Load Network Bundler is a data protocol specification and library that introduces the first bundled EVM transactions format. This protocol draws inspiration from Arweave's [ANS-102](https://github.com/ArweaveTeam/arweave-standards/blob/master/ans/ANS-102.md) specification. _**Bundler as data protocol and library is still in PoC (Proof of Concept) phase - not recommended for production usage, testing purposes only.**_ For the JS/TS version of LN bundles, [click here](https://github.com/weavevm/weavevm-bundles-js). #### 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. ```rust pub struct BundleData { pub envelopes: Vec, } ```

Envelope Lifecycle

#### Bundles Versioning Bundles versioning is based on the bundles target address: | Bundle Version | Bundler Target Acronym | Bundler Target Address | | :------------: | :--------------------: | :-----------------------------------------------------------------------------------------------------------------------: | | v0.1.0 | `0xbabe1` | [0xbabe1d25501157043c7b4ea7CBC877B9B4D8A057](https://explorer.wvm.dev/address/0xbabe1d25501157043c7b4ea7CBC877B9B4D8A057) | | v0.2.0 | `0xbabe2` | [0xbabe2dCAf248F2F1214dF2a471D77bC849a2Ce84](https://explorer.wvm.dev/address/0xbabe2dCAf248F2F1214dF2a471D77bC849a2Ce84) | #### 2. Envelope Format An envelope is a signed Legacy EVM transaction with the following MUSTs and restrictions. ```rust 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>, } ``` 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.

EVM transaction types - size in bytes

#### 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 A Large Bundle is a bundle under version 0xbabe2 that exceeds the Load Network L1 and `0xbabe1` transaction size limits, introducing incredibly high size efficiency to data settling on LN. For example, with [Alphanet v0.4.0](https://blog.wvm.dev/alphanet-v4) running @ 500 mgas/s, a Large Bundle has a max size of 246 GB. For the sake of DevX and simplicity of the current 0xbabe2 stack, Large Bundles in the Bundler SDK have been limited to 2GB, while on the network level, the size is 246GB. #### 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. ```rust 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.

0xbabe2 transaction lifecycle

#### 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 | Network gaslimit | L1 tx input size | 0xbabe1 size | 0xbabe2 size | | :--------------------: | :--------------: | :----------: | :----------: | | 500 mgas/s (current) | 4MB | 4MB | 246 GB | | 1 gigagas/s (upcoming) | 8MB | 8MB | 492 GB | ### Bundler Library #### Import Bundler in your project ```toml bundler = { git = "https://github.com/weaveVM/bundler", branch = "main" } ``` #### 0xbabe1 Bundles **Build an envelope, build a bundle** ```rust 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** ```rust async fn send_bundle_without_target() -> eyre::Result { // will fail until a tLOAD funded EOA (pk) is provided let private_key = String::from(""); let mut envelopes: Vec = 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** ```rust async fn send_envelope_with_tags() -> eyre::Result { // will fail until a tLOAD funded EOA (pk) is provided let private_key = String::from(""); let mut envelopes: Vec = 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** ```rust use bundler::utils::core::large_bundle::LargeBundle; async fn send_large_bundle_without_super_account() -> eyre::Result { 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** ```rust 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** ```rust async fn retrieve_large_bundle() -> eyre::Result> { let large_bundle = LargeBundle::retrieve_chunks_receipts( "0xb58684c24828f8a80205345897afa7aba478c23005e128e4cda037de6b9ca6fd".to_string(), ) .await? .reconstruct_large_bundle() .await?; Ok(large_bundle) } ``` For more examples, check the tests in [lib.rs](https://github.com/weaveVM/bundler/blob/main/src/lib.rs). ### HTTP API * Base endpoint: [https://bundler.load.rs/](https://bundler.load.rs/) #### Retrieve full envelopes data of a given bundle ```bash GET /v1/envelopes/:bundle_txid ``` #### Retrieve full envelopes data of a given bundle (with `from`'s envelope property derived from sig) ```bash GET /v1/envelopes-full/:bundle_txid ``` #### Retrieve envelopes ids of a given bundle ```bash 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) ```bash GET /v2/resolve/:large_bundle_txid ``` ### Cost Efficiency: some comparisons #### SSTORE2 VS LN L1 calldata
View comparison table In the comparison below, we tested data settling of 1MB of non-zero bytes. LN's pricing of non-zero bytes (8 gas) and large transaction data size limit (8MB) allows us to fit the whole MB in a single transaction, paying a single overhead fee. | Chain | File Size (bytes) | Number of Contracts/Tx | Gas Used | Gas Price (Gwei) | Cost in Native | Native Price (USD) | Total (USD) | | ------------------------ | ----------------- | ---------------------- | -------------------------------------------------- | ------------------------ | --------------------------- | ------------------ | ----------- | | LN L1 Calldata | 1,000,000 | 1 | 8,500,000 (8M for calldata & 500k as base gas fee) | 1 Gwei | - | - | \~$0.05 | | Ethereum L1 | 1,000,000 | 41 | 202,835,200 gas | 20 Gwei | 4.056704 | $3641.98 | $14774.43 | | Polygon Sidechain | 1,000,000 | 41 | 202,835,200 gas | 40 Gwei (L1: 20 Gwei) | 8.113408 | $0.52 | $4.21 | | BSC L1 | 1,000,000 | 41 | 202,835,200 gas | 5 Gwei | 1.014176 | $717.59 | $727.76 | | Arbitrum (Optimistic L2) | 1,000,000 | 41 | 202,835,200 gas (+15,000,000 L1 gas) | 0.1 Gwei (L1: 20 Gwei) | 0.020284 (+0.128168 L1 fee) | $3641.98 | $540.66 | | Avalanche L1 | 1,000,000 | 41 | 202,835,200 gas | 25 Gwei | 5.070880 | $43.90 | $222.61 | | Base (Optimistic L2) | 1,000,000 | 41 | 202,835,200 gas (+15,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.000203 (+0.128168 L1 fee) | $3641.98 | $467.52 | | Optimism (Optimistic L2) | 1,000,000 | 41 | 202,835,200 gas (+15,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.000203 (+0.128168 L1 fee) | $3641.98 | $467.52 | | Blast (Optimistic L2) | 1,000,000 | 41 | 202,835,200 gas (+15,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.000203 (+0.128168 L1 fee) | $3641.98 | $467.52 | | Linea (ZK L2) | 1,000,000 | 41 | 202,835,200 gas (+12,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.010142 (+0.072095 L1 fee) | $3641.98 | $299.50 | | Scroll (ZK L2) | 1,000,000 | 41 | 202,835,200 gas (+12,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.010142 (+0.072095 L1 fee) | $3641.98 | $299.50 | | Moonbeam (Polkadot) | 1,000,000 | 41 | 202,835,200 gas (+NaN L1 gas) | 100 Gwei | 20.283520 | $0.27 | $5.40 | | Polygon zkEVM (ZK L2) | 1,000,000 | 41 | 202,835,200 gas (+12,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.010142 (+0.072095 L1 fee) | $3641.98 | $299.50 | | Solana L1 | 1,000,000 | 98 | 490,000 imports | N/A | 0.000495 (0.000005 deposit) | $217.67 | $0.11 |
#### SSTORE2 VS LN L1 Calldata VS LN Bundler 0xbabe1
View comparison table Now let's take the data even higher, but for simplicity, let's not fit the whole data in a single LN L1 calldata transaction. Instead, we'll split it into 1MB transactions (creating multiple data settlement overhead fees): 5MB, 5 txs of 1 MB each: | Chain | File Size (bytes) | Number of Contracts/Tx | Gas Used | Gas Price (Gwei) | Cost in Native | Native Price (USD) | Total (USD) | | ------------------------ | ----------------- | ---------------------- | ---------------------------------------------------- | ------------------------ | --------------------------- | ------------------ | ------------- | | LN Bundler 0xbabe1 | 5,000,000 | 1 | 40,500,000 (40M for calldata & 500k as base gas fee) | 1 Gwei | - | - | \~$0.25-$0.27 | | LN L1 Calldata | 5,000,000 | 5 | 42,500,000 (40M for calldata & 2.5M as base gas fee) | 1 Gwei | - | - | \~$0.22 | | Ethereum L1 | 5,000,000 | 204 | 1,009,228,800 gas | 20 Gwei | 20.184576 | $3650.62 | $73686.22 | | Polygon Sidechain | 5,000,000 | 204 | 1,009,228,800 gas | 40 Gwei (L1: 20 Gwei) | 40.369152 | $0.52 | $20.95 | | BSC L1 | 5,000,000 | 204 | 1,009,228,800 gas | 5 Gwei | 5.046144 | $717.75 | $3621.87 | | Arbitrum (Optimistic L2) | 5,000,000 | 204 | 1,009,228,800 gas (+80,000,000 L1 gas) | 0.1 Gwei (L1: 20 Gwei) | 0.100923 (+0.640836 L1 fee) | $3650.62 | $2707.88 | | Avalanche L1 | 5,000,000 | 204 | 1,009,228,800 gas | 25 Gwei | 25.230720 | $44.01 | $1110.40 | | Base (Optimistic L2) | 5,000,000 | 204 | 1,009,228,800 gas (+80,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.001009 (+0.640836 L1 fee) | $3650.62 | $2343.13 | | Optimism (Optimistic L2) | 5,000,000 | 204 | 1,009,228,800 gas (+80,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.001009 (+0.640836 L1 fee) | $3650.62 | $2343.13 | | Blast (Optimistic L2) | 5,000,000 | 204 | 1,009,228,800 gas (+80,000,000 L1 gas) | 0.001 Gwei (L1: 20 Gwei) | 0.001009 (+0.640836 L1 fee) | $3650.62 | $2343.13 | | Linea (ZK L2) | 5,000,000 | 204 | 1,009,228,800 gas (+60,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.050461 (+0.360470 L1 fee) | $3650.62 | $1500.16 | | Scroll (ZK L2) | 5,000,000 | 204 | 1,009,228,800 gas (+60,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.050461 (+0.360470 L1 fee) | $3650.62 | $1500.16 | | Moonbeam (Polkadot) | 5,000,000 | 204 | 1,009,228,800 gas (+NaN L1 gas) | 100 Gwei | 100.922880 | $0.27 | $26.94 | | Polygon zkEVM (ZK L2) | 5,000,000 | 204 | 1,009,228,800 gas (+60,000,000 L1 gas) | 0.05 Gwei (L1: 20 Gwei) | 0.050461 (+0.360470 L1 fee) | $3650.62 | $1500.16 | | Solana L1 | 5,000,000 | 489 tx | 2445.00k imports | N/A | 0.002468 (0.000023 deposit) | $218.44 | $0.54 |
#### LN L1 Calldata VS LN Bundler 0xbabe1
View comparison table Let's compare storing 40 MB of data (40 x 1 MB transactions) using two different methods, considering the 8 MB bundle size limit: | Metric | LN L1 Calldata | LN Bundler | | ----------------------- | ---------------------------------- | ----------------------------------------------------- | | Total Data Size | 40 MB | 40 MB | | Transaction Format | 40 separate EIP-1559 transactions | 5 bundle transactions (8MB each, 40 \* 1MB envelopes) | | Transactions per Bundle | 1 MB each | 8 x 1MB per bundle | | Gas Cost per Tx | 8.5M gas (8M calldata + 500k base) | 64.5M gas (64M + 500k base) per bundle | | Number of Base Fees | 40 | 5 | | Total Gas Used | 340M gas (40 x 8.5M) | 322.5M gas (5 x 64.5M) | | Gas Price | 1 Gwei | 1 Gwei | | Total Cost | \~$1.5-1.7 | \~$1.3 | | Cost Savings | - | \~15% cheaper |
#### Table data sources * [Load Network price calculator](https://load.network/calculator) * [EVM storage calculator](https://swader.github.io/soroban/#calculator) ### Source Code [https://github.com/weaveVM/bundler ](https://github.com/weaveVM/bundler) File: using-load-network/json-rpc-methods.md (900 B) -------------------------------------------- --- description: About Load Network Native JSON-RPC methods --- # LN-Native JSON-RPC Methods ### The `eth_getArweaveStorageProof` JSON-RPC method This JSON-RPC method lets you retrieve the Arweave storage proof for a given Load Network block number ```bash 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. ```bash 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"] }] }' ``` Directory: using-load-network/miscellaneous File: using-load-network/miscellaneous/README.md (23 B) ------------------------------------------------ # Miscellaneous File: using-load-network/miscellaneous/arweaves-ans-104-rust-sdk.md (10.02 KB) ------------------------------------------------------------------- --- description: >- bundles-rs is a Rust SDK for creating, signing, managing and posting ANS-104 dataitems --- # Arweave's ANS-104 Rust SDK ### About A Rust SDK for creating, signing, managing and posting [ANS-104 dataitems](https://github.com/ArweaveTeam/arweave-standards/blob/master/ans/ANS-104.md). > 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`: ```toml [dependencies] # main library bundles_rs = { git = "https://github.com/loadnetwork/bundles-rs", branch = "main" } # use individual crates # or use branch/tag/rev -- we recommend checking and using the last client version ans104 = { git = "https://github.com/loadnetwork/bundles-rs", version = "0.1.0" } crypto = { git = "https://github.com/loadnetwork/bundles-rs", version = "0.1.0" } ``` #### Dev setup ```sh git clone https://github.com/loadnetwork/bundles-rs.git cd bundles-rs cargo clippy --workspace --lib --examples --tests --benches --locked --all-features cargo +nightly fmt cargo check --all ``` #### Supported Signers | Blockchain | Signature Type | | :--------: | :------------------------------------: | | Arweave | RSA-PSS | | Ethereum | secp256k1 | | Solana | Ed25519 (with base58 solana flavoring) | | - | Ed25519Core (raw Ed25519) | #### Regarding Tags This ANS-104 dataitems client fully implements the ANS-104 specification as-is | Constraint | bundles-rs | [Spec](https://github.com/ArweaveTeam/arweave-standards/blob/master/ans/ANS-104.md) | [arbundles js](https://github.com/DHA-Team/arbundles) | [HyperBEAM ar\_bundles](https://github.com/permaweb/HyperBEAM/blob/edge/src/ar_bundles.erl) | | :------------------------: | :---------------: | :---------------------------------------------------------------------------------: | :---------------------------------------------------: | :-----------------------------------------------------------------------------------------: | | Maximum tags per data item | <= 128 tags | <= 128 tags | <= 128 tags | No max tags | | Tag name max size | 1024 bytes | 1024 bytes | all keys + vals <= 4096 bytes | Can have empty strings | | Tag value max size | 3072 bytes | 3072 bytes | Can have empty strings | val <= 3072 bytes | | Empty names/values | non empty strings | non empty strings | Can have empty strings | Can have empty strings | ### Usage Examples #### Quick start ```rust use bundles_rs::{ ans104::{data_item::DataItem, tags::Tag}, crypto::ethereum::EthereumSigner, }; #[tokio::main] async fn main() -> Result<(), Box> { // create a signer let signer = EthereumSigner::random()?; // create tags (metadata) let tags = vec![ Tag::new("Content-Type", "text/plain"), Tag::new("App-Name", "Load-Network"), ]; // create and sign a dataitem let data = b"Hello World Arweave!".to_vec(); // first None for Target and the second for Anchor // let target = [0u8; 32]; -- 32-byte target address // let anchor = b"unique-anchor".to_vec(); -- max 32 bytes let item = DataItem::build_and_sign(&signer, None, None, tags, data)?; // get the dataitem id let id = item.arweave_id(); println!("dataitem id: {}", id); // serialize for upload let bytes = item.to_bytes()?; println!("Ready to upload {} bytes", bytes.len()); Ok(()) } ``` **Or for basic signed dataitem** ```rust use bundles_rs::ans104::{data_item::DataItem, tags::Tag}; // create unsigned data item let tags = vec![Tag::new("Content-Type", "application/json")]; let data = br#"{"message": "Hello World"}"#.to_vec(); let mut item = DataItem::new(None, None, tags, data)?; // sign dataitem item.sign(&signer)?; ``` #### Working with signers _**N.B: use random signer generation for testing purposes only**_ **Arweave Signer** ```rust use bundles_rs::crypto::arweave::ArweaveSigner; let signer = ArweaveSigner::from_jwk_file("wallet.json")?; // from stringified JWK let jwk_json = r#"{"kty":"RSA","n":"...","e":"AQAB","d":"..."}"#; let signer = ArweaveSigner::from_jwk_str(jwk_json)?; // random let signer = ArweaveSigner::random()?; // Arweave address let address = signer.address(); println!("Arweave address: {}", address); ``` **Ethereum Signer** ```rust use bundles_rs::crypto::ethereum::EthereumSigner; // generate random key let signer = EthereumSigner::random()?; // or from private key bytes let private_key = hex::decode("your_private_key_hex")?; let signer = EthereumSigner::from_bytes(&private_key)?; // EOA let address = signer.address_string(); println!("Ethereum address: {}", address); ``` **Solana Signer** ```rust use bundles_rs::crypto::solana::SolanaSigner; // random let signer = SolanaSigner::random(); // pk let signer = SolanaSigner::from_base58("your_base58_private_key")?; // from secret bytes let secret = [0u8; 32]; // your secret bytes let signer = SolanaSigner::from_secret_bytes(&secret)?; // Get Solana address let address = signer.address(); println!("Solana address: {}", address); ``` **Ed25519Core Signer** ```rust use bundles_rs::crypto::ed25519::Ed25519Core; // random let signer = Ed25519Core::random(); // from seed bytes let seed = [0u8; 32]; let signer = Ed25519Core::from_secret_bytes(&seed)?; ``` #### Verification **Manual** ```rust // verify signature and structure item.verify()?; // manual verification steps assert_eq!(item.signature.len(), item.signature_type.signature_len()); assert_eq!(item.owner.len(), item.signature_type.owner_len()); ``` **With Signer** ```rust use bundles_rs::crypto::signer::Signer; let message = item.signing_message(); let is_valid = signer.verify(&message, &item.signature)?; assert!(is_valid); ``` #### Deep hash ```rust use bundles_rs::ans104::deep_hash::{DeepHash, deep_hash_sync}; let data = b"custom data"; let hash_structure = DeepHash::List(vec![ DeepHash::Blob(b"custom"), DeepHash::Blob(data), ]); let hash = deep_hash_sync(&hash_structure); println!("Deep hash hex: {}", hex::encode(hash)); ``` #### Upload to Bundling services over HTTP (e.g. [Turbo](https://ardrive.io/turbo-bundler)) ```rust use reqwest::Client; async fn upload_to_turbo(item: &DataItem) -> Result> { let client = Client::new(); let bytes = item.to_bytes()?; let response = client .post("https://turbo.ardrive.io/tx/solana") .header("Content-Type", "application/octet-stream") .body(bytes) .send() .await?; if response.status().is_success() { let tx_id = response.text().await?; Ok(tx_id) } else { Err(format!("Upload failed: {}", response.status()).into()) } } ``` ### 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 [Turbo](https://turbo.ardrive.io/) ### Installation ```toml [dependencies] # main library bundles_rs = { git = "https://github.com/loadnetwork/bundles-rs", branch = "main" } # bundler only bundler = { git = "https://github.com/loadnetwork/bundles-rs", branch = "main" } ``` #### Imports ```rust use bundles_rs::bundler::BundlerClient; use bundles_rs::ans104::{data_item::DataItem, tags::Tag}; use bundles_rs::crypto::solana::SolanaSigner; ``` ### Usage Example #### Send Transaction (Solana) ```rust let client = BundlerClient::new().url("https://upload.ardrive.io").build().unwrap(); let signer = SolanaSigner::random(); let tags = vec![Tag::new("content-type", "text/plain")]; let dataitem = DataItem::build_and_sign(&signer, None, None, tags, b"hello world".to_vec()).unwrap(); let tx = client.send_transaction(dataitem).await.unwrap(); println!("tx: {:?}", tx); ``` #### Send Transaction (Turbo) ```rust let client = BundlerClient::turbo().build().unwrap(); let signer = SolanaSigner::random(); let tags = vec![Tag::new("content-type", "text/plain")]; let dataitem = DataItem::build_and_sign(&signer, None, None, tags, b"hello world turbo".to_vec()).unwrap(); let tx = client.send_transaction(dataitem).await.unwrap(); println!("tx: {:?}", tx); ``` #### Get Default Client Info ```rust let client = BundlerClient::default().build().unwrap(); let info = client.info().await.unwrap(); println!("{:?}", info); ``` #### Get Turbo Client Info ```rust let client = BundlerClient::turbo().build().unwrap(); let info = client.info().await.unwrap(); println!("{:?}", info); ``` #### Get Price for Bytes (Turbo) ```rust let client = BundlerClient::turbo().build().unwrap(); let price = client.bytes_price(99999).await.unwrap(); println!("{:?}", price); ``` #### Get Rates (Turbo) ```rust let client = BundlerClient::turbo().build().unwrap(); let rates = client.get_rates().await.unwrap(); println!("{:?}", rates); ``` #### Check Transaction Status (Turbo) ```rust let client = BundlerClient::turbo().build().unwrap(); let status = client.status("w5n6r6PvqBRph2or4WiyjLumL9HE-IR_JgEcnct_3b0").await.unwrap(); println!("{:?}", status); ``` ### Turbo API References: * upload api: https://upload.ardrive.io/api-docs * payment api: https://payment.ardrive.io/api-docs SDK source code: [https://github.com/loadnetwork/bundles-rs](https://github.com/loadnetwork/bundles-rs) File: using-load-network/miscellaneous/deploying-an-erc20.md (1.28 KB) ------------------------------------------------------------ --- description: Tutoral on how to deploy an ERC20 on Load Network --- # Deploying an ERC20 ### **Add Load Network Alphanet to MetaMask** Before deploying, make sure the Load Network network is configured in your MetaMask wallet. [Check the Network Configurations](../network-configurations.md). ### ERC20 Contract For this example, we will use the ERC20 token template provided by the [OpenZeppelin's](https://docs.openzeppelin.com/contracts/4.x/erc20) smart contract library. ```solidity // 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.

69420 LOADs because why not

After deploying the contract successfully, check your EOA balance!

Success!

File: using-load-network/miscellaneous/load-data-protocol.md (2.70 KB) ------------------------------------------------------------ --- description: Using load:// data retrieval protocol --- # load:// Data Protocol ### 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.

workflow

### 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: ```bash 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. ```bash 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.

/calldata endpoint benchmark

#### Check out the load:// data protocol protocol [here](https://github.com/weavevM/wvm-data-retriever) File: using-load-network/miscellaneous/load0-data-layer.md (2.51 KB) ---------------------------------------------------------- --- description: About Load Network optimistic & high performance data layer --- # load0 data layer `load0` is Bundler's [Large Bundle](https://github.com/weaveVM/bundler?tab=readme-ov-file#large-bundle) on steroids -- a cloud-like experience to upload and download data from [Load Network](https://docs.load.network) using the Bundler's `0xbabe2` transaction format powered with [SuperAccount](https://github.com/weaveVM/bundler?tab=readme-ov-file#superaccount) & S3 under the hood. {% hint style="info" %} To obtain API key and unlock higher limits, create an API key on [cloud.load.network](https://cloud.load.network) {% endhint %} ### 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_.

tx lifecycle

### REST API #### 1- Upload object ```bash curl -X POST "https://load0.network/upload" \ --data-binary "@./video.mp4" \ -H "Content-Type: video/mp4" \ -H "X-Load-Authorization: $YOUR_LCP_AUTH_TOKEN" ``` #### 2- Download object (browser) ```bash GET https://load0.network/download/{optimistic_hash} ``` Also, to have endpoints similiarity as in `bundler.load.rs`, you can do: ```bash GET https://load0.network/resolve/{optimistic_hash} ``` #### 3- Retrieve Bundle metadata using optimistic hash or bundle txid (once settled) ```bash GET https://load0.network/bundle/optimistic/{op_hash} ``` ```bash GET https://load0.network/bundle/load/{bundle_txid} ``` Returns: ```rust 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}` Source code: [https://github.com/loadnetwork/load0/](https://github.com/loadnetwork/load0/) File: using-load-network/miscellaneous/self-hosted-rpc-proxies.md (914 B) ----------------------------------------------------------------- # Self Hosted RPC Proxies ## Rust Proxy ### Run Locally ```bash git clone https://github.com/weavevm/wvm-proxy-rpc.git cd wvm-proxy-rpc cargo build && cargo shuttle run --port 3000 ``` ### Try it! ```bash curl -X POST http://localhost:3000 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' ``` You can find the proxy server codebase here: [https://github.com/weaveVM/wvm-rpc-proxy](https://github.com/weaveVM/wvm-rpc-proxy) ## JavaScript Proxy ### Run Locally ```bash git clone https://github.com/weavevm/proxy-rpc.git cd proxy-rpc npm install && npm run start ``` ### Try it! ```bash curl -X POST http://localhost:3000 -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}' ``` You can find the proxy server codebase here: [https://github.com/weaveVM/proxy-rpc](https://github.com/weaveVM/proxy-rpc) File: using-load-network/network-configurations.md (676 B) -------------------------------------------------- --- description: Load Network Configurations --- # Network configurations ### Alphanet V5 * RPC URL: [https://alphanet.load.network](https://alphanet.load.network) * Chain ID: 9496 * Alphanet Faucet: [https://load.network/faucet](https://load.network/faucet) * Testnet Currency Symbol: tLOAD * Explorer: [https://explorer.load.network](https://explorer.load.network) * Chainlist: [https://chainlist.org/chain/9496](https://chainlist.org/chain/9496) ### Add to MetaMask

Adding Load Alphanet in Metamask

Click on `Networks` > `Add a network` > `Add a network manually` File: using-load-network/supported-precompiles.md (12.87 KB) ------------------------------------------------- --- description: About Load Network precompiled contracts --- # Supported Precompiles ### 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 | Address | Name | Minimum Gas | Input | Output | Description | | --------------------------------------------------- | -------------------------- | ----------- | ---------------------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 0x01 (`0x0000000000000000000000000000000000000001`) | ecRecover | 3000 | hash, v, r, s | publicAddress | Elliptic curve digital signature algorithm (ECDSA) public key recovery function | | 0x02 (`0x0000000000000000000000000000000000000002`) | SHA2-256 | 60 | data | hash | Hash function | | 0x03 (`0x0000000000000000000000000000000000000003`) | RIPEMD-160 | 600 | data | hash | Hash function | | 0x04 (`0x0000000000000000000000000000000000000004`) | identity | 15 | data | data | Returns the input | | 0x05 (`0x0000000000000000000000000000000000000005`) | modexp | 200 | Bsize, Esize, Msize, B, E, M | value | Arbitrary-precision exponentiation under modulo | | 0x06 (`0x0000000000000000000000000000000000000006`) | ecAdd | 150 | x1, y1, x2, y2 | x, y | Point addition (ADD) on the elliptic curve alt\_bn128 | | 0x07 (`0x0000000000000000000000000000000000000007`) | ecMul | 6000 | x1, y1, s | x, y | Scalar multiplication (MUL) on the elliptic curve alt\_bn128 | | 0x08 (`0x0000000000000000000000000000000000000008`) | ecPairing | 45000 | x1, y1, x2, y2, ..., xk, yk | success | Bilinear function on groups on the elliptic curve alt\_bn128 | | 0x09 (`0x0000000000000000000000000000000000000009`) | blake2f | 0 | rounds, h, m, t, f | h | Compression function F used in the BLAKE2 cryptographic hashing algorithm | | 0x0A (`0x000000000000000000000000000000000000000A`) | point evaluation | 50000 | bytes | bytes | Verify p(z) = y given commitment that corresponds to the polynomial p(x) and a KZG proof. Also verify that the provided commitment matches the provided versioned\_hash. | | 0x17 (`0x0000000000000000000000000000000000000017`) | arweave\_upload | 10003 | bytes | bytes | upload bytes array to Arweave and get back the upload TXID in bytes | | 0x18 (`0x0000000000000000000000000000000000000018`) | arweave\_read | 10003 | bytes | bytes | retrieve an Arweave TXID data in bytes | | 0x20 (`0x0000000000000000000000000000000000000020`) | read\_block | 10003 | bytes | bytes | retrieve a LN's block data (from genesis) pulling it from Arweave | | 0x21 (`0x0000000000000000000000000000000000000021`) | kyve\_trustless\_api\_blob | 10003 | bytes | bytes | retrieve a historical Ethereum blob data from LN's smart contract layer | ### 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:** ```solidity 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:** ```solidity 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: ```solidity 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) * An Arweave gateway (optional and fallback to arweave.net if not provided): [https://ar-io.dev](https://ar-io.dev/) * 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: ```rust #[serde(rename_all = "camelCase")] pub struct Block { pub base_fee_per_gas: Option, // "baseFeePerGas" pub blob_gas_used: Option, // "blobGasUsed" pub difficulty: Option, // "difficulty" pub excess_blob_gas: Option, // "excessBlobGas" pub extra_data: Option, // "extraData" pub gas_limit: Option, // "gasLimit" pub gas_used: Option, // "gasUsed" pub hash: Option, // "hash" pub logs_bloom: Option, // "logsBloom" pub miner: Option, // "miner" pub mix_hash: Option, // "mixHash" pub nonce: Option, // "nonce" pub number: Option, // "number" pub parent_beacon_block_root: Option, // "parentBeaconBlockRoot" pub parent_hash: Option, // "parentHash" pub receipts_root: Option, // "receiptsRoot" pub seal_fields: Vec, // "sealFields" as an array of strings pub sha3_uncles: Option, // "sha3Uncles" pub size: Option, // "size" pub state_root: Option, // "stateRoot" pub timestamp: Option, // "timestamp" pub total_difficulty: Option, // "totalDifficulty" pub transactions: Vec, // "transactions" as an array of strings } ``` [Check out the 0x20 source code here](https://github.com/weaveVM/wvm-reth/pull/36/files) #### 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 [KYVE Trustless API](https://docs.kyve.network/access-data-sets/trustless-api/overview) 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 [19426589](https://etherscan.io/block/19426589) - 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`\ \ &#xNAN;_**N.B: blob\_index represents the blob index in the KYVE’s Trustless API JSON response:**_ ```solidity 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 \ Check out the 0x21 precompile source code [here](https://github.com/weaveVM/wvm-reth/pull/41/files).