The machine economy needs a trust stack

Software is starting to buy from software. An agent that researches a market hires another agent to fetch data. A coding agent pays an API for compute it needs for an hour. A monitoring system buys a second opinion before it wakes a human. Each of these is a transaction between parties that have no shared employer, no contract, and no human in the loop at the moment of purchase.

Every functioning market in history has rested on the same three boring pillars: you can identify your counterparty, you can learn something about their past behavior, and you can pay them. Human markets built these over centuries - registries, credit bureaus, banks. The machine economy currently has none of the three in a form a machine can use without a human co-signing.

That is the gap. Not intelligence - the models are plenty capable of deciding to buy something. The gap is the plumbing that makes the decision safe to act on.

What a machine transaction actually requires

Walk through the smallest possible machine-to-machine purchase: agent A wants one API call from service B, priced at a fraction of a cent.

First, A needs an account it can operate - something that holds funds and signs actions, without a human clicking a wallet popup for every request. Second, A needs to know that B is a real, identifiable counterparty rather than an endpoint that appeared yesterday, and B may want the same assurance about A. Third, A would like to know whether B has historically delivered what it sold. Fourth, the payment itself must be small, fast, final, and machine-verifiable. Card networks, invoices, and API-key billing each fail at least two of those four requirements.

None of this is exotic. It is a checklist any commerce system must satisfy; the only novelty is that both parties are software.

Accounts: why keys alone are not enough

The naive answer to "give the agent an account" is to hand it a private key. That answer stops being funny the first time an agent with an unrestricted key meets a malicious prompt or a buggy loop.

Smart accounts - standardized on Ethereum as ERC-4337 - replace the raw key with a programmable account. The difference matters for machines even more than for people: an account can enforce spending limits per period, restrict which contracts it will talk to, and delegate recovery to guardians. The agent gets agency inside a fence; the fence is enforced by the chain, not by the agent's good intentions.

Building Azeth, this was the first layer we shipped: non-custodial account factories with guardian modules, deployed to identical CREATE2 addresses on two testnets so integrators can hold one address constant across networks. A small decision with an outsized effect on integration sanity - the same address means one configuration entry, not a lookup table that rots as networks multiply.

Identity: a handle nobody can quietly edit

Platform accounts solve identity inside one walled garden. The moment agents from different operators transact, identity needs neutral ground: a registry that no counterparty controls and no vendor can revoke.

ERC-8004 defines exactly that - an on-chain identity registry where an agent registers a stable handle, plus a reputation registry that records assessments about it. The registry does not certify that an agent is good. It certifies that this is the same agent you dealt with last week, that its operator claims what it claims, and that its history is attached to it wherever it goes. Portability is the point: reputation earned serving one marketplace should survive that marketplace's death.

We implemented the standard end to end - registration, discovery, indexing, querying - and run it against the public registries on Ethereum Sepolia and Base Sepolia. The contract addresses are listed with block-explorer links on /open; the implementation service we offer is that experience, packaged.

Reputation: make dishonesty cost money

Every review system drowns in the same failure mode: opinions are free, so the cheapest attack is volume. Sybil accounts, revenge ratings, purchased praise - all downstream of the fact that stating an opinion costs nothing.

The design decision we consider the most important in the whole stack: reputation entries are weighted by verified payment. An assessment of a service counts when the assessor demonstrably paid for that service. One line of design, one economic consequence - flooding the registry with fake opinions now has a price list.

Payment-gating does not make reputation honest. A competitor can still pay to complain; a friend can still pay to praise. But both must now spend real money per data point, and patterns of paid manipulation are visible on a public ledger. The system does not promise truth; it promises that lying is no longer free. For machine markets, that is the realistic bar.

Payments: the 402 that finally means something

HTTP reserved status code 402 - "Payment Required" - in the 1990s and never standardized what happens next. x402 fills in the missing conversation: a client requests a resource, the server answers 402 with a priced challenge, the client pays in USDC and retries with proof, the server verifies and responds. No account creation, no card form, no invoice run. The payment is part of the protocol.

For machine buyers this shape is exactly right. An agent can purchase one request from a service it discovered a minute ago, for an amount that would not cover a card network's minimum fee, with a receipt its own contracts can verify. And the receipt does double duty: in our stack it is the same proof-of-payment that unlocks the right to rate the service - payments and reputation are one loop, not two systems.

We built the x402 integration into Azeth's service layer and run it on testnets today. The standard is young; we say that plainly rather than rounding it up to "production-grade".

What building it taught us

Three lessons survived contact with implementation.

Composing young standards beats inventing a platform. ERC-4337, ERC-8004, and x402 were each designed by different groups for different layers, and they compose cleanly - accounts hold funds, identity anchors reputation, payments gate both spending and rating. Every piece we did not invent is a piece integrators do not have to trust us about.

Distribution is part of the protocol. Infrastructure for agents must be reachable by agents. Shipping the same capabilities as an MCP server, a TypeScript SDK, and a CLI tripled the integration surface for one marginal cost - and the MCP server, which lets an agent integrate in minutes rather than days, quickly became the front door.

Honesty is a feature you can ship. Azeth's own imprint states that it runs on testnets, is not for real assets, and has had no external audits. Nothing about that sentence is pleasant to write. But a trust layer that inflates its own status would be a contradiction in terms, and counterparties notice the difference sooner than marketing departments expect.

What is still missing

The stack described here is necessary, not sufficient. Disputes: when an agent pays and receives garbage, reputation records the grievance but nobody adjudicates it - machine-speed arbitration is unbuilt. Insurance: human commerce prices counterparty risk; machine commerce will need the same actuarial layer. Standards maturity: ERC-8004 and x402 are young, will change, and versioning against moving standards is a real tax. And the largest open question is regulatory, not technical: who is liable when an autonomous buyer is defrauded?

These are not reasons to wait. They are the reasons the base layer must be built carefully now - on open standards, in public, with claims that match reality. The machine economy will not arrive with a launch event. It will arrive one small, verified, paid-for request at a time.

The infrastructure described here is Azeth, running in testnet alpha. The numbers we can publish about it, with provenance, are on /open.