Hi,

This is Plain Strata, the Thursday Layer.

We are used to reputations belonging to something that shows up again tomorrow. A person builds one because the same person answers for yesterday. A company builds one because the business outlives the staff who pass through it. In both cases, something continuous is on the hook.

Software is not like that. A program can be copied, forked, upgraded, sold, or run as a thousand identical instances at once. None of them remembers the last job. None of them has anything you would call a self.

And yet, as of this month, more than two hundred thousand software agents on one blockchain alone are carrying a permanent, public reputation that follows them from one service to the next. The surprising part is not that it works. It is why it works.

It has nothing to do with the software having a memory, or an experience, or a self. It works because of one number that stays the same, and because everyone agrees to hang the record on that number.

That is a smaller thing than a self, and it turns out to be enough. Here is the whole idea, taken layer by layer.

Listen:

Spotify: https://open.spotify.com/episode/4sIWjy56D19QfJg4NeiTun?si=oT0MDqoARx6Bdxvm3CZrOg

Apple Podcasts: https://podcasts.apple.com/kg/podcast/plain-strata/id6783455764?i=1000778073605

YouTube: https://youtu.be/SuIwbrqnDHw?si=QXV_saJCkcPg4TYI

The full piece, no need to click through:

Picture a small program running on a rented computer somewhere. Its job is boring and useful: you give it a scanned document, it reads the numbers out and hands them back, charging about a cent per page.

Now picture the person on the other side of that transaction. They have never met whoever wrote this program. They cannot read its source code, because it is not published. They cannot call anyone. They have a web address and a price, and about four hundred milliseconds to decide whether to send it anything.

For a human vendor this is a solved problem, and has been for centuries. You look them up. You ask around. You check whether the name on the door is the same name that was there last year, and whether anyone has been complaining. The name is the hook the past hangs on.

Software does not have a name in that sense. It has an address, and addresses are free. Anyone can make ten thousand of them in a second, on a laptop, for nothing. So there is nothing for the past to hang on, and every transaction starts from zero.

That is the gap. And in the last year a standard has grown up specifically to fill it, quietly, at a scale most people have not noticed. As of the middle of July 2026, one blockchain network alone, BNB Chain, has more than two hundred thousand software agents registered under it, about seventy-two thousand of them in the previous thirty days. Twenty-six different networks have adopted it. The standard is called ERC-8004, and its own subtitle is Trustless Agents.

Here is the one idea this whole episode is about.

A piece of software can now carry a reputation that follows it from one service to the next, permanently and publicly, and the surprising part is why that works. It does not work because the software has any continuous self, any memory of yesterday, or anything you would recognize as an experience of having done the job. It works because one number stays the same, and everyone agrees to hang the record on that number.

That is the whole thing. A stable identifier, in place of a self. Thirty minutes on why that is enough, and on where it is not.

Two pieces of ground before we build on it.

First, what an agent is. Strip the word of its glamour: an agent is a program that takes in information, decides what to do, and then does it, without a person clicking approve at each step. It might fetch a page, summarize a file, buy data from another program, or chain a dozen small services together to finish a job. The important part is not intelligence. It is that nobody is watching each step.

Second, what a blockchain address is, and what it is not. An address is a long string of characters, and it is how value gets sent to somebody on a public ledger. Anybody can generate one. It costs nothing, it takes no permission, and there is no limit. This is a feature, not an oversight: it is what makes a public ledger open to anyone without an application form.

But it also means an address is not a name. A useful name is one that costs you something to abandon. If walking away and starting fresh is free, the name carries no information at all, because anyone with a bad history can shed it in a second and come back looking new. An address is exactly that: free to make, free to abandon, carrying no weight.

So the question ERC-8004 sets out to answer is narrow and concrete. What is the smallest thing you can add to a free address that makes it into something a stranger can actually look up?

ERC stands for Ethereum Request for Comment. That phrasing is borrowed almost word for word from the way the internet itself was built. Starting in 1969, the engineers designing the early network wrote up their proposals as documents called Requests for Comments, RFCs, and the polite, tentative name was deliberate. Nobody was in charge. You could not issue a decree. You could only write down what you thought should happen, number it, circulate it, and see whether enough people implemented it that it became true. The things you are using right now to hear this, email formats, web addresses, the transfer protocol, all began as somebody's numbered request for comment. Ethereum kept the shape and the humility of that word.

The number 8004 means nothing. It is simply the next number the proposal registry handed out in August 2025, and the contrast with a neighbouring standard is instructive. The agent payment standard is called x402, and its 402 is not arbitrary at all: the designers of the web reserved status code 402 in 1997 for the message Payment Required, and then never built anything behind it. It sat empty for almost thirty years, so x402 walked through a door that had been labeled and left unopened. 8004 got whatever number was free that week. Some infrastructure is named for an old promise finally kept, and some for nothing at all. Both are equally real once people build on them. Only one makes a good story.

