Summary

A capacity oracle is a mechanism that allows a blockchain protocol to learn the true aggregate computational capacity of a decentralized set of suppliers — without trusting any single party. This is a prerequisite for the “delegation-verification” paradigm (ZK proving, TEE inference, AI on-chain) where the protocol needs reliability guarantees before users commit. Bahrani & Neuder (Apr 2026) model this as a mechanism design problem and show that random audits with convex reward functions achieve perfect capacity oracles at ~20% overhead, even under Sybil attacks.

Motivation

As blockchains evolve from “every node re-executes everything” toward specialized provers (ZK-EVMs, AI inference, TEE attestation), users must decide whether the network has sufficient capacity for their workload. The challenge: only the post-hoc view of what was executed signals capacity; the protocol cannot observe how much additional capacity is available. Capacity oracles solve this by designing the procurement mechanism to elicit truthful capacity reports.

Model

  • n suppliers, each with private capacity c_i and public unit cost (normalized to 1)
  • Suppliers bid b_i (claimed capacity) and receive allocation x_i(b) with probability ε (random audit)
  • Suppliers deliver up to their true capacity d_i ≤ c_i
  • Payment rule p_i(b, d) creates incentives
  • A perfect oracle aggregates bids/deliveries to recover Σ c_i

The protocol can generate synthetic work (“fake ZK puzzles”) to audit suppliers at any time.

Key Results

Naïve Mechanism (No Sybils): Works Perfectly

A simple random audit with monotone reward r(b_i) achieves truthful bidding as a dominant strategy — small ε makes it nearly free. But with Sybil attacks (unlimited identities), this collapses: a supplier splits into many identities and concentrates reward with negligible slash risk.

Correlated Payments: Sybil-Proof but Fragile

Allocate everyone or no one simultaneously (ε^n probability). Sybil attack fails (overreporting means getting allocated more than you can deliver). But this creates a griefing vector: one malicious supplier can guarantee nobody gets paid.

Staking + Slashing: Practical Solution

Adding stake S (fully slashed for under-delivery) with convex reward r(b_i) = b_i^p, p > 1 is the practical approach:

  1. Linear rewards are still Sybil-vulnerable: for any finite S, suppliers can create many tiny identities that rarely get allocated (avoiding slash), while collectively overreporting. Splitting makes variance → 0 while mean profit exceeds honest baseline.

  2. Convex rewards stop splitting: r(c_i) > 2r(c_i/2) by convexity — a single identity bidding the full capacity earns more than two halves. This discourages Sybil splitting directly.

Optimal Parameters (Numerical)

For p = 2 (quadratic reward) and stake S = 8× unit cost:

  • Protocol cost ≈ 20% of total capacity — pays 20 cents per dollar of capacity to maintain a perfect oracle
  • S ≈ 10× is a sweet spot: meaningful protection without excessive capital requirements
  • p ≈ 1.5 provides most of the convexity benefit with lower centralization pressure (convex functions favor large suppliers)

Key Practical Insights

  1. Some slashing is essential: without it, protocol cost approaches 100% (trivial oracle)
  2. Low curvature suffices: p ≈ 1.5 dramatically reduces protocol cost vs. p = 1
  3. Minimum bid helps: prevents infinite subdivision attacks at the margin
  4. Partial correlation is beneficial: if you can correlate some payments (e.g., “pay nobody if <50% of allocated work is delivered”) without full correlation, you tighten the oracle at lower griefing risk

Application Context

This problem is directly relevant to:

  • ZK proving markets: knowing whether enough provers exist to handle a given block size
  • AI inference on-chain (e.g., Ritual): deciding whether to use on-chain inference vs. centralized cloud
  • TEE attestation networks: understanding capacity before committing a workload

Open Questions

  • How does the model extend to heterogeneous resources (GPU vs. CPU vs. FPGA)?
  • Can partial-fulfillment penalties (proportional slashing) achieve better outcomes than all-or-nothing?
  • How do correlated capacity constraints interact when multiple suppliers share infrastructure?

Key Sources

  • Capacity oracles (Bahrani & Neuder, Apr 2026) — full model; Sybil analysis; numerical results; 20% optimal overhead