A Useful Token Must First Stand for Something of Real Value

When people talk about paying for AI Agents, the conversation tends to collapse into one question: how do we give an Agent a wallet so it can buy APIs, data, or other services on its own? The use case is real. Software that can act for a person or organization across services will eventually encounter payment. By Agent here, I mean that kind of delegated software. Delegation is the person's or organization's authorization for it to act, with a scope and a time limit.

But I think that treats the most visible step as the whole problem.

Agents bring the deeper problem into view because they act for people or organizations and call resources across services at machine speed. A call is not always just a price. It can involve a quota, a license, an access right, a revocable eligibility, or a service settled only after a billing period. To give these things to an Agent, limit its scope, record what it uses, and reconcile the result later, a system first has to express them as identifiable business units. Some systems call them credits, quotas, licenses, or entitlements; some use a token to identify or carry one of them. The point is not whether every object gets that name. It is that every object has to point to a real right, service, eligibility, or recorded event rather than an abstract name detached from the business. To keep the discussion precise, I use “business token” below in the narrower sense of an entitlement a service can honor, and discuss eligibility, authority, and receipts in their own roles.

If a token is meant to represent a service entitlement, it has to point to a clearly defined right that can be honored. A related credential can carry an issuer's claim about a subject. Whether a presenter may use the entitlement is still decided by the presentation and the resource service's own policy. A receipt can attest to what a service provider recorded or claimed to have delivered. Those are different roles, even when one signed object, credential, or ledger entry carries more than one of them. Whether the entitlement can be verified, used, or enforced depends on the service, policy, and records around it. Without a service behind it, it is only a record. Without clear rules for the right and its consumption, it is hard to say what it stands for.

That is why I do not think the infrastructure for AI Agents should be told as a story about wallets or payments alone. Payment is one way to settle. When an Agent works across organizations or service providers, or acts for somebody else, identity, delegation, resource units, usage records, and billing become much sharper problems. Commercial systems have handled versions of them for a long time. Airlines, hotels, card companies, and large cloud providers mostly built closed systems to do it themselves.

I wrote earlier that AI Agents need more than a wallet. That piece was about who authorizes an Agent, what it may do, and how we trace something when it goes wrong. Here I want to make a different question more concrete: when a system gives an Agent a credit, what exactly did it give?

When I think about tokens in ArcBlock, I keep returning to the same test: a useful token has to stand for something real with a defined business value, not an isolated concept. It might be a resource that can be consumed, or a conditional eligibility. Turn all of those objects into an undifferentiated string of abstract characters, and the system will eventually fail to reconcile its own accounts.

Model tokens, usage credits, authority, and receipts are not the same thing

The vocabulary has become a little messy. A model token is a unit of data that a foundation model processes.^[1] A product credit usually represents image generations, API calls, storage, compute, or inference a customer may use. An access token can represent authority to call a resource. A credential can carry claims from an issuer about a subject, which a resource service may evaluate before deciding whether to allow a request. These things relate to one another, but they are not the same kind of object.

To avoid mixing them back together, I separate four objects in this article:

When I say a business token below, I mean only the entitlement role: an entitlement or usage credit a service provider can honor. It does not perform a service by itself. The provider's rules and systems determine whether it is recognized, verified, consumed, and settled. A credential or another signed object can evidence an identity, authority, eligibility, entitlement, or receipt; a ledger entry can refer to any of them. The envelope is not the role. These roles matter just as much, but they are not the same balance waiting to be consumed.

That sounds old school, but it matters. Ten thousand retrieval calls, one hundred GPU minutes, and one GB-month of storage are different measurement units. The last one cannot simply mean "a one-GB file was uploaded." A system needs to define whether it measures file size, retention time, or average occupancy. Turning every action into an immediate monetary payment does not make the system clearer. One common pattern is to account for each unit by its own rules and settle after a billing cycle.

Many digital services manage credits this way. A customer receives credits. One type of image consumes one unit, another consumes more. The important question is not whether the unit has been renamed a token. It is whether the system can say who issued the credit, which service it applies to, when it expires, how it was consumed, and which record is relevant when a discrepancy needs to be investigated. Stripe Billing Credits are a plain example. A credit grant is allocated to a specific customer and can apply to eligible subscription items with metered prices whose usage is reported through Stripe Meters. Its states include pending, granted, depleted, expired, and voided. Stripe also prohibits connecting those credits to digital wallets or using them for third-party payments.^[2]

A useful usage credit often looks boring. It may simply mean the right to retain one GB of data for one billing month under a defined measurement rule.

Membership systems already keep rights, eligibility, and receipts separate

I have always thought airline, hotel, and card-membership programs are a good way to see what a token can represent in real commerce. They are already working commercial systems: they do not call every object a point, and they do not treat every record as payment.

