Games & Graphs

Optimistic Diffusion Claims

Participants include diffusion-derived rewards as bounded, challengeable claims verified by sampling, caps, bonds, and slashing instead of global computation.

Local Protocol allows participants to include diffusion-derived reward outputs inside their transaction SDLs without requiring validators to compute as a global vector.

This uses optimistic verification: claims are accepted subject to a challenge window; incorrect claims are deterred with bonds + slashing and are verifiable via sampling.

Intuition
A user can attach a “this is my bounded reward, relative to the last committed snapshot” claim. Validators don’t compute global diffusion; they enforce caps/bonds and audit a bounded subset.
Related work
Optimistic verification and fraud-proof patterns: Truebit and verifier-incentive discussions like the Arbitrum paper (Kalodner et al., 2018).
Why it fits
Diffusion is expensive globally, but individual claims can be checked with bounded audits. This keeps validator work predictable while shifting compute to provers.

What a user is allowed to claim

A user submitting a transaction SDL may include a reward claim:

The claim is a function of:

  • committed snapshot roots
  • the canonical snapshot artifact identifier (to fetch authenticated snapshot data needed for audits, including MarketRegistry; see Graph Commitments & Epoch Snapshots and Performance & Storage)
  • protocol parameters
  • transaction contents (counterparty, amount, and market context)
  • a protocol-defined estimator (random-walk / Monte Carlo diffusion)

Safety is achieved by combining:

  • strict caps (deterministic safety rails):
    • per-transaction:
    • per-user per-epoch:
    • per-market per-epoch:
    • optional global backstop:
  • canonical randomness (no grinding)
  • priced verification (bounded work)
  • bonds and slashing (negative EV for cheating)
  • delayed sampling (prevents adaptive transcripts)
Why caps matter even with audits
Audits are probabilistic, but caps are deterministic. Even if audits miss something temporarily, total extractable value is bounded per user and per market.
Bounded verification (anti-griefing)
Claims are structured so audits have deterministic worst-case cost: protocol parameters bound maximum walk length, the number of sampled walks opened per audited claim, and the size of each opening (Merkle proofs + alias-table proofs). These bounds prevent “audit griefing” via oversized transcripts or huge openings.

Canonical randomness (kills grinding)

Each epoch has a randomness beacon . For each transaction id txid, walk seeds are derived deterministically:

This removes user choice and prevents seed grinding / “variance extraction”.

Intuition
The prover doesn’t get to pick the dice rolls: walk randomness is derived from an epoch beacon, so users can’t retry until they get a lucky estimator outcome.
Related work
Verifiable Random Functions: RFC 9381.
Randomness beacon requirements
Audit selection and transcript determinism rely on being unpredictable at commit time and bias-resistant with respect to block proposers/validators. A common appchain design is a threshold BLS beacon in the style of drand (see also Cloudflare’s beacon background: Randomness Beacon).

Transcript commitment + delayed sampling (prevents adaptive cheating)

Commit now, sample later

The prover:

  1. computes the claim and a transcript for Monte Carlo walks
  2. commits to a transcript root
  3. posts a commitment hash:
Determinism
Binding , , plus the market context makes the transcript commitment deterministic: every verifier replays the same market-relative random-walk process on the same snapshot using the market’s committed teleport distribution . ensures the replay also uses the same estimator settings (walk count, max steps, etc.).
Replay-safety
Binding and prevents replaying a valid transcript under a different snapshot. Binding prevents reusing the transcript under a different market seed table.
Market derivation is auditable (minimal registry)
Users don’t get to pick a favorable marketId. In the fact layer, the transaction executes a MarketContext that emits an InteractionRecord, and the record’s marketId = m must match MarketRegistry[marketContext].marketId at that height. Because MarketRegistry is included in SnapshotBlob_t and bound by , auditors can deterministically verify the market derivation while verifying the same claim’s transcript steps against / .

Then sampling indices are derived from future randomness (e.g., ):

Because is unknown at commit time, the prover cannot craft a transcript that is only valid on the checked parts.

Intuition
First you lock in the transcript; later the protocol decides which parts must be opened. If you lied anywhere, there’s a good chance the opened part exposes it.
Related work
Merkle commitments and delayed random challenges are standard in fraud-proof protocols.

Transcript contents (minimal sketch)

For walk (length ):

  • starting node (sampled from the market-relative teleport , with teleport sampling proofs against and optionally a per-market seed alias commitment )
  • visited nodes
  • for each step :
    • restart decision correctness
    • market-scoped edge sampling proof:
      • open OutIndex(m) for the current node via Merkle proof from marketOutIndexRoot
      • prove the sampled outgoing edge index using a Merkle opening against the aliasRoot from OutIndex(m)
      • open the selected edge entry via Merkle proof against the adjacencyRoot from OutIndex(m)
  • final contribution to the estimator (e.g., terminal node count, hit counts, discounted hits)

Verification and penalties (validator audits)

In high-volume markets, a protocol-chosen subset of claims is mandatorily audited by assigned validators, and failed audits finalize as fact-layer penalties.

See: Validator Audits & Penalties

Related

Previous Graph Commitments & Snapshots
Next Validator Audits & Penalties
Copyright © 2026