Hi,

Four questions have to be answered before a piece of software can spend your money without asking you first.

Who is this. How has it behaved. Did it do the work correctly. And, quietly underneath all three: was it ever allowed to try at all.

Almost every serious engineering effort of the last two years went at the first three. Identity registries, reputation ledgers, mathematical proofs that a computation ran as claimed. The fourth one sat unbuilt, and it fails independently of the others. An agent can be perfectly named, spotlessly reviewed, and provably correct, and still have bought something nobody ever said it could buy.

On July 22 that fourth question got infrastructure. A bank now signs your permission into a small sealed object carrying a category, a cap, and an expiry date, and a stranger three days later can check it without ever phoning you.

This week's Layer opens that object up, all the way down to what is actually inside it, and names the older pattern it belongs to. Not a guest list. A key. The lock has no idea who you are. It only checks the key.

Listen:

Spotify: https://open.spotify.com/episode/6z55TaB6K3BU5Bb8dFColk?si=qDUNbg8eTcizDtTB0mQjtw

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

YouTube: https://youtu.be/lc5zTosWMzQ?si=zUGNdqBQL9D_qhNO

The full piece, no need to click through:

It is a Tuesday evening and someone taps a button in a banking app. The button says something close to "allow automatic grocery purchases." They choose a few limits: groceries only, a cap on any single purchase, a cap on the total, and a window of a few days. Then they put the phone down and stop thinking about it.

On Friday, at three in the morning, while that person is asleep, a piece of software buys eighty seven dollars of groceries in their name. Nobody wakes them. Nothing asks them anything. The charge clears in well under a second, and their phone buzzes once, afterward, to say it happened.

Everything interesting is in the gap between the Tuesday and the Friday. On Tuesday there was a human being, awake, making a decision. On Friday there was only software, a merchant, and a payment network, and none of them can phone the human to check. So the yes from Tuesday has to survive three days alone, in a form a total stranger can inspect and believe.

On July 22, 2026, that gap got infrastructure built specifically to sit inside it. The XRP Ledger's payment service for software agents began accepting a new kind of credential from Mastercard, called Verifiable Intent, built with an infrastructure company called t54.ai and checked by a risk engine from a company called Trustline before any money moves. A small, unglamorous integration. It also closes a hole that everything else being built for autonomous software had quietly left open.

This episode is about one thing: before anyone can check whether a piece of software did a job correctly, someone has to have said it was allowed to try, and that permission has now become its own signed, bounded, checkable object.

Hold on to the simpler version underneath it. There are two completely different ways a machine acting for you can go wrong. It can do the job badly. Or it can do a job it was never supposed to touch. Almost all the engineering effort of the last two years went into the first problem. This month the second one got serious infrastructure.

Start with the word everything here hangs on: agent. An agent is software that makes decisions and acts, rather than software that waits to be told exactly what to do. A program that reorders groceries when it notices you are low, without being asked each time, is an agent. That is the whole definition, and it is deliberately unromantic.

Once software acts on its own out in the world, spending money and hiring other software, a stranger on the other end has to decide whether to deal with it. Three separate questions come up, and each already has a real answer built for it.

The first question is who is this. Software does not have a name the way a shop on a street has a name, because a web address costs nothing and anyone can make ten thousand of them in a second. So a standard called ERC-8004 was built to give an agent a registered, durable identifier, a number that stays the same across every service it touches, so that a history has something to hang on.

The second question is how has it behaved. Once there is a stable name, feedback from past clients can hang on it. That is a reputation in the ordinary sense: a running record of what happened the last hundred times somebody trusted this thing.

The third question is did it actually do the work correctly. This one has the most impressive machinery behind it: a mathematical proof that a computation ran exactly as claimed, a small receipt anyone can check without redoing the work; or an attestation from a sealed piece of hardware; or letting anyone re-run the job and punishing a liar who gets caught. Different mechanisms, one question.

Now notice what none of those three answer. Identity tells you which agent you are dealing with. Reputation tells you how it behaved before. Verification tells you whether a particular job was done right. Not one of them tells you whether the agent was ever allowed to attempt the job in the first place.

That is a genuinely separate question, and it fails independently of the others. An agent can be perfectly identified, carry a spotless reputation, and produce a flawlessly correct, fairly priced purchase, and still have done something badly wrong, if nobody ever authorized it to buy that category of thing at all. Correctness and authorization are two different axes. You can fail either one while passing the other. This episode is about the second axis finally getting built.

Intent comes from the Latin intendere, literally to stretch toward. It is in- meaning toward, plus tendere, to stretch, the same root that gives us tension and extend. So an intention, at the level of its own etymology, is a mind stretched toward a goal it has not yet reached. That is exactly the thing that has to survive from Tuesday to Friday: a stretch across time between deciding and doing.

Verifiable is blunter: the Latin verus, true, plus the ending meaning able to be. A verifiable claim is one a stranger can check without taking anybody's word for it. Be precise about what is being checked here, though. In the correctness machinery, verifiable means a mathematical fact: this computation ran this way. Here it means a social fact wearing cryptography: a bank's word that a customer clicked yes. The signature is real math. What it vouches for is a human decision.