Take a perfectly ordinary frequent-flyer program as an illustration. After a qualifying flight, a passenger's account may gain mileage. That is an accumulated usage credit, which may be redeemed for a trip or another service if the relevant conditions are met. The same program may also record elite status. Status is not simply "more miles." It is an eligibility state that a member could prove to a service with a credential. During its validity period, it might change the rules for boarding, baggage, or a waitlist, but it is not something you split up and spend like mileage.

If a status level produces an upgrade certificate, that certificate is a third object. It can have its own expiry date, eligible routes, fare classes, and availability conditions. A travel credit created after a cancelled ticket is not another name for mileage or an upgrade certificate either. It is a restricted right to make a future booking. The confirmation left after a booking or upgrade is then a receipt. It says that the provider processed something under the rules at that time. It is not another balance to spend.

Card programs have similar layers. Many record points according to their own rules, provide a credit that applies to a defined statement item, or issue a coupon that works only in a particular campaign. Their presence in the same app does not make their rules identical. Once a reader sees them as different kinds of business objects rather than a pile of interchangeable numbers, it is easier to see why Agent systems need to keep their units separate too.

Small businesses make the same logic even more obvious. Plenty of restaurants have a stamp card: visit six times and the seventh meal is free. Nobody tries to calculate whether a particular meal deserves half a stamp or two. The rule is one visit, one stamp, then one service once the card is full. It is simple, but it already has issuance, possession, consumption, and redemption. A coupon follows the same pattern. It changes what may be redeemed in one defined transaction.

Taken separately, mileage is an accumulated usage credit. Elite status is an eligibility state that a member may evidence with a credential. An upgrade certificate is a specific entitlement. The confirmation after a booking or upgrade is a receipt. They cannot be treated as the same type of token simply because they appear inside one membership system.

This also shows why the difference between fungible (interchangeable) and non-fungible (item-specific) objects has a practical use. If any call to a defined API is interchangeable with any other, ten calls can be combined into one balance. If a right is tied to one passenger, date, seat, or task, it has to be tracked item by item. Transferability is a separate rule. It does not follow automatically from whether an object is fungible. A receipt is a historical event record, not an entitlement waiting to be consumed. Much popular discussion of NFTs focused on profile pictures and digital art. I have always found the more ordinary part more interesting: a ticket, a certificate, or a right that needs to be independently checked.

The kinds of systems ARC is meant to support push this illustration one step further. An application may meter traffic, storage, compute, model use, and API calls by different rules. A common credit is useful only if it preserves the underlying meter, scope, conversion, expiry, and settlement rules. It should not obscure those differences.

Resources are not the only objects that matter. There are also eligibility and credential-like objects: software licenses, user memberships, authorization that controls access, a user's identity and control relationship with a network node or account, and credentials related to using an online service. The systems ARC is meant to support need to keep these relationships distinct. DID and Verifiable Credential mechanisms can express claims about subjects, eligibility, and authorization; other service relationships can use their own artifacts. In a documented DID-domain hosting flow, the domain to be hosted is checked; after subscription, a DID Names NFT is sent to the user's wallet so the domain can be used on the Blocklet platform. After the domain is added to a Blocklet, its HTTPS certificate is generated automatically. Licenses, memberships, access grants, domain-related NFTs, certificates, and usage records should be typed according to their actual rule sets, because their issuance, verification, revocation, duration, and reconciliation may all differ.

A system may also package a third-party capability as one of its own services. In that case, an internal entitlement still has to respect the underlying provider's availability, rate limits, expiry, and settlement conditions. It cannot pretend that one internal credit has erased those outside constraints. That is why a new compute service needs to explain its different rights and records as carefully as an airline program does. The complexity is not for decoration. It prevents different promises from being collapsed into one vague balance.

A database can keep books. Blockchain shows its advantage when reconciliation crosses parties.

An ordinary database is enough when one service provider meters API use for its own customers. If the parties trust the operator or accept its exported records and audit process, it can still support audit and reconciliation. An Agent organizing local files or calling its own tools should keep its records in the appropriate local system.

But the design changes when different parties need to inspect or challenge the same record independently. A shared database plus signed receipts can work when the parties have already agreed that one operator is the keeper of the record. The limit is not that a database cannot keep books. It is that every participant has to accept a large platform's private database and interface as the final source of record: that operator controls the record format, access, export, and any historical correction. Independent verification and portability become more expensive, and the operator becomes the gatekeeper. For a smaller provider, even participation can depend on that platform's interface and permission. This is where a public blockchain or another open distributed ledger has an advantage. Participants can independently retain and validate a common ordered history and use mutually referable rules to express identity, delegation, eligibility, entitlements, and receipts, without each having to build a trusted platform from scratch or hand the root record of its business to one platform.

