Decentralized
Sports Betting
Protocol

SBET Protocol is a fully decentralized sports betting platform built on Ethereum, offering four distinct betting primitives — peer-to-peer trading, pool betting, NFT staking, and prediction markets — all governed by immutable smart contracts with no centralized counterparty risk.

Unlike traditional sportsbooks that act as the house, SBET removes the intermediary entirely. Users bet directly against each other through EIP-712 signed orders matched on-chain, or participate in pari-mutuel pools where odds are determined purely by market forces. Every operation — from order execution to fee distribution — is enforced by audited Solidity code running on Ethereum.

The Problem

The global sports betting market exceeds $500 billion annually, yet it remains dominated by centralized platforms that suffer from fundamental issues:

• Counterparty risk: Users must trust operators to honor payouts and not manipulate odds
• Opaque fee structures: Traditional sportsbooks embed 5-15% margins (vig) with no transparency
• Geographic restrictions: Regulatory fragmentation locks out billions of potential users
• Settlement delays: Withdrawals often take days and require KYC friction
• No composability: Bets are siloed — positions cannot be traded, hedged, or used as collateral

The SBET Solution

SBET addresses every dimension of this problem through a comprehensive protocol design:

Key Differentiators

Investment Thesis: SBET is building the decentralized infrastructure layer for sports betting — the "Uniswap of sports markets." With 24 production-grade smart contracts, a completed security audit, and exchange listings on Coinbase, Gate.io, and LBank, the protocol is positioned to capture share from a $500B+ market transitioning on-chain.

Protocol Milestones Achieved

Why SBET Matters

The convergence of three macro trends creates an unprecedented opportunity for SBET:

1. Regulatory tailwinds: Sports betting is being legalized globally at an accelerating pace, creating a massive legal market that was previously underground.
2. DeFi maturity: The DeFi ecosystem has proven that complex financial operations can run trustlessly on-chain. Sports betting is the next major vertical to be decentralized.
3. User demand: Millions of crypto-native users are actively seeking permissionless, transparent alternatives to centralized platforms that restrict access and manipulate odds.

SBET sits at the intersection of these trends with a fully built, audited, and listed protocol ready to capture this market opportunity.

Global Sports Betting Market

The global sports betting market is one of the largest entertainment verticals in the world, and it is accelerating due to regulatory liberalization, mobile adoption, and the convergence of sports and technology.

Market Drivers

Competitive Landscape

SBET's Edge: No competing protocol offers all four betting primitives (P2P trading, pool betting, NFT staking, prediction markets) within a unified, audited smart contract system. SBET's multi-modal approach means it can serve casual bettors (pools), sophisticated traders (P2P), collectors (NFT bets), and speculators (prediction markets) — all within a single token economy.

The Decentralized Betting Thesis

Traditional sportsbooks face structural constraints that decentralized protocols can exploit:

Sports Coverage Strategy

SBET's sports taxonomy system supports a comprehensive range of sports and leagues across multiple categories:

Total Addressable Market

SBET targets three converging markets:

SBET Protocol is a modular, upgradeable smart contract system that provides the complete infrastructure for decentralized sports betting. The protocol is organized around six core primitives, each implemented as isolated, audited contract modules.

Six Betting Primitives

Design Philosophy

Protocol Architecture

Contract Interaction Flow

A typical P2P bet follows this lifecycle:

System State Management

The SBET Core contract maintains several system-wide state variables tracked via the SystemStatus struct:

struct SystemStatus {
    bool isPaused;              // Global pause flag
    bool isEmergency;           // Emergency mode active
    uint256 emergencyEndTime;   // Auto-resume timestamp
    address treasury;           // Treasury contract address
    uint256 poolCount;          // Total pools created
}

Match Management

Matches are the atomic unit of betting in the SBET Protocol. Each match represents a real-world sporting event and tracks:

Data Architecture: Frontend-to-Contract Mapping

SBET follows a strict one-screen-per-contract pattern for the dApp:

