Around 2 weeks ago, on October 30th, we released the ~x402@1.0 device – the first intersection between the $AO token and the x402 protocol - a PoC of a mini-x402 facilitator on ao, as a HyperBEAM device.
Today, in line with the roadmap goal of first-class citizen support for AO in the x402 client, we’re launching the first fully AO-based x402 facilitator, ready to use today: hyper-x402.
Rationale
One of the very important missing features was making the ao facilitator work out of the box with x402 middleware - for example, using ao’s x402 natively beside the axum library, as middleware. And we thought, rewriting a middleware from scratch in the HyperBEAM device would be reinventing the wheel as the work exists, and is widely tested, in existing x402 facilitator clients, such as the x402-rs facilitator implementation.
But since x402-rs is written in Rust, it can be easily ported to a HyperBEAM as a sidecar, in the form of a NIF - which means two important things:
- we can extend the x402-rs facilitator to add support for ao network/tokens by building on top of large extensively adopted and tested client
- not losing the ability to host the facilitator as a HyperBEAM sidecar NIF.
Introducing 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!
We will keep it light on the implementation details, but as a TL;DR, ao network definitions and some high level types have been added in network.rs and the ao token is defined there, under the USDCDeployment struct type for the each of types and helpers reuse by the user (dev):
New ao related types have been added to types.rs (ExactAoPayload, TransactionHash, MoneyAmount, etc). And the AO provider (network’s client), alongside the core facilitator functionality (settle / verify) exists in the chain/ao.rs module – you can check the facilitator repo work in details here.
hyper-x402 in action
Alright, enough theory and implementation detail, let’s see how we can use this in practice. 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:
To test the axum example, head to examples/x402-axum-example and run the axum server that has protected endpoints (cargo run --bin x402-axum-example) after that it will run the axum server, as shown above.
Now to test the protected endpoint with a helper script, you need to place your wallet JWK file that has more than 1e-12 AO - one winston unit (the file is gitignored but always double check and use burner wallets only!!)
Why 1e-12? Because in our axum example we priced the protected endpoint with 0.000000000001 AO:
Now let’s pay and unlock this protected route! Run cargo run --bin ao_payment_helper and it will run the prebaked script that pays AO to the facilitator’s pay_to address (predefined as the A’s address) and it should return a response like this one:
status=200 OK body=This is a VIP content!
And the onchain proof:
- Source: ao.link
- Example src: x402-ao-facilitator
Conclusion
Today we shipped the x402-turing ao support in the x402-rs facilitator, making it possible for the x402 ecosystem to adopt ao payment rails frictionlessly, taking advantage of its features (sub-300ms verification/settlement flow, permanent payment receipts, walletless facilitator, etc). You know now ao processes can interact with x402 facilitator and unlock gated data? Yuge! We are excited to see how the ao facilitator will meet adoption and what could be built on top of it!