OpenInfer

01 / Problem and thesis

Purchasing beyond a fixed vendor list

Agents can already call tools and choose among services. Their purchasing authority usually comes from accounts, credentials, budgets, and vendors arranged by people. The difficult step is not choosing another endpoint: it is agreeing to bounded terms with a new counterparty, deciding what counts as delivery, and recovering when that counterparty fails.

Established providers, contracts, and conventional billing often solve this well. OpenInfer is worth pursuing only where a shared transaction format can reduce repeated integration and coordination costs without replacing them with greater verification, capital, or operational costs.

The first question to answer

Can one buyer repeatedly obtain a useful machine service with a clear advantage over their current approach, after accounting for delivery failures, full cost, and operator effort?

Begin with a known provider and human-approved spending limits. Permissionless participation is a separate hypothesis. A signature makes a claim attributable; it does not make the claim true. Add assurance research only when a specific unmet trust requirement justifies comparing it with ordinary delivery checks and provider audits.

Choose the workload with the buyer

Start with one bounded workload that fluxyard's existing Docker execution path supports. Open-model inference is a candidate when a buyer needs it: a specified model, a request, output tokens, measurable usage, and a price. No particular model family or new Runtime is a prerequisite.

A useful pilot would justify improving that service. It would not establish demand for a broad marketplace or prove that decentralized verification is feasible.

02 / One transaction

From an offer to an accountable outcome

Consider a research agent buying one inference request to extract facts from a filing. Its owner sets the spending limit and acceptable providers. The following is an illustrative purchase, not a live offer or a claim about available capacity.

1. Discover an offer

   The agent finds a signed offer describing the model and execution profile, input and output prices, limits, and supported assurance. A registry helps discovery; it does not make the provider trustworthy.

2. Agree and reserve

   The buyer selects the exact offer revision, output limit, deadlines, and acceptance policy. Before execution, the reservation must cover the permitted work in the agreed asset and unit scale. One buyer request binds to one accepted agreement; retrying is not another purchase.

3. Execute and record

   The provider runs the request off-chain, commits the output and usage digests, and signs a receipt linked to the agreement. This execution commitment follows the work; accepting commercial terms happens before it. Trace commitments are additional evidence only for profiles that require them.

4. Check delivery

   In the signed-receipt baseline, the buyer checks the delivered bytes and usage under the selected profile, then signs an acceptance. The buyer is also the trusted finalizer. This does not independently establish which model ran.

5. Finalize and settle

   A successful accepted receipt produces a payment instruction in the simulated ledger. Missing delivery follows explicit timeout and refund rules. Replays return the accepted result instead of charging again; changed messages are rejected. A real payment adapter is separate work.

No privileged router

fluxyard may provide the first marketplace and gateway, but a buyer should be able to use another gateway or inspect offers directly. Signed objects carry the accepted terms across those choices. The draft still names trusted finalizers and settlement adapters; interchangeable clients do not by themselves make a deployment decentralized.

Inference remains a direct buyer-to-provider interaction. The core standardizes identity, signed objects, replay handling, and outcomes; service profiles define the work and assurance profiles define the required evidence. A blockchain is not required to run the initial experiments. Settlement rails do not perform the computation.

03 / Verification and its limits

A receipt is a claim, not proof of execution

Usage, artifact identity, execution, performance, and provider history are different questions. Counting delivered tokens can check a usage claim without proving that the advertised weights generated them. Latency is partly an observation at the buyer; a history of receipts is not automatically a reliable reputation score.

Nor does faithful execution prove that an answer is true, useful, or safe to act on. A research agent still needs sources and task-level evaluation. Purchasing assurance about computation cannot replace judgment about its result.

Deferred: the experimental audit path

This design is outside the current pilot. It would need to demonstrate a useful improvement over simpler audits before implementation resumes. The provider commits to the output, usage, and a trace before audit randomness is available. A challenge selects evidence to open; a verifier checks it against the agreed execution profile. An internally consistent trace is insufficient if it can be fabricated independently of the request and returned output.

The diagram shows the experiment’s decision paths, not observed network behavior. An unaudited receipt may proceed under the agreed policy after the challenge window; that is an economic choice, not a proof that the request was executed faithfully.

Economic security must be measured

Audits would need to make expected gains from cheating smaller than expected losses, while keeping honest service viable. That depends on detection probability, how much work can be sold before detection, verifier incentives, false accusations, collusion, and capital cost—not merely a large stake number.

Private prompts and outputs create another constraint: a challenge must reveal enough to verify the claim without silently exposing customer data. The research must also specify an unpredictable, bias-resistant randomness source and credible dispute handling. These are unresolved dependencies.

Initial payments and penalties stay simulated. Stable-value settlement is the intended direction; a native asset is not part of the baseline and would need a demonstrated necessity.

04 / Practical pilot and decisions

What would justify the next step?

fluxyard already has a trusted GPU-market transaction path: revisioned offers, immutable accepted terms, usage evidence, and append-only charges. Its control plane and database are trusted. Those patterns are a starting point for OpenInfer, not evidence of permissionless providers, independent verification, or decentralized settlement. The draft’s evidence map makes that distinction explicit.

The next milestone is an agreed pilot with a real buyer and a known provider. Use existing capabilities first, adding portable signed records where they remove demonstrated coordination work. Existing runnable examples cover selected protocol cases; they do not establish buyer demand or complete conformance.

A four-week test with stop decisions

The practical research plan defines the evidence and gates. Before starting, name an owner and agree the spending cap, delivery criteria, data permissions, and acceptable cost and operator effort.

1. Week 1 · Establish the need. Find one recurring workload, document the buyer's current alternative, and agree a price and measurable reason to switch. Pause the build if no credible buyer advantage emerges.
2. Week 2 · Deliver one accountable job. Use the existing fluxyard path. Obtain buyer acceptance, reconcile terms and usage, and exercise retry, restart, missing evidence, and provider failure without duplicate charges or silent evidence loss.
3. Week 3 · Measure repeat use. Seek at least two further representative jobs on separate occasions. Include failures, subsidies, transfer, retries, audit costs, and operator labor. Simulated payments are not revenue or proof of willingness to pay.
4. Week 4 · Decide. Continue a useful service, timebox one measured fix, investigate one concrete trust gap, or pause/change the workload. A successful demo alone does not justify expanding the protocol.

OpenInfer settlement stays simulated; any commercial pilot requires separately approved ordinary billing and fluxyard's operational gates. If a trust gap later warrants research, compare operator audits and existing reference-based methods before custom trace verification. Judge aggregate cost, false alarms, detection, and buyer exposure together. The former E0–E7 program is superseded and remains in Git history.

Beyond inference

If one service works, an agent could purchase data, computation, storage, or specialist work through the same transaction envelope. A research agent might buy a dataset, run an analysis, and commission an independent review, settling each contribution separately.

What generalizes is agreement and accounting, not a universal verifier. Storage delivery, model execution, and a specialist’s judgment need different acceptance criteria. Each service would require its own profile and evidence before OpenInfer could claim to support it.

Documents and foundations

• Protocol Draft 0001 — core, inference, signed-receipt, and experimental assurance profiles, with maturity labels.
• Practical research plan — a four-week pilot of buyer demand, accountable delivery, repeat use, costs, and stop decisions.
• RFC 8785 and RFC 8032 — the draft’s JSON canonicalization and Ed25519 signature foundations. They support reproducible signed claims, not proof of model execution.

This paper explains the proposal; the versioned draft defines its wire rules. OpenInfer Draft 0001 is a project research draft, not an IETF RFC or an adopted standard. Corrections and counterexamples are welcome through the source repository.