Decentralization Is Not a Token

2026-09-01 · 7,825 words · Singular Grit Substack · View on Substack

The missing market is a portable claim on computation—one unit that an AI agent can spend across corporations, cloud providers, and spare GPUs

Keywords: decentralization; agentic AI; portable compute credits; GPU markets; confidential computing; verifiable computation; interoperability; AI subscriptions; metering; digital bearer instruments; Lightning Network; distributed computing

Abstract

Decentralization has been reduced to a branding exercise. Add a token to a service, route a payment through a distributed network, and a centrally controlled platform is suddenly described as decentralized. Yet a payment rail does not determine who controls the account, who may supply the service, where a purchased credit can be redeemed, how execution is verified, or whether a user can leave without forfeiting value. Those are the economically important questions.

This article argues that the missing institution in the emerging AI economy is not another speculative coin. It is a portable, divisible, transferable claim on computation: a single settlement unit that can move between corporations, cloud providers, specialist data centers, and qualified household GPUs. An individual should be able to buy compute once and spend it with OpenAI, Anthropic, another model provider, or an independent GPU supplier. A provider should be able to earn the same unit and use it elsewhere or redeem it. An autonomous agent should be able to request quotes, escrow a budget, verify an execution environment, receive a signed usage receipt, and settle without first opening a new subscription account at every vendor.

The token itself is the least difficult part. The hard work lies in standardizing job manifests, pricing heterogeneous hardware, proving execution, protecting private workloads, clearing inter-company obligations, constraining issuance, and preserving regulatory compliance. Existing systems already supply parts of this machinery: distributed GPU markets, remote attestation, confidential virtual machines, portable credentials, standardized telemetry, signed HTTP messages, and privacy-preserving authorization. What is absent is an integrated economic right that crosses corporate boundaries.

Real decentralization is not a picture of nodes around a coin. It is the ability to hold value, choose among competing suppliers, verify performance, transfer unused rights, redeem claims, and exit without asking the incumbent for permission.

The word that ate its own meaning

Decentralization has become one of those words that improves every business plan precisely because nobody is required to define it. A database is called a protocol. A customer account is called a wallet. A non-transferable coupon is called a token. A platform that can suspend the user, alter the price, expire the balance, reject the supplier, change the interface, and terminate redemption is described as decentralized because somewhere beneath the user interface a payment touched a blockchain.

That is not decentralization. It is central administration with a fashionable settlement rail.

The mistake begins by treating decentralization as a binary property. A system is said to be decentralized or not, as though the answer could be read from the logo. In reality, a service contains several distinct layers: settlement, custody, redemption, supply, execution, metering, identity, governance, and exit. One layer can be distributed while all the others remain controlled by a single firm. A token may circulate widely while the right attached to it is narrow. A protocol may have many nodes while the customer still holds nothing except a revocable entry in one company’s account database.

This distinction matters more as AI shifts from a tool that people occasionally consult to an infrastructure that software agents continuously procure. A human may tolerate opening five accounts, accepting five sets of terms, maintaining five prepaid balances, and discovering five incompatible definitions of usage. A machine should not have to. An agent that can select a model, negotiate a latency target, choose an assurance level, and route a workload should also be able to carry one budget across suppliers. Otherwise, the agent is not economically autonomous. It is merely an automated customer trapped inside a collection of corporate billing systems.

The present market is therefore decentralized in almost none of the ways that matter to the buyer of computation. Model providers sell subscriptions or prepaid usage. Cloud providers sell their own credits. Distributed-compute networks issue or accept their own tokens. Each balance is defined by its issuer, measured by its issuer, redeemed by its issuer, and usually extinguished by its issuer. The supposed owner is permitted to consume but not to transfer. That is a licence to request a service, not a portable economic asset.

A genuinely decentralized compute market requires something stronger: a transferable claim accepted by multiple unrelated providers, coupled to open procurement, verifiable metering, and credible redemption. The objective is not to put every floating-point operation on a public chain. It is to make the right to buy computation portable.

Lightning is a rail, not a compute market

Consider the familiar claim that Bitcoin or the Lightning Network has already solved this problem. It has not. Even where a payment network is decentralized in a meaningful technical sense, it does not follow that the service purchased with it is decentralized. Settlement and service architecture are different objects.

Lightning routes payments through channels connecting participating nodes. The official Lightning Labs documentation on sending payments explains that a payment may cross a route of several channels, with pathfinding, per-hop fees, timeouts, and liquidity constraints. Its guide to managing channel liquidity also explains that operating a node requires active management of inbound and outbound liquidity. Those are features of a payment-channel network, not of a universal market for computation. Lightning can move a unit of value. It does not define a model, a GPU, a service-level agreement, a privacy guarantee, a benchmark, an execution receipt, or a right of redemption against an AI company.

Cash App makes the distinction even clearer. Its documentation on sending and receiving BTC over Lightning shows that eligible users can use the rail, but the user still interacts through a Cash App account, a Cash balance or Bitcoin balance, account-specific limits, conversion rules, and policies administered by the company. The help material describes Lightning as one route available within the service and specifies rolling limits and other platform conditions. The Cash App Terms of Service are an agreement with Block, Inc., the company formerly known as Square. The underlying rail may involve multiple nodes; the customer’s operational relationship remains with one corporation.

