Result Replication Bounty

The core security model is based on cryptoeconomic incentives. A bounty issuer posts a reward for verifying a computation's result. Any participant (a challenger) can stake collateral to dispute a published result. If the challenger's re-execution proves the original result was wrong, they claim the bounty and the issuer's stake; if not, they lose their stake. This creates a Nash equilibrium where rational actors are economically motivated to either produce correct results or challenge incorrect ones.

For a result to be verifiable, the underlying computation must be deterministic. This means given the same inputs and code, it must always produce the exact same output. This property is essential for consensus on correctness. Common examples include:

• ZK-SNARK/STARK proof verification
• Hash function computations (e.g., Merkle root generation)
• Signature validation Non-deterministic operations (e.g., fetching a random live API price) cannot be securely verified by this mechanism.

When a challenge is issued, the system does not rely on voting or oracles. Instead, it forces a verification game where the disputed computation is re-run in a trusted environment. This is often implemented as a multi-round interactive fraud proof (like in Optimistic Rollups) or a direct on-chain execution. The final, canonical result is determined by this cryptographically enforced re-execution, providing objective resolution without subjective judgment.

Published results are not immediately final. They enter a challenge window (e.g., 7 days) during which any participant can post a bond and dispute them. This delay is a trade-off between security and latency. After the window expires without a successful challenge, the result achieves economic finality—it is considered valid because the cost of having hidden an error now exceeds the potential bounty. This model is foundational to Optimistic Rollup security.

The mechanism enables trust in expensive computations without paying the full on-chain gas cost every time. Only the input, output, and a small proof of correctness are initially posted on-chain. The full computational cost is only borne in the dispute case, which is statistically rare if the system is honest. This makes it viable for verifying complex tasks like machine learning inference or large-scale simulations that would be prohibitively expensive to run directly on-chain.

Security scales with the number of independent verifiers watching for incorrect results. This creates a permissionless verification network. Participants run watchtower software that automatically monitors published results, re-executes them off-chain, and can automatically submit challenges if a mismatch is detected. The system's robustness increases as more independent agents participate, reducing reliance on any single trusted party.

The primary goal is to guarantee that the result of a complex on-chain computation is correct. This is critical for trustless systems where participants must rely on the output of a smart contract or oracle. By offering a bounty, the protocol creates a financial disincentive for publishing incorrect results and an incentive for the network to audit them.

• Mechanism: A bounty is posted alongside a claimed result.
• Verification: Any network participant can attempt to recompute the result.
• Claim: If a verifier finds a discrepancy and can prove the correct result, they claim the bounty, invalidating the original claim.

Instead of relying on a single, trusted entity to perform and attest to computations, the bounty model distributes the verification work across the entire network. This aligns with the decentralized security model of blockchains.

• Permissionless Auditing: Anyone with the requisite technical knowledge can act as a verifier.
• Economic Security: The cost of corrupting the system scales with the size of the bounty and the number of independent verifiers.
• Reduced Centralization Risk: Eliminates single points of failure in the data provision or computation layer.

This is a foundational component of optimistic rollups and similar Layer 2 scaling solutions. In these systems, transactions are assumed to be valid (optimistic) unless challenged.

• Fraud Proof Window: A result (state root) is published with a bounty.
• Dispute Resolution: During a challenge period, any watcher can submit a fraud proof demonstrating an invalid state transition.
• Slashing & Rewards: A successful challenger claims the bounty from the party that posted the incorrect result, which is typically slashed.

Used by decentralized oracle networks to ensure the accuracy of off-chain data (like price feeds) brought on-chain. A bounty is offered for proving that reported data is incorrect.

• Data Integrity: Protects DeFi protocols from manipulation via faulty oracle inputs.
• Incentive Alignment: Encourages node operators to report accurate data and watchdogs to monitor them.
• Example: A protocol might offer a bounty for proving a price feed deviated from the median of reputable sources by more than a defined threshold.

The model provides high security assurance without requiring every network participant to redundantly execute every computation. It's a game-theoretic approach to security.

• Pay for Performance: The protocol only pays for verification (via the bounty) when a result is successfully challenged. Correct results cost nothing extra to verify.
• Efficiency: The vast majority of computations will be correct, so the system avoids the overhead of universal verification.
• Security Budget: The bounty size is a tunable parameter that directly sets the economic cost of attacking the system.

The effectiveness of a bounty depends on carefully chosen parameters that define the cryptoeconomic game.

• Bounty Size: Must be large enough to incentivize honest verification and make attacks prohibitively expensive.
• Challenge Period (Dispute Window): The length of time during which a result can be challenged. Must be long enough for verifiers to act.
• Bond Size: The collateral posted by the original claimer, which is slashed if proven wrong and used to pay the bounty.
• Verification Logic: The unambiguous, on-chain function or circuit that defines the "correct" result for the challenge.

The bounty is a cryptoeconomic security mechanism that enforces computational integrity. It works by:

• Posting a Challenge: After a prover submits a result (e.g., a SNARK proof), a challenge period begins.
• Incentivizing Verification: Any verifier can download the proof, re-execute the computation, and check for discrepancies.
• Claiming the Bounty: If a verifier finds an error, they can submit a fraud proof to claim the bounty, which is slashed from the original prover's stake.

This mechanism is critical in zk-rollups and validiums where the cost of verifying a zero-knowledge proof on-chain is high. Instead of forcing all nodes to verify every proof, the system relies on economic games:

• One honest verifier is sufficient to keep the system secure.
• The bounty must be large enough to make verification profitable, deterring lazy validation.
• This creates a scalable security model where only one party needs to perform the heavy computation.

Polygon zkEVM employs a result replication bounty (often called a verification bounty) as part of its LxLy consensus. After a sequencer posts a validity proof for a batch of transactions, a 10-day challenge window opens. During this period, any network participant can:

• Re-run the zkEVM circuit computation.
• Dispute the proof's validity by submitting a counter-proof.
• If successful, they claim a bounty from the sequencer's bond, and the invalid batch is reverted.

Designing an effective bounty system requires careful calibration of several parameters:

• Bounty Size: Must significantly exceed the cost of verification to incentivize participation.
• Challenge Window Duration: Must be long enough for verifiers to perform the computation but short enough for finality.
• Stake/Slash Amount: The prover's locked stake must cover the potential bounty payout and penalty.
• Verifier Cost: Includes computational resources (CPU/GPU) and gas fees for submitting a fraud proof.

Result replication bounties differ from other decentralized verification models:

• vs. Interactive Fraud Proofs (Optimistic Rollups): Bounties are for verifying a deterministic computation result (like a ZK proof), while fraud proofs involve re-executing transaction logic over a multi-round game.
• vs. Proof-of-Work: No race to solve a hash puzzle; the reward is for catching invalid work, not for producing it.
• vs. Pure Validity Proofs: Adds an economic layer of redundancy to the cryptographic guarantee, protecting against implementation bugs or malicious provers.

While powerful, the model introduces specific engineering and game-theoretic challenges:

• Verifier's Dilemma: If the bounty is too small or verification is too costly, no one will check, breaking the security assumption.
• Data Availability Dependency: Verifiers must have access to all input data to recompute the result. This ties the mechanism's security to data availability solutions.
• Timing Attacks: Malicious provers could time proof publication to minimize the chance of verification within the challenge window.
• Centralization Risk: Verification may become professionalized, leading to a small set of bounty hunters.

The bounty is the central cryptoeconomic security mechanism. It creates a financial disincentive for a result provider (e.g., a node or oracle) to submit an incorrect result. The bounty is locked when a result is posted and can be claimed by any verifier who successfully proves the result is wrong through a fault proof or challenge period. This aligns economic security with computational integrity.

Verifiers (or challengers) are economically motivated participants who monitor the network. Their incentive to check work comes from the potential to claim the slashed bounty and often an additional reward. This creates a decentralized verification layer without requiring every user to re-run computations. Key steps for a verifier include:

• Monitoring for new result submissions.
• Independently replicating the computation.
• Submitting a fraud proof if a discrepancy is found.
• Successfully claiming the bounty after a dispute resolution process.

The bounty is typically a stake or bond posted by the result provider in a native token or stablecoin. Its value must be high enough to make fraud economically irrational. If a verifier successfully challenges a result:

1. The incorrect result is rejected.
2. The provider's bounty is slashed (partially or fully).
3. A portion of the slashed funds is awarded to the honest verifier, with the remainder often burned or sent to a treasury. This slashing condition is the primary penalty for dishonesty.

A critical time-bound parameter is the challenge period (or dispute window). This is the fixed duration after a result is published during which verifiers can submit a challenge. Design considerations include:

• Length: A longer window increases security but delays finality.
• Finality: Results are only considered final and executable (e.g., payments released) after the challenge period expires with no valid challenges.
• Liveness vs. Safety: This parameter directly trades off between system liveness (speed) and safety (security).

The mechanism must be designed to resist specific economic attacks:

• Nothing-at-Stake: Verifiers have no cost to challenge, potentially spamming the network. Mitigated by requiring a small verification bond.
• Bribery Attacks: A malicious provider could bribe verifiers to not challenge. Mitigated by making the verifier reward a large, unpredictable portion of the slashed stake.
• Stake Centralization: If bounty/staking is too high, it may lead to centralization among wealthy actors, reducing censorship resistance.

In an Optimistic Rollup, a Sequencer posts state roots to Ethereum, backed by a bond. There is a standard 7-day challenge period. During this window, any Verifier can compute the rollup's state transitions and submit a fraud proof to Ethereum if the Sequencer's root is invalid. A successful proof slashes the Sequencer's bond, rewards the Verifier, and reverts the incorrect state. This model underpins security for chains like Arbitrum One (Nitro) and Optimism (with fault proofs).