Compute market

Compute market

Confidential Compute Market Architecture

A node with a cryptographic DID, proven track record, and authenticated messaging channel possesses the prerequisites for decentralized compute. Fleetmesh leverages this foundation to create an open compute market without central coordination.

Why there is no fee to charge

Traditional marketplaces extract transaction fees by monopolizing four services: identity (counterparty authentication), reputation (historical tracking), discovery (order book matching), and settlement (escrow and clearing). Transaction fees represent the cost of proprietary access to these four functions.

In this network all four already exist as public infrastructure, and none of them belongs to anyone:

The absence of fees is a structural property rather than a policy choice. Because all four marketplace functions run on open protocols, there is no centralized service left to charge a fee. Third parties may still construct value-added venues (such as curated indexing or UI frontends) and charge for their services. However, they cannot monopolize access: the order book is a public topic, and reputation consists of signed events held across the mesh.

The job, and why WASM

Two executors are defined, and the difference between them is not power but verifiability:

fleetmesh does not implement an execution engine and should never grow one. It specifies the envelope: what a job is, how it is priced, how it is paid for, and what evidence a dispute needs. Executors sit behind a stable interface, as adapters. A third executor that arrives with better determinism guarantees should require no change here.

The price unit has to be objective

Quotes are only comparable if they are quoted in something both sides can count. Wall-clock seconds are not that: they measure the seller's hardware, not the work. For the wasm executor the unit is fuel: the runtime's metered instruction count. Fuel is a deterministic function of the module and its inputs, so it is identical on every honest executor. A price is millisatoshis per million fuel units, plus a declared ceiling.

Two things follow that ordinary cloud pricing cannot offer. A buyer can know the cost before paying, by metering a dry run locally or accepting the seller's committed fuel bound. And two quotes are directly comparable, because the denominator is a property of the job rather than of the machine. Bacalhau jobs price per resource-second instead and are explicitly marked as estimates, because that is what they are.

What the order book may see

An ask has to reach sellers the buyer has not chosen yet, which is what makes it a market rather than a purchase order. It does not have to say what the job is. Those are separable, and this document separates them.

Everything a seller needs to price the work is structural: the executor, the engine, the fuel ceiling, the input length, the deadline and the verification mode. Everything that identifies the work — the module digest and the input digest — is needed only by the seller that wins. So the ask carries the first set and a commit over the second, and the job itself travels in compute/1.0/accept, encrypted to one seller after it has won.

Two things survive that a naive reading might expect to break. Price discovery is unaffected, because quotes are priced against the declared fuel_max ceiling, which is exactly what § The price unit already said a buyer commits to. And the buyer can still re-run its own jobs, because the buyer holds the plaintext. What it does mean is that a third party cannot re-run a job it was not given — which is why the next section stops treating re-execution as the only way to be sure.

Paying without an escrow agent

The oldest problem in trade: whoever moves first can be robbed. Lightning solves it here without a third party, because a payment already reveals a secret when it settles.

What replaces atomicity: signing the claim before taking the money

The gap is closable without a proof system, by making a failed delivery provable rather than preventable. Before the buyer pays anything, the seller sends a signed compute/1.0/sealed naming three things at once:

{
  "ciphertext":   "<sha256 of the bytes the buyer was handed>",
  "payment_hash": "<SHA256(k) — the invoice the buyer is about to pay>",
  "result":       "<sha256 of the plaintext that k is claimed to reveal>",
  "fuel_used":    2311904772
}

Now the seller has committed, under its own signature and before receiving anything, that this ciphertext opens under the preimage of this invoice to a plaintext with that hash. A buyer who pays and cannot decrypt, or who decrypts to something whose hash does not match, holds the seller’s signed statement and the contradicting bytes. That is precisely the evidentiary standard § Severity ladder already demands, and it makes taking payment for a useless key an S3 rather than an unprovable dispute.

Pluggable Execution Runtimes (ComputeExecutor)

To prevent vendor lock-in to a single WebAssembly runtime engine, execution environments are abstracted behind the async ComputeExecutor trait. Sellers can run Wasmtime, Wasmer, WasmEdge, or distributed container runners (Bacalhau) as pluggable drivers.