Calling Lightning itself “a centralized database” is technically too crude. Calling the Cash App experience decentralized is economically false. From the customer’s perspective, the relevant balance, permissions, conversion, limits, interface, and continued access are centrally administered. The user has not acquired a portable claim on any service merely because the payment departed over Lightning.

This is the first rule of serious decentralization analysis:

A decentralized payment beneath a centralized account does not decentralize the account.

Nor does a payment token decentralize the object being purchased. BTC can be sent to a model provider, a cloud provider, or a person with a graphics card only where each party independently agrees to accept it. Even then, the buyer still needs a separate contract describing what the payment buys. A transaction can settle perfectly while the computation is never performed, is performed on the wrong model, leaks the data, misses the deadline, or is metered dishonestly. Money movement is one component of exchange. It is not the exchange in its entirety.

The confusion persists because payments are visible and services are complicated. It is easy to draw a network graph of nodes. It is harder to specify who may enter the supply market, what constitutes one unit of delivered work, how a private workload is protected, how an output is challenged, and which party bears the loss when a machine fails halfway through a job. Yet those difficult questions are exactly where decentralization either becomes real or collapses into theatre.

Figure 1. A token-enabled account platform may use a distributed settlement rail while custody, redemption, supply, execution, metering, identity, and governance remain centralized. A portable compute market decentralizes rights and contestability across the full stack.

Today’s AI credits are designed not to travel

The current credit structures of major AI providers reveal the problem in unusually direct language.

OpenAI’s Service Credit Terms state that service credits are tied to the applicable service, are non-transferable, cannot be sold or traded, generally expire after a stated period, and are not treated as a bank account, wallet, stored-value account, or property right. Anthropic’s Supplemental Credit Terms similarly provide that credits have no cash value, expire under the stated conditions, and may not be transferred or sold to another person or entity. Anthropic’s own billing guidance describes the purchase and consumption of prepaid usage credits within its Console environment.

These terms are not accidental technical limitations. A database row can be moved. The prohibition is contractual and institutional. The issuer has chosen to define the balance as permission to consume its own service rather than as value the customer can carry elsewhere.

That arrangement is convenient for the issuer. Prepayment improves cash flow. Expiration creates breakage: some purchased capacity is never consumed. Non-transferability prevents secondary markets and arbitrage. Account-level control assists fraud management, sanctions screening, usage-policy enforcement, and price discrimination. Closed balances also keep customers inside the vendor’s own product bundle. These motives are economic inferences, not admissions by the companies, but the transfer restrictions themselves are explicit.

For the user, the consequence is fragmentation. A business can have an unused OpenAI balance, an unused Anthropic balance, committed cloud credits, and spare local GPU capacity while simultaneously purchasing additional computation elsewhere. None of those positions naturally offsets another. The firm is rich in stranded entitlements and poor in portable purchasing power.

The absurdity becomes more obvious with agentic systems. Suppose an agent has a monthly compute budget. It determines that one provider is best for code generation, another for a long-context legal review, a third for image generation, and a local GPU for a non-sensitive batch task. Under the present model, the agent must be provisioned separately at every service. Each vendor maintains its own account, identity, billing relationship, rate limits, usage semantics, and refund rules. The agent’s “choice” is bounded by balances that its human owner prepaid in advance.

Now suppose the agent finishes the month with unused purchased capacity at one provider but needs additional capacity at another. The economically obvious action is to transfer or sell the unused claim. The legally permitted action is generally to do nothing and allow the issuer to retain control over the balance until it is consumed or expires.

This is not a technological inevitability. It is a market design.

There is also a necessary distinction between purchased credits and subscription allowances. A prepaid API credit represents money paid in advance for future usage. A consumer subscription often represents access during a period, subject to dynamic limits and fair-use controls. One cannot simply declare every unused subscription minute to be transferable property. The provider may never have promised a fixed quantity. Nevertheless, a provider could redesign the product. It could issue a defined monthly allocation of portable units, permit the user to return unused units to a clearing pool, or convert unused contractual capacity into a transferable balance at a published rate.

What cannot be done honestly is to “wrap” existing OpenAI or Anthropic credits without consent and pretend that the wrapper created a redemption right. A token representing a claim against a company is valuable only if the company has undertaken to honour it. Portability therefore requires participating issuers, contractual clearing, or a new intermediary that buys capacity and assumes the redemption obligation. Code cannot manufacture privity.

The missing object: a portable compute credit

The required instrument can be called a Portable Compute Credit, or PCC. The name is less important than the rights.

A PCC would be a divisible and transferable settlement unit accepted by multiple compute providers. A person, company, or software agent could hold it independently of any one vendor account. A participating provider could quote a job in PCCs, receive PCCs after verified completion, spend them with another provider, sell them, or redeem them through an issuer or clearing mechanism. The same unit would move across corporate boundaries.

A PCC is not valuable merely because it is represented by a token. It is valuable because there is a credible answer to five questions:-

What backs issuance? A PCC must be issued against prepaid money, reserved compute capacity, high-quality collateral, or another transparent backing rule. Unconstrained issuance turns a useful clearing instrument into an unsecured promise.

Who accepts it? Multiple independent providers must undertake to quote and deliver services in PCCs. Acceptance cannot depend on one issuer’s continued grace.

How is work specified? Each purchase needs a signed, machine-readable service manifest describing the requested computation and assurance conditions.

