On-Chain RFQ for Compute: How Job Quotes, Verification, and Slashing Work

A Real RFQ Protocol for Compute

Most compute marketplaces work on reputation and hope. You pick a provider, they quote you a price, you send payment, and you trust that what comes back is correct. If the provider runs your ML inference on a cheaper GPU, serves stale results from a cache, or quietly degrades quality during peak load, you probably won’t know. The provider keeps your money either way.

On-chain RFQ (Request for Quote) protocols solve this by enforcing accountability at three layers. Quotes become EIP-712 cryptographic commitments: signed structs with price, expiry, and job parameters that are tamper-proof, time-bounded to 5 minutes, and single-use once submitted on-chain. Results pass through composable verification: redundant multi-operator execution with quorum agreement, on-chain correctness hooks, TEE hardware attestation, and domain-specific checks like canary prompts for AI inference. Operators stake collateral (for example, $50,000) that gets algorithmically slashed when verification fails, making cheating unprofitable whenever P(detection) x slash_amount exceeds the profit from cutting corners.

Tangle’s Blueprint SDK implements this full pipeline. Prices aren’t posted on a dashboard; they’re signed and verified on-chain. Results aren’t accepted on faith; they’re checked through mechanisms that blueprint developers wire in declaratively. And when operators don’t deliver what they promised, they lose real money from their staked collateral. The penalty is financial loss enforced by smart contracts, not a bad review or a platform ban.

This post breaks down how all three layers work: the RFQ protocol, verification, and slashing. The design decisions at each layer solve real problems that simpler approaches get wrong.

The RFQ Protocol: Two Quoting Modes

Traditional RFQ workflows follow a pattern: buyer requests a quote, seller returns a binding price, buyer accepts. On-chain RFQ protocols add cryptographic binding to this flow, making every quote independently verifiable before the buyer commits money. Tangle implements two distinct RFQ modes, and understanding why they’re separate matters.

Service Creation Quotes: Resource-Based Pricing

When a consumer wants to spin up an entire service instance (a long-running deployment with a defined TTL), they request a quote via GetPrice. The operator’s pricing engine computes cost from hardware benchmarks multiplied by configured resource rates.

The formula is concrete. Here’s what the operator configures:

# default_pricing.toml
[default]
resources = [
  { kind = "CPU", count = 1, price_per_unit_rate = 0.001 },
  { kind = "MemoryMB", count = 1024, price_per_unit_rate = 0.00005 },
  { kind = "GPU", count = 1, price_per_unit_rate = 0.005 },
]

And here’s what happens with real numbers: 4 CPU cores at $0.001/core/sec, running for 600 blocks at 6 seconds per block, comes out to $14.40. USD prices get scaled to on-chain units via a 10^9 factor, so $1 becomes 1,000,000,000 on-chain units. The consumer submits this on-chain via createServiceFromQuotes(blueprintId, [signedQuotes], config, callers, ttl).

Per-Job Quotes: Operator-Determined Pricing

The second mode is simpler but has a different purpose. When a consumer wants to execute a single job on an existing service, they request a GetJobPrice quote. This isn’t computed from resource rates. It’s a lookup table the operator maintains:

# job_pricing.toml
[1]
0 = "1000000000000000"       # Job 0: 0.001 ETH
7 = "250000000000000000"     # Job 7: 0.25 ETH

Prices are in wei because these quotes go directly on-chain in native currency. No conversion layer, no oracle dependency. The consumer submits via submitJobFromQuote(serviceId, jobIndex, inputs, [signedQuotes]).

Why Two RFQ Modes Matter

The distinction isn’t arbitrary. Service quotes price infrastructure: how much does it cost to keep these resources allocated for this duration? Job quotes price work: how much does this specific computation cost to execute? An operator running a GPU cluster might charge $50/hour for the service but $0.01 per inference job. These are fundamentally different pricing questions with different cost structures.

Cryptographic Quote Binding

Here’s where on-chain RFQ diverges from traditional quoting. Both quote types use EIP-712 typed signatures, the same standard used for typed data signing across Ethereum. A job quote signature covers this struct:

JobQuoteDetails {
    service_id: uint64,
    job_index: uint8,
    price: uint256,
    timestamp: uint64,
    expiry: uint64,
}

The domain separator pins the signature to name: "TangleQuote", version: "1", the specific chain ID, and the verifying contract address. This means a quote signed for testnet can’t be replayed on mainnet. A quote for one contract can’t be submitted to another.

