HyperBEAM Introduction

HyperBEAM is the primary, production-ready implementation of the AO-Core protocol, built on the robust Erlang/OTP framework. It serves as a decentralized operating system, powering the AO Computer—a scalable, trust-minimized, distributed supercomputer built on the permanent storage of Arweave.

For the most current technical specifications and implementation details, refer to the official HyperBEAM documentationopen in new window.

What is HyperBEAM?

Think of HyperBEAM as your "Swiss Army knife" for decentralized development. It's not a single-purpose application, but rather a powerful, extensible engine that transforms the abstract concepts of AO-Core into a concrete, operational system.

HyperBEAM provides the runtime environment and essential services to execute computations across a network of distributed nodes, making the AO Computer accessible through familiar web technologies like HTTP.

HyperBEAM serves as the bridge between standard HTTP interfaces and the AO Computer, managing message routing, device execution, state queries, and cryptographic verification.

Core AO-Core Concepts in HyperBEAM

HyperBEAM implements the three fundamental components of AO-Core:

Messages: Modular Data Packets

In HyperBEAM, every interaction within the AO Computer is handled as a message. Messages are cryptographically-linked data units that form the foundation for communication, allowing processes to trigger computations, query state, and transfer value.

// Example message structure in HyperBEAM
const message = {
  Id: "MESSAGE_TX_ID",
  Process: "TARGET_PROCESS_ID", 
  Owner: "SENDER_ADDRESS",
  Data: "Hello, AO Computer!",
  Tags: [
    { name: "Action", value: "Greet" },
    { name: "Device", value: "[email protected]" }
  ]
};

HyperBEAM nodes are responsible for routing and processing these messages according to the rules of the AO-Core protocol, ensuring reliable delivery and execution.

Devices: Extensible Execution Engines

HyperBEAM introduces a uniquely modular architecture centered around Devices. These pluggable components are Erlang modules that define specific computational logic—like running WASM, managing state, or relaying data—allowing for unprecedented flexibility.

Common HyperBEAM Devices:

[email protected]: Manages persistent, shared computational states (like smart contracts)
[email protected]: Executes Lua scripts for serverless functions
[email protected]: Executes WebAssembly code for high-performance computing
[email protected]: Provides JSON data structure manipulation
[email protected]: Forwards messages between nodes or external HTTP endpoints
[email protected]: Handles message ordering and execution timing

For a complete list of devices and their latest specifications, see the HyperBEAM Devices documentationopen in new window.

# Using the Lua device to execute a calculation
GET /[email protected]&script=return 2 + 2/result
# Response: 4

# Using the process device to query state
GET /[email protected]/now/balance
# Response: Current process balance

Paths: Composable Pipelines

HyperBEAM exposes a powerful HTTP API that uses structured URL patterns to interact with processes and data. This pathing mechanism allows developers to create verifiable data pipelines, composing functionality from multiple devices into a single, atomic request.

The URL bar becomes a command-line interface for AO's trustless compute environment.

# Complex pipeline example: Calculate token supply and format as JSON
GET /[email protected]/now/cache/[email protected]&module=CALC_MODULE/sum/[email protected]

# This path:
# 1. Reads latest state of TOKEN_PROCESS on the cache variable
# 2. Pipes state to Lua script 
# 3. Calls 'sum' function to calculate total supply
# 4. Formats result as JSON

Four Key Principles of HyperBEAM

Building with HyperBEAM can be simplified to four core principles:

1. Everything is a Message

You can compute on any message by calling its keys by name. The device specified in the message determines how these keys are resolved.

# Direct message access
GET /[email protected]&greeting="Hello"&count+integer=42/count
# Response: 42

# Process message
GET /[email protected]/compute/userCount  
# Response: Number of users in the process

2. Paths are Pipelines of Messages

A path defines a sequence of 'request' messages to be executed. You can set a key in a message directly within the path using the &key=value syntax.

# Pipeline: Get process data → Transform with Lua → Format as JSON
GET /[email protected]/now/[email protected]&script=transform_data/[email protected]

3. Device-Specific Requests with `~x@y`

The ~device@version syntax allows you to apply a request as if the base message had a different device, providing powerful compute and storage logic.