How is delivery proved? The system needs standardized meters, signed execution receipts, and a dispute process appropriate to the job.

How is value redeemed? Holders need a route to spend, convert, net, or redeem the unit without returning to the original seller.

The PCC should therefore be understood as a clearing instrument, not a magical unit of physical computation. That distinction solves a problem that many token proposals ignore: compute is radically heterogeneous.

One second on an old consumer GPU is not equivalent to one second on an H100. One generated token from a small model is not equivalent to one generated token from a frontier model. Training, inference, rendering, simulation, storage, bandwidth, memory, latency, geographic residency, reliability, and confidentiality are different services. Even two nominally identical GPUs can deliver different throughput because of memory, drivers, thermal limits, batching, interconnects, and surrounding CPU and storage performance.

For that reason, one PCC should not pretend to equal one GPU-second or one floating-point operation. The uniform object should be the settlement unit. The heterogeneous object should be the service quote.

This is how ordinary money already works. A dollar does not represent one sandwich, one kilowatt-hour, or one minute of legal advice. It is a common unit in which different suppliers quote unlike goods. A portable compute market should adopt the same separation. The token settles value; the manifest defines the service.

A provider might quote:-

14 PCCs for one million input tokens and 100,000 output tokens on a specified model, with a stated latency range;

8 PCCs for a deterministic rendering job on a benchmarked GPU class;

40 PCCs for a private inference job in an attested confidential environment;

3 PCCs for a low-priority batch task on a household GPU with no confidentiality guarantee;

120 PCCs for a replicated scientific computation whose result is checked across three independent providers.

Those prices would move with demand, hardware efficiency, energy cost, model licensing, congestion, and risk. The PCC provides comparability and settlement. It does not erase the differences between services.

A more ambitious design could index the PCC to a basket of benchmarked compute services. That might reduce volatility relative to compute costs, but it would introduce an index committee, benchmark revisions, hardware-generation changes, and disputes over the basket. A simpler first version would be fully reserved and denominated against a stable monetary value, with providers posting compute prices in PCCs. Portability matters more than pretending that computation has one natural physical denomination.

A protocol an autonomous agent could actually use

The market must be machine-readable from beginning to end. An agent cannot negotiate by opening a support ticket and waiting for a sales representative. It needs a protocol.

The following sequence is sufficient to show what the architecture requires.

1. Create a signed job manifest

The agent first describes the job. The manifest identifies the workload or permitted workload class; the model, container, or executable hash; input and output constraints; maximum budget; deadline; latency target; geographic restrictions; data-retention rule; network-egress policy; required hardware; verification method; and assurance tier.

The manifest should disclose only what suppliers need to quote. A private job may reveal the resource profile without revealing the plaintext input. The buyer could state that the task requires 24 GB of GPU memory, a named runtime, ten minutes of expected execution, no outbound network access, and an attested environment. The data itself need not be broadcast to the market.

2. Obtain competing signed quotes

Eligible providers respond with price, capacity, start time, expected completion, hardware class, software image, assurance evidence, and cancellation terms. The quote is signed so that the provider cannot later deny the offer or silently replace its conditions.

The agent can compare offers across an AI company, a cloud provider, a specialist data center, and a qualified household machine. The comparison need not select the cheapest. It can optimize a weighted objective: price, latency, confidence, privacy, energy source, jurisdiction, reputation, or diversity of supply.

3. Lock PCCs in escrow

Once a quote is selected, the required PCCs are placed in escrow. The provider now knows that payment is available. The buyer knows that funds will not be released merely because the provider claims success. Cancellation and partial-completion rules are bound to the quoted job.

Escrow need not mean a fashionable smart contract performing every detail on a public blockchain. It can be a public script, a federated clearing service, a regulated custodian, or a threshold-controlled account. The decentralization question is whether either side can unilaterally rewrite the result, whether the rules are inspectable, and whether users can choose among escrow services.

4. Attest the execution environment

For jobs requiring confidentiality or strong environmental assurance, the provider produces remote-attestation evidence. The evidence identifies measured hardware, firmware, boot state, virtual-machine or container image, and relevant security configuration. A verifier appraises that evidence against the policy in the job manifest.

The IETF RATS architecture supplies a general vocabulary for this process: an attester produces evidence, a verifier appraises it, and a relying party uses the result. NVIDIA’s attestation documentation, AMD SEV, and Intel TDX provide concrete technologies for hardware-backed isolation and evidence in supported environments. NIST’s current confidential-computing work frames the objective as protecting data while it is in use, rather than only at rest or in transit.

5. Release the encrypted workload

If the attestation satisfies policy, the buyer releases a decryption key to the accepted environment. The provider can receive encrypted data before attestation but cannot use it until the environment has been accepted. The runtime enforces network and storage restrictions where the assurance level supports them.

“Unknown computation” must be described precisely. The host operator may be prevented from learning the plaintext input or output, but the executing code necessarily processes them. Privacy means limiting which parties and components can observe the workload, not making computation unknowable to the machine performing it.

6. Produce a signed meter and result receipt

During and after execution, the provider produces standardized usage records. These can include start and stop times, hardware identifiers, model or image hashes, token counts, memory allocation, energy where measured, retries, network use, output hash, and the attestation result. OpenTelemetry’s metrics specification offers a mature structure for collecting and exporting measurements; MLPerf Inference demonstrates why performance claims must be tied to named tasks, accuracy conditions, latency constraints, and system classes rather than a generic number.

