On-Chain Compute Quotes: When to Bind the Operator First

You need a graphics processing unit (GPU) job completed by a named operator, the provider responsible for that job, not whoever is online when the request lands. Three operators can offer capacity, but their prices, hardware, and privacy policies differ. You want the chosen operator and price committed before the job is sent, and a way to challenge non-delivery later.

An on-chain request-for-quote (RFQ) flow does that. It turns an off-chain price conversation into signed data that a contract checks before it accepts the job. The promise is narrower than many explanations suggest. The quote proves who priced the work and on what terms. It does not prove the AI answer is correct.

Bind the operator before the job starts

In Tangle’s job RFQ flow, operators sign structured quotes off-chain. The requester submits the selected signed quotes with the job. The contract checks the quote’s requester, service, job, input binding, time bounds, signature, operator eligibility, and payment. It records the quoted operators for that call. Only those operators can submit a result for the RFQ job.

If a quoted operator fails a service-defined obligation, an authorized process can propose a slash with evidence and the configured dispute path. A client disliking an answer is not, by itself, grounds for a slash.

Terms for a quoted job

An RFQ, or request for quote, is a negotiation in which a requester asks one or more operators to price a specific job before committing it on-chain.

A Blueprint is a public Tangle service definition that names jobs and describes how operators run and verify them. An operator is the person or team that supplies infrastructure and runs a service instance. A job is one invocation of a named Blueprint function with a particular input. A runtime executes that function, and a job router maps the job index to the handler that runs it.

An attestation is signed evidence about a protected runtime, such as a TEE measurement. It can be one part of a job’s verification policy, but an RFQ signature is not an attestation.

An evaluation checks a result against an expected condition. Verification checks evidence against a rule. Verifying an operator’s signature differs from evaluating whether a model output satisfies a schema.

An x402 payment is an HTTP payment exchange for a resource request. RFQ is an on-chain commitment flow for a chosen operator and job price. They can coexist, but neither replaces the other.

A trace is the record that joins quote collection, on-chain submission, execution, result, and any dispute evidence.

The continuing example

An agent needs a confidential embedding job over a private document. It asks three eligible operators for quotes. Each operator sees the job identity, price request, deadline, and input digest, while the plaintext input stays protected under the service policy.

The example uses ether (ETH), the network’s native unit. The sample quote responses are:

Sample operator	Price	Expiry	Confidentiality	Decision
Sample A	0.003 ETH	10 minutes	Required	Selected
Sample B	0.0025 ETH	4 minutes	Required	Backup
Sample C	0.0018 ETH	10 minutes	Not offered	Rejected

The requester chooses A because the service requires the operator’s confidential-execution capability. It can include B as a second quoted operator if the Blueprint requires redundant execution. The choice happens before the on-chain submission, not after a public job appears.

The prices above are illustrative. The protocol amount is represented in the native token’s smallest unit, and the deployment’s current price and payment configuration are the authority for a real call.

What an operator signs

The current Tangle documentation describes JobQuoteDetails as binding a quote to these fields:

requester       address that may submit this quote
serviceId       service instance receiving the job
jobIndex        named job within the service
price           quoted amount in the protocol's payment unit
timestamp       time the quote was created
expiry          last time the quote may be used
confidentiality whether the quote requires confidential handling
inputsHash      digest of the job inputs

The public Tangle pricing and payments guide describes this binding, and the Tangle types library is the source for the current Solidity representation.

The quote is signed with Ethereum Improvement Proposal 712 (EIP-712), the typed structured-data signing standard. EIP-712 makes the signed fields explicit and binds signing to a domain, such as a chain and verifying contract. That binding helps prevent a quote meant for one contract or network from being replayed in another.

The signature does not contain the plaintext document. inputsHash is a digest that lets the contract check that the quote covers the input commitment the requester submits. A digest does not recover the original document, but a poorly chosen input encoding can still create ambiguity. Define canonical encoding before hashing.

The operator’s signed object is conceptually:

{
  "operator": "0xOperatorA",
  "details": {
    "requester": "0xRequester",
    "serviceId": 42,
    "jobIndex": 3,
    "price": "3000000000000000",
    "timestamp": 1785751200,
    "expiry": 1785751800,
    "confidentiality": true,
    "inputsHash": "0x<canonical-input-digest>"
  },
  "signature": "0x<eip712-signature>"
}

The numbers and addresses are examples. Do not copy them into production without checking the current contract, chain, and service configuration.

What the contract checks

The contract checks the quote before it accepts payment and job state. The current documented checks include:

1. The quote’s requester is the caller, rather than a wildcard or zero address.
2. The service ID and job index match the call.
3. The quote has not expired and is not too old.
4. The signature recovers to the stated operator.
5. The quote has not already been used.
6. The operator is active and eligible for the service.
7. Operators are not duplicated in the quote set.
8. The submitted payment matches the quoted price requirements.

The requester binding closes an authorization hole. If an operator signed a quote for one requester and another caller could submit it, the signature would prove a price but not who was authorized to use it. Binding the requester makes the quote a commitment to a specific caller.

The input digest closes a different hole. Without it, an operator could quote one workload and later claim the same signature covered a more expensive or more sensitive one.

Timestamp and expiry do different jobs. Expiry limits how long the offer can be used. A maximum quote age rejects a quote that has a generous future expiry but was signed too long ago.

Why only quoted operators can submit results

The contract records the operator set for the RFQ call and checks that the sender belongs to it before it accepts a result.

That gate blocks a free-rider outcome. An unquoted operator cannot watch a profitable job, do the work afterward, and submit a result for the quoted payment. The payment and the identity commitment stay connected.

It also clarifies failure attribution. If A and B were the quoted operators, an unrelated C cannot claim it completed the call. The trace can distinguish “quoted but did not submit,” “quoted and submitted a result,” and “not authorized for this call.”

This is an identity and payment rule, not a correctness proof. A quoted operator can still run the wrong model, return an invalid result, or fail to finish. The Blueprint must define the result checks that address those cases.

RFQ does not replace result verification

Consider three verification policies for the embedding job:

Job property	Possible verification	What it proves
Deterministic encoding	Recompute and compare	The output matches the deterministic function
Protected private inference	Check TEE attestation and measurement	The approved workload ran in an accepted environment
Model quality	Schema, thresholds, or human review	The selected evaluation conditions passed

An attestation can be part of the evidence, but it does not prove a language model’s answer is useful. A schema evaluation can pass while the summary is factually wrong. Redundant operators can agree on the same bug.

The service’s published verification policy should say which result failures are retryable, refundable, or slashable. Those outcomes are not interchangeable.

From quote to payment

The on-chain flow is roughly:

requester asks for quotes
    |
    v
operators sign JobQuoteDetails off-chain
    |
    v
requester submits selected quotes + job inputs + payment
    |
    v
contract validates quotes and records quoted operators
    |
    v
quoted operators execute through the Blueprint runtime
    |
    v
contract accepts only quoted-operator results
    |
    v
service verification and payment finalization

A signed quote is not an on-chain transaction. It becomes an on-chain commitment when the requester submits it and the contract accepts it. Quote collection stays cheap, and job creation still has a checkable commitment.

The public Tangle pricing documentation distinguishes service-level RFQ from job-level RFQ. This article covers job quotes, because the job-specific identity, price, and input binding are the useful accountability mechanism for a single request.

The sample price calculation

Suppose the selected quotes are A at 0.003 ETH and B at 0.0025 ETH. If both operators must submit, the caller funds the configured total:

quoted payment = 0.003 ETH + 0.0025 ETH
               = 0.0055 ETH

The contract’s payment check is the authority, not a client-side suggestion. The client should compute the expected total and compare it with the contract’s required value before submitting.

Selecting only A makes the payment and accountability set smaller. Two operators buy a second execution path at an explicit price.

Quotes also cost the operator capacity. A short expiry improves price freshness but raises quote churn. A long expiry improves conversion but exposes the operator to changed compute, gas, or token conditions.

Slashing is a process, not a button

Slashing reduces an operator’s stake when the service’s rules and enforcement path establish a defined violation. It should answer four questions:

1. What did the operator promise?
2. What evidence shows the promise was broken?
3. Who is authorized to propose or execute the consequence?
4. How can the operator challenge an incorrect proposal?

For an RFQ job, the quote makes the first question precise. The operator accepted a particular job identity, input commitment, price, and time window. It does not answer the other three.

Possible evidence includes a missing result after the deadline, an invalid deterministic output, a failed attestation policy, or a protocol record showing an unauthorized state transition. The service must define which evidence counts.

An evaluator report that says “the summary was poor” may justify a product retry, not a slash. An invalid cryptographic proof is a narrower and stronger failure.

The Tangle slashing lifecycle separates proposal, dispute, execution, and cancellation. Dispute periods exist because on-chain evidence can be incomplete, clocks can differ, and service owners can be wrong. The effective duration and authority are deployment configuration. Read the current contract and network settings rather than copying a duration from an older article.

A trace for the selected quote

Keep a redacted trace that the requester, operator, and dispute process can all use:

trace: tr_rfq_42_17
requester: 0xRequester
service_id: 42
job_index: 3
inputs_hash: 0x<digest>
selected_operators: [0xOperatorA, 0xOperatorB]
quoted_prices: [0.003 ETH, 0.0025 ETH]
quote_expiry: 2026-08-03T12:10:00Z
on_chain_call: <transaction-reference>
results: operator_a_submitted, operator_b_timeout
evaluation: attestation_passed, output_check_pending
dispute_state: none

The trace should not publish the private input merely because the quote is public. The input digest, confidentiality flag, and access policy tell a reviewer what can be inspected.

Failure cases and recovery

A quote expires while the requester is submitting. Ask for fresh quotes and submit a new call. Do not extend the old quote off-chain and assume the contract will accept it.

The quoted operator loses capacity. The job cannot silently move to an unquoted operator if the RFQ gate works as designed. The recovery path is a retry with a new quote set or the service’s defined failure process.

The input digest was computed over non-canonical JavaScript Object Notation (JSON). Two systems can hash visually equivalent inputs differently. Define canonical serialization and test it across the requester and operator implementations.

A quote is valid but the result is wrong. Run the job-specific verification or evaluation. The signature itself is not a correctness proof.

A non-quoted operator submits a result. The contract should reject it. Record the attempt in operational monitoring, but do not pay it.

A slash proposal is wrong. Use the configured dispute process, preserve the original quote and job trace, and distinguish an unavailable operator from a proven protocol violation.

The RFQ price is in a native unit while the user budgets in USD Coin (USDC). Show the current conversion and expiry to the requester before signing. Do not treat a stale exchange rate as a fixed guarantee.

RFQ versus x402

Use x402 when an agent needs a fast HTTP capability and any eligible backend can handle a stateless request. Use RFQ when the requester needs named operators to commit to a specific job and price before execution.

What matters is which trust question each mechanism answers.

Question	x402	Job RFQ
How does the client learn the price?	HTTP payment requirements	Signed operator quotes
Who is committed to the job?	Service endpoint and its routing policy	The quoted operator set
Where is the commitment checked?	Payment verification and settlement path	On-chain quote validation
What prevents duplicate use?	Payment-scheme and gateway replay rules	Quote digest and contract replay rules
What proves correctness?	Separate service verification	Separate Blueprint verification

An application can use x402 to pay for an RFQ-selected job, but it needs an explicit mapping between the HTTP payment and the on-chain call. The two paths do not reconcile automatically.

The x402 payments guide explains the HTTP payment lifecycle. The operator economics guide explains how a service fee is allocated after payment enters the on-chain path.

When RFQ earns its cost

Choose job RFQ when operator identity, price commitment, input binding, and result-submission authority matter enough to pay the on-chain coordination cost. Choose ordinary job submission when any eligible operator can execute and the service has a different accountability model. Choose x402 for request-level payment discovery when operator selection can stay behind the HTTP service boundary.

The strongest RFQ claim is precise: “These operators signed this price and input commitment, this requester submitted the quotes before expiry, and only those operators could submit the result.” Add attestation, proofs, or evaluations only when the service collects and checks them.

What is an on-chain compute quote?

It is a signed operator commitment to perform a particular job for a particular requester at a particular price and within a particular time window. The requester submits it on-chain so the contract can validate and bind it to the job.

Can an operator change its price after signing?

Not for the accepted quote. The requester either submits the signed price before it expires or asks for a new quote.

Why bind the quote to the requester?

It prevents another caller from reusing a valid signature that was intended for a different requester.

Can an unquoted operator submit a result?

Not for an RFQ call whose quoted-operator gate is enforced. The contract records the quoted set and rejects other result submitters.

Does an RFQ quote prove that an AI result is correct?

No. It proves a signed commitment about identity, job, input, price, and timing. Correctness needs a separate verification or evaluation mechanism.

Is slashing automatic when an operator misses a job?

A timeout alone does not establish a slashable violation. The service’s configured evidence, authority, and dispute process determine whether a failure can become a slash.

Public sources

The Tangle pricing and payments guide documents job RFQ fields, expiry, replay protection, requester binding, and quoted-operator result rules. The Tangle slashing guide documents the evidence, authorization, dispute, and execution lifecycle. The Tangle types define the on-chain quote structures. EIP-712 defines typed structured-data signing. The Tangle Blueprint SDK contains the public runtime and job integration.

Decision

Use an on-chain RFQ when the requester needs the chosen provider, price, input commitment, and expiry bound before a job is submitted. Choose ordinary job submission when any eligible provider can execute and separate evaluation or dispute rules provide the accountability. For the operational signals that decide whether a quoted provider should keep accepting work, see operator operations, metrics, quotes, and health.