# Execute Lua on process state
GET /[email protected]/now/[email protected]&func=calculateMetrics/metrics

# Execute WASM for high-performance computing  
GET /[email protected]/[email protected]&module=WASM_MODULE/compute

4. Signed Responses over HTTP

The final message in a pipeline is returned as an HTTP response. This response is signed against the hashpath that generated it, ensuring integrity and verifiability of the computation.

# Every response includes cryptographic proof
HTTP/1.1 200 OK
X-HyperBEAM-Signature: 0x123abc...
X-HyperBEAM-HashPath: path_to_computation_verification
Content-Type: application/json

{"result": 42, "verified": true}

HyperBEAM Architecture

Built on Erlang/OTP Framework

HyperBEAM leverages the battle-tested Erlang/OTP platform, providing:

Exceptional Concurrency

Handle millions of lightweight processes simultaneously
Actor model naturally maps to AO processes
Message passing between isolated processes

Fault Tolerance

"Let it crash" philosophy with supervised restarts
System continues operating even if individual components fail
Automatic recovery and error isolation

Hot Code Swapping

Update running code without stopping the system
Zero-downtime deployments and upgrades
Live system maintenance and improvements

Distributed Systems

Built-in clustering and node discovery
Network partitioning tolerance
Transparent inter-node communication

%% Example of HyperBEAM device implementation
-module(my_custom_device).
-export([handle_message/2]).

handle_message(Message, State) ->
    case maps:get(<<"action">>, Message, null) of
        <<"calculate">> ->
            Result = perform_calculation(Message),
            {ok, Result, State};
        _ ->
            {error, unknown_action, State}
    end.

Hardware Abstraction

HyperBEAM abstracts away underlying hardware differences, allowing diverse nodes to contribute resources without compatibility issues. Whether running on:

Consumer laptops
Enterprise servers
Cloud instances
Edge devices
Specialized hardware (GPUs, TPUs)

All nodes can participate in the AO Computer through the common HyperBEAM interface.

Use Cases and Applications

Serverless Computing with Trustless Guarantees

Replace traditional cloud functions with permanently available, cryptographically verifiable compute:

// Traditional serverless function
exports.handler = async (event) => {
    return { statusCode: 200, body: "Hello World" };
};

// HyperBEAM equivalent - permanently available on AO
// Accessible via: /[email protected]/hello
Handlers.add(
    "hello", 
    function() { return true; },
    function(msg) {
        ao.send({
            Target = msg.From,
            Data = "Hello from the permanent web!"
        })
    }
)

Hybrid Smart Contract + Serverless Applications

Combine persistent state management with on-demand compute:

# Smart contract state management
GET /[email protected]/now/balance

# + Serverless data processing  
GET /[email protected]&module=ANALYTICS/process/result

# + External API integration
GET /[email protected]/call?method=GET&path=https://api.external.com/data

Custom Execution Environments

Build specialized computational environments through custom devices:

AI/ML Inference: Custom devices for model serving and GPU acceleration
Scientific Computing: Devices for mathematical libraries and simulations
Cryptographic Applications: Specialized devices for zero-knowledge proofs
Cross-chain Bridges: Devices for interacting with other blockchain networks

Composable Data Pipelines

Create complex, verifiable data processing workflows:

# Data pipeline: Fetch → Validate → Transform → Store → Notify
GET /DATA_SOURCE/fetch/
    [email protected]&schema=SCHEMA/validate/
    [email protected]&rules=RULES/transform/
    [email protected]&destination=DEST/store/
    [email protected]&webhook=WEBHOOK/notify

Getting Started with HyperBEAM

Accessing HyperBEAM Nodes

HyperBEAM nodes are accessible via HTTP. You can use any node while maintaining trustless guarantees:

// Example HyperBEAM node URLs (verify node availability before use)
// Note: Node availability can change. Always verify endpoints are operational.
const EXAMPLE_NODES = [
  'https://forward.computer',  // Community HyperBEAM node
  // Additional nodes can be found in the AO ecosystem
  // Use official node directories for current endpoints
];