The receipt itself should be signed. RFC 9421 defines HTTP Message Signatures for authenticating selected message components. W3C Verifiable Credentials provide another possible envelope for tamper-evident claims issued by one party and checked by another. Neither standard proves that the computation was correct by itself. They make the provider accountable for a specific assertion.

7. Verify, challenge, or accept

Verification depends on the workload.

A deterministic task can be replayed on a sample, checked against an output hash, or replicated across providers. A rendering job can be inspected for missing or corrupted frames. A model inference can bind the receipt to a model hash, prompt hash, sampling parameters, random seed where available, and output hash. A long training job may use checkpoints, signed logs, spot challenges, and independent performance evaluation.

The system must distinguish three claims that are frequently confused:-

Environment authenticity: the declared hardware and software state was running;

meter accuracy: the recorded resources and duration correspond to execution;

semantic correctness: the output is actually right or useful.

Remote attestation helps with the first. Signed telemetry helps with the second. Neither automatically supplies the third. An attested program can faithfully execute the wrong algorithm. A model can generate nonsense inside a perfectly secure enclave. The dispute mechanism must therefore match the service rather than invoke “verification” as a single magical property.

8. Release payment and clear positions

After acceptance—or after the dispute rule resolves—the escrow releases PCCs to the provider. Providers and issuers then net their positions. A company that accepted more PCCs than it issued can spend them, sell them, or redeem them. A company whose customers spent PCCs elsewhere may owe value into the clearing system. Credits used for redemption can be retired or recycled under a transparent supply rule.

9. Preserve portability after the transaction

The provider’s proceeds must remain portable. If a household GPU earns PCCs but can only redeem them through the same marketplace that assigned the job, the system has recreated platform scrip. The provider should be able to spend the balance on another model, cloud storage, another compute job, or an approved redemption route.

Figure 2. The PCC settles value while the signed manifest, quote, attestation, meter, receipt, and dispute process define and verify the service. Supply can come from corporations, data centers, or qualified household machines.

Turning spare household GPUs into supply

The household-GPU example is important because it reveals whether the word “decentralized” describes actual market entry or merely the distribution of machines owned by approved intermediaries.

Millions of people own NVIDIA graphics cards that sit idle for substantial periods. Some are unsuitable for serious remote work: they may lack memory, bandwidth, cooling, reliability, or a stable connection. Others are perfectly capable of rendering, inference, transcoding, simulation, compilation, or other bounded tasks. The economic problem is not the absence of silicon. It is the absence of a trusted way to describe, price, secure, meter, and pay for its output.

A provider client could convert a qualifying machine into a market participant through the following process.

First, it would benchmark the machine using a reproducible test suite. The result would describe the GPU model, memory, driver, runtime, CPU, storage, bandwidth, thermal stability, and measured performance on relevant workloads. The market should not rely on the model name alone. A throttled card in a poorly ventilated case is not equivalent to the same card operating reliably under sustained load.

Second, the provider would publish availability and policy. The owner might offer the machine only overnight, cap power consumption, refuse workloads above a given storage size, prohibit particular legal or safety categories, and accept only jobs that can run inside an approved container. These are legitimate supplier choices. Decentralization does not require every participant to accept every job. It requires that entry and selection are governed by open rules rather than private favour.

Third, the provider would be assigned an assurance tier. A basic tier might permit public or non-sensitive workloads in a sandboxed container. A stronger tier might require reproducible execution, restricted network access, encrypted temporary storage, signed telemetry, and random challenges. The highest tiers would require supported confidential-computing hardware, remote attestation, stronger operational controls, and perhaps an audited operator.

Fourth, the machine would receive only jobs compatible with its tier. A public Blender frame can be sent to ordinary hardware with comparatively little risk. A confidential medical model or proprietary source-code analysis should not be sent to a consumer machine merely because someone has installed Docker and promised not to look. The market must price assurance honestly.

Fifth, payment would follow measured delivery. The provider earns PCCs after the agreed receipt and verification conditions are satisfied. Reputation can influence future selection, but reputation should not become an unchallengeable platform score. The underlying evidence—completed jobs, failure rates, challenged receipts, benchmark history, and policy compliance—should be portable enough to support exit from one marketplace and entry into another.

This is not speculative fantasy. Existing networks demonstrate pieces of it. Golem’s provider documentation describes a peer-to-peer market in which requestors obtain resources from providers and notes that almost any internet-connected computer can participate, with compensation in the network’s native token. Render Network onboards CUDA-capable NVIDIA GPUs, publishes hardware guidance, and has extended its compute initiative to containerized and AI-oriented workloads. Its GPU-compute waitlist material describes benchmarking and hardware requirements that include recent consumer GPUs. Akash connects provider-operated Kubernetes clusters to a market in which providers bid for deployment orders and manage CPU, GPU, memory, storage, and tenant workloads.

These systems prove that distributed supply is possible. They do not yet produce the cross-corporate portability proposed here. A GLM, RENDER, or network-specific settlement arrangement does not automatically become a claim redeemable by OpenAI, Anthropic, a cloud company, and an unrelated home provider. The missing layer is not the ability to distribute work. It is the shared economic right and clearing obligation across markets.

Confidential does not mean magical

A market for household compute will fail if it promises privacy that the hardware cannot provide.

