On September 22, BlackRock’s Digital Assets Research team published a paper called “The Machine-Native Economy: How Digital Assets Connect Intelligence, Commerce, and Compute.”
We read it for a fairly simple reason.
At PayAgents, we’re building payment infrastructure for AI agents. So when one of the world’s largest asset managers starts talking about a future where software agents can participate in the economy on their own, we pay attention.
The interesting part isn’t simply that BlackRock is talking about AI and digital assets.
It’s why the two technologies might fit together.
AI agents are going to need money
Today, most AI agents can do things for you.
They can search the web, call APIs, use tools, write code, analyze data and coordinate multi-step tasks.
But there is still a missing piece:
They generally can’t pay for those things on their own.
Imagine an agent working on a task and needing three different services:
- $0.002 for a data API
- $0.01 for an inference request
- $0.0005 for another tool
For a human, these amounts are trivial.
But the payment experience around them isn’t.
You don’t want an agent creating a new account, entering card details, going through KYC, waiting for approval and then making a payment every time it needs an API.
That doesn’t scale to machine-to-machine commerce.
This is the problem behind the idea of a machine-native economy.
Three pieces of the machine-native economy
One useful way to think about BlackRock’s thesis is around three components:
- AI becomes machine-native intelligence. Agents can reason, plan, delegate tasks and coordinate workflows without a person directing every individual action.
- Digital assets become machine-native money. Programmable digital assets can move value between software systems without requiring the traditional human payment experience.
- Blockchains become machine-native infrastructure. They provide programmable settlement that can operate continuously rather than around banking hours and traditional payment workflows.
Put those three together and something interesting happens.
An agent can potentially decide what it needs, find the service, pay for it and continue its task.
That’s a very different model from today’s internet.
The payment problem is easy to underestimate
Most internet payments were designed around humans.
You have an account.
You have a card.
You log in.
You click “Buy.”
You approve the transaction.
That makes sense when the customer is a person buying something occasionally.
But imagine an agent making hundreds of small purchases during a single workflow.
A few cents here.
A fraction of a cent there.
A payment for a piece of data.
Another payment for compute.
Another payment for an API call.
The economics start to look very different.
A fixed payment fee that is insignificant for a $50 purchase can become the entire cost of a $0.002 API call.
And the friction of human authentication becomes even more problematic.
This is where protocols such as HTTP 402 and x402 become interesting.
What HTTP 402 changes
HTTP 402 has existed for decades as a reserved status code for “Payment Required.”
The idea behind x402 is much more practical:
This request costs X.
Here is how to pay.
Pay it and try again.
The agent doesn’t need to create an account just to make one request.
It can inspect the payment requirement, check its own spending rules, make the payment and retry the request.
That turns payment into part of the API interaction itself.
And that is a much more natural model for software-to-software commerce.
Why multiple payment rails matter
There probably won’t be a single payment rail for every machine transaction.
Different payments have different requirements.
A dollar-denominated API might naturally use USDC on a network such as Base.
A tiny, high-frequency payment might make more sense over Bitcoin Lightning.
The important part is not forcing the agent to understand all of this every time.
The payment layer should be able to handle the complexity underneath.
That’s one of the ideas we’re working on at PayAgents.
Our goal is to let an agent interact with a paid endpoint without having to manually reason about the underlying payment rail.
The agent asks for the resource.
The endpoint returns the payment requirement.
PayAgents handles the payment flow and can work across x402 and L402.
The application gets the result.
And it isn’t just about APIs
This is where the BlackRock paper gets particularly interesting.
The idea extends beyond paying for API calls.
Agents could eventually need to purchase:
- compute
- data
- model inference
- specialized tools
- storage
- access to private datasets
- other agents’ services
Think about what happens when compute itself becomes something software can discover and purchase dynamically.
Instead of an application signing a large, fixed contract for infrastructure, an agent could potentially acquire the resources it needs for a particular task and pay based on actual usage.
The same basic mechanism applies:
Discover → price → pay → use.
That is much closer to how software already operates than the way traditional commerce works today.
But autonomous spending needs guardrails
There is an obvious problem.
You probably don’t want an AI agent with unlimited access to a company wallet.
A badly designed agent could make an expensive API call.
A loop could keep spending.
A compromised workflow could redirect payments.
So giving agents money isn’t enough.
They need rules around the money.
For example:
- maximum amount per transaction
- daily spending limits
- approved domains
- approved vendors
- separate budgets for different agents
- human approval above a certain threshold
This is an important part of agentic payments that can sometimes get lost in the excitement around autonomous commerce.
The question isn’t simply:
“Can an agent pay?”
It’s:
“Can an agent pay within rules that a human or company controls?”
That’s the direction we’re interested in at PayAgents.
We’re still early
It’s worth keeping some perspective here.
The machine-native economy doesn’t exist at scale today.
The infrastructure is being assembled.
The standards are evolving.
Developers are experimenting with agent-to-service payments, stablecoins, Lightning and HTTP 402.
But the basic direction is becoming easier to see.
AI agents are getting better at acting independently.
As they do more things independently, they will eventually need to buy things independently.
And once software can buy resources on its own, payments stop being a separate part of the user experience.
Payments become part of the agent’s execution loop.
That’s the idea behind PayAgents.
We’re building the payment layer that lets an agent pay for the next thing it needs — across rails such as Lightning and Base — while keeping spending programmable and controlled.
The machine-native economy may still be early.
But the payment problem is already here.
And we’re building for it.