This pattern ensures every new contract integration follows a predictable, auditable structure that reduces the risk of frontend bugs and makes the codebase navigable for new contributors.

Event Architecture

SBET emits structured events for every state-changing operation, enabling off-chain indexing, analytics, and audit trails:

Compiler & Toolchain

Contract Hierarchy

The protocol follows a layered architecture with clear separation of concerns:

Inheritance Tree

OpenZeppelin Contracts v5
├── ERC20                    → SBET Token
├── ReentrancyGuard          → SBET Core, Treasury, NFTVault
├── Pausable                 → SBET Core, Treasury
├── ERC721Holder             → NFTVault
├── ERC1155Holder            → NFTVault
├── EIP712                   → SBET Core (domain separator)
└── AccessControl            → Treasury, IntegratorHub

SBET Protocol
├── SBET.sol                 → Core entry + P2P + Pools
│   ├── EIP712 domain management
│   ├── Order lifecycle (create, fill, cancel)
│   ├── Pool lifecycle (create, stake, finalize)
│   ├── Match management (create, finalize, oracle)
│   └── Nonce management (min, cancel, range)
├── NFTVault.sol             → ERC-721/1155 escrow
├── NFTManager.sol           → NFT bet coordination
├── NFTFeeManager.sol        → Per-collection fees
├── PredictionMarket.sol     → LMSR market lifecycle
├── PredictionAMM.sol        → Automated market maker
├── Treasury.sol             → Hub contract
├── TreasuryFacade.sol       → External interface
├── FeeManager.sol           → Fee configuration
├── BudgetManager.sol        → Budget allocation
├── VestingManager.sol       → Token vesting
├── YieldManager.sol         → Yield strategies
├── MultisigManager.sol      → Multi-sig authorization
├── DonationManager.sol      → Community donations
├── IntegratorHub.sol        → Partner integration
└── SBETQuery.sol            → Read-only queries

Security Primitives

EIP-712 Domain Configuration

EIP712_DOMAIN = {
  name: "Sports BET (SBET) Protocol",
  version: "1.0",
  chainId: <dynamic>,
  verifyingContract: <SBET Core address>,
  salt: keccak256("53019554eadfcd6f3ee53ec6d0bcd18db643b20cfcf8655aae83229cdeb079bd")
}

Order Type = {
  maker: address, taker: address, token: address,
  matchId: uint256, amount: uint256, price: uint256,
  direction: uint256, expiry: uint256, timestamp: uint256,
  orderGroup: uint256, nonce: uint256,
  isNFT: bool, nftAddress: address, nftId: uint256
}

Gas Optimization Techniques

Frontend Provider Stack

The SBET dApp uses a modern React/TypeScript stack with a carefully layered provider architecture:

WagmiProvider (wallet connection + contract reads/writes)
  └─ QueryClientProvider (TanStack Query, 10s stale time)
       └─ RainbowKitProvider (wallet modal UI)
            └─ App (routing + pages)

This stack provides:

• WagmiProvider: React hooks for wallet connection, contract reads (useReadContract), and writes (useWriteContract)
• TanStack Query: Automatic caching, background refetching, and optimistic updates with a 10-second stale time
• RainbowKit: Pre-built wallet connection modal supporting MetaMask, WalletConnect, Coinbase Wallet, and 50+ wallets

Type System Architecture

SBET maintains a strict type system that mirrors Solidity types in TypeScript:

Supported Odds Formats

The frontend supports seven international odds formats to serve a global user base:

The peer-to-peer trading engine is SBET's flagship betting primitive. It enables users to create and fill orders against each other without any intermediary, automated market maker, or liquidity pool. Prices are set by the market — makers offer odds, and takers accept them.

How It Works

Order Structure

Every P2P order contains 14 fields, all included in the EIP-712 typed data hash:

Price Model

Prices in SBET are expressed as basis points (0–10000), representing the implied probability of the outcome:

Example: A maker creates an order at price 6000 (60% implied probability) with 100 SBET. The taker must put up 100 × (10000 − 6000) ÷ 6000 = 66.67 SBET. If the maker's side wins, they receive 166.67 SBET minus the protocol fee.

Nonce Management

SBET implements a three-tier nonce system for flexible order management:

Fee Separation

P2P trading fees are separated into distinct categories:

• Protocol fee: Collected by the SBET treasury on each filled order
• Integrator fee: Optional fee split for front-end operators who source the order
• NFT fee: Additional fee when NFT collateral is involved (per-collection configurable)

Order Direction & Settlement

SBET orders use a binary direction model mapped to match sides:

At settlement, the oracle sets a finalPrice for the match. Orders are resolved based on whether the final price exceeds or falls below the order's price point, enabling continuous-price settlement rather than simple binary outcomes.

Security Considerations

Market Maker Integration

The P2P engine is designed to support professional market makers:

• Free order creation: Off-chain signing means market makers can maintain thousands of live orders without gas costs
• Efficient cancellation: setMinNonce() cancels all orders below a threshold in one transaction — ideal for rapid market repositioning
• Open taker field: Setting taker = address(0) creates open orders visible to all participants
• Price granularity: Basis point pricing (0-10,000) provides 0.01% price precision
• Batch fills: Multiple orders can be filled in a single transaction for gas efficiency

Pool betting (pari-mutuel) is SBET's most accessible betting primitive. Users stake tokens on outcomes, and payouts are determined by the total pool distribution — there is no counterparty and no fixed odds. The protocol simply collects a small fee and distributes the rest to winners proportionally.

Pari-Mutuel Model

In pari-mutuel betting, the odds are not set by a bookmaker. Instead, they are determined entirely by the ratio of stakes across outcomes:

This means odds continuously adjust as new stakes come in, naturally reflecting the collective wisdom of all participants.

Pool Lifecycle

Pool State

Each pool tracks the following on-chain state:

Worked Example

Multi-Outcome Pools

SBET pools support arbitrary numbers of outcomes, not just binary (win/lose). This enables:

• Three-way pools: Home win, Draw, Away win (standard football/soccer)
• Tournament pools: Multiple teams or players competing
• Score range pools: Betting on score brackets (0-1, 2-3, 4+)

Batch Operations

For gas efficiency, SBET supports batch staking — users can stake on multiple outcomes or multiple pools in a single transaction. This is particularly useful for:

• Hedging positions across outcomes
• Placing bets on multiple matches simultaneously
• Integrator platforms that batch user orders

Pool vs P2P: When to Use Each

Pool Finalization & Oracle Integration

Pool outcomes are determined by oracle-submitted finalization data. The finalization process includes built-in safety mechanisms:

User Pool Details

Users can query their position in any pool via the SBETQuery contract:

struct UserPoolDetails {
    uint256 totalStake;         // User's total stake across all outcomes
    uint256[] outcomeStakes;    // Stake per outcome
    uint256 potentialPayout;    // Maximum payout if user's outcome wins
}

This data is consumed by the frontend to display real-time potential returns as odds shift with incoming stakes.

SBET's NFT betting primitive enables users to stake ERC-721 and ERC-1155 non-fungible tokens on match outcomes. This opens sports betting to the NFT community, allowing collectors to put their digital assets to work without selling them — if they win, they get their NFT back plus token winnings.

How NFT Betting Works

Architecture

NFT betting involves three specialized contracts working together:

NFT Stake Record

struct NFTStake {
    address owner;        // Original NFT owner
    address nftAddress;   // ERC-721/1155 contract
    uint256 nftId;        // Token ID
    BetSide side;         // SideA (1) or SideB (2)
    bool claimed;         // Whether payout was collected
}

Per-Collection Fees

The NFTFeeManager allows the protocol to set different fee rates for different NFT collections:

Collection Blacklist

The protocol maintains a blacklist of NFT collections that cannot participate in betting. This protects users from:

• Malicious contracts with re-entrancy or callback exploits
• Spam NFTs with no real value (airdrop attacks)
• Non-standard tokens that don't properly implement ERC-721/1155

NFT Betting + P2P Integration

NFT bets can be combined with P2P orders by setting isNFT = true in the order struct. This enables sophisticated betting scenarios:

NFT Valuation & Settlement

When NFTs are used as betting collateral, the protocol handles valuation at the order level — makers and takers agree on terms before filling. This peer-negotiated model avoids the complexity and manipulation risk of on-chain NFT price oracles.

• No price oracle dependency: The agreed trade terms implicitly value the NFT
• Winner takes all: The winning side receives both the NFT(s) and any token collateral
• Fee basis: Fees are calculated on the token component only — no fee on NFT transfers

SBET's prediction market engine uses the Logarithmic Market Scoring Rule (LMSR) to provide automated market making for multi-outcome events. Unlike P2P trading where prices are set by makers, prediction markets have an algorithmic market maker that continuously quotes prices for all outcomes.

LMSR Algorithm

The LMSR, developed by Robin Hanson, is the gold standard for prediction market pricing. It guarantees bounded loss for the market maker while providing unlimited liquidity:

The liquidity parameter b controls the market maker's price sensitivity. Higher b means more liquidity (less price impact per trade), but higher maximum loss for the market maker subsidy.

Architecture

Share Trading

Users interact with prediction markets by buying and selling outcome shares:

M-of-N Dispute Resolution

Prediction markets use a multi-oracle dispute mechanism for outcome resolution:

1. Initial resolution: The designated oracle submits the outcome
2. Challenge period: Anyone can challenge the outcome by posting a dispute bond
3. Multi-oracle vote: If challenged, M-of-N designated resolvers vote on the correct outcome
4. Finalization: The majority-voted outcome becomes final; losing challengers forfeit their bond

LMSR Worked Example

Market Lifecycle

Use Cases for Prediction Markets

Prediction Markets vs Pool Betting

The SBET treasury is a hub-and-spoke smart contract system that manages all protocol funds with defense-in-depth security. It consists of a central Treasury.sol hub contract and seven specialized module contracts, each handling a specific financial operation with independent access controls and daily limits.

Hub-and-Spoke Architecture

Treasury Modules

Security Controls

Fund Flow

Token Metrics Tracking

The treasury system tracks comprehensive on-chain metrics for transparency and auditing:

struct TokenMetrics {
    uint256 totalDeposited;    // Cumulative inflows
    uint256 totalWithdrawn;    // Cumulative outflows
    uint256 totalFees;         // Cumulative fees collected
    uint256 lastUpdated;       // Block timestamp of last update
}

These metrics are queryable via the TreasuryFacade contract, enabling any external dashboard or analytics platform to display real-time treasury health.

Vesting Schedules

The VestingManager supports multiple vesting configurations for different stakeholder categories:

Budget Allocation

The 30% of protocol fees that flow to treasury operations are allocated across categories:

The Integrator Hub (IntegratorHub.sol) enables third-party platforms to build on top of SBET Protocol with built-in revenue sharing. Any developer or platform can register as an integrator and earn a share of the fees generated through their front-end.

Self-Service Registration

Integrator onboarding is fully permissionless:

1. Register: Call register() with integrator metadata (name, website, payout address)
2. Receive ID: The hub assigns a unique integrator ID used to attribute trades
3. Embed ID: Include the integrator ID when submitting orders through SBET Core
4. Earn fees: A configured percentage of each attributed trade's protocol fee flows to the integrator

Fee Sharing Model

Payout Sweeps

Integrator earnings accumulate in the hub contract and can be swept to the integrator's wallet at any time. Batch sweep operations allow multiple integrators to claim in a single transaction, reducing gas costs for the protocol operator.

Use Cases

Developer Incentive: The integrator model aligns incentives — the more volume an integrator drives, the more they earn. This creates a network of motivated distribution partners building the SBET ecosystem without any centralized business development effort.