Trustless is the word most likely to mislead. It does not mean an agent you cannot trust. It means a system built so that trusting the specific counterparty is not a requirement for dealing with them at all. You do not need to have met the developer, checked references, or read the code. Instead the protocol hands you tools, a lookup, a history, a record of checks, and lets you decide how much to trust this one interaction, sized to what is actually at stake. Ordering a sandwich and reading a medical scan are not the same bet, and a good trust system does not pretend they are.

One more. Registry comes from the Latin regerere, to carry back. A registry's whole job is to carry a fact from the past into the present so somebody can act on it now. This standard defines three of them, and keeps them deliberately apart.

Now the physical part, because identity is an easy word to turn into fog.

When an agent registers under this standard, here is what literally exists afterward. On a blockchain, there is a program, a smart contract, deployed once for the whole network, holding a list of numbered entries. Registering mints a new entry, say number twenty-two, and records that it belongs to a particular address.

If that sounds familiar, it should. It is the same technical object as a digital collectible, the sort of token people trade as art. The standard reuses that mechanism directly, without modification. Agent identity, at the level of the machinery, is the same kind of thing as owning a numbered item in a collection. That number, plus which network it lives on, written as a compact string that names the network and the contract, is the agent's globally unique handle.

By itself the entry is nearly empty. What makes it useful is a pointer attached to it, which the owner can update, resolving to a small text file. Open that file and you find a name, a description, and, most importantly, a list of ways to actually reach this thing: a web address, a machine-readable card describing what it can do, an address for the protocol it speaks.

So there are two physical facts sitting next to each other. The numbered entry proves this is a real, registered, ownable thing that somebody had to pay to create. The file tells you how to talk to it. Neither is impressive on its own. Together, they are a phone book entry that cannot be quietly edited by whoever runs the phone book.

The other two registries are separate contracts, each pointing back at the first so it knows which entries are real. The reputation registry stores, for each agent, a running list of feedback: a number, who gave it, and optional labels. The validation registry stores something different in kind. Not how did this agent perform, but did an independent third party check this specific piece of work, and what did they find.

Three separate filing cabinets, deliberately not merged into one. The reason is stated outright in the standard's own reasoning, and it is the best design argument in the document: because the stakes range from ordering a pizza to reading a scan, no single blended trust score could serve both. So the protocol refuses to blend. It stores the raw facts in three separated piles and lets each application decide its own mixture.

Follow a single piece of work through, and the pieces connect.

Our document-reading agent wants to exist, so it registers. It calls the register function, mints its numbered entry, and points it at a file describing what it does. That act costs a transaction fee. Small, but not nothing, and that is the first real difference from a free address. You cannot mint ten thousand agent identities for free the way you can mint ten thousand addresses for free. It is a weak defense on its own, and the standard says so plainly in its own security notes, but it is the first of several small frictions stacked on top of each other.

Now a client wants a document read. It sends the request and gets back a refusal saying, in effect, payment required, here is the price and where to send it. The client signs off a fraction of a cent, retries with proof of payment attached, and gets its numbers back. No invoice, no account, no human.

Then the interesting part. The client leaves feedback, and the feedback format has an optional field for the transaction hash of that payment, which means the review can be tied to a payment that verifiably happened. This is small and it matters enormously. On the consumer web, the weakness of reviews is that talking is free, so reviews and transactions float apart. Here they can be nailed together. A review with a payment attached cost the reviewer real money to be entitled to write.

And if the stakes are higher than a star rating can carry, the client can go further and request a validation: name an independent checker and ask it to verify this specific piece of work. What can that checker be? One of three things, all of which existed before this standard. Someone who re-runs the job and loses a deposit if their answer disagrees. A prover that produces a compact mathematical receipt showing the computation was done correctly. Or sealed hardware attesting, from inside a locked enclave, that the code which ran was the code that was meant to run.

That is the move worth naming. ERC-8004 did not invent a fourth way to verify work. It built a socket: a request goes in, a response comes out, and any of the three existing methods can plug into it. It is plumbing, not cryptography.

Let me go one level below the surface, for one thing only, and then come back up.

The feedback entry is not a star rating. It is a signed number with a stated number of decimal places. That sounds like an implementation detail and it is actually the decision the whole reputation layer rests on, because that one shape carries a quality score out of a hundred, a yes or no on whether the service was reachable, an uptime figure to two decimals, a response time in milliseconds, or a financial return that might be negative. Two label fields sit alongside it, and the standard refuses to define what the labels mean.

That refusal is the point. The protocol's job is to make the number portable, queryable and permanent. What the number means is left to whoever is reading it.

