8. Security & Fraud Proofs
Speed is meaningless without security. Frogment employs an Optimistic Rollup model anchored to Solana's robust consensus mechanism.
8.1 The Optimistic Assumption
We assume that the Sequencer is honest by default to maximize speed. However, we must trust but verify.
Whitelisted Verifiers: A network of decentralized Verifier Nodes constantly monitors the batches posted by the Sequencer.
Re-execution: Verifiers download the batch data from Solana, decompress it, and re-execute the transactions locally to check if their resulting State Root matches the Sequencer's posted Root.
8.2 The Fraud Proof System (Interactive Fault Proofs)
If a Verifier detects a discrepancy (e.g., the Sequencer approved a transfer without sufficient funds), a Challenge is initiated.
Challenge Window: There is a defined time window (e.g., 2 hours) after a batch is posted to Solana during which it can be challenged.
Bisection Protocol: Instead of re-running the whole batch on-chain (which is expensive), the Verifier and Sequencer play an interactive game to pinpoint the exact single instruction where they disagree.
One-Step Proof: Only that single instruction is executed on-chain (on Solana L1) to determine the truth.
8.3 Slashing & Security
If Sequencer lies: Their bonded stake (in SOL/FRG) is slashed. A portion goes to the Verifier as a reward, and the invalid batch is reverted.
If Verifier spams false alarms: The Verifier's stake is slashed.
This economic game theory ensures that the Sequencer has a massive financial disincentive to act maliciously.
8.4 Censorship Resistance
What if the Sequencer goes offline or refuses to process your transaction?
L1 Forced Inclusion: Users can bypass the Sequencer and submit a transaction directly to the Frogment Anchor Program on Solana L1. The Sequencer is forced to include this transaction in the next batch within a set timeframe, or the chain halts.
Last updated