Integrator Registration Flow

Integrator Dashboard

Each integrator can query their performance metrics via the IntegratorHub contract:

Integrator Tiers

As integrators grow their volume, they unlock higher fee shares:

Technical Integration Guide

Integrating with SBET requires minimal development effort:

// 1. Register as integrator (one-time)
const tx = await integratorHub.register("MyApp", "https://myapp.com", payoutAddress);
const integratorId = /* extract from event */;

// 2. Include integrator ID when submitting orders
const order = {
  ...standardOrder,
  // Integrator ID is passed as a parameter to the fill function
};
await sbetCore.fillOrder(order, signature, integratorId);

// 3. Sweep accumulated fees
await integratorHub.sweep(integratorId);

SBET Protocol integrates a dual-provider AI system that provides real-time market analysis, confidence scoring, and intelligent suggestions to users. The AI layer is strictly read-only — it never signs transactions or controls funds.

Dual-Provider Architecture

Users can switch between providers at runtime based on their preference. API keys are stored in sessionStorage only (tab-scoped, cleared on browser close) and are never sent to any SBET backend.

Key Features

Confidence Scoring

The AI system generates per-market confidence scores (0–100%) by analyzing:

• Current odds and implied probabilities across all available markets
• Odds movement patterns (sharp money indicators)
• Live match statistics (possession, shots, momentum) for in-play events
• Historical matchup data and form analysis
• Liquidity depth and market efficiency metrics

AI Suggestions

The system produces structured suggestions with:

interface AISuggestion {
  marketId: string;           // Target market
  pick: string;               // Recommended selection
  odds: number;               // Current odds
  confidence: number;         // 0–1 confidence score
  reason: string;             // Human-readable rationale
  kellyFraction: number;      // Kelly criterion fraction
  recommendedStake: number;   // Suggested stake size
}

Simulated Market Maker

The AI can simulate a market maker that continuously monitors markets and suggests liquidity actions:

Security Model

Market Context

The AI system receives a structured market context snapshot containing current matches, odds, live scores, wallet state, and open bet slip items. This context is sent directly to the AI provider from the user's browser — SBET servers never see the data.

Context Data Structure

The market context passed to the AI provider includes:

interface MarketContext {
  matches: Array<{
    id: string;
    lg: string;                // League
    home: string;              // Home team name
    away: string;              // Away team name
    status: string;            // "live", "upcoming", "finished"
    homeOdds: number;
    drawOdds?: number;
    awayOdds: number;
    homeLiq?: number;          // Home side liquidity
    awayLiq?: number;          // Away side liquidity
    minute?: number;           // Current minute (live only)
    homeScore?: number;
    awayScore?: number;
  }>;
  walletConnected: boolean;
  walletBalance: number;
  openSlip: Array<{ pick: string; odds: number; stake: string }>;
  networkName: string;
}

Kelly Criterion Integration

The AI system uses the Kelly Criterion for optimal bet sizing recommendations. The Kelly formula determines the fraction of bankroll to wager based on the edge and odds:

The AI applies a fractional Kelly approach (typically 25-50% of full Kelly) to reduce variance and account for estimation uncertainty. This conservative approach protects users from overbetting on high-confidence but potentially miscalibrated signals.

AI Ethics & Responsible Use

SBET is an ERC-20 token on Ethereum mainnet with a fixed, immutable supply of 3,500,000,000 (3.5 billion) tokens. There is no minting function — the total supply was set at deployment and can never increase.

Token Details

Token Allocation

Deflationary Mechanics

SBET implements a continuous burn mechanism that reduces the circulating supply over time:

Token Utility

Value Accrual: SBET's tokenomics create a virtuous cycle — more betting volume generates more fees, which drives more staking rewards (attracting holders), more token burns (increasing scarcity), and more integrator interest (driving more volume). This flywheel effect means the token's utility grows with protocol adoption.

Value Accrual Flywheel

Token Flow Diagram

