[email protected] device

The first ao token x402 facilitator

Thjs was a demo for educational purposes only, for a production ready x402 facilitator on ao, checkout the hyper-x402 section

Hyper-x402

hyper-aos is an 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 (supports base & ao) and the best example to showcase it, is via the axum example

Axum Middleware Example

This example repository 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:

    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

    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:

status=200 OK body=This is a VIP content!

onchain proof: https://www.ao.link/#/message/_zrmkURCLrHOKWzsErmFTEdXzcUEur1iWGErepju3w0

[OLD] [email protected] device

About

The [email protected] 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.

N.B: The [email protected] 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/[email protected]/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 [email protected] 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 [email protected] from an EVM/SOL facilitator - wip

Technical Overview

On HyperBEAM’s [email protected] 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

On the other hand, EVM facilitators (e.g. x402-rs) have the same HTTP schema but the payment is an ERC‑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.