OpenInfer paper 001September 2026
An open protocol for the machine economy.
Read the paperPaper / 4 sections / ~10 min
Protocol Draft 000101 / The premise
An agent can decide what to do. It still cannot independently decide whom to do business with.
Agents can reason, write software, search, operate computers, and manage workflows. But the infrastructure beneath them still depends on accounts, API keys, billing relationships, and vendor lists established by humans. OpenInfer asks whether software can discover a service, agree to terms, verify delivery, and settle payment with a provider it has never met.
Two trust models
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.
02 / The protocol
OpenInfer defines a common loop for purchasing work. Providers, buyers, gateways, and settlement rails remain replaceable.
Initial 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()
Design constraint
The protocol describes the market; it does not dictate the buyer’s decision.
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.
Execution 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.
03 / The trust model
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?
Optimistic challenge model
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.
Progressive assurance
A two-cent request and a ten-million-dollar decision should not carry the same proof burden.
Economic security
The practical objective is not perfect detection. Providers place capital behind their claims, unpredictable audits create detection risk, and proven fraud destroys stake. Enforcement must ultimately be open: an independent challenger should be able to prove fraud and earn part of the penalty without permission from OpenInfer.
Commerce should settle in stable units. A native asset is justified only if measured protocol use shows that staking, slashing, validation, or governance cannot work without one.
04 / The research program
Product foundation
Build the dependable, familiar GPU marketplace first. Make independently operated hardware legible and prove placement, recovery, metering, and settlement with conventional workloads.
Protocol proposal
Let providers compete to serve open models through machine-readable offers, signed receipts, independent metering, and progressive verification.
Long-term implication
Extend the same transaction primitive to compute, data, media, tools, and specialist agents—without making OpenInfer the mandatory buyer or seller.
Beyond inference
If the inference market works, the same transaction model can extend to compute, data, storage, media, tools, and specialist agents.
An agent begins with an objective, budget, and purchasing policy. It composes only the services required, evaluates each offer, and settles each contribution independently.
This is an implication, not the initial product. OpenInfer first has to prove that its verification model works for one narrow, measurable service.
Central 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.
Measure how honest implementations diverge across runtimes, kernels, parallelism, and quantization. Define what must match exactly and what can vary within a tested bound.
Instrument one open MoE model to commit routes and selected checkpoints. The working target is less than 3% overhead to normal inference.
Choose a token, layer, and expert only after commitment. Test whether an independent verifier can check it for less than 0.1% of the original request cost.
Try lower precision, skipped layers, altered expert routing, substitute models, and selective cheating. Publish false-positive and false-negative curves.
Combine measured audit cost, detection probability, provider margin, stake, and challenge rewards. Proceed only where the expected value of fraud is negative.
Exercise signed receipts and shadow challenges through the existing Offer-to-Charge path under restart, replay, timeout, and evidence-gap failures before real settlement or slashing.