AI Agents Need More Than a Wallet

I recently read Christian Crowley et al.'s “The missing infrastructure for AI agents: 5 ways blockchains can help”^[1] on a16z crypto. It considers AI Agent identity, governance, payments, trust, and user control together. I especially agree that the question cannot be reduced to a single one: how to let an Agent pay.

Two sentences in the article are particularly direct, and they are why I want to respond to it:

“The bottleneck for the agent economy is now identity, not intelligence.”

“Scale without verification is a liability that builds over time.”

I broadly agree with both judgments. Once Agents stop being assistants inside a chat window and begin to call services, spend money, and deliver results on behalf of people and organizations, the old internet does lack some essential infrastructure. But I would move the emphasis one step earlier. AI Agents need more than a wallet.

ArcBlock has worked on decentralized identity, Blockchain, and application infrastructure for a long time.

Payment is the easiest scenario to see. An Agent calls an API, buys a piece of data, completes a service, and pays automatically. That obviously matters. But before it pays, a system should be able to answer more basic questions: who is it, whom does it represent, who granted it authority, how far does that authority extend, and who can reconcile what happened when something goes wrong? Without answers to those questions, a wallet is only a key handed to a program.

I agree with the five questions, but they form a chain of responsibility

Crowley et al. discuss identity, governance, machine payments, verifiable trust, and user control separately. That is useful. But in a real Agent system, I think they are often not five independent product categories. They are a continuous chain of responsibility.

An Agent needs an identity before others can know who it is. Only then can we discuss who may authorize it. Once the authorization has a scope, we can know how much it may spend, which services it may call, and whether it may issue a particular result on behalf of a team. After it acts, records can be verified, reconciled, and traced. Only then can users tell whether they are using an Agent or handing themselves over to an opaque platform.

ArcBlock's starting point has a natural continuity with this. We have long used DID, or Decentralized Identifier, which can be understood as an identity marker that does not depend on a temporary account from one platform, can persist, and can be independently verified. The point is not to put another cryptographic label on every object. It is to let people, devices, and future Agents all have this kind of identity. DID Connect is a foundation for identity, sign-in, and signing interactions. DID Spaces are users' data spaces. Neither concept was assembled just for today's Agents. Both address a more basic problem: identity, authorization, and data should not inherently belong to a single platform or a single application installation.

This is why I do not like the question, “Can Blockchain let Agents pay?” It treats the easiest step to demonstrate as the hardest one. The hard part is delegation.

A small hot wallet can limit loss, but it cannot explain authorization

Machine payment protocols such as x402 solve something practical: they let a service request and a payment happen in the same machine workflow. Small balances, virtual cards, and constrained wallets all have value as well. A hot wallet here means a wallet or account connected to an online program. At least, these approaches can reduce the worst-case loss.

But they do not automatically answer: why may this Agent spend this money? Who assigned it? Which services may it spend it on? Where are the budget, time, frequency, and revocation conditions? If a team discovers abnormal consumption, can it trace the evidence to the authorization, Agent, and call that went wrong?

This problem did not begin with Agents. We encountered the same tension in decentralized applications long ago. We cannot ask a user to take out a wallet and sign again for every automated transaction. Nor can we keep a user's main private key in an online service for the program to decide everything by itself. The first approach cannot be automated. The second makes it difficult to speak of a meaningful security boundary.

So the question we have long considered is not how to let a program hold money for a user. It is how to express identity, delegation scope, limits, rules, and the chain of responsibility separately. DID can provide identity and verification relationships. A delegation or capability model, which specifies what a credential can and cannot do, defines scope and constraints. Verifiable Credentials, or VCs, can serve as signed evidence that can be independently verified. In this way, even if an Agent needs to use its own constrained credential, a user does not need to place their main private key in the custody of a continuously online service.

I do not think this makes risk disappear by magic. It changes the question from “a program has a key” to “who issued which constrained key under what conditions.” The latter can at least be discussed, inspected, and revoked.

The value of a ledger often becomes visible after payment

PaymentKit is ArcBlock's existing payment abstraction layer. Payment itself is not a new problem. Agents make it more important because a payment brings a larger set of questions with it.

Imagine a team using several AI services at once. Different Agents are calling external tools. Employees are using API keys. The bills arrive from yet another system. One day, an amount does not look right. What you usually see are several disconnected records: vendor invoices, credit card charges, and internal logs. Was there a billing problem on the service side? Was a key misused? Did an employee exceed their authority? Or did an internal system fail to pass authorization correctly? It is often hard to tell.

I do not think the answer is to write every log to a public chain. That is neither necessary nor reasonable. Our view is this: records should be layered according to the trust boundary.

Receipts, invoices, service delivery, third-party service calls, and information about who authorized, used, and consumed a service can be expressed through verifiable data formats such as VCs, then stored at the ledger layer appropriate to the situation. ARC here means Agentic Realm Computer, the runtime and computing architecture ArcBlock is building for people and Agents. This is the direction we hope ARC will gradually carry forward. It does not mean that complete blockchain-side integration, on-chain settlement, and multilayer flows have all been delivered today.

Such records will not automatically prove that a service was correct, nor will they assume responsibility in place of people. Their role is simpler: as a world of Agents becomes too complex for people to watch every action one by one, important actions should at least leave evidence that the appropriate parties can verify.

A chain should be an evidence boundary, not the destination of every action

The a16z article points out that as automated execution becomes cheap, verification becomes expensive. I agree. A human in the loop, with a person reviewing each action, cannot examine every call made by thousands of Agents.

But the value of Blockchain should not be described as “producing trust.” Blockchain can provide durable evidence, shared ledgers, and enforceable constraints. Correctness, service quality, dispute handling, and ultimate responsibility still depend on system design and people. Confusing the two makes the discussion sound easier than it is.

So not every Agent needs to go on-chain. If an Agent is only organizing a local draft, the simplest tool is usually best. But when it acts across systems on behalf of a user or organization, and when money, authority, verifiable delivery, or reconciliation among multiple parties is involved, identity, delegation, and records should not exist only in one platform's backend.

This is what I take from the article, but I would add one point: payment is only the entry point. The more fundamental infrastructure for Agents is a verifiable chain of delegation. It should let us answer clearly: who is acting, who authorized it, what it is allowed to do, and how we can reconcile what happened when something goes wrong.

Reference