A working tour of x402, OKX APP, ERC-3009, TEE-backed inference, and the missing pieces of the autonomous internet stack.
Most "AI agents" today are really just chatbots with tools.
The moment an agent needs to independently spend money, access paid resources, prove identity, or justify a decision, the current web stack starts breaking down.
Every payment, identity, and trust primitive on the modern web was designed for a human clicking a button in a browser.
Agents were never part of the model.
I've been building AI agents for the last six months and this became obvious very quickly: most agents cannot actually do useful things on the open internet without human infrastructure glued around them.
They cannot:
- pay for APIs autonomously
- prove they're allowed to access a resource
- get billed dynamically at request time
- carry portable identity and reputation
- prove what decision they made and why
- protect sensitive business logic from the model provider
The problem is structural.
The good news is that the missing pieces are finally starting to ship publicly, and multiple teams are independently building compatible parts of the stack.
Coinbase is shipping x402.
OKX is shipping APP.
0G Labs is shipping verifiable storage and TEE-backed inference.
Anthropic pushed the MCP ecosystem into the mainstream.
For the first time, these systems are starting to compose into something real.
This post walks through:
- what agents are missing today
- the protocols filling those gaps
- why verifiable receipts and TEE-backed decisions matter
- a real implementation stitching all of it together
What a real agent actually needs
Strip the phrase "AI agent" down to fundamentals and the requirements become pretty obvious.
An autonomous system needs:
1. A wallet
Real money it can move programmatically.
Not a Stripe customer ID.
Not a human-owned credit card.
Not a manually refreshed API key.
A real wallet.
Ideally gasless, because forcing every agent to also manage ETH for transaction fees becomes operationally painful very quickly.
2. Identity
Other systems need to know:
- who this agent is
- who operates it
- what permissions it has
- what reputation it carries
Without identity, an agent calling your API is just another anonymous request.
You cannot apply:
- trust scoring
- rate limiting
- fraud heuristics
- permissions
- reputation systems
at the agent level.
3. Dynamic billing at the HTTP layer
The modern web flow looks like this:
request
→ blocked
→ create account
→ verify email
→ add payment method
→ generate API key
→ retry request
That flow completely breaks for autonomous software.
Agents need something closer to:
request resource
→ server says "this costs $0.01"
→ agent evaluates
→ pays
→ receives resource
No signup flow.
No dashboard.
No out-of-band billing.
The payment negotiation has to happen directly inside the request/response cycle.
4. Portable memory
Most agent frameworks today store memory in vector databases controlled by the platform itself.
That creates weird ownership problems.
The agent cannot:
- move its memory somewhere else
- prove what it knows
- selectively reveal memory
- keep sensitive memory private from the model provider
Those are not futuristic requirements.
They're basic ownership guarantees we'd expect from any serious software system.
5. Decisions it can defend
This is the part almost nobody talks about.
If an agent:
- approves a refund
- blocks a payment
- rejects a customer
- accepts a lead
- spends money
somebody downstream is eventually going to ask:
"Why did the agent make that decision?"
Right now, most systems cannot answer that.
"The LLM decided" is not a serious audit trail.
The protocols filling the gap
None of this exists as one unified stack yet.
But almost every missing primitive now has at least one working implementation.
x402: pay on resource access
The HTTP 402 status code ("Payment Required") has existed since 1989 and basically sat unused for decades.
Coinbase revived it in 2025 as x402.
The flow is simple:
Agent
↓
GET /resource
↓
402 Payment Required
↓
sign payment authorization
↓
payment submitted
↓
resource unlocked
The server responds with:
- the price
- accepted asset
- recipient address
- network
- settlement requirements
The agent signs a payment authorization and submits it back.
The resource unlocks immediately.
No signup flow.
No API key generation.
No human interaction.
Cloudflare shipped a version of this model for AI crawlers under their "pay per crawl" work.
Smaller services are now exposing:
- paid APIs
- oracle endpoints
- downloadable assets
- inference endpoints
through x402-compatible paywalls.
ERC-3009: the gasless payment primitive underneath it
Both x402 and OKX APP rely heavily on ERC-3009.
ERC-3009 is the signing standard underneath most gasless USDC payments.
Instead of sending a transaction directly on-chain, the agent signs a permission slip saying:
"Allow up to $0.01 USDC to move from my wallet to this merchant before this deadline."
Another system then submits the transaction and pays the gas fee for the agent.
This matters because it removes the requirement for agents to hold ETH.
The agent only needs USDC.
That's a surprisingly important usability improvement.
OKX APP: extending the x402 model
OKX shipped their own protocol variant called APP (Agent Payment Protocol).
At the wire level, APP is extremely similar to x402:
- same EIP-712 typed signatures
- same ERC-3009 settlement model
- same request/response payment flow
But APP adds some important extensions.
Deferred aggregation
Instead of settling every tiny payment individually on-chain, agents can batch many small payments together.
Example:
100 API calls
→ 100 off-chain authorizations
→ 1 on-chain settlement
This becomes important for high-frequency agent workloads.
Session-based billing
APP also introduces the idea of prepaid session budgets.
Example:
Agent prepays $5
→ server deducts usage over time
→ long-running workflow completes
This is important for:
- video generation
- deep research
- multi-step workflows
- autonomous browsing sessions
The specs exist today.
SDK support is still early.
Agent identity: ERC-8004
Identity for agents is still immature.
ERC-8004 is one early attempt at solving this.
The basic idea:
- agents get on-chain identities
- identities contain claims
- other systems can inspect those claims before interacting
An agent could eventually advertise:
- operator identity
- capabilities
- permissions
- reputation
- certifications
Very little production infrastructure depends on ERC-8004 today.
But the underlying problem it tries to solve is real.
The real missing layer: verifiability
Payments alone are not enough.
You also need:
- verifiable receipts
- verifiable decisions
This is where the 0G stack becomes interesting.
Verifiable receipts with 0G Storage + 0G Chain
Suppose an agent buys data for $0.10.
A normal payment system gives you:
- transaction hash
- payment confirmation
But that is not enough.
You also want:
- the exact payload that was served
- proof that it wasn't modified later
- a permanent cryptographic reference to it
0G Storage handles the content layer.
The receipt or payload gets uploaded into decentralized content-addressed storage.
That returns a root hash.
The root hash then gets anchored onto 0G Chain.
Now the transaction has a 3-layer proof trail:
1. Base transaction
→ proves money moved
2. 0G Storage receipt
→ proves what content was served
3. 0G Chain anchor
→ proves the content was not modified later
A third party can independently verify every step.
Nobody has to trust the merchant.
Verifiable decisions with TEE-backed inference
This is the part I think people are underestimating.
Agents increasingly make policy decisions.
Questions like:
- should this refund be approved?
- does this request violate policy?
- should this payment be blocked?
- is this customer risky?
- should this lead be accepted?
Today, those prompts usually go directly to:
- OpenAI
- Anthropic
- another centralized inference provider
Which means the provider can theoretically see:
- refund policies
- fraud heuristics
- pricing rules
- sensitive business logic
- internal compliance workflows
That becomes a serious issue very quickly.
What a TEE actually changes
0G Compute runs inference inside a TEE (Trusted Execution Environment).
Think of a TEE as hardware-isolated secure memory.
The workload runs inside an encrypted enclave protected by the CPU itself.
Even the infrastructure operator cannot inspect:
- the prompt
- the model input
- the output
- the business logic
The system then returns:
- the result
- a hardware attestation proving what code actually ran
This creates something extremely important:
decisions agents can defend cryptographically
Example:
merchant defines refund policy
→ agent evaluates refund request inside TEE
→ signed decision returned
→ merchant policy never leaks
For a $0.10 ebook purchase, this is probably overkill.
For:
- healthcare data
- financial systems
- enterprise automation
- compliance workflows
- trading systems
it becomes very important.
A real implementation: Coal
Over the last few months I've been building Coal.
Coal is a payment platform for autonomous software running on Base + 0G.
Instead of talking abstractly about the stack, here's the concrete implementation.
Coal does five things.
1. Hosts an agent-discoverable merchant catalog
Merchant catalogs live on 0G Storage.
Agents can discover products without:
- API keys
- dashboards
- centralized marketplaces
2. Accepts both x402 and OKX APP
The same /verify endpoint accepts:
- x402-v1
- app-v2
The server advertises supported protocols and the agent picks whichever it supports.
3. Settles via Base USDC
Payments settle using USDC on Base.
The operator wallet relays transactions so agents never need ETH.
Typical confirmation time is around 2 seconds.
4. Anchors receipts on 0G
Every payment receipt gets:
- uploaded to 0G Storage
- anchored onto 0G Chain
Anyone can independently verify the proof trail.
5. Runs policy decisions inside TEEs
Refund checks, quotas, permissions, and policy evaluations run through 0G Compute Sealed Inference.
Merchant rules stay private from the model provider.
A concrete example
Open:
https://agent.usecoal.xyz
Ask the embedded agent:
"Buy me the 0G Builder's Cheatsheet"
The flow looks like this:
discover_merchants
→ find merchant catalog
→ pay_merchant
→ sign ERC-3009 authorization
→ facilitator submits transaction
→ receipt anchored on 0G
→ PDF unlocks
The payment is real USDC on Base.
No human clicks anything.
What's still broken
The stack works today.
But a lot is still rough.
Discovery is fragmented
There is no "Google for agent-payable services" yet.
Current discovery options are fragmented across:
- ERC-8004 registries
- MCP marketplaces
- project-specific catalogs
- Coinbase Bazaar
- custom integrations
Agents still mostly rely on manually configured endpoints.
That does not scale long term.
Identity is immature
Agent reputation and trust scoring barely exist today.
A malicious agent and a high-quality agent can often look identical at the protocol layer.
Cross-chain UX is messy
Different payment ecosystems prefer different chains.
Agents increasingly need:
- multiple wallets
- multiple balances
- cross-chain settlement paths
which reintroduces operational complexity.
Async billing is still early
The request/response model works well for instant resources.
It breaks down for:
- long-running research
- asynchronous workflows
- large generation jobs
Session-based billing exists in specs but is still early in production SDKs.
TEE tooling is rough
The primitives are good.
The developer experience still feels early.
Attestation verification from TypeScript applications is still awkward and under-tooled.
It reminds me a lot of early Web3 tooling around 2018.
Why this matters
I think the important shift here is conceptual.
For years, "AI agents" mostly meant:
- prompts
- workflows
- tool calling
- orchestration
Now we're starting to see:
- autonomous payments
- machine-native identity
- programmable commerce
- verifiable decisions
- cryptographic receipts
The infrastructure layer is finally catching up.
Try it yourself
Live agent sandbox
https://agent.usecoal.xyz
Runs Claude/Qwen with an embedded wallet capable of autonomous payments.
MCP server
Official MCP Registry
Smithery
https://mcp.usecoal.xyz/api/mcp
13 tools for:
- discovery
- payment
- verification
- downloads
Multi-tenant by design.
Every user passes their own wallet key.
Source code
https://github.com/emmanuel39hanks/coal
MIT licensed.
Includes:
- x402 facilitator
- APP v2 settlement flow
- receipt anchoring
- React SDK
- MCP server
- Base USDC integration
The autonomous internet needs more visible reference implementations and fewer speculative threads.
Hopefully this helps move the first category forward.
