SBET V2 Protocol Overview

What V2 Is

V2 is not an incremental feature patch on top of the legacy SBET stack. It is a fresh deployment model with explicit contract boundaries, explicit authority boundaries, and a deterministic lifecycle for every match: registration, betting, outcome proposal, challenge, dispute, finalization or void, and payout or refund.

The 13 Locked Architectural Decisions

The V2 source tree is organized around thirteen non-negotiable decisions. These are the design anchors that explain the shape of the contracts, the economics, and the governance surface.

Protocol Topology

SBET V2 is decomposed into dedicated contracts. Core owns state transitions, Treasury owns user funds, DisputeManager owns the bond ladder, GraderRegistry owns grader collateral, GuardianCouncil owns protocol-wide pause authority, and StakerRewards owns reward accounting.

Contract Set and Boundaries

How a Match Moves Through V2

Every V2 match progresses through a deterministic state graph. Pool type is immutable, but state changes are explicit and role- or time-gated. This is the core difference from the older architecture: a match does not simply "finalize". It enters a proposed state, becomes challengeable, may escalate into dispute, and only then exits into payout or refund conditions.

State Transitions

Challenge Window Tiers

V2 does not use one fixed delay for every match. The window is chosen from four tiers depending on dissent count, quorum quality, AI confidence, and source agreement.

function computeTier(
    uint256 n,
    uint256 m,
    uint256 signers,
    uint256 dissents,
    uint16 confidenceBps,
    uint8 sourceAgreement
) internal pure returns (Tier tier, uint32 windowSeconds);

Settlement Models

V2 supports two immutable accounting regimes. This is one of the largest conceptual changes from V1: the core can serve both sportsbook-like binary exposure and pot-based community pools, while keeping payout logic explicit per match.

Payout Math

// Signed-position payout (V1 parity)
payoff_long  = longPos  * finalPrice / MAX_PRICE;
payoff_short = shortPos * (MAX_PRICE - finalPrice) / MAX_PRICE;
finalPrice   = outcome * MAX_PRICE / (numOutcomes - 1);

// Parimutuel payout
payout = userStake * totalAccepted / winningOutcomeStake;

Prediction Markets (LMSR AMM)

V2 includes a dedicated prediction market layer built on top of Core. PredictionMarketV2 manages the market lifecycle and metadata. PredictionAMMV2 provides LMSR (Logarithmic Market Scoring Rule) pricing with ERC-1155 outcome shares, autonomous payouts, and fee routing to Treasury.

LMSR Pricing

The AMM uses Hanson's LMSR with PRBMath SD59x18 fixed-point arithmetic. The b parameter controls market depth. A higher b means more liquidity and tighter spreads; a lower b means prices move faster with each trade.

The minimum safe b parameter is 1e18 (enforced in seedLiquidity). For production pools, SAFE_RECOMMENDED_B = 1000e18 provides a large safety margin against PRBMath exp() overflow.

// Symmetric fee formula (Polymarket pattern)
// fee = totalFeeBps * min(price, MAX_PRICE - price) * amount / (MAX_PRICE * BPS_DENOM)
// Near 50/50 price: full fee. Near certainty: fee approaches 0.
// Minimum fee floor: at least 1 wei when amount > 0 and fees configured.

Autonomous Payouts

Prediction markets use a push-based payout model. Users do not need to manually claim winnings. Keeper bots detect Core finalization and push payouts:

1. Keeper calls syncAndDistribute(marketId, holders[]) on PredictionMarketV2.
2. Market syncs the resolution from Core (idempotent, safe to call multiple times).
3. AMM iterates holders, burns their winning ERC-1155 shares, and transfers pro-rata collateral.
4. If one holder's transfer fails, the batch continues. Failed holders can redeem individually later.

The same pattern works for voided markets via syncAndRefund, where all outcomes are refundable pro-rata.

Domain Separation

Prediction market IDs are namespaced to avoid collision with sportsbook match IDs in Core. The formula coreMatchId = keccak256(PREDICTION_DOMAIN, marketId) is deterministic and requires no coordination between sportsbook and prediction market registrars.

Security Hardening

PredictionAMMV2 (991 lines) underwent a dedicated security review. Five P0 critical fixes were applied:

Additionally, the AMM's reference to PredictionMarketV2 is now governance-settable with a 48-hour timelock (HIGH-1 fix), and 20 Echidna invariant properties validated pool solvency, fee bounds, and redemption fairness. Echidna found and we fixed a zero-fee LMSR rounding arbitrage; sell payouts now round down.

Disputes and Pause Architecture

Disputes in V2 are their own protocol subsystem. A dispute is not an informal challenge flag; it is a capitalized, deadline-driven ladder that eventually resolves through an arbiter ruling. Separately, pause logic is split into match, category, and global layers so operations can isolate damage instead of toggling one giant kill switch.

Dispute Bond Escalation