Encryption in transit protects a job while it travels to the provider. Encryption at rest protects stored files when they are not being used. Neither protects plaintext while an ordinary processor or GPU is actively reading it. Confidential computing attempts to close that gap by isolating code and data during execution and allowing a remote party to verify the environment before releasing secrets.

The available technology is real, but its coverage is uneven. AMD SEV-SNP and Intel TDX can provide protected virtual-machine environments on supported server processors. NVIDIA provides attestation and confidential-computing support for particular data-center and professional GPU configurations. Its current supported-platform list names hardware such as H100, H200, B200, HGX B300, and RTX Pro 6000 BSE configurations. Ordinary gaming cards are not on that official confidential-container list.

That fact should shape the market rather than be hidden by marketing. A home RTX card can sell useful computation, but it generally should not advertise the same hardware-backed confidentiality as a supported confidential GPU platform. The solution is tiering, not pretence.

A practical assurance ladder could look like this:-

Tier 0 — public execution: the input is non-sensitive, and the buyer assumes that the operator could inspect it;

Tier 1 — controlled sandbox: signed container, restricted privileges, encrypted transport, temporary storage controls, and signed telemetry;

Tier 2 — challengeable execution: Tier 1 plus replication, randomized spot checks, deterministic replay where possible, and financial penalties for discrepancies;

Tier 3 — attested confidential execution: supported CPU and GPU isolation, remote attestation, policy-bound key release, and measured software state;

Tier 4 — regulated or audited execution: Tier 3 plus organizational controls, jurisdictional commitments, external audit, retention guarantees, and sector-specific compliance.

The same job might be divided across tiers. Sensitive preprocessing could occur in an attested environment, while anonymized or encrypted shards are dispatched to cheaper machines. Independent providers could compute redundant fragments so that no single operator sees the full dataset. Some algorithms may support cryptographic verification or privacy-preserving computation. Others will not. The architecture should permit these methods without pretending that every modern AI workload can cheaply use fully homomorphic encryption or a compact proof of arbitrary GPU execution.

Remote attestation also has limits. It can provide evidence about measured state. It does not prove that the hardware has no undiscovered vulnerability, that every side channel has disappeared, that a model is truthful, or that a provider will remain online. A buyer must be able to state which assurances matter and pay accordingly.

This is where NIST’s Zero Trust Architecture supplies a useful discipline. Trust should not be granted merely because a machine sits inside a corporate network or carries a familiar brand. Each resource interaction should be authenticated and authorized under explicit policy. A decentralized market ought to be more demanding, not less, because the provider may be a stranger.

Metering is where the market becomes honest

Most token proposals discuss issuance at length and metering hardly at all. That is backwards. The buyer does not principally need a token. The buyer needs confidence that a quoted amount of useful work was delivered.

Compute cannot be metered by one number across all tasks. A robust receipt may need several dimensions:-

input and output units for model inference;

wall-clock and accelerator time;

allocated and peak memory;

model, image, and dependency hashes;

batch size and precision;

latency distribution rather than a single average;

retries, failed attempts, and pre-emption;

data transferred and stored;

assurance and attestation status;

verification samples and challenge outcomes;

energy use, where measured and contractually relevant.

The quote should say which measurements determine the final price. A model API may price input and output separately. A render provider may charge by a benchmark-adjusted unit. A scientific job may pay a fixed amount for a validated result. A low-priority batch market may use an auction. There is no reason to impose one tariff merely because there is one settlement token.

Standardized receipts are essential for comparison and dispute. The receipt should be independently parseable, signed by the provider, linked to the accepted quote, and bound to the job identifier. It should include enough evidence to detect double billing and enough privacy protection to avoid publishing the customer’s workload.

Decentralized Identifiers and Verifiable Credentials could be used for provider identities, hardware attestations, licences, audit status, and reputation claims without forcing every marketplace to use the same central account. Privacy Pass demonstrates an architecture in which authorization tokens can be issued and redeemed with unlinkability properties. It is not a compute-payment protocol, but it shows that a system can separate authorization from persistent cross-site identity. OAuth 2.0 Token Exchange is likewise an identity and security-token mechanism rather than an economic credit system, yet it supplies a useful design lesson: tokens issued in one security context can be exchanged for tokens meaningful in another when the parties explicitly define trust and audience.

The caveat matters. Reusing the word “token” does not make these standards interchangeable. An identity token says who or what is authorized. A PCC settles value. An attestation token reports measured state. A usage receipt records performance. Conflating them would recreate the conceptual mess this proposal is intended to solve.

How unused Claude or OpenAI capacity could become portable

The most immediately understandable use case is the stranded AI balance.

Imagine that a company buys 100,000 PCCs at the start of a quarter. It can place them with any participating provider. OpenAI might quote a particular model invocation in PCCs. Anthropic might quote another. A specialist provider might offer an open model at a lower price. A data center might quote a private fine-tuning run. A household machine might quote a batch rendering task. The company carries one budget while the services compete.

There are three ways existing vendors could join.

Direct acceptance

The simplest method is for the vendor to accept PCCs at checkout or through its API. The vendor posts a price, performs the work, receives PCCs, and clears them through the network. The customer never needs to prepay a separate vendor balance.

Conversion at the boundary

A vendor could continue using its internal meter while allowing a PCC gateway to fund jobs just in time. The gateway converts PCCs into an internal usage authorization for the exact quoted job. Unused value remains in the user’s PCC wallet rather than in the vendor’s account.

