Fraud-Proof by Design: Challenge Protocol and Slash Conditions

The weakest point of any proof-of-work system is the verification cost. If verifying a proof costs as much as producing it, you have not saved anything. Proof of Feed solves this with asymmetric verification: producing a FeedProof requires running full Blazil inference, but verifying it requires only one TigerBeetle lookup. The verification is cheap. The production is expensive.

But cheap verification creates a different problem: a miner who produces fake proofs would only get caught if someone re-runs the inference and checks the output. The challenge protocol exists to make that probabilistic check economically ungameable.

How challenge sampling works

At the end of each epoch, the network selects 5% of inference jobs for re-verification. The selection is deterministic but unpredictable:

challenge_seed    = BLAKE3(block_hash ++ epoch_nonce)
challenged_jobs   = jobs where
  BLAKE3(challenge_seed ++ job_id ++ block_height)[0..8] as u64
    < (u64::MAX / 20)  // 5% threshold

The key property is that block_hash is a future block hash — it does not exist at the time the miner accepts the job. The miner cannot know in advance which jobs will be challenged. They cannot selectively fake some jobs while running genuine inference on others.

The threshold of 5% is a deliberate tradeoff. Higher sampling catches more fraud but costs more in re-verification compute. Lower sampling is cheaper but reduces the deterrent. At 5%, a miner who fakes 100% of their proofs has a 5% chance of being caught per epoch. Over 10 epochs, the probability of detection exceeds 40%. The expected value of fraud is negative when slash amounts are factored in.

Re-verification process

When a job is challenged, the network selects three independent miners to re-run the same input through their own Blazil instances:

1. The challenger broadcasts the challenge with the original input CID
2. Three independent miners retrieve the input data and run inference
3. Their outputs are compared against the original output CID

The comparison uses a model-specific divergence threshold defined in the ModelRegistry. Different ONNX models have different acceptable output variance — a language model and an image classifier have different numerical properties. The threshold accounts for floating-point non-determinism across hardware.

If any of the three re-verifiers produce output that diverges beyond the threshold, the original miner is slashed 100% of their stake. The slashing miners split 50% of the recovered stake as a reward. The other 50% goes to the treasury.

Slash conditions and amounts

The protocol has four distinct slash conditions:

Invalid FeedProof — TransferId not found in TigerBeetle. This means either the miner never ran Blazil, or ran it against a different TigerBeetle cluster. Slash: 10% of staked F.

Challenge failure — Re-verification produces divergent output. Slash: 100% of staked F. This is the harshest condition because it represents deliberate fraud — the miner accepted a fee for inference they did not perform correctly.

Double-sign — Miner signs two different blocks at the same height. Slash: 100% of staked F. This is a classic BFT safety violation. The evidence is two signed blocks with the same height from the same pubkey.

SLA violation — Inference delivered outside the committed latency window. Not a slash in the traditional sense, but a fee-based penalty: 50% or 100% fee refund from the miner's stake depending on severity.

All slashes are executed as atomic TigerBeetle linked transfers. The linked flag means all transfers in the batch either succeed or fail together. There is no partial state where a miner is slashed but the treasury does not receive the funds.

Why miners cannot game the system

The challenge protocol has three properties that make gaming unprofitable.

Unpredictability: The challenge seed is derived from a future block hash. At job acceptance time, this hash does not exist. The miner has no information that would let them predict which jobs will be sampled.

Independence: The three re-verification miners are selected by the network, not the original miner. The original miner cannot arrange for friendly re-verifiers.

Asymmetric punishment: A successful fraud saves one inference compute cost. A detected fraud costs 100% of stake. At 1,000 F minimum stake and a 5% detection probability per epoch, the expected loss from fraud vastly exceeds the gain from skipping inference.

The data availability component

Challenge verification requires access to the original input data. If a miner deletes or withholds input data after the job completes, re-verification is impossible.

Feedable Network handles this with the data availability requirement: miners must serve raw data for any CID in the last 1,000 blocks. If a validator requests data for a challenged job and the miner fails to serve it within 30 seconds, they receive a 0.1% stake slash per incident. After 10 incidents, they are removed from the validator set.

This creates an additional economic requirement: miners must maintain sufficient storage and bandwidth to serve historical data. The 1,000-block window (approximately 2.8 hours at 10s blocks) gives the challenge protocol enough time to complete re-verification for any recent job.

What this means for the network

The challenge protocol makes Proof of Feed trustless in the strongest sense. Miners do not need to trust each other. Users do not need to trust miners. The protocol guarantees that inference results are correct with overwhelming probability — any miner who skips inference will be detected and economically destroyed within a small number of epochs.

This is what separates Proof of Feed from systems that rely on reputation, staking alone, or optimistic rollup-style fraud proofs. The verification is probabilistic but automatic, immediate, and economically decisive.