On September 17, 2026, two documents landed that describe the same machine from opposite ends. One was an order from the SEC. The other was a research paper from BlackRock. Between them they map how an agent pays, who may trade, and what a venue is allowed to require. Neither says where the answer comes from.

The SEC order allows Tokenized Securities Venues to trade tokenized NMS stock on permissioned automated market makers, on public blockchains, with retail investors named as eligible participants. It describes the mechanism a venue may use. A pool "may be encoded with criteria or a list of persons to ensure that only certain 'white-listed' or 'allow-listed' crypto asset wallet participant addresses (i.e., wallet addresses that meet certain credentialing requirements) gain access to trading."

The BlackRock paper, The Machine-Native Economy, argues that AI and digital assets are converging, that agentic commerce will need machine-native payment rails, and that compute is becoming a market in its own right. It is a serious paper, and it names seven protocols.

Five for how an agent pays: x402, MPP, ACP, AP2, TAP. Two for how agents coordinate before paying: MCP and A2A.

For the part where somebody works out whether a given payment should go through, it has one sentence.

"Anti-money laundering (AML), know-your-customer (KYC), and know-your-agent (KYA) checks generally occur off-chain, where identity and compliance data can be assessed, with verified results passed on-chain to determine transaction eligibility."

That sentence is carrying more weight than the seven protocols above it.

Look at where the determining happens

Read the sentence for its architecture rather than its content. Checks run off-chain. Results get passed on-chain. The results determine eligibility.

The party whose money and licence are at risk does not appear anywhere in it. Whoever ran the check has made the determination, and the venue receives it as a finding.

Two different jobs are hiding in that clause. Setting the standard is one. Evaluating whether a given wallet meets it is the other. A venue can hand out the second, and should, because answering the same question ten thousand times a day is work. It cannot hand out the first, because the consequences of a wrong standard land on the venue and nowhere else.

The SEC order is explicit about the part the paper leaves compressed. In the order the criteria belong to the pool: the venue encodes the standard. An outside service can answer facts against it. What those facts mean for admission stays with the venue.

What the answer has to be

Once the decision stays with the venue, the requirements for everything upstream of it get specific.

It has to answer their question, not somebody else's. A generic risk finding is not the same as a determination that this wallet meets this venue's stated condition at this moment. The condition has to come from the party that bears the consequence.

It has to be current. A verdict computed last Tuesday is a statement about last Tuesday. Agents move faster than the refresh cycle of any cached compliance record, and the gap between when a fact was true and when somebody acts on it is where losses live.

It has to arrive as evidence. If the answer is just a yes, everyone downstream is trusting a database they cannot inspect. The payment rails went to real trouble to be verifiable, and handing them an unverifiable finding at the final step throws that away.

It has to survive the counterparty. The venue that let the trade through and the examiner asking about it eight months later should be able to reach the same conclusion from the same artifact, without ringing anyone up.

It has to be cheap and fast enough to live inside a machine transaction. An answer that costs a dollar and takes four seconds is not part of an agent's workflow. It is a reason the workflow never gets built.

Identity checks are real and they are not going away. But some eligibility questions are not identity questions at all. Whether a wallet holds a required asset, clears a threshold, or carries a delegation that has not been revoked is a question about current state, and that is public, recomputable, and provable by anyone who cares to look.

What the person on the other end gives up

There is a human at the end of this, and the shape of the answer decides what they hand over.

An identity-first check asks somebody to produce documents, and then the venue holds them. A condition-based check asks a different question entirely: does this wallet meet the rule the venue wrote. The answer is met or not met. The venue learns that the threshold was met. It does not learn what else the wallet holds, what it is worth, or where the rest of it went.

That is a better deal for the shareholder claiming a discount at a checkout, for the holder proving a delegation is still live, and for anyone who would rather prove one fact than surrender a file. It is also a better deal for the venue, which now holds an answer it can show an examiner instead of a pile of documents it has to defend.

Three layers, and where each one stops

Trust in this kind of system separates cleanly into three things that people tend to mash together.

Origin. Did the party who claims to have answered actually answer it. A signature settles that, and the relying party checks it locally against a published key.