Migration of purchased balances

A participating vendor could permit prepaid credits to be converted into PCCs. To prevent double spending, the original credits would be cancelled or burned when the portable units are issued. The conversion rate and any fee would be published. Promotional credits could remain non-transferable, while purchased credits receive stronger portability.

The same logic can apply to a monthly allowance only when the allowance is defined. Suppose a Claude plan or another subscription promises a measurable bundle rather than merely access subject to variable limits. The provider could allow unused units to be returned to a pool, sold to another customer, or rolled into PCCs. If the plan does not promise a quantity, then there is no definite remainder to transfer. Product design must precede tokenization.

Under current OpenAI and Anthropic terms, users cannot unilaterally do this. Both companies prohibit transfer of their service credits. A portable market therefore requires changed terms, direct vendor participation, or an intermediary that purchases services and issues its own enforceable obligation. This legal fact is not a footnote. It is the difference between a genuine claim and a token pointing at nothing.

The economic pressure for change may come from business customers rather than retail users. Large organizations already negotiate cloud commitments, model access, rate limits, and enterprise terms. A consortium could begin with bilateral or multilateral clearing among a handful of providers. Once the service manifests and receipts are standardized, the settlement unit can broaden. Interoperability often begins as an agreement among institutions before it becomes an open consumer market.

Why the large platforms will resist

The large AI companies are unlikely to greet portable credits as a moral revelation. Portability weakens several profitable forms of control.

First, it reduces lock-in. A customer with a vendor-specific prepaid balance has a reason to continue using that vendor even when a rival offers a better service. A portable balance turns that inertia into contestable demand.

Second, it reduces breakage. Expiring or unused credits benefit the issuer. A secondary market allows the buyer to recover value and directs capacity toward someone willing to use it.

Third, it exposes price discrimination. Closed platforms can offer different bundles, discounts, limits, and effective prices to different users. A common settlement and quote protocol makes comparisons easier and arbitrage more likely.

Fourth, it weakens control over the customer relationship. The platform currently sees the account, funding, procurement history, usage, and switching behaviour. A portable agent can obtain competing quotes without surrendering its entire commercial history to every bidder.

Fifth, it complicates safety and compliance. Transferability can facilitate account resale, sanctions evasion, stolen balances, abusive automation, and jurisdiction shopping. These are real risks, not excuses invented from nothing. A serious design needs revocation for proven theft, policy-bound authorization, selective disclosure, transaction monitoring where legally required, and a distinction between privacy and impunity.

Sixth, it changes capacity planning. Subscription products allow a provider to sell access knowing that many customers will not simultaneously consume the maximum. A fully transferable fixed entitlement could concentrate usage at peak times. The solution is not necessarily to forbid transfer. It is to price time, priority, and capacity honestly. A PCC can buy a spot quote, a reserved window, or a low-priority job. The service contract carries the congestion terms.

These incentives explain why portability is institutionally difficult even when it is technically straightforward. The incumbent does not merely operate a meter. It benefits from defining what the balance is allowed to mean.

One token must not become one new sovereign

A single portable unit can itself become centralized. If one company issues every PCC, controls the wallet software, approves every provider, operates the only verifier, sets every exchange rate, freezes balances without an external process, and remains the sole redemption counterparty, then the system has created a new platform rather than a decentralized market.

The governance design therefore matters as much as the token format.

There can be multiple qualified issuers under common rules. Each issuer can place reserves, publish liabilities, and undertake redemption. Clearing can net obligations among issuers. Providers can choose which issuers they accept or apply risk discounts. Users can hold claims from more than one issuer while software presents a unified balance where the risks are equivalent and clearly disclosed.

The ledger could be a public blockchain, a federated ledger, a high-volume signed-note system, or another auditable structure. The implementation should be judged by its properties: double-spend resistance, finality, throughput, privacy, auditability, cost, recovery, and ability to exit. A blockchain is not mandatory. Nor does the presence of a blockchain excuse a single administrator.

Token-interface standards such as ERC-20 and ERC-1155 show how applications can share transfer functions and represent fungible or semi-fungible assets. That solves a software-interface problem. It does not decide who owes redemption, whether reserves exist, what the compute quote means, or whether a provider delivered the work. A perfect token contract can represent a worthless promise with immaculate precision.

Good governance would require, at minimum:-

public issuance and reserve rules;

auditable liabilities and redemption performance;

separation between promotional units and purchased units;

published criteria for providers, verifiers, and issuers;

portable receipts and reputation evidence;

a defined process for theft, fraud, sanctions, disputes, and mistaken transfers;

no unilateral change to already issued economic rights without a governed procedure;

competing wallet, market, verifier, and clearing implementations;

an exit route that does not depend on one firm’s continued API access.

The objective is not the abolition of institutions. It is the replacement of one unavoidable institution with several contestable institutions whose claims can be verified and whose customers can leave.

Regulation cannot be wished away with vocabulary

A transferable and redeemable compute credit may cross several regulatory categories depending on its design and jurisdiction. It could be treated as stored value, electronic money, a crypto-asset, a commodity-like contract, a voucher, a payment instrument, or a claim against an issuer. Intermediaries may face money-transmission, custody, consumer-protection, sanctions, tax, insolvency, disclosure, or licensing obligations.