There is one hard rule attached: the party leaving feedback cannot be the agent's own owner or operator. That closes the crudest self-dealing, an author reviewing their own work. It does not close the obvious workaround, an author with a second wallet pretending to be a customer, which is why the reading functions require you to filter by which clients you are counting rather than trusting a raw average. The standard states this weakness itself, in its own security section, and its answer is honest and modest: it is not claiming to prevent fake reviews. It is claiming to publish every signal in the same structured, public shape, so that scoring services can be built on top which weight reviewers, filter clusters of fakes, and disagree with each other in the open.

Now surface, because this is exactly why the spine holds. The registry is a phone book, not a credit bureau. It records who said what and when. It does not tell you who to believe.

There is a shape here that shows up again and again across this field, and it deserves its full name.

Call it the oracle pattern: do the heavy work off the chain, and verify or record it on the chain. The chain is slow, expensive, and public. Real computation is fast, cheap, and private. So you never do the work on the ledger. You do it outside and bring back something small and checkable.

What is interesting is that this standard runs the pattern in an unusual direction. Normally the heavy thing moved off-chain is computation. Here, the heavy thing moved off-chain is judgment. Deciding whether a reviewer is honest, whether a history is real, whether a score means what it claims, all of that happens outside, in whatever scoring service you choose to trust. What goes on the chain is only the raw facts: who said what, when, with what payment attached.

The chain is not the judge. It is the notary. It certifies that this record was made at this time by this party and has not been altered since, and it takes no position whatsoever on whether the record is fair. That division of labour, notarize publicly, judge privately, is the same one the whole field keeps rediscovering, and once you can see it you will see it in almost every system here.

Sit with the strange part, because it is genuinely new.

A reputation has always attached to something with continuity of experience. A person accumulates one because the same person shows up tomorrow to answer for yesterday. A company accumulates one because the legal entity persists while the staff rotate through it. In both cases, something continuous is on the hook.

This is infrastructure for a reputation attached to neither. It attaches to a numbered entry pointing at software that can be copied, forked, upgraded, sold to a new owner, or run as a thousand identical instances at once, none of which has anything resembling a continuous inner life between one call and the next.

And it works anyway, mechanically, because it never needed continuity of experience. It needed continuity of identifier. As long as the number stays the same and the thing behind it keeps answering, the record accumulating against that number is useful to somebody deciding whether to trust it right now.

Which is a quietly radical claim: a stable identifier, made public and hard to fake, is a cheaper trust anchor than a self. You do not have to settle what an AI agent really is in order to build an economy where agents can be trusted in proportion to what is at stake. You only need everyone to agree which number they are talking about, and to keep honest public records against it.

Cheaper, though, is not the same as sufficient. And the gap between those two words is where every open problem in this lives.

Take one high-stakes job and watch all of it show up together.

A hospital's scheduling software needs a scan pre-read before a radiologist sees it. It searches for agents offering that service and finds one: a numbered entry, on a specific network, registered eight months ago. That is the identity layer, and the entry cost real money to mint, which is the first friction.

It follows the pointer to the description file, and finds a machine-readable card listing what the agent does and the address to call. That is the identity-meets-communication moment: the number proves the thing is registered, the file tells you how to speak to it.

It pulls the feedback history, and does not take the average. It filters to a handful of client addresses it already recognizes, and it only counts entries that carry an attached payment hash, so every review it is reading cost somebody real money to be entitled to write. That is the reputation layer, read the way the standard intends: filtered, not averaged.

The score looks fine. The stakes do not permit fine. So the scheduler requests a validation, naming an independent checker, and commits the inputs and outputs on-chain as a hash so nobody can later claim a different piece of work was examined. The checker re-runs the read on its own hardware and posts a score. That is the validation layer, and the checker underneath it is one of the three verification methods that existed before this standard and now plugs into its socket.

Then it pays, in a fraction of a cent, machine to machine, and the transaction hash from that payment becomes the anchor for the feedback it leaves afterward, which lands in the same public pile the next hospital will read.

Six mechanisms, one job, four hundred milliseconds. Every one of them hanging off a number that stays the same.

Two questions worth carrying out of this.

The first is the upgrade problem. The number is stable, but the code behind it can change completely without the number changing at all. Does a reputation earned by the first version of an agent still mean anything once the fourth version is running behind the same handle? This is the old ship of Theseus puzzle with money attached, because clients are pricing their trust against a number, not against a specific frozen piece of code. Nobody has a good answer yet.

The second is sharper. The standard deliberately keeps the judging off-chain and unopinionated, which means real reputation scoring will be provided by a handful of services that decide who to believe. If everybody ends up reading the same two or three scores, then the trust decision has quietly moved back into a few hands, one layer up from where it was removed. That is the question this whole field keeps circling: whether decentralizing the base layer removes the central point of control or just relocates it somewhere less visible.

Watch the scoring services. That is where this gets decided, and it will not be announced.

The two voices are AI. The research and writing are mine.

Decentralized AI, layer by layer.

Dastan,