You have three independent service providers that can run the same job. For a sample quote, one says the work will cost 0.004 ETH, Ethereum’s native token, another says 0.005 ETH, and the third sample quote says 0.0035 ETH. You choose the third quote, send the job, and wait. The buyer needs the selected provider to stay bound to the job and the quoted amount to stay tied to the request.
An RFQ, short for request for quote, turns that conversation into a set of signed facts. Tangle is a protocol for registering and coordinating services that are run by independent operators. The requester identifies the job and its inputs. An operator is the provider that signs a price and an expiry for that exact request. The Tangle contracts check those facts when the job is submitted and when a result is paid. The signature does not prove that the computation is correct, but it makes the economic and identity claims testable.
This distinction matters for agent services. An agent can select a provider by comparing signed quotes returned for the same request, but a buyer still needs to know which provider accepted the work, what the provider promised to charge, and what happens if the provider disappears. An RFQ supplies those bindings without pretending that a signature is a quality guarantee.
Quote fields and their on-chain bindings
A Blueprint is the deployable service definition that tells Tangle what jobs exist, how they are called, and what evidence or payment rules apply. An operator is the person or service that runs an instance of that Blueprint and takes responsibility for responding to jobs. A service instance is one registered deployment, identified on-chain by a service ID. A job index is the number assigned to one callable operation inside that service.
The requester is the account asking for the job. The request includes the service ID, job index, and inputs. A quote is an operator’s signed offer for that particular job. The quote contains a price and time bounds, but it also carries the identity of the requester and a hash of the inputs. The confidentiality field states which execution boundary the requester requires; it records intent, not proof that the work ran privately.
The inputs hash is a fixed-length fingerprint of the exact bytes the requester says should be processed. It is not the input itself. Anyone can recompute the fingerprint from the agreed serialization and check whether it matches, while sensitive inputs can remain out of the public transaction.
Tangle’s current public type defines the quote details as follows:
struct JobQuoteDetails {
address requester;
uint64 serviceId;
uint8 jobIndex;
uint256 price;
uint64 timestamp;
uint64 expiry;
uint8 confidentiality;
bytes32 inputsHash;
}The field names and types above come from the public TNT Core contract. The contract source is the authority for the encoding, while the Tangle pricing and payments guide explains the user-facing flow.
What the signature binds
An operator signs the quote details with EIP-712. EIP-712 is an Ethereum standard for signing structured data with a domain that identifies the intended contract and network. It makes a wallet prompt easier to inspect than an opaque blob and prevents a signature from being valid in an unrelated domain. The EIP-712 specification describes the standard encoding.
The signature says, in effect:
This operator key offers this requester this job, for this input fingerprint, at this price, during this time interval, under this confidentiality setting.
That sentence is a useful mental model, but it is not a substitute for checking the encoded fields. The contract still needs to recover the signer, compare the requester to the caller, validate the service and job, reject an expired quote, and ensure that the payment matches the selected prices.
A signed quote does not say that the operator has enough capacity. It does not say that the result will be accurate. It does not say that the input serialization was meaningful. It says that a particular key signed a particular offer, and the protocol can use that fact when deciding who may act next.
How a signed quote reaches result submission
Consider Alice, who needs a document-extraction job. Her client serializes the document reference and extraction options, computes the input fingerprint, and asks several operators for prices. The operators can calculate prices locally because the request contains the information they need, while the sensitive document can remain outside the quote response.
In this sample, Operator A returns a signed offer for 0.004 ETH that expires at 12:05. In this sample, Operator B returns a signed offer for 0.005 ETH that expires at 12:10. Alice selects Operator A at 12:01. Her transaction supplies the selected quote and the exact payment amount.
The important checks happen at the boundary between those steps:
| Boundary | What must match | Why it matters |
|---|---|---|
| Quote creation | Service, job, requester, input fingerprint, price, and time bounds | A price for one request cannot be reused as a price for another |
| Quote submission | Recovered signer is an active operator for the service | The protocol knows which operator made the offer |
| Caller binding | Quote requester equals the transaction sender | A stranger cannot submit a quote made for Alice |
| Payment | Transaction value equals the sum of selected quote prices | The contract does not silently substitute a different amount |
| Result submission | The submitting operator was quoted for this job | An unselected operator cannot free-ride on the payment |
| Settlement | The job reaches its configured completion or failure path | Payment and service outcome remain separate facts |
The caller binding is easy to overlook. The current type includes requester as a first-class signed field, and the contract rejects a zero requester and requires it to equal the caller. That prevents a valid signature from being lifted out of one user’s request and attached to another user’s transaction.
The input fingerprint provides a second binding. If the client changes the model, document, or options after asking for a quote, the new bytes should produce a new fingerprint and therefore require a new quote. That is the desired failure. Silently reusing the old price for materially different work would make the quote look precise while pricing the wrong job.
Payment is also exact at submission. For multiple selected operators, the transaction value must equal the sum of their quote prices. The submitted value must equal the displayed quote total and the amount escrowed.
Why the result check is the accountability mechanism
It is tempting to describe RFQ as a pricing feature. The result check enforces which quoted operator may claim the job payment.
Once a job has been created from quotes, Tangle records which operators were quoted for that job. When an operator submits a result, the jobs submission contract validates that relationship. The current public implementation rejects an operator that was not quoted for the job with a NotQuotedOperator error. The rejected operator may have the right service, a good reputation, and a plausible result; those facts do not authorize it to claim this job’s payment.
This prevents a free-rider pattern:
- Operator A spends time answering the RFQ.
- Operator B watches the public job and computes a result more cheaply.
- Operator B submits first and tries to receive the payment.
Without an identity check at result submission, the quote would describe an intention rather than an enforceable assignment. With the check, the protocol can distinguish a quoted operator that failed to deliver from an unrelated operator that was never selected.
The check has a deliberate limitation. It authenticates the responsible operator; it does not evaluate the content of the result. A document extractor can return a syntactically valid but incorrect answer. An operator can submit the wrong model version while still being the quoted key. Quality requires a separate verification method, such as a deterministic check, a quorum, a challenge, a test vector, or a dispute process that can evaluate evidence.
Time, replay, and stale prices
A quote has a timestamp and an expiry. The timestamp gives the protocol an age to check. The expiry gives the requester a latest acceptable execution time. Both are needed because a quote can be valid according to its own expiry while still being too old for the service’s current risk policy.
The pricing engine documentation describes quote TTL and expiry as security controls. The service can also enforce a maximum quote age. That means an operator cannot keep one signed price alive indefinitely merely because the original expiry was generous.
The job submission path must reject a quote signature reused for duplicate work or duplicate payment. The exact replay key belongs to the deployed contract version, so production clients should use the public contract and ABI for the target network rather than reimplementing the rule from memory.
Clock handling deserves a concrete policy. If a client clock is two minutes fast, it may discard a quote that the chain would accept. If it is two minutes slow, it may present a quote that is already too old. Use the chain’s observed time for final decisions, allow a small measured skew, and display the quote expiry to the user in the same timezone as the request.
What happens when an operator fails
Tangle’s slashing system is a proposal and dispute process, not an automatic punishment attached to every missed request. An authorized party proposes a slashing case with evidence. The operator can dispute it. After the dispute period, an eligible proposal can execute, or it can be cancelled according to the contract rules. The public slashing documentation describes those stages and the evidence requirements.
The current network documentation lists a seven-day default dispute window, or 604800 seconds, with a configurable range from one hour to thirty days. That is a network default, not a promise that every deployment uses the same value. Read the active service and network configuration before telling a customer that a case will resolve in seven days. The operator’s seven-day dispute window is separate from the default 14-day deadline for an administrator to resolve a dispute after it is filed.
The distinction between a result check and slashing is important:
| Event | Immediate protocol fact | What still requires separate handling |
|---|---|---|
| Unquoted operator submits | The submission is rejected | Nothing is paid to that operator |
| Quoted operator misses a deadline | The job can remain incomplete or enter its failure path | Someone must gather evidence and propose a case if slashing is appropriate |
| Quoted operator submits a wrong result | The operator identity check can still pass | An independent checker or dispute process must establish that the result was wrong |
| Payment settles but the client times out | The payment record and job outcome may diverge | The client needs idempotent status lookup and a refund or dispute policy |
This is why “signed quote” should not be advertised as “guaranteed result.” The signature gives the system a clean starting point for attribution. Accountability still depends on evidence, authority, timing, and the rules of the active deployment.
RFQ and x402 solve different boundaries
x402 is an HTTP payment flow in which a server responds with payment requirements and a client signs a payment. A facilitator is the service that checks the signed payment and helps complete settlement. Tangle’s x402 gateway verifies and settles the payment before it enqueues a paid job and returns HTTP 202 Accepted, which means accepted for processing rather than completed. The Tangle x402 runner documentation describes that off-chain ingress.
RFQ is useful when the requester needs a signed, on-chain selection of operators and exact job-level price commitments. x402 is useful when the client should pay through HTTP before the gateway enqueues the job. They can coexist when the product keeps HTTP payment and on-chain operator assignment as separate records, but a successful x402 payment alone does not identify an operator in the RFQ sense or prove that the result is correct.
Use RFQ when provider selection and accountable assignment are part of the product. Use x402 when the primary problem is payment at an HTTP boundary. Use both only when the extra state is worth the operational and user-interface complexity.
The on-chain RFQ guide goes deeper into verification and slashing. The x402 payments guide covers the separate HTTP payment path.
Failure cases worth designing before launch
The most common failure is ambiguous input encoding. If two clients hash semantically identical JSON with different whitespace or key ordering, they will produce different fingerprints. Define canonical serialization in the public client contract and test it across languages.
The next is partial capacity. An operator may quote a job and then lose its worker before submission. The product needs a status endpoint, a retry policy that does not accidentally replay payment, and a clearly documented outcome for an unfulfilled quote. Selecting several operators can improve availability, but it also changes the payment total and the result aggregation problem.
Confidentiality is another boundary, not a magic privacy guarantee. The quote records a confidentiality setting and an input fingerprint, but the setting must correspond to an actual execution and data-handling policy. If the service promises confidential execution, document where the input is decrypted, who can observe logs, and what evidence a buyer receives.
Finally, do not make a dispute window the only customer support plan. A dispute can protect stake, but it may take days. Give the client a fast status path, an idempotent request identifier, and a policy for failures that are obvious without on-chain adjudication.
Use RFQ when assignment matters
An RFQ becomes a meaningful accountability primitive when four things are bound together: the requester, the exact job and inputs, the selected operator, and the amount paid. Tangle’s current quote shape makes those bindings explicit, and the result submission check prevents a non-quoted operator from taking over the assignment.
The remaining work is product design. You still need a quality check, a capacity strategy, a dispute evidence plan, and a customer-facing explanation of pending versus completed work. Build those around the protocol’s actual guarantees, and the quote becomes a useful contract between an automated buyer and an independent service operator.
Is an RFQ quote the same as a completed job?
No. A quote is a signed offer. The job still needs to be submitted, paid, executed, and resolved according to its service rules.
Can any operator submit the result?
No. For an RFQ job, the current jobs submission contract rejects an operator that was not included in the quoted assignment.
Does a signature prove the result is correct?
No. It proves that the operator key signed the quote details. Result correctness needs an independent check or dispute procedure.
Is the dispute window always seven days?
No. Seven days is the current documented network default. The active configuration can differ within the supported bounds.
Should I use RFQ or x402?
Choose RFQ when accountable operator selection is central to the job. Choose x402 when you primarily need an HTTP payment boundary. Combine them only after you can explain which layer owns payment, assignment, execution status, and disputes.
For the health and quote-lifetime signals after assignment, see operator health monitoring on Tangle.