The label “compute token” will not settle the matter. The United States Financial Crimes Enforcement Network’s guidance on convertible virtual currency business models focuses on functions and activities rather than accepting a project’s preferred terminology. In the European Union, the Markets in Crypto-assets Regulation establishes obligations for defined categories of crypto-assets, issuers, and service providers. A PCC design would require jurisdiction-specific analysis before launch.

Regulation is not necessarily fatal to the proposal. It may strengthen it. Reserve rules, segregation of customer assets, redemption rights, disclosures, and insolvency treatment are precisely the matters that turn a token from a marketing object into a credible claim.

A staged approach is more plausible than an immediate global bearer market. The first implementation could be a closed B2B clearing arrangement among identified firms. Transfers could occur only among contracted participants, with explicit limits and compliance procedures. The protocol and receipts could remain open even while the issuer set is permissioned. Later stages could admit regulated retail wallets, more issuers, independent providers, and privacy-preserving credentials.

This illustrates another point routinely lost in token discourse: permissionless settlement is not the only dimension of decentralization. A system can begin with regulated issuers yet still create meaningful portability, supplier competition, verifiable delivery, and exit. Conversely, a permissionless token can sit inside a service whose economically relevant layers are entirely closed.

A realistic path from subscriptions to a market

The complete architecture need not appear in one heroic launch. It can be built in stages.

Phase 1: Standardize the service, not the coin

The first task is a common job-manifest, quote, meter, and receipt format. Providers should be able to describe model inference, GPU jobs, storage, and assurance in machine-readable terms. Receipts should be signed and linked to accepted quotes. An independent test suite should check interoperability.

This phase can use ordinary invoicing and existing payment methods. Its purpose is to prevent each platform from defining delivered compute in an incomparable private language.

Phase 2: Establish inter-company clearing

A small group of AI and cloud providers can accept a common fully reserved settlement unit. Customers fund one balance. Providers net positions daily or continuously. Purchased balances can be converted under explicit rules. The system publishes issuance, redemption, and reserve data.

At this stage, the unit may operate under contractual permission among identified companies. That is still a significant advance over non-transferable vendor credits.

Phase 3: Open the supply side

Independent data centers, model hosts, and distributed-compute networks can join through standardized provider credentials and assurance tiers. Marketplaces compete to match jobs rather than owning the only accepted balance. Providers retain portable performance evidence.

Phase 4: Admit qualified household hardware

Consumer machines enter where workloads and assurance permit. Benchmarking, sandboxing, challenge protocols, and reputation reduce risk. Confidential workloads route only to supported confidential platforms. Non-sensitive tasks benefit from a much larger and geographically dispersed supply pool.

Phase 5: Permit autonomous procurement

Agents receive spending authority subject to human-defined policy. A policy might permit no more than 500 PCCs per day, forbid specified jurisdictions, require Tier 3 assurance for private data, demand two quotes above a threshold, and route disputed jobs to human review. The agent can split work, hedge supplier failure, and select between price and latency without maintaining stranded balances everywhere.

Phase 6: Create a secondary market for unused rights

Purchased credits and defined allocations can be sold or transferred. Promotional units can remain restricted and visibly distinct. Time-specific capacity rights—such as a reserved inference window—can trade separately from general PCCs using signed service claims. This is where the market begins allocating not only money but unused capacity.

The sequence matters. Beginning with a speculative token and hoping that services, metering, security, and redemption will later emerge is the usual route to failure. Begin with enforceable service definitions and verified delivery. Add the portable settlement claim when there is something real to settle.

Eight questions that expose fake decentralization

Any platform claiming to decentralize AI or computation should be asked eight questions.

1. Can the user control the balance independently of the service provider?

If the balance exists only in a corporate account that the issuer can erase or expire under ordinary commercial discretion, custody remains centralized.

2. Can the value be transferred to another person or agent?

A non-transferable credit is a coupon. Calling it a token does not change the right.

3. Can unrelated providers accept and redeem it?

Transfer between users is not enough. A portable compute credit must cross supplier boundaries.

4. Can new suppliers enter under public, technically relevant criteria?

A network with many machines but one private admissions desk may distribute hardware while centralizing the market.

5. Is the purchased service specified independently of the provider’s dashboard?

The quote and manifest must be portable and machine-readable. Otherwise the buyer cannot compare or challenge performance.

6. Can a third party verify the meter and receipt?

A provider should not be the sole author, judge, and archivist of its own bill.

7. Are revocation and disputes governed rather than improvised?

Absolute irreversibility invites theft; unlimited administrative reversal destroys ownership. The rules must distinguish final settlement from defined fraud and dispute processes.

8. Can the user leave without abandoning value, identity, or performance history?

Exit is the final test. A system is not decentralized when departure requires surrendering everything accumulated inside it.

A platform need not achieve perfection on every dimension before it is useful. But it should state honestly which layers are decentralized and which are not. “We use a token” is not an answer to any of the eight questions.

Decentralization is the right to say no

The deepest benefit of a portable compute market is not cheaper tokens. It is refusal.

A user can refuse a vendor’s new price because another provider accepts the same balance. A provider can refuse a marketplace’s commission because its reputation and earnings are portable. An agent can refuse an opaque execution environment because the job manifest requires attestation. A business can refuse to let prepaid value expire because it can transfer the claim. A developer can refuse to integrate five proprietary billing systems because the quote and receipt protocols are open.

