Today we are thrilled to showcase our latest HyperBEAM ship, the ~x402@1.0 device. Building this device comes after our experimentation in EVM-based x402 land. In this article we will go over the rationale behind ~x402@1.0 and its near-term roadmap.
The Rationale
The main reason behind us building the HyperBEAM ~x402@1.0 device is our first experiment with x402, the 402104 platform. Before the x402 hype, we read the x402 Foundation PR on the Cloudflare blog on Sep 23rd, and by Sep 24th we had our own facilitator running with custom support for Load Alphanet.
After that we shipped a use case that x402 is perfect for: paywalled expirable shareable private ANS-104 DataItems, or as our users like to call it “pay to access data” – 402104 is integrated on Load Cloud Platform (LCP) and allows users to create paywalled sharable links from inside private storage buckets. Read more about 402104 here, and check it out on x402scan.
Right now, x402 facilitators primarily support EVM networks and Solana (recently there is support for Sei, Aptos and Avalanche). And as a project from the Arweave/AO ecosystem, we wanted an ao-native facilitator, so we built it. Here’s how it works:
ao’s native facilitator is the micropayments rails for AI agents
HyperBEAM is the Cyberspace Operating System, and there’s no better place to build an ao network x402 facilitator. Why? HyperBEAM’s modularity.
With the x402 facilitator being a HyperBEAM device, it has first class citizen access to ao’s compute and the HyperBEAM canonical stack. Which means the ~x402@1.0 device can not only offer micropayments processing, but also provide ao’s compute natively to its users (e.g. AI agents) through the facilitator interface: payments + unmatched compute in a single client.
Speaking of ai agents and compatibility, the ~x402@1.0 device is being built based on the x402 API standard. The facilitator is compatible with the API schema of the protocol’s standard which means the ease of adding support for ao’s facilitator in an evm/standard facilitator, such as x402-rs – extending standard facilitators with ao tokens support (verification & settlement).
Another differentiator between ~x402@1.0 and other facilitators is the built-in payments data storage. Settled payments (ao messages) are recorded permanently on Arweave (ANS-104 DataItems), and can be queried permissionlessly from Arweave gateways, via GraphQL.
And if we compare ao network to other networks (especially EVM L2s and Solana), ao wins when it comes for settlement finality and keyless dependency. When we tested the ~x402@1.0 device, it took 270ms for the whole test that includes the full request lifecycle
client -> dev_x402_facilitator.erl -> Rust NIF -> (validate ANS-104 integrity, settle ao message on Arweave, make ao scheduler aware of the message) -> return response to the client (on success: ao message id and the unlocked paywalled data)
Such JSON-RPC free request cycle, nearly-gasless, and near instantaneous finality is great for true ai agents.
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 messaging protocol tags, etc), then posts the signed dataitem to Arweave and make an 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.
Roadmap
In this release, the ~x402@1.0 facilitator is in the exploratory phase that works, with minimal features support, but the core is there. Our next goal is to implement the server middleware feature, then port this facilitator side by side of an EVM facilitator (compatible routes for /verify and /settle), offering ao’s token settlement and compute in a single library.
| 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 siddleware | provide ready-to-use integration for Rust web frameworks such as axum and tower - wip |
| integration in an x402-rs fork | routing ao requests to ~x402@1.0 from an EVM/SOL facilitator - wip |
Conclusion
The ~x402@1.0 device is another device to add to our history of HyperBEAM contributions. However, this one is production-ready, and not only fits in (sigh) a narrative, it actually makes it better. This HyperBEAM device brings ao’s financial and compute layers to the masses of EVM-land.