BlackRock's machine-native economy — the world's largest asset manager says stablecoins are AI agents' money, and its own diagram shows who gets paid first

What BlackRock published on September 23, 2026

The paper is short — eleven pages — and it comes from the part of BlackRock that runs the firm's digital asset products, not from a strategist writing about the future in general. Its authors are Will Su (Head of Digital Assets Research), Robert Mitchnick (Head of Digital Assets), Jay Jacobs (U.S. Head of Equity ETFs) and William Helm (Head of U.S. iShares Product Innovation). The full text is on BlackRock's site, and Cointelegraph summarised it the same day.

It makes three arguments. First, large language models and blockchains share a "tokenization architecture": both turn real-world inputs into units a machine can process natively. Second, "agentic commerce requires machine-native payment rails," and stablecoins are the likely transactional leader. Third, compute is becoming an investable resource. BlackRock cites consensus estimates of roughly $1.1 trillion in combined AWS, Microsoft Intelligent Cloud and Google Cloud revenue by 2030, and argues that tokenised claims on compute capacity could become "a significant digital asset use case."

The market context it uses is worth writing down, because it is now the institutional baseline. Stablecoins had more than $300 billion in circulating market capitalisation as of September 2026. Adjusted stablecoin transaction volume exceeded $11 trillion in 2025, "in the same broad range as Visa and Mastercard's annual payment volumes." That is still far below the $93 trillion that moved over ACH, but stablecoin volume grew at an 80% CAGR from 2020 to 2025, against roughly 8.5% for ACH. The paper credits growing regulatory clarity (the GENIUS Act, MiCA, and the Hong Kong and Singapore regimes) for the trend.

The most useful part for businesses is the conclusion, where BlackRock is careful: "The ecosystem remains nascent, with agentic payment activity and compute-market liquidity still limited." This is an investor document stating a thesis, not announcing a product. It helps to read it that way.

The frictions BlackRock lists are all seller-side costs

Here is the passage that matters most to anyone who sells something. According to the paper, many existing payment rails are "less well suited to high-volume, low-denomination agentic transactions" because they involve:

• "Account setup, credentialing, and authorization processes that may require human involvement;"
• "Merchant acceptance fees that can make very low-value transactions uneconomic;"
• "Settlement and finality constraints, as most ACH volume settles within one business day or less, while card authorization is near-instant but merchant settlement and dispute finality can take longer;" and
• "Potential scalability limitations as machine-generated transaction volumes grow."

Look at who bears each one. Account setup is the seller's onboarding. For an API business, that means a signup form, a billing profile, an API key to issue and a card on file for every new customer. An agent can't fill in that form without a human. Acceptance fees are charged to the merchant, and a fixed per-transaction fee makes a two-cent call cost more to collect than it earns. Settlement and dispute finality is the seller's cash flow and the seller's reversal risk. The buyer — human or agent — doesn't feel any of these. The seller does.

BlackRock frames the argument as demand for digital assets. For a business, the same list is a description of why selling small things to software has been impractical. The paper's answer is that on x402, settlement is "24/7, near-real-time, verifiable," which "can reduce the resource provider's counterparty exposure and enable the immediate release of requested data or services upon payment confirmation." Resource provider is BlackRock's word for the seller. The benefit it describes is getting paid before you serve the request, with no credit risk on the caller.

Read the diagram: the first seller is an API, not a store

Figure 2 of the paper walks through one agentic purchase from start to finish:

1. A person asks an agent to book a trip "for under $2,500."
2. The primary agent reads calendar, email and approved payment credentials through MCP connectors.
3. It hands data-gathering to a specialised travel sub-agent over A2A.
4. The sub-agent "calls paid airfare and hotel-rate APIs, with applicable payments handled through x402 and settled on-chain."
5. The primary agent "completes reservations through airline and hotel checkout systems" — via ACP, which the paper describes as letting "sellers retain their existing commerce and payment infrastructure."
6. Itinerary and receipts go back to the person.

Notice where the stablecoin payment happens. The biggest purchase — the flight and the hotel, most of the $2,500 — goes through existing checkout systems. The on-chain, per-call x402 payment goes to the data provider: whoever sells fares, room rates, seat maps and availability to the agent doing the research. That is the high-frequency, low-value, always-on transaction BlackRock says crypto rails are best suited to. The compute section of the paper follows the same pattern, with agents that "discover, provision, optimize, and pay for compute through programmable payment rails such as x402" on "a per-use, per-model-token, or per-job basis."

So the most detailed institutional forecast so far gives a clear answer to "who gets paid by agents first?" It isn't retailers. It's APIs, data feeds, tools and compute — businesses whose product is already a URL that returns a response. We made the same argument when Stripe agreed to buy OpenRouter, a deal BlackRock also cites as "an early strategic signal."

The number BlackRock's critics will quote — and why it points the same way

The coverage paired the paper with a less flattering data point. On September 9, 2026, TRM Labs published "Who's Actually Paying?", an attempt to measure agent payments on-chain. TRM looked at about $52.7 million settled across 198.9 million x402 transactions on Base, Solana and Polygon since May 2025. 99.6% of that value was in USDC. After removing self-payments, flows concentrated in one or two payers, and sellers with fewer than ten distinct buyers, $25.62 million of plausible commerce remained. TRM's estimate of the genuinely agentic share was 0.6% to 7.5%. The run-rate was in the thousands of dollars a month, not millions.

