You need a graphics processing unit (GPU) job completed by a named operator, the provider responsible for that job, rather than whoever happens to be 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 sending the job, and you want a way to challenge non-delivery later.
That is the problem an on-chain request-for-quote flow solves. It turns an off-chain price conversation into signed data that a contract can check before accepting the job. It also makes a narrower promise than many explanations suggest. The quote proves who priced the work and under what terms; it does not prove that the eventual 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 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. Slashing is not an automatic reaction to a client disliking an answer.
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 is the process that executes that function. 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 is a check against an expected result condition. Verification checks evidence against a rule. For example, verifying an operator’s Ethereum Improvement Proposal 712 (EIP-712) signature is different from evaluating whether a returned model output satisfies a schema.
An x402 payment is an HTTP (Hypertext Transfer Protocol) payment exchange for a resource request. RFQ is an on-chain commitment flow for a chosen operator and job price. They can coexist, but one does not replace 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 can see the job identity, price request, deadline, and input digest, but the plaintext input remains protected according to 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 important fact is that the choice is made before the on-chain job 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 inputsThe public Tangle pricing and payments guide describes this binding, and the public 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 domain binding helps prevent a quote intended for one contract or network from being replayed in another context.
The signature does not contain the plaintext document.
inputsHash is a digest that lets the contract check that the quote covers the same input commitment the requester submits.
A digest is not a way to 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 requester submits the selected signed quotes with the job. The contract checks the quote before accepting payment and job state.
The current documented checks include:
- The quote’s requester is the caller, rather than a wildcard or zero address.
- The service ID and job index match the call.
- The quote has not expired and is not too old.
- The signature recovers to the stated operator.
- The quote has not already been used.
- The operator is active and eligible for the service.
- Operators are not duplicated in the quote set.
- The submitted payment matches the quoted price requirements.
The requester binding closes a subtle 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 for 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 workload.
The timestamp and expiry serve different purposes. Expiry limits how long the offer can be used. A maximum quote age can reject 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. When a result arrives, it checks whether the sender belongs to that set before accepting the result.
That gate prevents a free-rider outcome. An unquoted operator cannot watch a profitable job, perform the work after the fact, and submit a result for the quoted payment. The payment and the identity commitment remain connected.
It also makes failure attribution clearer. 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 finalizationThe quote is not an on-chain transaction when the operator signs it. It becomes an on-chain commitment when the requester submits it and the contract accepts it. That design keeps quote collection cheap while preserving a checkable commitment at the point of job creation.
The public Tangle pricing documentation distinguishes service-level RFQ from job-level RFQ. This article focuses on 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 are required to submit, the caller must fund the configured total:
quoted payment = 0.003 ETH + 0.0025 ETH
= 0.0055 ETHThe exact payment check is contract behavior, not a client-side suggestion. The client should calculate the expected total and compare it with the contract’s required value before submitting.
If only A is selected, the job’s payment and accountability set are smaller. Choosing two operators is not free redundancy; it is an explicit price for an additional execution path.
The quote also has a capacity cost for the operator. Signing a short expiry can improve price freshness while increasing quote churn. Signing a long expiry can improve conversion while exposing 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:
- What did the operator promise?
- What evidence shows the promise was broken?
- Who is authorized to propose or execute the consequence?
- How can the operator challenge an incorrect proposal?
For an RFQ job, a quote can make the first question precise. The operator accepted a particular job identity, input commitment, price, and time window. It does not automatically answer the other three.
Possible evidence might include 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 and may not be strong enough for a slash. An invalid cryptographic proof is a much 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 can be used by the requester, operator, and dispute process:
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: noneThe trace should not publish the private input merely because the quote is public. The input digest, confidentiality flag, and access policy should 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 be handed to an unquoted operator if the RFQ gate is working 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. Do not call the signature itself 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.
The difference is not “off-chain versus on-chain” in the abstract. It is which trust question the 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 on-chain call. Do not imply that the two paths 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 the operator selection can remain 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 public 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.