On-Chain Settlement

Overview

Every prediction on Frenzy.Finance is settled on-chain through the FrenzyFinance smart contract. This means your earnings aren't paid from a pool or a house — they're FD credits minted by the FrenzyDollar escrow, backed 1:1 by USDC. Incorrect predictions are burned, removing credits from circulation. Learn more about the escrow and overcollateral system in Smart Contracts.

The Settlement Flow

1. Make a Prediction (Off-Chain)

When you click a cell on the trading grid, your session wallet signs an EIP-712 Intent — a structured, typed message that specifies exactly what you're predicting:

• Which market (e.g., BTC/USD)
• The price range (low and high)
• The time interval (start and end)
• Your trade amount

This signature is sent to the Frenzy backend, which validates it and confirms your prediction instantly. No blockchain transaction is needed at this stage — that's why trading feels instant.

2. Oracle Acknowledges (Off-Chain)

The backend's oracle verifies your prediction and signs an Acknowledgment — that includes the current price and your prediction's multiplier. Both your Intent signature and the oracle's Acknowledgment signature are stored, ready for on-chain settlement.

3. Interval Closes, Settlement Begins (On-Chain)

When the 5-second price interval ends, the oracle reads the final settlement price and triggers on-chain settlement by calling batchSettleV2() on the FrenzyFinance contract. This single transaction can settle many predictions at once, in any order.

The smart contract:

1. Verifies your signature — confirms you actually made the prediction
2. Verifies the oracle's signature — confirms the oracle acknowledged it and attested the settlement price
3. Determines the outcome — checks if the settlement price falls within your prediction's price range
4. Nets the results per user — instead of minting and burning individually, the contract accumulates all wins and losses per user, then executes a single net operation:
   • Net positive: A single mintCredits() call for the difference
   • Net negative: A single burnCredits() call for the difference
   • Break-even: No mint or burn needed

4. Balance Updates (Real-Time)

After settlement, your frontend receives a WebSocket notification with your updated balance. The grid animates your result, and your balance refreshes automatically.

Why Mint and Burn?

• USDC-backed — Every FD credit is backed 1:1 by USDC held in the FrenzyDollar escrow contract, plus an overcollateral surplus.
• No counterparty — You're not trading against other users or a house. The protocol itself settles outcomes based on verified price data.
• Transparent — Every settlement is a verifiable on-chain transaction. You can inspect the mint/burn events on the block explorer.

Unordered Settlement with Netting

Predictions can be settled in any order — there's no sequential numbering or buffering. The oracle submits resolved predictions in batches via batchSettleV2(), and the contract processes them using per-user netting: all wins and losses within a batch are accumulated, then a single net mint or burn is executed per user. This eliminates intermediate balance failures and simplifies the entire settlement pipeline.

If a prediction's nonce has already been used (e.g., settled in a previous batch), it's silently skipped — no revert, no wasted gas.

Self-Settlement

If the oracle is slow or unavailable, you can trigger settlement yourself by calling selfSettleAll() on the FrenzyFinance contract. This settles all your resolved-but-unsettled predictions in a single transaction.

To prevent cherry-picking (settling only winning predictions and skipping losses), the oracle signs a UserSeal — a commitment to the complete set of predictions you must submit. The contract verifies that your submitted batch matches the seal before processing. Predictions already settled by the oracle are automatically skipped, and the net result adjusts accordingly.

Security

• EIP-712 signatures — All predictions use typed structured data signatures, preventing replay attacks and ensuring you can verify exactly what you signed.
• Nonce system — Each prediction has a unique nonce (bitmap-based), allowing parallel predictions without conflicts.
• Role-based access — Only authorized oracle operators can sign price attestations and trigger batch settlements.
• On-chain verification — The smart contract independently verifies every signature before minting or burning. The backend cannot fabricate settlements.