The question becomes sharper when different parties need to inspect or challenge the same records independently. An Agent might act for one user, use data provided by another organization, call a third party's compute service, and deliver the result to a customer or auditor. Who acted, whom it represented, why it was allowed to use a resource, which use the provider says it processed, and which system deducted which unit are no longer only internal questions for one backend.

The sequence I find most useful is simple. Identity answers who is acting. Delegation answers why it may act and where the boundary is. An entitlement answers which service it may consume. A receipt and ledger entry record what a system asserts or observes happened. This is not a stack every system must reproduce in full. It is a way not to fold different questions into one token.

A DID can identify a subject, but it does not by itself establish a real-world identity or confer access. The W3C DID standard does not require its verifiable data registry to be a blockchain. A trusted database, a distributed ledger, and other storage systems can serve the role.^[3] A Verifiable Credential can carry a tamper-evident claim from an issuer about a subject. An organization could, for example, issue a claim concerning an Agent's permission to handle one class of work. A resource service still needs an authorization framework and its own policy.^[4] If the credential scheme provides status checks, the service needs to check that status too.^[5]

This is where a Blockchain may make sense: as a shared, tamper-evident record when the relevant parties have independent access and agree on its governance. NIST describes Blockchain as a tamper-evident and tamper-resistant distributed ledger, not a machine that guarantees every input is true. It can help participants check whether recorded transactions, signatures, and provenance were later changed. It cannot tell us whether a sensor was wrong, a service was actually completed, or an Agent lied.^[6]

That also sets the privacy boundary. Most original data, prompts, and business details do not need to be public. Often it is enough to keep them in the appropriate system and share a signed receipt or hash commitment with appropriate disclosure and access controls when necessary. A signature first shows that an issuer made an assertion. A hash lets someone who receives the original content check whether it matches an earlier commitment. Auditability is not putting everything on a public network. It is letting the right parties verify the right portion at the right time.

Agents make multi-party verification and reconciliation routine

Take an easy-to-measure illustration. Suppose an organization assigns Project P ten thousand calls to a document-retrieval API, valid through September 30. It then delegates that entitlement to Agent A, but only for Project P. The system needs to state who provides the service, which methods Agent A may call, how many units each call consumes, and what happens outside the boundary.

When Agent A calls the API within that authority, the service provider could emit a signed usage receipt. It can state which Agent the provider saw, when, how many calls were recorded, and which delegation and entitlement identifier it referenced. The receipt first shows that the provider made the assertion that its metering system recorded a request under those rules. It does not automatically prove that assertion, or a business outcome, was correct. If every layer keeps records that can point to one another and the relevant parties can access them, those records can help trace and reconcile a discrepancy. They do not resolve a dispute on their own.

In this example, payment can happen after billing. It may also be handled through a pre-existing credit, a contractual allowance, or another settlement method. A design need not require an Agent to pay instantly for every retrieval. Replace document retrieval with compute, model inference, data access, storage, or a service completed by a dedicated tool, and the structure is similar. The measurement rules are what change.

Agents are unusual not because they invent this kind of accounting, but because they can multiply it at machine speed across systems. Sophisticated credit, membership, and audit programs have historically been more common in large organizations. A small team may now use several models, data sources, and automated services at once. It needs the same clarity about who may use what, how much was used, and who is responsible for the result.

If those units live only in private tables at each company, the system can still run. Once a business connects multiple providers, Agents, or customers, it may repeatedly face integration and reconciliation work. DID, Verifiable Credentials, scoped delegation, append-only ledgers, and verifiable receipts are not substitutes for every database. They can let different providers express "who was delegated, what entitlement existed, and which use was recorded" in formats that can refer to one another. That still requires compatible fields, semantics, trust policies, and dispute processes. It does not happen automatically.

There is no magic in this. Identity is not authorization. A signature is not truth. A ledger is not service quality. A token is not proof that a service exists. A real system still has to deal with revocation, expiry, privacy, exceptions, disputes, and responsibility. None of that disappears because Blockchain is involved.

This is the kind of environment ARC is being built to provide. A Blocklet can recognize a DID-aware caller, read and write in that DID's data space, and access resources through providers. For an Agent, payment is only one relationship. Identity, delegation, credentials, service entitlements, and records all need clear roles of their own. ArcBlock's current direction is to make important authorization and usage records more verifiable at the appropriate trust boundary. A token matters only when it represents a real service, right, or eligibility; cross-service credits, credentials, settlement, and reconciliation still have to be defined with the actual business, providers, and governance rules.

References

Appendix: What the Sources Do and Do Not Establish

This article puts four kinds of material together without treating them as the same kind of evidence:

Evidence map

These sources are not endorsements of one conclusion. They place boundaries around key terms. This article does not assess any token's legal status, compliance, or market value. It asks a narrower question: when can a digital business object accurately represent an existing service entitlement, credential, record, or responsibility chain?