Default validity is 300 seconds, and there’s a hard on-chain maxQuoteAge limit of 1 hour. After submission, each quote digest gets marked as consumed on-chain, which prevents replay.

This is what makes dynamic pricing safe in a trustless environment. An operator can update prices every minute without worrying that a consumer will hoard old quotes. Every quote is tamper-proof (the signature breaks if any field changes), time-bounded (expires after 5 minutes by default), and single-use (the digest gets burned on submission). Compare this to a traditional API where “pricing” means trusting whatever the server’s /pricing endpoint returns right now.

Signing a quote in code looks like this:

use blueprint_tangle_extra::job_quote::{JobQuoteSigner, JobQuoteDetails, QuoteSigningDomain};

let signer = JobQuoteSigner::new(keypair, QuoteSigningDomain { chain_id, verifying_contract });
let signed = signer.sign_job_quote(&JobQuoteDetails {
    service_id: 1,
    job_index: 7u8,
    price: U256::from(250_000_000_000_000_000u64), // 0.25 ETH
    timestamp: now,
    expiry: now + 3600,
});

Anti-Abuse on the RFQ Channel

Quote requests themselves are gated by a SHA-256 proof-of-work challenge: 20 leading zero bits, roughly a million hashes. On commodity hardware that takes less than a second, but it makes flooding an operator’s gRPC endpoint with junk requests expensive. The timestamp has a +/-30 second tolerance window that prevents pre-computing challenges in advance.

When Quotes Become Payments: The Token Conversion Pipeline

For operators accepting stablecoin payments (common in the x402 flow), quoted wei amounts need to convert to token amounts. This four-step pipeline uses rust_decimal throughout, with zero floating-point arithmetic:

1. Wei to native units: divide by 10^18
2. Native to token amount: multiply by a configured rate_per_native_unit
3. Apply markup: multiply by (1 + markup_bps / 10000)
4. Convert to smallest token units: multiply by 10^decimals, floor the result

Concrete example: 0.25 ETH at a rate of 3200 USDC/ETH with 50 basis points markup gives you 0.25 x 3200 x 1.005 x 10^6 = 804,000,000 micro-USDC.

One deliberate design tradeoff here: exchange rates are static operator config, not oracle-fed. No oracle dependency means no oracle manipulation risk and no extra gas cost, but operators need to manage their own rate refresh. For operators processing high volume, this is a knob they’ll want to automate externally.

Result Verification: Composable Mechanisms per Job Type

A consumer paid for a computation. How do they know the result is correct? Rather than picking one verification strategy and forcing it on every workload, an on-chain RFQ system can provide composable verification, where blueprint developers choose the mechanisms that match their job type. Tangle’s Blueprint SDK implements five such mechanisms.

Redundant Execution

The simplest approach: have N operators run the same job independently, then compare results. The router configuration maps each job ID to a handler with a TangleLayer, and you can set different aggregation quorums per job:

pub const XSQUARE_JOB_ID: u8 = 0;     // Single operator
pub const VERIFIED_JOB_ID: u8 = 1;     // 2 operators must agree
pub const CONSENSUS_JOB_ID: u8 = 2;    // 3 operators (BFT quorum)

Router::new()
    .route(XSQUARE_JOB_ID, square.layer(TangleLayer))
    .route(VERIFIED_JOB_ID, verified_square.layer(TangleLayer))
    .route(CONSENSUS_JOB_ID, consensus_square.layer(TangleLayer))

This works well for deterministic computations. If all three operators run the same function on the same input and two return 49 while one returns 50, you have a clear disagreement signal.

On-Chain Verification Hooks

For jobs where correctness is cheaply checkable (even if the computation itself is expensive), blueprint developers can write verification functions:

#[verify(job = 0)]
pub fn verify_square(input: u64, output: u64) -> VerifyResult {
    if output == input * input {
        VerifyResult::Valid
    } else {
        VerifyResult::Invalid { slash: true }  // triggers slashing
    }
}

The #[verify] macro is doing real work here. The blueprint developer writes the correctness check; the SDK handles wiring it into the verification pipeline, calling it at the right time, and routing the result to the slashing contracts if it returns Invalid. The slash: true flag means this isn’t just a “try again” signal. It’s a “you lied and you’re going to pay for it” signal.