The best word of the three is the one the framework itself uses for the permission: mandate. From the Latin mandare, to entrust, built out of manus, hand, and dare, to give. Literally, to give into someone's hand. That is not a general grant of trust. It is a specific, bounded thing handed over, and the boundary is the entire point. Which is exactly what the person in the banking app did on Tuesday. Not "I trust you." Rather: here, into your hand, this much money, for these things, until this date.

Strip the language away and ask what actually exists, as bytes and events, when one of these permissions is issued and used. It starts with an ordinary human action. A person opens their banking app and approves a spending mandate, choosing the merchant categories it covers (grocery stores, say, and convenience stores, identified by the same numeric category codes card networks have used for decades), a cap per purchase and a cap in total, and a validity window, at most seven days in the current specification. That single click is the entire real-world authorization event. Everything after it is machinery for making that one click checkable by strangers, over and over, for days, without going back to ask the person again.

The issuing bank then produces a signed credential locked to exactly those parameters. The mechanism is ordinary public-key signing, the same idea behind every padlock icon in a browser: the bank holds a private key only it has and signs with it, and anyone at all can hold the matching public key and check that signature without ever contacting the bank. The credential goes to the operator of the agent, the company running the shopping software, not to the person directly. From there the agent can present it at checkout as many times as it likes, at any merchant the categories allow, until either the money cap or the window runs out.

At checkout, the agent hands the credential to the payment service alongside the actual payment request. That request runs on a rail called x402, whose name is a small joke with history in it. HTTP status code 402 has read "Payment Required" since 1997 and went essentially unused for a quarter century, because the web never grew a way to pay a few cents mid-request. x402 finally uses it: a server answers with 402, the client sends a small amount of stablecoin, the request retries with proof of payment attached, and nobody needed an account or an API key. On the XRP Ledger this rail already carries real volume, into the millions of transactions.

The new part is what happens before that payment settles. The credential goes to a risk engine, which checks the bank's signature, then checks whether this purchase, this merchant, this amount, at this moment, falls inside the mandate's bounds. Only then does the payment proceed. Grocery store, eighty seven dollars, day three of seven: inside every bound, approved, settled. Electronics store, four hundred dollars, same day: outside the categories and outside the cap, refused before it ever touches the ledger. Not disputed afterward. Refused before.

One more physical detail, a design decision rather than a nicety: the person gets a push notification at the moment of each purchase, not a line on a monthly statement. A system built to take the human out of the loop keeps them informed during the delegated activity instead of after it. That is how something this automatic still feels controllable to the person who authorized it.

Here is the one place this episode goes all the way down, because the internal shape of the credential is where the design choices actually live.

The credential is not a single flat signed blob. It is built on a format called SD-JWT, which stands for Selective Disclosure JSON Web Token. A JSON Web Token, said out loud as "jot", is an old and extremely boring web standard: a small signed packet of claims, used every day to prove you are logged in somewhere. The interesting word is the first one. An ordinary token reveals every claim inside it the moment you show it to anyone, the way handing over a passport reveals your birthday and your document number to a bartender who only needed to know you are over eighteen. Selective disclosure lets the holder reveal only the claims a particular recipient needs, while the rest stay sealed under the same original signature and unreadable.

The implementation chains three of these together. The first layer is identity: who the person is, who runs the agent, enough for the network to know a real relationship exists. The second is the mandate itself: the categories, the caps, the window. The third is the specific transaction: this purchase, this amount, this merchant, tied back to the mandate it claims to satisfy. A merchant checking a sale needs the second and third layers and has no business seeing the first, and with selective disclosure it structurally cannot, rather than being asked politely not to look.

One precision worth carrying out, because it is easy to get wrong. Selective disclosure is not the same as a zero-knowledge proof, though both are about revealing less. Selective disclosure is redaction: you choose which fields to black out before handing the form over. A zero-knowledge proof is a mathematical guarantee about something never shown at all, proving you are over eighteen without the document containing your birthday ever leaving your pocket. The second is much stronger, and this framework did not use it. Either a proportionate choice for low stakes, or a soft spot, and reasonable people can disagree.

Surface now, because that is as deep as the spine needs. The point of all that structure is a single sentence: the permission travels as a small, sealed, self-checkable object that reveals only what each party needs, which is what lets a stranger honor a yes given three days ago by someone they will never speak to.

There is a shape here that shows up all over computing and all over ordinary life, and naming it makes every future version of this story readable. There are two classic ways to control access to anything. The first is a list: a gatekeeper holds the approved identities and checks each arrival against it. Guest lists work this way, and so do most corporate systems. The second is a capability, where the permission itself is embodied in an object that is hard to forge, and whoever holds that object gets exactly what it grants, with no identity check beyond checking the object is genuine. A physical door key is a capability. The lock has no idea who you are. It only checks the key.

A Verifiable Intent credential is a capability token wearing payment-network clothing. The merchant does not need to know or trust the person or the company running the agent. It only needs to trust that this credential, if genuine, grants exactly what it says on its face.