This is a fair data point, and we have covered its history elsewhere, from the 2026 volume decline to what the median x402 seller actually earned. TRM's method has a limit it states itself: a single-purpose agent that pays one service repeatedly looks the same on-chain as a scheduled script, so the strict figure probably undercounts. But the direction is clear. Agent demand today is small.

These two readings don't conflict; together they tell you how to act. BlackRock is describing where the rails are going. TRM is describing how much money is on them now. If demand is small and growing, the rational seller move is the one that costs almost nothing to make: be payable by agents, at a price, without building anything. A seller who has to write an integration, run a wallet service and maintain protocol code to catch 0.6%–7.5% of a small market will reasonably wait. A seller who can switch it on from a dashboard in an afternoon has no reason to.

What BlackRock gets right — and what the paper doesn't cover

The paper is strong on the rail and quiet on the business. Three things a seller should add to it:

• Custody is a design choice, not a given. "Machine-native money" says nothing about whose account the money lands in. The same stablecoin can pay a seller's own wallet or a processor's pooled balance with a payout schedule. BlackRock's settlement argument — immediate, final, no counterparty exposure — only fully holds when the funds land somewhere you control. We compared the two models in stablecoin settlement vs acceptance.
• Protocols are multiplying, not consolidating. The paper lists x402, MPP, ACP, AP2 and TAP in two paragraphs. A seller shouldn't have to choose among them by writing code for each. We looked at the trade-offs in MPP vs x402 for API sellers.
• Pricing is the seller's hardest problem. An agent compares prices by reading a 402 response. The businesses that did well in the early x402 data published a clear, stable per-call price and served a useful response. No white paper can do that part for you.

For merchants selling to people, the paper also holds a quieter message. It says "modified traditional payment systems will remain important for connecting agents with human-operated businesses and consumers." Translation: agents will buy hotel rooms through checkout for a while yet. The stablecoin case for a store or a service business is still mainly the human one — lower cost, no chargebacks, funds in your own wallet — and doesn't depend on AI agents arriving.

How Payzum fits: x402 in front of your existing API, no code

BlackRock's example needs a data provider that an agent can pay per call without an account. That is exactly what Payzum's x402 is for, and Payzum's role is specific. Payzum is the middleware in front of your API, not the facilitator and not a new API you have to build:

• You configure, in the dashboard, your existing endpoint, the API key or bearer token it already uses, and a price per call.
• Payzum publishes an x402 URL for it. When an agent calls without paying, Payzum returns the 402 Payment Required with your price.
• The agent pays USDC on Base. Settlement goes through an external facilitator (today, Coinbase's) straight to your own wallet. Payzum doesn't hold the funds.
• Payzum then proxies the paid call to your real endpoint, with your key, and returns the response to the agent.

No SDK to add, no protocol to implement, no changes to your API. The friction list in BlackRock's paper maps onto it line by line: no account setup for the buyer, no percentage acceptance fee that makes a one-cent call uneconomic, and funds that are final and yours when the call is served. Your human customers keep the API keys and plans they already have. The x402 URL is an additional door, not a migration. For the wider comparison, see x402 vs API-key billing.

The rest of Payzum is built on the same non-custodial model. That covers the human side of your revenue (hosted checkout, payment links, invoices, subscriptions and a QR POS, with optional auto-conversion to USDC or USDT) and the money going out (CSV mass payouts and EVM stablecoin payouts). There's a REST API with signed webhooks, an audit log and an integration playground if you want to wire it into your own systems.

How an API seller would set this up, step by step

1. Pick the endpoint an agent would actually want. Look for BlackRock's example in your own product: a lookup, a quote, a rate, a search, a score, an enrichment. It should be something with a clear per-call value and a response that stands on its own.
2. Set the price per call. Start from what a human customer pays per request on your cheapest plan, then adjust. Sub-dollar is normal. Keep it stable, because agents compare.
3. Choose the receiving wallet. This is where USDC on Base will arrive. Treat it as an account of record, with 2FA on the dashboard and keys held according to your treasury policy.
4. Configure it in Payzum. Enter the endpoint, the API key or bearer token, and the price. Payzum gives you the x402 URL.
5. Publish the URL where agents look. That means your docs, your MCP server description, an agent-facing page. BlackRock's travel sub-agent found paid APIs because they were listed and priced.
6. Watch and adjust. Signed webhooks and the audit log show each paid call. If TRM is right that demand is small, the first month tells you your share of it. Setup took an afternoon, so that is a cheap thing to learn.

BlackRock's friction list vs selling to agents with x402 through Payzum

The honest counter-arguments

"This is an asset manager talking its book."

Partly, yes. BlackRock sells digital-asset products, and a paper arguing that AI drives digital-asset demand supports them. Read the numbers with that in mind. But the part that matters to a seller — that card rails are a poor fit for sub-cent, account-free, always-on payments — isn't controversial, and doesn't depend on any token's price. You can disagree with the investment thesis and still agree with the friction list.

"If agents are 0.6%–7.5% of x402 commerce, why bother now?"

Because the cost of being ready has collapsed, while the cost of being late in a price-comparison market is real. Agents choose among sellers by reading a 402 response. The ones that show up in an agent's options early build the history and the listings. If setup required a quarter of engineering work, waiting would be correct. When it's a dashboard form in front of the API you already run, the maths reverses. If demand stays small, you've lost an afternoon.

"Won't card networks solve agent payments themselves?"

They are trying, and for large purchases they probably will. BlackRock's own example routes the flight and the hotel through existing checkout. The high-frequency, low-value calls underneath — the data, the tools, the compute — are the segment the paper says card economics don't fit. Both can be true, and a seller can take part in both.