Stobox and the Machine-Native Economy: Position and Commitments

Software is starting to act in the economy on people's behalf. It reads, compares, decides, and increasingly pays. In September 2026 BlackRock described the result as a machine-native economy: AI as machine-native intelligence, digital assets as machine-native money, blockchains as the settlement layer between them. The payment rails for it already exist. The x402 protocol, which lets an agent pay for a resource inside an ordinary web request, is now governed by a foundation under the Linux Foundation with forty members, Visa, Mastercard, Stripe and Google among them.

We agree with that picture, and we have written at length about the part of it that decides whether real-world assets take part: The Machine-Native Economy Runs on Records. This document is shorter and more specific. It states what Stobox believes, what we have already built toward it, what we are building, and what we will not do, so that anyone, including the software reading this page, can hold us to it.

What we believe

An agent can pay in two seconds. What it cannot do on its own is find out what it is paying for. A blockchain proves that a wallet holds a token and that a transfer settled. It does not prove that the token is a real claim on a real asset, that the holder was allowed to receive it, or which company stands behind the key that sent it. Those facts live in documents, registers and legal agreements, and until they are structured and sourced, an agent either skips the asset or guesses. A careful agent skips.

So the constraint on the machine-native economy, for everything except the dollar, is not the payment rail. It is the record. That has been our thesis since 2018, when the only readers were people: the hard part of tokenization was never the token, it was getting the record and the structure right first. The readers are changing. The thesis is not.

We have added one clause to our mission and two principles to the four we already publish on our about page.

The mission. Make ownership of any real asset as easy to issue, hold and transfer as a message – for people and for the software acting on their behalf – within the law, not around it.

Readable by machines, by default. Every fact about an asset carries its source document. Every rule sits inside the instrument, where software can check it. Every record can be queried through open interfaces – MCP, structured data, public standards – not only read as a PDF.

Software acts inside mandates, people stay accountable. Machine access is read-only by default. Anything that moves value happens only under an explicit, bounded mandate: an allowlist, caps, an expiry, a kill switch. Behind every agent there is a named legal entity.

The four that stand unchanged: compliance is a feature, not a footnote; you hold your keys; no percentage of your raise; standards over lock-in.

What we commit to, and where each commitment stands

Each line below has a status. Live means it runs today and you can check it at the link. Building means it is in design, not yet a product and not for sale. Not doing means it is outside what Stobox is, and we will say so when asked.

The one line in progress is the one we think matters most. Today an agent can pay a counterparty it cannot identify, for an asset it cannot verify. The public registries meant to solve this are, on the evidence, mostly empty: in a study of the ERC-8004 agent registries, between 98.7% and 100% of reputation records carried neither a proof of payment nor a link to the work being rated. Verifying that a company exists, who controls it and whether its claims hold up is what we have done for issuers since 2018. Applying it to the companies that operate agents is the natural next step, and it is where we are putting our design work. When it becomes a product, this line will change, and so will the version number at the top of this page.

What this means if you issue or own an asset

The practical question is not whether agents will transact. They already do, in small numbers, and the rails are live. The question is whether your asset will be one they can transact in. An asset is readable by software when it passes three tests.

A standard representation. The token follows a public interface an agent already knows how to query, instead of a custom contract it has to reverse-engineer.

Rules inside the instrument. Who may hold, from where, under which lock-up and caps, is enforced by the token itself. Eligibility checked by a function call is something an agent can respect. Eligibility described in a subscription agreement is something an agent has to ignore or refuse.

A record with provenance. Every claim about the asset and its issuer exists as structured data, and each data point links to the document that proves it, with a date. Without this, the first two tests only guarantee that an unverified claim settles quickly.

We describe what software can read about Stobox today, and what it cannot do, on one page for agents and the people who build them.

How we will keep this honest

This document is versioned. When a status changes, the line changes and the version at the top moves; nothing is removed to hide that it was once different. We will not describe anything as live that you cannot check at its link. We will not publish figures about agent adoption that we cannot source. And we will keep saying what we do not do, because in a market this early the most useful thing a company can publish is its boundaries.

If you want to know how your own asset reads to a machine, the free readiness score takes about eight minutes. If you would rather talk it through, book a call.

Gene Deyev, Founder and CEO, Stobox