This pattern works for any computation where verification is cheaper than execution. Factoring a large number is expensive; multiplying two primes to check the result is cheap. Training a model is expensive; running inference on a known test set to check accuracy is cheap.

TEE Attestation

For confidential workloads, hardware-level attestation (Intel SGX, AMD SEV-SNP) provides cryptographic proof signed by the chip manufacturer that specific code is running in an enclave. This proves code identity and guarantees the operator can’t observe the computation.

Important caveat: TEE attestation proves what code ran, not that the code is correct. It’s a complement to other verification mechanisms, not a replacement.

AI Inference Verification

Model serving has a specific attack vector: model substitution. An operator advertises GPT-4-class inference but actually runs a cheaper model. Tangle’s approach combines weight hash verification (proving which model file loaded), challenge prompts (canary inputs with known-good outputs), latency fingerprinting (smaller models respond faster), and token probability extraction.

Verification Mechanism Comparison

Mechanism	What it proves	Failure mode	Best for
Redundant execution	Result consistency across operators	Non-deterministic outputs produce false disagreements	Deterministic compute (math, compilation, hashing)
On-chain verify hooks	Output correctness (cheaply checkable)	Only works when verification cost is much less than execution cost	Asymmetric problems (factoring, optimization, search)
TEE attestation	Code identity and confidentiality	Hardware compromise; proves code identity, not correctness	Confidential workloads, private data processing
AI inference checks	Model identity and output quality	Sophisticated operators can detect and special-case canaries	ML model serving, LLM inference
Redundant + verify (combined)	Consistency and correctness	Higher cost from running multiple operators	High-value deterministic jobs

Why Layering Matters

No single mechanism covers every case. Redundant execution doesn’t work for non-deterministic workloads. On-chain verification doesn’t work if correctness isn’t cheaply checkable. TEE attestation doesn’t cover result quality. AI-specific checks don’t apply to general compute.

By providing these as composable building blocks, blueprint developers pick the right combination for their specific workload. A deterministic math service might use redundant execution plus an on-chain verify hook. A confidential ML inference service might combine TEE attestation with canary prompts. The mechanisms stack.

Economics as the Universal Backstop

Every verification mechanism has failure modes. Redundant execution fails for non-deterministic outputs. TEE attestation fails if the hardware is compromised. Canary prompts fail if the operator detects and special-cases them.

Economics is the catch-all: make cheating unprofitable regardless of the specific detection mechanism.

The equation is straightforward:

With real numbers: suppose an operator could save $5,000 by running a cheaper model. If the detection probability is 80% and their stake is $50,000, the expected loss from cheating is 0.80 x $50,000 = $40,000. The expected gain from going undetected is 0.20 x $5,000 = $1,000. A rational operator won’t take that bet.

How This Compares to Other Accountability Models

Stake-based slashing isn’t the only approach to operator accountability, and each alternative makes different tradeoffs. Reputation systems (used by most centralized cloud marketplaces) are cheap and simple, but a malicious operator can build reputation with honest behavior and exploit it later, and reputation scores aren’t enforceable on-chain. Escrow models hold payment until delivery confirmation, but they require a trusted arbiter to resolve disputes and don’t impose penalties beyond withholding payment, so the operator’s downside is capped at the job revenue. Optimistic fraud proofs (used by Optimism and Arbitrum for rollup verification) assume results are correct unless challenged within a window, which is gas-efficient, but detection depends entirely on external watchers submitting challenges in time. Stake-based slashing is more capital-intensive for operators, but it provides the strongest deterrent: the penalty for cheating scales with the operator’s total stake, not just the value of one job.

The combination of technical verification and economic enforcement is more robust than either alone. The known gaps: irrational actors might cheat anyway (which is why verification mechanisms exist as the first line of defense), and subtle quality degradation (serving a slightly worse model, returning slightly stale results) might lower P(detection) enough to shift the equation.

When Operators Don’t Deliver: Two Speeds of Slashing

When an on-chain RFQ system detects that an operator failed to deliver against their quoted commitment, the response needs to be proportionate to the system’s maturity. Tangle integrates with EigenLayer’s slashing infrastructure and provides two contract models that map to this spectrum.

InstantSlasher

Immediate execution, no delay, no veto. When the slashing condition triggers, the operator’s stake gets cut in the same transaction:

function fulfillSlashingRequest(
    IAllocationManager.SlashingParams calldata _slashingParams
) external onlySlasher

This calls through to AllocationManager.slashOperator() directly. Maximum deterrence. Appropriate for mature blueprints with well-understood slashing conditions where the verification logic has been thoroughly audited and false positives are unlikely.

VetoableSlasher

Queued execution with a configurable veto window. A designated veto committee can cancel during the window:

function queueSlashingRequest(
    IAllocationManager.SlashingParams calldata params
) external onlySlasher

Slashing requests go through a lifecycle: Requested -> Cancelled | Completed. This exists because newer blueprints might have bugs in their verification logic. A false positive in a verify hook triggering an instant slash of $50,000 would be catastrophic. The veto window gives humans a chance to review before collateral gets destroyed.

The progression from VetoableSlasher to InstantSlasher maps to trust accumulation. A new blueprint starts with veto protection. As the verification logic proves itself over months of operation without false positives, the blueprint can migrate to instant slashing for stronger deterrence.

Runtime Monitoring

The SlashingMonitor component polls every 5 minutes, checking is_operator_slashed() and logging CRITICAL: Operator has been slashed! on detection. It can also query getSlashableSharesInQueue(operator, strategy) to show collateral currently at risk. Deregistered operators get treated as potentially slashed.

The x402 Timing Detail

In the x402 payment flow, settlement happens before execution via .settle_before_execution(). The operator gets paid, then does the work. This means if the operator fails to deliver, the consumer has already paid. The slashing mechanism is what makes this safe: the operator’s staked collateral is worth far more than any single job payment, so failing to deliver after collecting payment is a losing strategy.

The Full RFQ-to-Settlement Pipeline

Start to finish, here’s how the system flows:

1. Consumer requests a quote via the RFQ protocol. The operator’s pricing engine returns a signed EIP-712 commitment with a 5-minute expiry.
2. Consumer verifies the signature independently, confirms the price, and submits the quote on-chain with payment.
3. The on-chain contract checks the signature, confirms the quote isn’t expired or replayed, and marks the digest as consumed.
4. The operator executes the job. Settlement happened before execution; the operator already has the payment.
5. Verification kicks in: redundant execution compares results across operators, verify hooks check correctness on-chain, TEE attestation confirms code identity, or domain-specific checks (canaries, weight hashes) validate quality.
6. If verification fails, the verify hook returns VerifyResult::Invalid { slash: true }, triggering the slashing contract.
7. The slashing contract (instant or vetoable) reduces the operator’s staked collateral.

Each layer reinforces the others. Cryptographic quotes prevent price manipulation. Settlement-before-execution prevents operators from doing free work. Verification catches incorrect results. Slashing makes incorrect results expensive. And the P(detection) x slash_amount > profit equation is what makes the whole system safe to use without trusting any individual operator.

FAQ

Can an operator change their prices after I’ve received a quote?

Your quote is locked. It’s a signed commitment with a fixed price and expiry. The operator can update their pricing config every second; your quote remains valid at the agreed price until it expires. Once submitted on-chain, the digest is marked as consumed, preventing reuse by anyone.

What happens if operators disagree during redundant execution?

The quorum configuration determines the outcome. In a 2-of-3 setup, two matching results win and the dissenting operator’s result is flagged. The disagreement signal can feed into the slashing pipeline, though the specifics of dispute resolution for edge cases are still being formalized in the protocol.

Why are exchange rates static config instead of oracle-fed?

Static rates eliminate oracle manipulation risk, extra gas costs, and dependency on third-party infrastructure. The tradeoff is that operators need to refresh rates themselves. For high-volume operators, this likely means an external automation script updating the config periodically.

If the operator gets paid before doing the work, what protects the consumer?

The operator’s staked collateral, which dwarfs any single job payment. An operator with $50,000 staked isn’t going to pocket a $0.25 job payment and skip execution, because failing verification triggers a slash worth orders of magnitude more. The stake-to-payment ratio is what makes settlement-before-execution safe.

Can I use multiple verification mechanisms on the same job?

Yes, and they compose additively. A confidential ML inference blueprint might use TEE attestation (proving the right model loaded in an enclave), canary prompts (checking output quality), and redundant execution (comparing results across operators). Each mechanism covers different failure modes, reducing the overall probability that a bad result goes undetected.

---

Build with Tangle | Website | GitHub | Discord | Telegram | X/Twitter