That is a different kind of trust from reputation, and the two are complements rather than rivals. Reputation is list-shaped: a history attached to a name, consulted each time, answering "should I trust this thing's judgment in general." A capability is bounded and history-blind: it answers "is this thing allowed to spend this money on this thing right now," and does not care what the agent did last Tuesday. A mature economy of autonomous software needs both, and until this month it had only one of them built.

There is a second, older pattern underneath this one: push the expensive, unverifiable human judgment as far upstream as possible, and let only a small checkable receipt travel through the parts of the system strangers have to trust. The hard judgment here, does this person genuinely want to authorize this, happens off the network entirely, inside a banking app and a human's actual finger. What crosses into the checkable layer is only the compact signed artifact that judgment produced. Verify a receipt, not a mind.

Delegation is one of the oldest ideas humans have for reaching past the limits of one body in one place. A ruler sends an ambassador, entrusted to negotiate within limits set in advance. A company hands an employee a card with a spending limit on it. Every version across history has the same three-part structure: who granted this authority, what exactly did they grant, and how does a stranger check the boundary without trusting either party directly.

So the idea is not new. What is new is the timescale and the grain. An ambassador negotiates for months under one mandate. A corporate card resets monthly. This credential authorizes possibly hundreds of tiny independent decisions across seven days, each one small enough that asking the human every time would defeat the point of automating it. This is delegation at machine speed: a person stretching their intent, there is intendere again, across thousands of small acts they will never individually witness, trusting a cryptographic boundary rather than their own attention to keep each act inside the shape of what they meant.

And there is a trade here worth being honest about, because it is the trade the rest of this stack refused to make. The identity standard is open to anyone: no company's approval is required to register. The payment rail is open to anyone: no account, no gatekeeper. This authorization layer is not. It requires the operator of the agent to be a registered business with a relationship to a card network, and an anonymous or unaffiliated operator falls outside the framework entirely, by its own stated limits. Every layer of this field seems to arrive twice, once from the open direction and once from the institutional one, built by different kinds of organizations at different speeds. Authorization got its first serious answer from the institutional side, and it is not obvious that was the wrong outcome. The hard problem here was never "how do we prove this mathematically." It was "who eats the loss when the boundary gets crossed," and that question only has teeth when a real institution stands behind the answer.

Which is exactly what changed underneath. In ordinary online card fraud the loss usually lands on the merchant. This framework adds a new party who can be held liable: the operator of the agent, specifically for purchases where its software went outside the mandate it was given. That is not a cryptographic innovation. It is a legal one, a rewriting of dispute rules inside a system decades old, and it is the same shape as punishing a cheater in an open network by taking their money. Someone can be proven wrong after the fact, and eating the cost is the deterrent. One version runs through a court, the other through code.

Walk one transaction from end to end, naming each layer as it appears.

The person clicks yes on Tuesday: groceries only, capped, seven days. That is the mandate, the bounded permission given into a hand. The bank signs it into a selectively disclosable credential and hands it to the company running the agent. The capability token now exists.

On Friday the agent decides it is time to reorder. It arrives at the merchant carrying a registered identity, a number that stays the same across every service it deals with, and hanging off that number a reputation, the record of how it treated its last hundred clients. Those two answer who is this and how has it behaved.

It hits checkout. The merchant answers with payment required, and the agent pays with stablecoin over the open rail. Payment executed, no account, no human. Riding beside that payment goes the credential. The risk engine checks the bank's signature, checks that eighty seven dollars of groceries on day three sits inside the caps and the window and the categories, and only then lets the money settle. Authorization checked.

Afterward, if anyone wants to know whether the software actually did what it claimed, that is the fourth question, answered by proof or attestation or re-running. Four questions, four pieces of infrastructure. Until this month, three of them existed. The phone buzzes. The person, asleep, has groceries arriving and a boundary that held.

Two questions worth chasing, neither with an answer yet.

The first is whether the bank issuing these mandates becomes a chokepoint exactly where the rest of this stack worked hard to avoid one. One version of this argument says centralization creeps back in anyway, one layer up, in the services that aggregate reputation. This framework skips that worry by building the concentration in from day one: one institution is the sole source of every permission. It is the cleanest available test of whether "keep the base layer open and let a centralized service sit on top" and "centralize the layer outright" produce different outcomes, or quietly converge.

The second is what happens at the seams. This framework covers one card network. Every other network, and the purely open rails, each need their own equivalent, and there is no cross-network standard for mandates in sight. An agent shopping across several rails for one person would need a different permission slip for each. Communication between agents went through the same fragmentation and eventually converged. Whether authorization converges the same way, or stays split by network for years, is an open bet.

The thing to watch for is a permissionless version: a mandate registry nobody needs a banking relationship to use. If it appears, this becomes a two-path layer like every other layer here. If it does not, then the moment software started spending real money on our behalf is the moment the banks quietly got their hands back on the wheel.

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

Decentralized AI, layer by layer.

Dastan