// Example: Query process state from a HyperBEAM node
const processId = 'YOUR_PROCESS_ID';
const nodeUrl = 'YOUR_HYPERBEAM_NODE_URL'; // Replace with verified node URL
const response = await fetch(`${nodeUrl}/${processId}[email protected]/now`);
const state = await response.json();

Basic Operations

Query Process State:

GET /[email protected]/compute
# Returns the latest known state (faster)

GET /[email protected]/now  
# Returns real-time state (slower, more accurate)

Execute Lua Code:

GET /[email protected]&script=return os.time()/result
# Returns current timestamp

Send Messages to Processes:

import { connect, createDataItemSigner } from "@permaweb/aoconnect";

const ao = connect({
  MU_URL: "YOUR_HYPERBEAM_NODE_URL"  // Replace with verified HyperBEAM node
});

await ao.message({
  process: "PROCESS_ID",
  tags: [
    { name: "Action", value: "Transfer" },
    { name: "Recipient", value: "RECIPIENT_ADDRESS" }, 
    { name: "Quantity", value: "100" }
  ],
  signer: createDataItemSigner(wallet)
});

Security and Trust Model

Cryptographic Verification

Every HyperBEAM response includes cryptographic proofs:

Signatures: All responses signed by the executing node
HashPaths: Verifiable computation trails
State Hashes: Merkle proofs of state integrity
Message IDs: Tamper-evident message identification

Trusted Execution Environments (TEEs)

Many HyperBEAM nodes run in TEEs for additional security:

# Verify node is running in genuine TEE
GET /[email protected]/attestation
# Returns cryptographic attestation report

Decentralized Trust

No single point of failure or control:

Computation can be verified independently
Multiple nodes can execute the same request
Consensus mechanisms for critical operations
Open network - anyone can run a node

Performance Characteristics

Concurrency

Millions of concurrent processes per node
Lightweight message passing between processes
Non-blocking I/O for network operations
Parallel device execution for complex pipelines

Scalability

Horizontal scaling through additional nodes
Load balancing across node network
Caching layers for frequently accessed data
Eventual consistency model for global state

Efficiency

Compiled code execution via BEAM VM
Memory management with garbage collection
Hot code reloading for zero-downtime updates
Optimized message serialization for network transport

Network Effects

As more nodes join the HyperBEAM network:

Increased Resilience: More redundancy and fault tolerance
Better Performance: Load distribution and edge computing
Enhanced Security: More verification nodes and cryptographic diversity
Expanded Capabilities: New devices and specialized services
Lower Costs: Competition drives down execution costs

Next Steps

Explore HyperBEAM's capabilities in detail:

Learn Querying: Querying AO Process State
Build Serverless Functions: Lua Serverless Functions
Understand Devices: HyperBEAM Devices
Start Building: Builder's Journey

Resources

HyperBEAM Official Documentation: HyperBEAM Docsopen in new window
AO Cookbook: AO Documentationopen in new window
HyperBEAM Migration Guide: Migration from AO Connectopen in new window

Note: Node endpoints and availability may change over time. Always verify node status and select reliable endpoints for production use. Consider running your own HyperBEAM node for maximum reliability and control.

Documentation

# HyperBEAM Introduction

# What is HyperBEAM?

# Core AO-Core Concepts in HyperBEAM

# Messages: Modular Data Packets

# Devices: Extensible Execution Engines

# Paths: Composable Pipelines

# Four Key Principles of HyperBEAM

# 1. Everything is a Message

# 2. Paths are Pipelines of Messages

# 3. Device-Specific Requests with ~x@y

# 4. Signed Responses over HTTP

# HyperBEAM Architecture

# Built on Erlang/OTP Framework

# Hardware Abstraction

# Use Cases and Applications

# Serverless Computing with Trustless Guarantees

# Hybrid Smart Contract + Serverless Applications

# Custom Execution Environments

# Composable Data Pipelines

# Getting Started with HyperBEAM

# Accessing HyperBEAM Nodes

# Basic Operations

# Security and Trust Model

# Cryptographic Verification

# Trusted Execution Environments (TEEs)

# Decentralized Trust

# Performance Characteristics

# Concurrency

# Scalability

# Efficiency

# Network Effects

# Next Steps

# Resources