Correctness. Was the answer true. Because the inputs are public chain state, anyone can audit it independently. Nobody has to take the answer's word for itself.

Acceptance. Given a true answer, does the venue allow the trade. That is a policy decision, it belongs to the venue, and no outside party should be making it.

The first two are work that can be done for you. The third is not, and any architecture that quietly absorbs it has taken something from the venue that the venue cannot afford to give away.

We do the first two. We answer the condition the venue wrote, yes or no, and we sign the receipt. What the venue does with that answer is the venue's.

What already runs

None of this is a gap in the technology. It is a gap in the maps.

Wallet auth does one thing. It reads blockchain state, evaluates it against a condition the merchant or venue defined, and returns a signed answer with the evidence attached. Conditions in, signed attestations out. Nine condition types covering token holdings, NFT ownership, EAS attestations, on-chain view calls, ratio tests, agent registry entries and delegation status. Thirty-seven chains: thirty-one EVM networks plus Solana, XRPL, Bitcoin, Tron, Stellar and Sui.

Every response is ECDSA-signed and verifiable offline, against a published key set, by anyone holding the artifact. Each one also carries a post-quantum companion signature, ML-DSA-65 under FIPS 204, over the same content the classical signature covers. The companion sits alongside the classical signature rather than replacing it.

The two keys are tied together by a cross-signed binding published at a well-known URL, with the digest of that binding anchored on Base, in block 50758053. A verifier does not have to take anyone's word that the post-quantum key and the ECDSA key belong to the same issuer. It checks the binding, then checks the anchor against a public chain.

In the JWT format the companion is bound to the classical token by the entire claim set: the same member names, and for every member a deeply equal value, compared as parsed JSON rather than bytes. Any difference, a changed value or a missing or extra member on either side, and the companion is refused. A check that passes while covering only part of an artifact is the failure that looks most like success, so the rule covers all of it.

The reference verifier is a published npm package, so checking an answer never requires trusting the party that produced it. A read that fails or comes back partial is refused rather than signed, because a signature over a guess is worse than no answer at all.

It also sits where the research paper says the traffic is heading. The API is payable per call over x402, with no account and no API key, in USDC on Base, Polygon, Arbitrum, Arc and Solana. A condition check costs five cents. The payer is charged only for a successful answer, and the payer sees the answer only after the payment settled.

The paper singles out Arc, Circle's network where USDC is the native gas asset, as a venue worth watching. Arc reached mainnet on September 16. It was live on this engine on September 17, the same day the paper's file was created, and payable over x402 four days after that.

Wallet auth is also in active standards work across UCP, A2A, Ethereum ERCs and the IETF, with vocabulary contributions merged into an external agent-governance specification. The specification work on this layer is happening in the open. It is happening outside the institutions drawing the maps, which is why it keeps not appearing on them.

The sentence is the whole argument

The notable thing about that one sentence is not that it is wrong about the world. Checks do run off-chain, and verified results do get passed along.

The notable thing is that an entire category got compressed into a subordinate clause, in a paper that spends pages on the protocols upstream of it, and that the compression hides the distinction between answering the condition and owning the decision.

Five ways to pay. Two ways to coordinate. One clause for where the answer comes from, and in that clause the venue disappears.

The market has not put a box around this layer yet, or settled on a name for it. What the institutions drawing the maps have not yet worked out is that the answer and the decision are different jobs, and that only one of them can be handed to somebody else.

Douglas

Sources: BlackRock, "The Machine-Native Economy: How digital assets connect intelligence, commerce, and compute," September 2026 (Will Su, Robert Mitchnick, Jay Jacobs, William Helm). U.S. Securities and Exchange Commission, Release 34-106402, File No. 4-927, September 17, 2026. Comment letter on File No. 4-927 filed by the author, September 17, 2026, and posted to the Commission's public comment file.

Condition-based access across 37 chains

InsumerAPI: evaluate wallet conditions, get a signed result. No secrets. No identity. Free tier available.

View API Docs

Get every post by email

The Inevitable series and builder notes on condition-based access. Free, one or two posts a week.