#[async_trait]
pub trait ComputeExecutor: Send + Sync + 'static {
    /// Runtime engine identifier (e.g. "wasmtime", "wasmer", "v8", "bacalhau")
    fn engine_id(&self) -> &'static str;

    /// SHA-256 digest of the standardized WASI capability profile
    fn wasi_profile_digest(&self) -> [u8; 32];

    /// Estimate fuel and provide a deterministic price quote
    async fn quote(&self, module_bytes: &[u8], limits: &ComputeLimits)
        -> Result<ComputeQuote, ComputeError>;

    /// Execute a verified module with metered fuel limits
    async fn execute(&self, module_bytes: &[u8], inputs: &[u8], fuel_cap: u64)
        -> Result<ComputeExecutionResult, ComputeError>;
}

Standardized Deterministic Capability Profile (fleetmesh-wasi-v1)

Executing untrusted stranger bytecode requires rigorous, capability-based sandboxing and mathematical determinism. fleetmesh defines the fleetmesh-wasi-v1 standard profile that every WASM executor MUST enforce:

Profile Digest: An executor computes the SHA-256 hash of its canonical profile configuration document, publishing it as the fourth element in its runtime tag: ["runtime", "wasmtime", "18.0.0", "<wasi_profile_digest>"]. Buyers verify this digest to ensure the seller executes in an identical, secure sandbox before submitting paid tasks.

Correctness is a mode, declared before the work

The shape is unchanged from § Severity ladder: your signed claim against my measurement, with divergence as the offence. A false result hash is a misreport, which is an S2; a seller that returns fabricated results at scale is an S3. The evidence requirement is satisfied by construction, because the seller signed the result hash in order to get paid for it.

What the shape does not fix is how that measurement is taken. Re-execution is a fine mechanism and a poor requirement: it obliges whoever adjudicates to hold the plaintext, which is precisely what a confidential job will not give them. So the mechanism is named in the ask, before the work happens, the same way a grant names its remedy before the breach. The verify tag was already there and already declared up front; it now has a vocabulary.

A refutation citing evidence the declared mode does not admit is not a finding. This is not a courtesy to sellers; it is what stops a buyer choosing the cheapest verification and then litigating as though it had bought the strongest.

Sampling rate remains the buyer's choice and its own cost. Verifying everything doubles the compute bill and defeats the purpose of buying it; verifying nothing means a seller learns that lying is free. The arithmetic is worth doing rather than asserting: at sampling rate p, catching a seller who cheats on a fraction f of jobs with confidence c takes ln(1-c) / ln(1-pf) jobs. At p = 0.05 against a seller cheating every job that is about 45 jobs for 90% confidence — fast only if the buyer actually sends 45 jobs. Against one cheating a tenth of the time it is roughly 450. Any claim faster than that — "within a working day", say — is smuggling in a job rate it has not stated.

Verifiable work units, and why they close the loop

Sampling is probabilistic, and the arithmetic above is the honest description of what that costs. Under proof the seller returns evidence that the committed module, run on the committed input, produced the committed result. The buyer verifies without re-running. Nobody re-runs at all.

That is worth having on its own, but the reason it belongs in this document is that it is the same change as the section above. Confidentiality is only affordable if correctness does not require re-execution, and correctness only stops requiring re-execution if the unit carries its own proof. They are one property, not two. A proof-mode receipt can be adjudicated by a third party who never sees the job, which is the thing no amount of sampling can offer.

The cost is real and should not be soft-pedalled. Proving costs orders of magnitude more than executing, and it inverts the pricing argument: msat_per_mfuel prices execution, and a prover's bill is not proportional to the fuel it is proving about. So proof ships as an expressible mode with no reference implementation, on the same footing this document already gives contingent payment — a named direction rather than a requirement.

Dual-Execution Cross-Validation Protocol ("I'll run it if you do too")

Decentralized compute faces a classic cold-start challenge: proving a new worker's competence without exposing buyers to financial loss or corrupt results.

Because the fleetmesh-wasi-v1 execution environment guarantees bitwise output determinism, the network supports dual-execution cross-validation:

Modular AI & LLM Inference Routing (InferenceProvider)

WASM execution handles deterministic, bitwise-verifiable compute. Modern AI workloads — language models, image generation, voice transcription — are non-deterministic. Floating-point GPU variance, temperature sampling and model quantisation each break reproducibility. Strict bitwise hash-matching does not apply to generative LLM outputs.

Rather than forcing non-deterministic AI into the deterministic fuel engine, fleetmesh abstracts AI inference behind the modular InferenceProvider adapter interface. Nodes can run local GPU workers or bridge into specialized decentralized inference marketplaces such as Routstr (OpenAI-compatible routing over Nostr & Cashu) and NIP-90 Data Vending Machines (DVMs).

#[async_trait]
pub trait InferenceProvider: Send + Sync + 'static {
    /// Provider scheme identifier (e.g. "routstr", "nip90", "ollama", "vllm")
    fn provider_id(&self) -> &'static str;

    /// List active models served by this provider
    async fn list_models(&self) -> Result<Vec<ModelDescriptor>, InferenceError>;

    /// Estimate cost/rate per token for a given model
    async fn estimate_cost(&self, model: &str, prompt_tokens: u32)
        -> Result<InferenceQuote, InferenceError>;

    /// Stream completions over an authenticated session
    async fn complete(&self, req: &InferenceRequest)
        -> Result<Box<dyn InferenceStream>, InferenceError>;
}

Wire formats

Three kinds, verified free by the same method as the others on 2026-08-29 and listed in § Registration. Quotes are deliberately not events: a quote is addressed to one buyer and travels over compute/1.0, so a seller's pricing to one counterparty is not a public commitment to all of them.

{
  "kind": 11803,
  "tags": [
    ["executor", "wasm",     "msat_per_mfuel", "45"],
    ["executor", "bacalhau", "msat_per_cpu_s", "900", "estimate"],
    ["limit", "max_fuel",   "50000000000"],
    ["limit", "max_bytes",  "1073741824"],
    ["limit", "concurrent", "4"],
    ["pay", "bolt11"], ["pay", "bolt12", "<offer>"],
    ["runtime", "wasmtime", "<version>", "<wasi profile digest>"],
    ["expiration", "1789000000"]
  ],
  "content": ""
}

{
  "kind": 30810,
  "tags": [
    ["d", "<ask id>"],
    ["commit", "<sha256 of the job spec, which is not published>"],
    ["executor", "wasm"],
    ["runtime", "wasmtime", "18.0.0", "<wasi profile digest>"],
    ["fuel_max", "2500000000"],       // what a quote is priced against
    ["input_size", "1048576"],
    ["bid", "msat_per_mfuel", "50"],
    ["deadline", "1787004000"],
    ["verify", "proof", "risc0-v1"],  // declared up front, so it is not a surprise
    ["expiration", "1787004600"]
  ],
  "content": ""
}

{
  "kind": 30811,
  "tags": [
    ["d", "<blinded job identifier — only buyer and seller can derive it>"],
    ["commit", "<commitment to the receipt, which is encrypted in content>"],
    ["scheme", "sha256-blind/1", "nip44/2"],
    ["expiration", "1789600000"]
  ],
  "content": "<nip44 ciphertext to the buyer: ask, module, input, result,
              fuel_used, paid_msat, payment_hash, executor, proof>"
}

The result inside that ciphertext is still the verification anchor: a falsifiable claim, and the same value the seller committed to in the pre-payment sealed message. What has changed is who can read it. A receipt is a record of a job that went right, and § Grants & receipts already established that this protocol does not publish those — positive events are inert under the trust weighting and broadcasting them leaks topology for nothing. The argument does not stop applying because the subject is compute.

A seller MAY publish a cleartext receipt where the buyer has consented. Some buyers want a public record of work done on their behalf. That is their disclosure to make, and the point is that it is a choice rather than the default.

Modular Settlement Rails & Zero-Custody Payments (PaymentRail)

A node should not need custody of funds to participate, nor should it be hardwired to a single proprietary payment daemon. fleetmesh abstracts all payment generation, verification, and settlement behind the PaymentRail adapter interface.

What is likely to go wrong