initialBond = max(5_000e18, min(50_000e18, matchTvl * 100 / 10_000));

Pause Tiers

Economic Security Model

V2 ties the maximum stealable value on a match to the collateral at risk from the grading quorum. The protocol is trying to make dishonest resolution economically irrational, not merely socially discouraged.

Core Invariants

Cap and Collateral

uint256 public constant ABSOLUTE_CAP = 225_000e18;

function perMatchPayoutCap() public view returns (uint256) {
    uint256 floor_ = GRADERS.graderStakeFloor();
    uint256 candidate = floor_ * _quorumM;
    return candidate < ABSOLUTE_CAP ? candidate : ABSOLUTE_CAP;
}

With the default stake floor of 25_000e18 SBET and quorum 9, the quorum's combined collateral equals the cap: $225k. That is the core security claim. A malicious quorum should always have at least as much at risk as it could steal from one match.

Worked Attack Scenarios

Treasury Hardening (V2.1)

SBETTreasuryV2 enforces a per-match deposit/release ledger that prevents cross-match drainage, double-claims, and over-release. Every payout path is checked against what was actually deposited for that specific match.

// Outflow invariant — enforced on every payout path
uint256 alreadyReleased = matchReleased[matchId][token];
if (alreadyReleased + amount > matchDeposited[matchId][token])
    revert OutflowExceedsDeposit(matchId, token, amount);
matchReleased[matchId][token] = alreadyReleased + amount;

// One-shot role lock — irreversible after deployment wiring
function lockCriticalRoles() external onlyRole(GOVERNANCE_ROLE);
// Sets rolesLocked = true. All subsequent grantRole / revokeRole
// for CORE_ROLE, GRADER_REGISTRY_ROLE, DISPUTE_MANAGER_ROLE revert.

Match Expiry

Every match can have a deadline. If a match passes its deadline without finalization, anyone can expire it. This prevents stale matches from locking user funds indefinitely.

Events: MatchDeadlineSet(matchId, deadline), MatchExpired(matchId). The deadline field on MatchInfo starts at 0 (unset). The indexer's deadline keeper sets deadlines based on actual match schedules via setMatchDeadline.

Defense-in-Depth Properties

V2 layers multiple independent security mechanisms. Compromise of one subsystem should not cascade into fund loss.

Roles and Authority

V2 intentionally decomposes authority. Graders attest. Guardians pause. The arbiter resolves irreducible disputes. Treasury enforces custody by role. Governance still exists, but no single role should simultaneously control grading, dispute judgment, and user funds.

Operator and User Flows

The protocol is easiest to understand when you follow concrete flows. The important implementation detail is that approvals go to different contracts depending on the action.

Approval Cheat Sheet

Flow Summary

1. Place a parimutuel bet: approve Treasury, call placeBet, and watch for BetPlaced plus Treasury custody events.
2. Open a signed position: approve Treasury, call openSignedPosition, and remember the cap applies to directional exposure, not the sum of both sides.
3. Watch a match finalize: track OutcomeProposed, read unlockAt, then either wait for a relayer or permissionlessly call finalize.
4. Open or answer a dispute: approve DisputeManager, post the required round bond, and be prepared for a 24-hour response window at each stage.
5. Claim payout or refund: use the claim function that matches the pool type, or claimVoidRefund if the match was voided.
6. Opt into gasless auto-claim: set Treasury auto-claim opt-in and accept the default fee path of 2% for SBET or 3.5% for other tokens.
7. Create a prediction market: approve Treasury for the Core bond, approve PredictionMarketV2 for initial liquidity, call createMarket.
8. Trade prediction shares: approve PredictionAMMV2, call buy or sell. LMSR pricing with symmetric fees.
9. Redeem prediction winnings: either call redeem manually after syncResolution, or wait for a keeper to push payouts via syncAndDistribute.

// Example: parimutuel bet
await usdc.approve(treasuryAddress, parseUnits("100", 6));
await sbetCore.placeBet(matchId, 0, usdcAddress, parseUnits("100", 6));

// Example: open dispute
await sbet.approve(disputeManagerAddress, parseEther("5000"));
await sbetCore.openDispute(matchId, 1);

From V1 to V2

V2 is a fresh-start deployment, not an in-place upgrade. V1 keeps operating for existing positions; V2 introduces a new contract set, new addresses, new match identifiers, and a new trust model.

V1 vs V2 at a Glance

Migration Rules

• Existing V1 positions remain governed by V1 settlement paths.
• There is no forced migration and no treasury merge at V2 launch.
• V2 is a fresh-start deployment with a new set of contracts and new match IDs.
• Governance may eventually stop creating new V1 matches, but old V1 positions continue to settle under V1 rules.

Ship-Blocking Problems Addressed in V2

Deep Dives and Downloads

This page is the narrative overview. The engineering source documents go deeper into contract APIs, attack scenarios, operator requirements, and migration details.