The market talks about AI agents paying for compute, data, and APIs as if it's a solved problem. It's not.
HTTP 402, x402, and basic wallet integrations give agents a wallet, but no control layer. No ability to say 'this agent can spend $50 per hour on inference, but only with verified providers.' No mechanism to revert a payment when the LLM delivers junk. No trail to audit why 10,000 microtransactions happened in one block.
That gap is exactly what X-Agent's xpense claims to fill. And after spending the weekend digging through their open-sourced repo and talking to a few friends who run AI agent shops, I have to say: the architecture is clever. The execution still needs a lot of heavy lifting.
Context: What xpense Actually Is
X-Agent, a team that remains largely anonymous, open-sourced xpense on July 2024 after months of quiet integration work with OKX. The project is not a new blockchain or a token. It's a middleware layer – what they call a 'payment control plane' – that sits between an AI agent (or any autonomous software) and the payment channels it uses.
Think of it like the difference between giving a teenager a credit card (x402) versus giving them a card with a smart contract that defines categories, limits, delivery verification, and a dispute system (xpense). The latter is what enterprises need before they let agents spend money autonomously.
xpense hooks into OKX's Agentic Wallet via its TEE (Trusted Execution Environment). It also supports x402 for gasless USDC settlement. The combination means agents can pay for services without holding native gas tokens, and the private key is protected in hardware.
The Core: Seven Steps, Two State Machines, and a Hard No to LLM Trust
The technical design is where xpense gets interesting. I've audited enough smart contracts to recognize when a team has thought through edge cases. xpense's seven-step deterministic control flow is that kind of thinking.
- Intent generation – the agent decides it needs a service.
- Policy check – the strategy engine validates against pre-set budgets and rules.
- Route selection – a payment-aware router picks the cheapest or fastest provider.
- Hold – funds are locked in a buffer, not sent yet.
- Execution – the service is delivered.
- Verification – a separate state machine confirms delivery quality.
- Settlement – if verified, funds are released; if not, the hold is reversed.
This dual-state-machine approach is critical. Most naive implementations combine payment and delivery into one atomic operation. That fails when a service is delivered but the payment times out, or vice versa. By decoupling them, xpense allows for partial refunds, dispute windows, and idempotent retries.
I don't trust narratives. I trust serialized bytecode. And the bytecode here shows a deliberate effort to keep the LLM – the agent's brain – out of the money loop. The paper states: 'Large Language Models are not trust roots.' That's not just a design choice; it's a security axiom. If the agent hallucinates and tries to pay 100 ETH for a cat picture, the strategy engine rejects it. The agent can think, but it cannot initiate a transfer without passing through the control plane.
That is the right call. I've seen agent-based systems lose funds because the model was jailbroken into approving transactions. xpense makes that attack surface significantly smaller.
The smart routing module, which compares providers by latency, cost, and historical delivery success, is also well thought out. It reminds me of how OpenRouter aggregates LLM APIs. But xpense adds the ability to blacklist providers that fail verification multiple times. Over time, the system self-optimizes.
The Contrarian: Dependency, Anonymity, and the Audit Gap
Now for the hard part. xpense is not a decentralized panacea. It is a dependency hub.
The most glaring issue is the near-total reliance on OKX's TEE. If OKX's implementation has a vulnerability – and hardware-level bugs happen, as we saw with SGX – every agent relying on xpense for key protection is exposed. There is no fallback, no alternative hardware provider mentioned. That's a single point of failure for an infrastructure layer that aims to be the standard for autonomous payments.
Furthermore, the team behind X-Agent is anonymous. On one level, that's consistent with crypto culture. On another, it's a problem for enterprise adoption. Who do you call when the strategy engine has a bug? Who's liable if a flawed route selection drains an agent's balance? Right now, the answer is no one. The code is open source, so you can fork it. But if you're building a business around agent payments, you want a phone number.
The bigger red flag: no professional audit. The repository is live, it's generating interest, but as of this writing, there is no Trail of Bits, OpenZeppelin, or ConsenSys Diligence report. The code isn't trivial. It's a solid few thousand lines of Rust and Solidity. I've run basic static analysis on the contracts, and I didn't find obvious reentrancy or overflow issues, but that's not a clean bill of health. Formal verification of the dual-state-machine logic would be ideal. Without it, I wouldn't let an agent spend more than a few hundred dollars.
Regulatory risk is also real, though deferred. USDC settlement via x402 means every payment goes through a regulated stablecoin. That's fine for now. But if xpense later adds a token to capture value – say, a governance token that also serves as a payment fee discount – the SEC could view the entire network as a common enterprise. The Howey test gets tricky when agents pay fees to a DAO that manages the protocol. The fact that the foundation explicitly says LLMs are not trust roots helps, because it reduces reliance on 'efforts of others.' But a token could redefine that.
The Takeaway: A Solid Blueprint, But Don't Bet the Farm Yet
xpense is the most pragmatic AI-agent payment infrastructure I've seen to date. It solves a real problem with a sound engineering approach. The dual-state-machine verification and the non-trust-LLM principle are lessons the industry will have to learn one way or another. X-Agent is ahead of the curve.
But the product is not ready for production scale. The lack of an audit, the single dependency on OKX, and the anonymous team are three reasons to be cautious. I'll be watching for three signals: a public audit report, support for an alternative hardware wallet or TEE provider, and the first well-known AI agent project publicly committing to xpense.
Until then, treat xpense as a 0.1 beta. It's a map of the territory, but the territory itself is still being charted.
Emotion is the only variable I cannot hedge. And right now, the emotional narrative around AI agents is running ahead of the technical reality. xpense could bridge that gap. But bridges collapse when you skip the load tests.