Supply Schedule

With no minting and continuous burning, SBET's effective supply decreases over time:

SBET Protocol's fees are fully transparent and enforced on-chain. Unlike traditional sportsbooks that embed hidden margins (vig) into odds, SBET charges explicit, predictable fees that users can verify before placing any bet.

SBET Token Fee Advantage

The protocol incentivizes use of the native SBET token by offering a significantly lower fee rate compared to other ERC-20 tokens or ETH:

Why the discount? By using SBET as the betting collateral, users directly contribute to the token's velocity and utility. The 2% fee for SBET holders represents a 43% discount over the 3.5% standard rate — a powerful incentive that drives organic token demand while keeping fees lower than any competitor.

Fee Schedule

Fee Distribution

Comparison with Traditional Sportsbooks

Fee Advantage: SBET's peer-to-peer model eliminates the house edge entirely. The protocol charges just 2% when betting with the SBET token (or 3.5% with other tokens) — 3-7x lower than traditional sportsbooks. Moreover, 70% of fees flow back to the token ecosystem (staker rewards + burn), making SBET users the primary beneficiaries. Free cash back and zero withdrawal fees complete the low-cost picture.

Fee Economics Deep Dive

Understanding SBET's fee advantage requires comparing the total cost of placing a bet across different platform types:

Traditional Sportsbook Fee Breakdown

Fee Revenue Model

SBET's fee model creates sustainable revenue without extracting excessive value from users:

As the protocol scales across multiple chains and integrator partners, fee revenue grows proportionally — creating a direct link between ecosystem growth and token holder returns.

Fee Governance

Fee rates are governable parameters that can be adjusted through the governance process:

• Current: Multisig can adjust fee rates within defined bounds
• Phase 2: Token holder advisory vote on fee changes
• Phase 3: Full DAO governance of fee parameters

Fee changes are bounded by smart contract-enforced minimums and maximums to prevent governance attacks that could either extract excessive fees or eliminate protocol revenue entirely.

SBET's staking system allows token holders to earn a share of all protocol fees by locking their tokens. Stakers collectively receive 60% of all fees generated across every betting primitive — P2P trading, pool betting, NFT staking, and prediction markets.

Revenue Sharing Model

How Staking Works

1. Stake: Users deposit SBET tokens into the staking contract
2. Earn: Revenue from protocol fees accrues to stakers proportionally by share of total stake
3. Claim: Rewards can be claimed at any time without unstaking
4. Unstake: Users can withdraw their staked tokens (subject to any cooldown period)

Reward Sources

Staking Benefits

Yield Projection: As protocol volume grows, staking yields increase proportionally. With SBET's multi-primitive approach covering P2P trading, pool betting, NFT staking, and prediction markets, fee revenue is diversified across multiple sources — reducing dependency on any single market or event.

Staking Mechanics

The staking system is designed for simplicity and security:

Staking Security

Revenue Diversification

SBET staking yields are uniquely diversified because they draw from four independent betting primitives:

SBET Protocol is transitioning from a multisig-controlled governance model to a fully decentralized DAO. This progressive decentralization ensures security during the early protocol phase while building toward community-owned governance.

Current Model: Multisig Governance

The protocol is currently governed by a multisig arrangement managed through the MultisigManager.sol contract:

Planned: Full DAO Transition

Governable Parameters

Governance Parameter Details

DAO Transition Plan

The transition from multisig to full DAO governance is designed to be gradual and safe:

SBET Protocol underwent a comprehensive security audit conducted by Versus Security in February 2026, covering all 24 smart contracts, 25,000+ lines of Solidity code, and 883 test cases. The audit identified 146 findings across all severity levels, all of which have been addressed.

Audit Overview

Findings by Severity

Audit Methodology

Critical Fixes Applied

Audit Scope

The Versus Security audit covered every contract in the SBET protocol, including:

Test Coverage

The protocol's 883 test cases cover critical paths across all contract domains:

Ongoing Security Practices

