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 central research question

Can an inference provider commit to evidence of its execution cheaply enough that unpredictable audits make dishonest computation uneconomic, at a small fraction of the cost of repeating the request?

This is a hypothesis, not a property of the current protocol. A signature makes a claim attributable; it does not make the claim true. The research must establish whether sampled evidence is meaningfully connected to the delivered output, whether honest implementations agree, and whether useful cheating can be distinguished from normal numerical variation.

Why begin with inference?

Open-model inference gives the proposal a bounded first service: a specified model, a request, output tokens, measurable usage, and a price. Start with one accessible model and a fixed execution profile. Larger Mixture-of-Experts models are a later scaling question, not a prerequisite for the first experiment.

The protocol can still be useful as accountable transaction infrastructure if inexpensive execution verification fails. That narrower outcome should be evaluated on its own merits.

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.

The experimental audit path

In the experimental design, 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 / Research and implications

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 implementation milestone is a cross-language set of signed-object fixtures and a shadow transaction through Fluxyard. Existing runnable examples cover selected cases; they are not a complete conformance suite or a working inference network.

Experiments and stop conditions

Each experiment should publish its code revision, model and hardware configuration, control runs, raw measurements, uncertainty, failures, and advance-or-stop decision. The E0–E7 research plan contains the procedures.

1. Fix the execution profile · E0, E3. Measure honest divergence across runtimes, kernels, and precision. Stop exact-transition verification if useful cheating cannot be separated from ordinary numerical variation.
2. Measure commitments and replay · E1, E2. Target less than 3% service overhead and less than 0.1% of original request cost for one challenged transition. Include weight loading, transfer, and cold-verifier costs. These are research targets, not achieved results.
3. Attack and price the design · E4, E5. Test substitute models, skipped work, altered routes, and fabricated traces paired with different outputs. Publish detection curves and aggregate audit cost. Do not advance if a useful shortcut remains profitable or security needs implausible capital or subsidies.
4. Rehearse failure and independent review · E6, E7. Exercise restart, duplicate delivery, missing evidence, and verifier timeout without real funds. Require two independent verifiers to agree on the same evidence before progressing toward open challenges.

If the simple sampling design fails, compare replication, trusted execution, or proof systems against the same workload and cost model. A negative result should narrow the protocol’s claims and guide the next experiment.

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.
• Research plan E0–E7 — methods, measurements, controls, and stop conditions.
• 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.