That is what decentralization changes. It redistributes the power to decline.

The current AI economy offers remarkable models through remarkably conventional commercial structures. The user subscribes, prepays, consumes, and starts again at the next vendor. Compute is sold as a sequence of walled gardens. Even where crypto is accepted, the payment does not make the capacity portable. Even where GPUs are distributed, the settlement unit often remains native to one network. Even where a model is open, access to efficient execution may be controlled by a handful of infrastructure providers.

A single inter-corporate compute credit would not solve every problem. It would not make bad models good, abolish regulation, eliminate fraud, or turn a gaming card into confidential hardware. It would, however, establish the economic primitive that today’s market lacks: a claim that survives movement between suppliers.

The architecture is within reach. Distributed-compute networks already match jobs to independent machines. Confidential-computing systems already attest protected environments. Standard metrics already describe performance. Signed-message and credential standards already support portable assertions. Clearing systems already net obligations among institutions. The components exist. What is missing is the decision to connect them around a right the customer actually owns.

And that is why so much talk of decentralization stops at the token. The token is easy. Portability is expensive to incumbents.

Real decentralization begins when the credit can leave.

References

OpenAI. “Service credit terms.” Updated 1 January 2026. https://openai.com/policies/service-credit-terms/

Anthropic. “Supplemental Credit Terms.” Effective 4 March 2024. https://www.anthropic.com/legal/credit-terms

Anthropic Help Center. “How do I pay for my Claude API usage?” https://support.claude.com/en/articles/8977456-how-do-i-pay-for-my-claude-api-usage

Cash App. “Terms of Service.” https://cash.app/us/en/legal/tos

Cash App. “Sending and Receiving Bitcoin with Lightning.” https://cash.app/help/us/en-us/6506-lightning

Lightning Labs. “Sending Payments.” Builder’s Guide. https://docs.lightning.engineering/lightning-network-tools/lnd/payments

Lightning Labs. “Managing Channel Liquidity.” Builder’s Guide. https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/channel-liquidity

Akash Network. “Provider Service Overview.” https://akash.network/docs/providers/architecture/overview/

Golem Network. “Introduction to Providers on the Golem Network.” https://docs.golem.network/docs/providers

Render Network. “How to get started as a Node Operator.” https://know.rendernetwork.com/general-render-network/what-role-am-i/how-to-get-started-1

Render Network. “Render Compute Network GPU Compute Node Waitlist FAQ.” https://know.rendernetwork.com/general-render-network/what-role-am-i/how-to-get-started-1/render-compute-network-gpu-compute-node-waitlist-faq

MLCommons. “MLPerf Inference Benchmarks.” https://docs.mlcommons.org/inference/

OpenTelemetry. “OpenTelemetry Metrics.” https://opentelemetry.io/docs/specs/otel/metrics/

IETF. “RFC 9334: Remote ATtestation procedureS (RATS) Architecture.” January 2023. https://www.rfc-editor.org/rfc/rfc9334.html

NVIDIA. “NVIDIA Attestation.” https://docs.nvidia.com/attestation/index.html

NVIDIA. “Supported Platforms—NVIDIA Confidential Containers Architecture.” https://docs.nvidia.com/datacenter/cloud-native/confidential-containers/latest/supported-platforms.html

AMD. “AMD Secure Encrypted Virtualization (SEV).” https://www.amd.com/en/developer/sev.html

Intel Trust Authority. “TEE TDX.” https://docs.trustauthority.intel.com/main/articles/articles/ita/tee-tdx.html

National Institute of Standards and Technology. “IR 8320E: Hardware-Enabled Security: Confidential Computing of Data in Cloud Workloads.” Initial Public Draft. https://csrc.nist.gov/pubs/ir/8320/e/ipd

National Institute of Standards and Technology. “SP 800-207: Zero Trust Architecture.” August 2020. https://csrc.nist.gov/pubs/sp/800/207/final

World Wide Web Consortium. “Verifiable Credentials Data Model v2.0.” W3C Recommendation. https://www.w3.org/TR/vc-data-model-2.0/

World Wide Web Consortium. “Decentralized Identifiers (DIDs) v1.0.” W3C Recommendation. https://www.w3.org/TR/did/

IETF. “RFC 9421: HTTP Message Signatures.” February 2024. https://www.rfc-editor.org/rfc/rfc9421.html

IETF. “RFC 9576: The Privacy Pass Architecture.” June 2024. https://www.rfc-editor.org/rfc/rfc9576.html

IETF. “RFC 8693: OAuth 2.0 Token Exchange.” January 2020. https://www.rfc-editor.org/rfc/rfc8693.html

Ethereum Improvement Proposals. “ERC-20: Token Standard.” https://eips.ethereum.org/EIPS/eip-20

Ethereum Improvement Proposals. “ERC-1155: Multi Token Standard.” https://eips.ethereum.org/EIPS/eip-1155

Financial Crimes Enforcement Network. “Application of FinCEN’s Regulations to Certain Business Models Involving Convertible Virtual Currencies.” 9 May 2019. https://www.fincen.gov/resources/statutes-regulations/guidance/application-fincens-regulations-certain-business-models

European Union. “Regulation (EU) 2023/1114 on markets in crypto-assets.” 31 May 2023. https://eur-lex.europa.eu/eli/reg/2023/1114/oj/eng

← Back to Substack Archive