This article extends a five-part series on agentic systems: the shift in the primary user layer, mandates as the missing primitive, a taxonomy of agents by authority, the governance layer around a mandate, and where Web3 rails become material. It reads BlackRock's September 2026 paper against that framework.
In September 2026 BlackRock published The Machine-Native Economy: How digital assets connect intelligence, commerce, and compute, authored by its digital assets research and ETF product leadership. The core claim is compact: AI is machine-native intelligence, digital assets are machine-native money, and agentic AI is where the two converge.
The paper makes three arguments. Language models and blockchains share an analogous tokenization architecture. Agentic commerce needs payment rails built for always-on, sub-cent, machine-to-machine transactions. And compute is becoming a large enough economic resource to support a new class of tokenized claims.
When the largest asset manager in the world writes that agentic payments are a structural source of demand for digital assets, it changes who takes the topic seriously. That is the paper's real contribution, and it deserves credit on those terms.
What the paper describes in detail is the money. What it describes in a single clause is the authority to spend it. My argument in this series has been that the second problem is the harder one, and BlackRock's own reference workflow shows why.
What does BlackRock's machine-native economy paper actually claim?
It claims that broad AI adoption is an underappreciated source of demand for digital assets, through three channels: payments, standardized asset representation, and compute.
On payments, the paper argues that card and ACH rails carry onboarding requirements, merchant fees and settlement timelines that make them a poor fit for high-frequency, very low-value, programmable transactions. Blockchain rails — with stablecoins as the likely transactional asset — fit that profile better. It lists the emerging protocol stack: MCP and A2A as foundational agent standards, and above them x402 (Coinbase), the Machine Payments Protocol (Stripe and Tempo), the Agentic Commerce Protocol (Stripe and OpenAI), Google's AP2, and Visa's Trusted Agent Protocol.
The supporting numbers: stablecoins above $300 billion in circulation as of September 2026; adjusted stablecoin transaction volume above $11 trillion in 2025, against roughly $93 trillion through ACH; an 80% compound annual growth rate for adjusted stablecoin volume between 2020 and 2025, against about 8.5% for ACH.
On compute, the paper cites consensus estimates that the major hyperscaler cloud segments reach roughly $1.1 trillion in combined revenue by 2030, argues that inference will become the largest AI workload, and proposes that standardized claims on compute capacity could be tokenized, financed, hedged and settled on programmable rails. It points to Stripe's August 2026 agreement to acquire OpenRouter as an early signal that model routing and usage billing are becoming financial infrastructure.
The paper is also careful in places where coverage of it will not be. It states that agentic payment activity remains nascent, that compute-market liquidity is still limited, and that the Bitcoin Policy Institute study it cites — models favouring stablecoins for payments and bitcoin for savings — reflects simulated model responses rather than observed agent behaviour. Those caveats are worth keeping when the paper gets quoted.
Where does the paper put the authorization problem?
Inside one arrow in its reference workflow.
The paper's illustrative scenario runs like this. A user asks a primary agent to book a trip under $2,500. The primary agent reaches the user's calendar, preferences and approved payment details through MCP. It delegates data gathering to a travel sub-agent through A2A. The sub-agent pays for airfare and hotel-rate APIs through x402, settled on-chain. The primary agent then completes the booking through merchant checkout via ACP and returns the itinerary.
Read that sequence as an authority chain rather than a data flow, and the questions appear immediately.
What exactly did the user authorize — a $2,500 ceiling on the trip, or on everything the agents spend while planning it, including paid API calls? The paper does not say, and the two readings produce different outcomes when the sub-agent spends $40 on data and the flights cost $2,480.
What authority did the sub-agent receive? It pays through x402 from somewhere. Either it holds its own funded wallet, in which case someone pre-funded a second actor, or it spends against the primary agent's authority, in which case delegation happened and its bounds are undefined in the diagram.
How long does any of this last? Does the sub-agent's ability to spend end when the itinerary is returned, or when someone remembers to revoke it?
Who is accountable when the sub-agent pays for a data feed the user would never have approved?
None of these are exotic edge cases. They are the default questions any system executing on someone else's behalf has to answer, and the diagram answers none of them. The $2,500 is a spending bound. The hand-off to the sub-agent is a scope. Both are fields of a mandate, and in the workflow as drawn both travel inside the prompt, enforced by nothing.
That is not an oversight of the paper so much as a faithful picture of the stack. MCP's specification lists user consent and control as core principles and states plainly that the protocol cannot enforce them — that is left to implementations. The foundational agent protocols standardize how agents talk and deliberately leave authorization outside. The paper mentions AP2's use of cryptographic mandates and audit trails in one sentence. That sentence carries the entire authorization layer of the machine economy.
Machine-native intelligence exists. Machine-native money exists. The authority connecting them is still a line of text.
Why is payment capability not the same as payment authority?
Because a rail answers whether a payment can settle, while authority answers whether this payment should have been made by this actor on this principal's behalf.
x402 is a good example of a rail doing its job well. It turns HTTP 402 into a payment step, settles near real time, and lets a resource provider release data immediately on confirmation. From the provider's side the problem is solved: it got paid, with finality, with no counterparty exposure.
From the principal's side, nothing about authority has been established. A settled payment proves that a key signed a transfer. It does not prove that the key belonged to an actor entitled to spend on that task, within that amount, before that deadline, on that category of purchase.
In the second article of this series I argued that the missing primitive is a portable mandate: an object that binds six fields together — the principal, the scope, the expiry, the revocation path, the accountable party, and the spend semantics. BlackRock's workflow needs every one of them and specifies none.
Spend semantics is the one most likely to fail quietly. A cap of $2,500 can mean per transaction, per task, per day, or in aggregate across delegated sub-agents. Machine-to-machine payments at sub-cent granularity make the aggregate reading the only safe one, and also the hardest to enforce, because the danger is no longer one large wrong payment. It is an unbounded sequence of individually valid, individually trivial ones.
Are all AI agents economic actors?
No, and the paper implicitly treats them as if they were.
The third article proposed classifying agents by authority rather than capability: assistants that recommend, orchestrators that coordinate, operators that execute inside bounded permissions, and economic actors that commit resources on a principal's behalf. The distinction matters because each class needs a different control model, and the cost of treating an assistant as an economic actor is paid in exposure.
BlackRock's workflow contains three agents. Classified by authority, the travel sub-agent is an orchestrator that also makes payments, the primary agent is an economic actor committing up to $2,500, and the merchant-side checkout logic is an operator. The paper describes them all as agents that pay.
That flattening matters for the demand thesis too. If most deployed agents are assistants and orchestrators — which is what I would expect for years, because firms extend spending authority slowly — then the volume of genuinely autonomous machine payments will grow more slowly than the number of agents. Agent count is not transaction count, and transaction count is not value.
There is one correction to my own taxonomy that the paper forces, and it comes from the compute section rather than the payments one. In June I argued that Web3 rails matter for a narrow subclass: economic actors. That still holds, but the boundary of the subclass moved. An agent that pays for its own inference becomes an economic actor without anyone deciding to make it one. The decision to grant spending authority used to be a deliberate act of the principal. Once compute is bought per call on programmable rails, it becomes a side effect of letting the agent run. The class of economic actors widens through operation, not through design — and nothing in the classification flags the moment an orchestrator crossed over.
Does machine-readable money make a machine economy?
It makes one possible. The paper's tokenization analogy overstates how much it makes inevitable.
The analogy is that language models convert text into discrete numeric tokens and blockchains convert economic claims into discrete digital tokens, so agents get a more direct interface with on-chain assets than with fragmented legacy systems. The paper itself notes that the functions are distinct.
They are more distinct than the analogy lets on. A language-model token is a unit of representation; it carries no claim and needs no verification. A digital-asset token is a unit of entitlement; its entire value depends on a verifiable link to an issuer, a registry and a legal right. What agents gain from on-chain assets is not that both systems use tokens. It is that on-chain state can be read and checked by anyone without asking the operator — which is a property of verifiability, not of tokenization.
That is also where the paper's own caveat becomes load-bearing. For tokenized real-world assets it notes that KYC, AML and know-your-agent checks happen off-chain, with verified results passed on-chain, inside a legal framework that still relies on authoritative off-chain registries. So the agent reads a machine-readable token whose meaning is determined by a machine-unreadable legal relationship. Standardized representation reduces integration work. It does not remove the dependency on the off-chain source of truth.
When do blockchain rails actually matter for agents?
When the parties do not share a trusted operator.
The fifth article drew a narrow boundary. Blockchain rails become material when an agent transacts across organizational boundaries, with counterparties that do not share an operator, and when authority needs to travel with the agent rather than live inside one platform's database. Inside a single company, or between parties already on the same processor, a conventional ledger is usually cheaper and sufficient.
BlackRock's segmentation supports this more than it seems to. It splits the market into machine-to-machine transactions, where it expects crypto-native rails to fit best, and business-to-machine and consumer-to-machine settings, where adapted traditional rails remain important. That is the same boundary drawn from the payments side: rails matter where there is no shared operator and no pre-existing relationship.
Which clarifies the demand thesis. The on-chain share of agentic commerce will track the share of agent transactions that cross operator boundaries without a prior relationship — not the total volume of agent activity. A travel agent booking through a merchant's existing checkout is a card transaction with extra steps. A sub-agent buying data from a provider it has never contracted with is where x402 does something a card cannot.
Who governs the agent once it has authority?
Nobody, in the paper's frame. That is the gap the fourth article was about.
A mandate specifies authority at a point in time. Governance is everything around it: issuing, monitoring, amending, revoking, auditing, and resolving disputes. Inside one organization those functions can live in one policy engine. Between organizations there is no shared place for them to live, which is why AP2's audit trails and Visa's trusted-agent verification exist at all.
The paper lists these protocols side by side as a stack. They are better read as competing answers to the governance question. x402 establishes that a payment settled. AP2 aims to establish that a user authorized it. TAP aims to let a merchant recognize an agent it can trust. ACP lets sellers keep their existing infrastructure. Each of them solves a different part of the authority problem, and none of them solves delegation from one agent to another, which is exactly the step BlackRock's workflow depends on.
Which part of a mandate fails first?
Revocation, and it fails silently.
Of the six mandate fields, five fail loudly when they are wrong. A scope violation throws an error, an expired mandate gets rejected, a spend cap trips. Revocation is the one field whose failure produces no signal by default, because a revocation that did not take effect looks exactly like an authority that was never revoked.
I hit a version of this in my own tooling the week this paper came out. An agent's access to an external service went through a normal consent flow. Consent succeeded, no errors, the token file was fresh. Access did not work. The cause was a process that was not listening on the port where the provider sends its callback, so it kept quietly refreshing the old token. For five days the agent ran on authority that nobody had reconfirmed, and nothing in the system reported anything.
It cost me a weekend. Put the same agent on rails where it also holds a wallet with stablecoins, and the same failure mode has a different name. A revocation that cannot be observed is not a revocation. Any agentic payment design worth trusting has to make the current state of authority checkable from outside the agent, not asserted by it.
What happens when an agent buys its own compute?
The mandate acquires a second axis, and the failure mode changes shape.
The compute section is the strongest part of the paper, and the paper itself describes the scenario that matters: agents querying marketplace APIs, comparing capacity by price, latency and hardware, provisioning what the workload needs, and settling per use, per model token or per job through x402. Elastic, just-in-time compute with limited human intervention.
Read that as an authority question and it changes what a mandate has to cover. The mandate in this series answered what an agent may do and on whose behalf. An agent that procures its own compute also needs an answer to how much and who pays when the number runs away. That is not a new primitive. It is the same object with a consumption dimension it did not previously need, because the resource being spent is the one the agent needs in order to keep working.
The failure mode is not a hallucination. It is a loop. The task does not converge, the agent buys more capacity to keep trying, the meter keeps running, and every individual purchase is valid and within per-call limits. It is the aggregate-spend problem from the payments section, except that the agent is now spending on itself, and the natural stopping condition — the task finishing — is exactly the thing that failed.
Two consequences follow that neither the paper nor my June articles covered.
Spend bounds for compute have to be bound to outcomes, not only to amounts. A cap on dollars stops the meter. It does not tell anyone whether the spend produced anything. A mandate for self-procured compute needs a budget tied to a task and a condition under which the agent stops and escalates rather than continuing to buy.
If compute claims become collateral, agent overspend becomes somebody's liquidity problem. The paper's vision includes compute claims that can be pledged as collateral. Once that is true, an agent burning through prepaid or pledged capacity is not just an operational cost overrun. It is a reduction in someone's collateral base, possibly inside a financing structure that assumed the capacity would be there. The runaway loop stops being an engineering incident and becomes a credit event on a balance sheet that did not choose to be exposed to it.
Where does compute actually need a blockchain?
At the tail, not at the exchange.
The paper's path for compute runs through commodity-market machinery: basis markets, contracts for difference, standardized exchange-traded futures, hedging for providers and buyers. All of that is sensible, and none of it needs a distributed ledger. Commodity exchanges have run futures, basis and hedging for over a century on central clearing. Price discovery for GPU capacity is a job for an exchange with a clearinghouse, and tokenizing it adds little that a CME-style venue does not already provide.
The chain earns its place at the other end: settlement for a specific job, a single inference call, between agents that nobody onboarded to each other. The always-on, sub-cent tail where there is no clearinghouse, no account relationship and no party that both sides already trust to keep the record. That is the least glamorous part of BlackRock's thesis and the only part where there is genuinely no one else to hold the ledger — which is the same operator-boundary test from the fifth article, applied to compute.
What does the compute thesis need that the paper leaves open?
A correction path and a delivery definition.
The paper is candid that standardized compute products face contract-design problems: productivity differences across chip generations, regional energy-cost divergence, and the need to define both cash settlement and delivery of contracted capacity. It proposes commodity-market precedents — basis markets, contracts for difference, exchange-traded futures — and treats the problems as resolvable.
They probably are. But the order of operations matters, and it is the same order I argued for tokenized real-world assets in the market-structure test. A tradable claim needs a defensible price anchor, a way to correct mispricing through delivery or redemption, and someone willing to warehouse inventory between buyer and seller. A GPU-hour claim without a delivery obligation that can be enforced at a known location, on a known hardware class, within a known latency, is a claim with no correction path. Tokenizing it makes transfer easy and leaves pricing unanchored.
The compute case also carries a lifecycle problem that most commodities do not. Hardware generations depreciate on a timescale of a couple of years, and a claim on today's accelerator is a claim on a declining asset whose replacement changes the unit of account. The paper names chip-generation heterogeneity; the harder version is that the underlying unit itself is not stable.
A falsifiable version of the argument
Stated so it can be checked rather than just argued:
Agentic payment volume on public blockchains will grow first and fastest in agent-to-provider micropayments with no prior relationship — paid APIs, data, and per-call inference — and will lag in consumer purchases executed by agents, where existing rails and existing merchant relationships already work.
Method: x402 settlement is observable on-chain, and facilitators publish volume. Track the share of x402 volume going to API, data and inference endpoints versus merchant checkout over the next four quarters. If agent-driven consumer checkout grows faster on-chain than agent-to-provider micropayments, the operator-boundary reading in this article is wrong.
A second, more uncomfortable prediction: the first material agentic-payment losses will come from delegation, not from rails. Not a failed settlement or a broken protocol, but a sub-agent spending inside technically valid permissions that nobody intended to grant — the aggregate-spend failure described above. If the first widely reported incidents are rail failures rather than authority failures, that prediction is wrong too.
A third, specific to compute: the first costly incident in agent-procured compute will be a non-converging task buying capacity in a loop, not a pricing or delivery dispute. Observable in the same way — through post-mortems and provider-side usage anomalies. If disputes over delivered capacity dominate instead, the loop reading is wrong.
What can you check yourself before trusting an agentic payment design?
Six questions, answerable from documentation without access to anyone's internals.
Where is the spending limit enforced? In the wallet, the protocol, the facilitator, or only in the agent's prompt. A limit that lives in the prompt is a suggestion. The wallet is the most natural enforcement point, and modular smart accounts are the most mature place to put per-module spending policy today — with the trade-offs against MPC-based custody that apply to any agent wallet.
Is the limit aggregate? Per-transaction caps do not bound a stream of micropayments. Ask whether the limit covers everything spent under one task, including sub-agents.
What happens on delegation? When one agent hands work to another, does spending authority transfer, narrow, or get re-issued? If the answer is "the sub-agent has its own funded wallet", someone pre-funded an actor whose authority nobody specified.
How is authority revoked, how fast, and how would you know? Revocation that depends on an agent noticing is not revocation. Ask for the mechanism, the latency, and — the part usually missing — how an outside observer can confirm that revoked authority is actually dead.
Can the agent buy its own compute, and what stops it? If yes, ask whether the budget is tied to a task and whether there is a condition under which the agent stops buying and escalates. A dollar cap alone will stop a runaway loop only after it has spent the whole cap.
What evidence exists afterwards? A settled transaction proves a key signed. Ask what proves that the principal authorized that category of spend, and who holds that evidence.
What this changes for the series
The five earlier articles built the argument bottom-up: the user layer is shifting to agents, the missing primitive is a portable mandate, agents differ by authority rather than capability, governance is the layer around the mandate, and blockchain rails matter at a narrow boundary.
BlackRock's paper builds the same picture top-down, from the capital markets side, and arrives at the same place with one layer compressed. It is right that machine-native money is arriving and that compute is becoming a financeable resource. The money layer is the most visible part of the machine economy and the most investable one.
The authority layer is less visible and less investable, which is precisely why it will be underbuilt. And compute makes the gap wider rather than narrower: an agent that pays for its own thinking turns every open-ended task into an open-ended spending authority.
It is a good paper, and it is written by a firm that builds products on its thesis, which is how theses usually get written. One detail is worth sitting with. In a document about machines paying machines, with every other layer described as protocol, standard or token, the one thing still written in human language is the permission.
Disclosure and scope
This is independent analytical commentary reflecting my own views. BlackRock did not commission, review or approve it, and I hold no financial interest in BlackRock or in the protocols and companies named. It is not investment, legal or tax advice. The views expressed do not represent Haia, Haust Network or Innowise. Figures attributed to the paper are as published in September 2026; the paper itself describes them as estimates and projections, and I have not independently verified them. Protocol descriptions reflect public documentation at the time of writing and may change.