• Continuous monitoring: Smart contract events monitored for anomalous behavior patterns
• Slither CI/CD: Static analysis runs on every commit to catch regressions
• Dependency auditing: Regular npm audit and OpenZeppelin version tracking
• Second audit planned: A follow-up audit is planned before protocol ossification (Phase 4)
• Bug bounty: Responsible disclosure program planned for launch

SBET Protocol consists of 24 production smart contracts organized across four functional domains. Each contract is independently audited, tested, and deployed.

Complete Contract List

Code Metrics

Contract Interaction Map

The following diagram shows how contracts interact with each other:

                    ┌─────────────────────┐
                    │     SBET.sol         │
                    │  (Core Entry Point)  │
                    └──────┬──────────┬────┘
                           │          │
              ┌────────────┤          ├────────────┐
              │            │          │            │
    ┌─────────▼────┐ ┌─────▼─────┐ ┌─▼──────────┐ │
    │ NFTManager   │ │ Prediction│ │ Integrator  │ │
    │              │ │ Market    │ │ Hub         │ │
    └──────┬───────┘ └─────┬─────┘ └────────────┘ │
           │               │                       │
    ┌──────▼───────┐ ┌─────▼─────┐           ┌────▼───────┐
    │  NFTVault    │ │ Prediction│           │  Treasury  │
    │  (Escrow)    │ │ AMM       │           │  (Hub)     │
    └──────────────┘ └───────────┘           └────┬───────┘
    ┌──────────────┐                               │
    │NFTFeeManager │                    ┌──────────┼──────────┐
    └──────────────┘                    │          │          │
                                   ┌───▼────┐ ┌───▼────┐ ┌──▼───────┐
                                   │Fee Mgr │ │Budget  │ │Vesting   │
                                   └────────┘ │Manager │ │Manager   │
                                              └────────┘ └──────────┘
    ┌──────────────┐                ┌────────┐ ┌────────┐ ┌──────────┐
    │ SBETQuery    │                │Yield   │ │Multisig│ │Donation  │
    │ (Read-only)  │                │Manager │ │Manager │ │Manager   │
    └──────────────┘                └────────┘ └────────┘ └──────────┘

Deployment Architecture

SBET Protocol is deployed on Ethereum mainnet for token operations and uses Ethereum's security guarantees as the foundation. The protocol's multi-chain strategy focuses on expanding to high-throughput Layer 2 networks while maintaining Ethereum mainnet as the canonical settlement and security layer.

Current Deployment

Expansion Roadmap

Cross-Chain Architecture

SBET will use battle-tested cross-chain messaging protocols for token bridging and state synchronization:

Multi-Chain Design Principles

• Canonical token on Ethereum: The SBET ERC-20 on mainnet remains the canonical token. All L2 tokens are bridged representations.
• Independent per-chain state: Each chain runs its own betting contracts with independent match and pool state.
• Unified treasury: Fees from all chains are periodically swept back to the Ethereum mainnet treasury.
• Chain-specific EIP-712 domains: Each deployment has its own chainId in the EIP-712 domain, preventing cross-chain order replay.

L2 Deployment Benefits

Lower transaction costs on L2s unlock use cases that are uneconomical on mainnet, such as micro-bets (small stake sizes), high-frequency pool adjustments, and real-time prediction market trading during live events.

Cross-Chain Security Considerations

SBET Protocol follows a phased development approach, with each milestone building on the previous one. The roadmap prioritizes security, user experience, and ecosystem growth.

2026 Milestones

2027 Vision

Key Performance Indicators

The SBET team tracks progress against the following KPIs at each milestone:

Development Methodology

Investors and users should carefully consider the following risk factors before participating in the SBET Protocol. The protocol team actively mitigates these risks through engineering, design choices, and operational practices.

Risk Matrix

Risk Mitigation Framework

SBET employs a layered defense strategy to address each risk category:

Emergency Response Protocol

Insurance & Coverage

SBET explores DeFi insurance options to provide additional protection layers for users:

• Smart contract cover: Working with DeFi insurance protocols to offer optional coverage against smart contract exploits
• Treasury reserve: 15% of treasury operations budget allocated as an emergency reserve for user compensation in extreme scenarios
• Bug bounty: Planned bounty program for responsible vulnerability disclosure, incentivizing white-hat security researchers

Core Contributors

SBET Protocol is developed by a distributed team of smart contract engineers, frontend developers, and protocol designers with deep experience in DeFi, sports technology, and cryptographic systems.

Open Source

SBET's frontend dApp is open source under the BUSL-1.1 license. The smart contracts are source-verified on Etherscan. Community contributions are welcome through the standard pull request process.

Community Channels

Engineering Culture

The SBET development team operates with a set of non-negotiable engineering principles:

Technology Stack

Open Source Contributions

The SBET team encourages community contributions in several areas:

• Frontend improvements: UI/UX enhancements, accessibility, internationalization
• Integrator tools: SDKs, example applications, documentation
• Analytics: Subgraph indexers, dashboards, data visualizations
• Testing: Additional test cases, edge case coverage, fuzzing seeds
• Security: Responsible vulnerability disclosure (bug bounty planned)

SBET has established a strong presence across major cryptocurrency exchanges and data platforms, providing liquidity, visibility, and credibility for the protocol.

Exchange Listings

Data & Analytics Partners

Media Coverage

Listing Strategy: SBET's exchange listing strategy focuses on Tier 1 exchanges to maximize liquidity, credibility, and user access. Each listing is paired with market making arrangements to ensure healthy order books and tight spreads.

Partnership Categories

Listing Timeline

Ecosystem Map

SBET's ecosystem extends beyond exchanges to include a comprehensive network of infrastructure and data partners:

Future Partnership Targets

Key Terms

General Notice

This whitepaper is provided for informational purposes only and does not constitute financial advice, investment advice, trading advice, or any other form of professional advice. The information contained herein should not be relied upon as a basis for making any investment decision.

No Offer or Solicitation

Nothing in this whitepaper constitutes an offer to sell, a solicitation to buy, or a recommendation for any security, token, investment product, or financial instrument. SBET tokens are utility tokens designed for use within the SBET Protocol ecosystem and should not be considered securities, investment contracts, or financial instruments.

Risk Acknowledgment

Cryptocurrency and decentralized finance involve substantial risk of loss. The value of SBET tokens may fluctuate significantly and may go to zero. Smart contracts, despite auditing, may contain undiscovered vulnerabilities. Users should:

• Only use funds they can afford to lose entirely
• Conduct their own research and due diligence
• Consult qualified financial, legal, and tax advisors
• Understand the technical risks of interacting with smart contracts
• Be aware of regulatory requirements in their jurisdiction

Forward-Looking Statements

This whitepaper contains forward-looking statements regarding the SBET Protocol's planned development, features, and milestones. These statements reflect current expectations and are subject to significant risks and uncertainties. Actual results may differ materially from those expressed or implied. The SBET team makes no guarantees regarding the completion of any roadmap items or the achievement of any projected metrics.

Regulatory Compliance

The regulatory landscape for cryptocurrency and decentralized betting varies by jurisdiction and is subject to change. It is the responsibility of each user to determine whether their use of the SBET Protocol complies with applicable laws and regulations in their jurisdiction. The SBET Protocol is a decentralized technology platform and does not provide or endorse any gambling services.

Intellectual Property

The SBET Protocol smart contracts and frontend application are released under the Business Source License 1.1 (BUSL-1.1). The SBET name, logo, and brand assets are the property of the SBET Protocol contributors.

No Warranty

The SBET Protocol is provided "as is" without warranty of any kind, express or implied. The contributors and developers disclaim all warranties including but not limited to merchantability, fitness for a particular purpose, and non-infringement. In no event shall the contributors be liable for any direct, indirect, incidental, special, or consequential damages arising from the use of the protocol.