If you’ve been spying on our engineering progress lately, you’ve probably noticed some strange new codebases cropping up—RISC-V EVMs, GPU compute layers, HyperBEAM runtimes.
This post ties it all together. It’s a follow-up to last week’s post about HyperBEAM, and a wider framing of why Load Network is the high-bandwidth base layer for alien compute.
EVM alien compute?
The EVM is the most successful decentralized execution environment. But should it have been? It has had a ton of eyes on it (with enough, all bugs are shallow), and undoubtedly benefits from first mover advantage.
The breadth of the developer tooling ecosystem means it Just Works in many cases. Lots of docs means lots of tutorials, which feeds into how well-versed LLMs are that help builders go from 0 to 1 building dApps.
But it’s good because it’s popular, perhaps not the inverse. We don’t think any less of it despite that.
The fact that it is the global onchain compute standard is exactly why we built Load Network as an EVM chain. That said, detractors from outside Ethereum, the EF itself, and even Vitalik have a strong point when they call it out as legacy tech. Its first formal implementation came in 2014 in Gavin Woods’ Ethereum Yellow Paper. Back then, Ethereum didn’t consider the efficiency gains that zk would enable. The yellow paper predates the first major zk system, ZCash, by 2 years and it was not yet remotely practical to prove EVM execution in zk circuits.
Eleven years later, the EVM is a bottleneck for zkEVMs and provers, and zk is being brought in as a way to scale the L1.
Ethereum itself still has baggage, but teams that use Ethereum tech (hello) are free to mess with experimental OSS clients as much as they like. At its core, Load Network is built on Reth, the Rust Ethereum client, and modded to support connectivity with layers like Arweave, and easily flexible enough to act as the base layer for alien compute layers like the RISC-V EVM, GPU kernel functions, and HyperBEAM itself.
Alien compute: alt-EVM implementations, esoteric execution layers that have never existed onchain, and HyperBEAM - a protocol for hyperparallel message-passing that can be extended to work with any kind of compute.
Load as the home planet for alien compute
Load’s design as high-capacity EVM, extensible via precompiles and Reth ExExes, with permanent Arweave data settlement and an Arweave-based gas fee market, make it a natural home planet for alien compute. Why?
If all current L2s were to suddenly start posting data to Load Network instead of Ethereum, Load would handle it with 99.8% capacity left over. Load is one of the highest throughput EVM chains out there because we built it to match Arweave’s data-intensivity. Similar to how Ethereum (32kb/s) can handle DA for layers with much higher capacity than it has natively, Load is that, times 4000. This is why Load is the ideal home planet for alien compute layers:
- Handles 125mb/s data throughput
- Easily extensible to bring off-chain calls native inside the client
- Everything settles permanently to Arweave
Without the technical baggage of the Ethereum Foundation, Load Network can (and should) add support for experimental compute layers. We have already shipped a proof-of-concept for a RISC-V EVM and GPU kernel function machine on HyperBEAM.
HyperBEAM is the first step because it’s a way to turn an execution layer into a network participant that comes wrapped in a REST API. In turn, this REST API can be wrapped as precompiles natively inside Load. Once that’s set up, tapping into alien compute from Load is as simple as posting transactions with input functions and destinations in the calldata.
Effect: the Load EVM as the entrypoint for anything you can’t usually do in EVM land.
On HyperBEAM
HyperBEAM is a lightweight, message-passing runtime for decentralized computation. It’s the canonical compute client for AO that replaces consensus-heavy virtual machines with modular, verifiable devices.
HyperBEAM interprets messages over HTTP, routed through stackable compute modules called devices. Each device handles a specific execution role: some run WASM or kernel code, others manage message relaying, pricing, or trusted computation. Devices are modular, pluggable, and independently upgradeable. This is what makes HyperBEAM an ideal substrate for alien compute layers:
- Interoperability with the AO ecosystem and compute layer
- Supports WASM execution, GPU compute, and TEEs
- Exposes REST API interface per node
- No need for global consensus
Load Network integrates HyperBEAM by treating its REST interface as a native extension to the EVM. Through precompiles and ExExes, Load wraps HyperBEAM endpoints as callable compute devices—effectively making non-EVM logic callable from EVM calldata. This turns the Load EVM into a router for any compute system that can speak HTTP – post messages to programmable endpoints and Load handles the rest.
This stack gives developers a bridge to run logic for anything that can’t natively exist inside a monolithic EVM, needs WASM, GPUs, or TEEs.
HyperBEAM turns execution into message-passing, like an oracle for compute. Load Network turns message-passing into onchain function calls. Together, they’re how you bring alien compute onchain without making it feel alien to devs.
The next ships into space
We’ve already built the bare bones for several novel HyperBEAM-compatible layers, both EVM and non-EVM:
- Load HyperBEAM: all of the Load team’s HyperBEAM work so far in one place
- Kernel execution machine on HyperBEAM: deploy custom kernels (shaders) as GPU compute sidecars to your ao process
- Chain state of HyperBEAM REVM: the simplest demonstration of a HyperBEAM EVM – vanilla EVM exposed over REST API
These are in an experimental stage. Next steps: native Load integrations, formation of the united federation of alien chains.
Follow along @useload, @decentlandor.