Manifesto / 6 chapters / ~12 min
Chapter I · 00 / The vision
Without permission, prior relationships, or blind trust.
AI is becoming autonomous. Agents can reason, write software, search, operate computers, and manage workflows. But the infrastructure beneath them still depends on accounts and commercial relationships established by humans. An agent can consume services. It cannot truly procure them.
Chapter I · 01 / The missing layer
Human trust infrastructure
This works. A company purchasing cloud infrastructure may be better served by a legal agreement, insurance, and an identifiable vendor. OpenInfer does not exist to abolish that system.
Machine trust infrastructure
Autonomous software may make thousands of tiny procurement decisions across counterparties that exist for seconds. A legal relationship for every transaction is impossible.
The thesis
Autonomous agents need a permissionless way to discover, purchase, verify, and pay other machines for intelligence and computation.
Chapter II · 02 / The protocol
OpenInfer provides the economic control loop. Providers and buyers remain replaceable.
Chapter II · 03 / The first market
Inference is the first service that makes every part of the protocol concrete: capability, price, performance, usage, artifact identity, verification, and settlement.
A provider should be able to announce a model, endpoint, price, stake, and execution profile—and compete for traffic without an application, sales call, or preferred-provider agreement.
Agent procurement policy
Constraints satisfied → buy()
Chapter II · 04 / Market, not middleman
It is the market underneath every router.
Fluxyard may bootstrap the first product: a familiar compute marketplace and gateway built on OpenInfer. It must never become indispensable. Anyone can build another router; an agent can query competing offers directly and route its own work. OpenInfer exposes supply. The buyer decides what “best” means.
Chapter II · 05 / A boundary
Prompts do not need consensus. Transformer operations do not belong in smart contracts. Latency-sensitive computation remains a direct path from buyer to provider to hardware.
The protocol lives around the work: identity, discovery, commitment, verification, reputation, and settlement. Blockchain infrastructure may provide useful primitives for some of these functions. It is not the product.
Chapter III · 06 / Verification
When an unknown provider says “I served this model and generated this usage,” the protocol must make five properties legible.
Was the reported quantity of work calculated correctly from a canonical tokenizer and request?
Did the provider serve the advertised model, weights, quantization, and execution profile?
Was the computation faithful enough to satisfy that profile rather than a cheap substitute?
Did the provider deliver the latency, throughput, and availability it advertised?
Has this identity consistently satisfied its claims across prior transactions and challenges?
Chapter III · 07 / Optimistic verification
The provider returns its output with a signed receipt and a commitment to what happened during execution. Only after that commitment is locked does protocol randomness decide whether—and where—the computation must be opened.
The provider cannot know in advance which token, layer, expert route, or activation region will be inspected. Most transactions settle cheaply. Random or suspicious transactions escalate.
Chapter III · 08 / Progressive assurance
A two-cent request and a ten-million-dollar decision should not carry the same proof burden.
Chapter III · 09 / Economic security
The practical objective is to make honest execution more profitable than fraud. Providers place capital behind their claims. Unpredictable audits create detection risk. Proven fraud destroys stake and rewards the challenger who found it.
Chapter III · 10 / Open enforcement
A decentralized provider market with a centralized fraud department is not enough. Anyone should eventually be able to challenge execution commitments, prove fraud, and earn part of the penalty. Providers earn by computing. Challengers earn by finding dishonest computation. Neither needs permission from OpenInfer.
Chapter IV · 11 / Useful computation
A mathematically valid execution can still be a terrible service. Buyers care about quality, price, latency, throughput, availability, context, privacy, and verification. No routing algorithm should be universally privileged.
Chapter IV · 12 / Money and security
Agents budget in stable units. They should not need to speculate on a volatile asset to buy inference. Stablecoins are a natural settlement rail for commerce.
If a native asset ever improves staking, slashing, validation, or governance, the protocol should earn the right to introduce one. The sequence is utility, market, protocol, demonstrated security need—and only then a token, if necessary.
Chapter IV · 13 / Why agents
Today an agent operates inside relationships created by its owner: cloud credentials, API keys, billing accounts, and approved vendors. It can decide what to do. It cannot independently decide who to do business with.
A wallet and protocol identity change that. An agent can discover a service, evaluate the offer, purchase it, verify delivery, and settle—entirely through software.
Chapter V · 14 / The path
Foundation
Build the dependable, familiar GPU marketplace first. Make independently operated hardware legible and prove placement, recovery, metering, and settlement with conventional workloads.
First market
Let providers compete to serve open models through machine-readable offers, signed receipts, independent metering, and progressive verification.
End state
Extend the same transaction primitive to compute, data, media, tools, and specialist agents—without making OpenInfer the mandatory buyer or seller.
Chapter V · 15 / Beyond inference
Chapter V · 16 / The research question
For trillion-parameter Mixture-of-Experts models, can a provider cheaply commit to enough of its execution that unpredictable post-commit challenges detect dishonest computation at a tiny fraction of the cost of reproducing the original request?
The target is not theoretical perfection. It is a machine-readable economic guarantee strong enough that an autonomous agent can rationally transact with an unknown provider.
Chapter VI · 17 / Principles
If a participant satisfies the protocol, OpenInfer should not decide whether it belongs.
Use decentralized infrastructure around execution, not inside the latency-sensitive path.
Gateways are clients of the market. An agent must be free to route for itself.
Capability, price, execution, usage, and performance should be machine-readable and challengeable.
Buy the verification appropriate to the value and risk of the transaction.
Make the expected value of fraud negative and reward independent enforcement.
Real demand, providers, payments, and adversarial behavior come first.
Make one strange hardware combination boringly reliable. Then generalize.
Chapter VI · 18 / Our north star
Can they discover one another, agree on the purchase of intelligence, execute the work, determine whether the agreement was satisfied, and settle payment—without a trusted intermediary or human intervention?
If yes, the protocol is working.
Everything else is implementation.