Players wager against the house (liquidity provided by BetSwirl or their partners) in randomized games of chance, such as coin tosses or dice rolls.

Betswirl is a non-custodial betting platform built on Polygon, BNB Chain, and Avalanche. BetSwirl was co-founded by Romuald Hog and Nato, and was launched in March 2022.

The BetSwirl team own and govern the protocol. They and BETS holders currently receive all fees paid by players (revenue).

github

twitter

discord

etherscan

website

Prediction markets

BetSwirl

# BetSwirl Revenue Methodology

## 1. Overview

Betswirl revenue represents the total fees collected by the Betswirl prediction markets protocol from betting activities. The metric captures house edge amounts that are allocated across different recipients including dividends to token holders, treasury reserves, team payments, partner rewards, and bank reserves. Revenue is calculated by aggregating fee allocation events from both regular betting contracts and Russian Roulette game contracts across multiple blockchains and protocol versions, then converting to USD values on a daily basis.

## 2. Data sources

- **Blockchain events**: Parsed `AllocateHouseEdgeAmount` events from Betswirl Bank contracts on BSC, Polygon, Avalanche, and Arbitrum across protocol versions v1 through v4
- **Blockchain events**: Parsed `AllocateHouseEdgeAmount` events from Betswirl Russian Roulette contracts on Arbitrum, Avalanche, BSC, and Polygon for v1 protocol
- **External data**: End-of-day token price feeds for USD conversion of various tokens including native tokens and BETS tokens
- **Token metadata**: Token symbol and decimal precision information for proper amount calculations and display
- **Configuration data**: Chain availability settings that determine which chains are included in final results

## 3. Step-by-step calculation

### Component A: Regular betting revenue allocation extraction
- **Purpose**: Extracts and standardizes fee allocation data from main Betswirl betting contracts across different protocol versions
- **Logic**: Queries parsed `Bank_AllocateHouseEdgeAmount` events from BSC and Polygon (v1), Avalanche and BSC (v2), and multiple chains including Arbitrum (v3/v4). Each protocol version has different fee allocation structures - v1 includes `dividend_amount`, `treasury_amount`, `team_amount`, and `referral_amount` fields; v2 adds `partner_amount`; v3/v4 replace referral with `bank_amount` and retain partner amounts. Events are filtered by distinct transaction hash and log index to avoid duplicates, with chain and version information added based on the source schema
- **Key fields**: `block_timestamp` for timing, `token_address` for the fee token, various amount fields (`dividend_amount`, `treasury_amount`, etc.) that represent different fee allocations, `transaction_hash` and `log_index` for event identification

### Component B: Russian roulette revenue allocation extraction  
- **Purpose**: Captures fee allocation data specifically from Russian Roulette game contracts which have different allocation structures
- **Logic**: Queries parsed `RussianRoulette_AllocateHouseEdgeAmount` events from Arbitrum, Avalanche, BSC, and Polygon for v1 protocol. These events include `dividend_amount`, `treasury_amount`, `team_amount`, and `initiator_amount` fields, where initiator amount represents fees paid to game initiators. Events are deduplicated by transaction hash and log index, with chain and version metadata added
- **Key fields**: `block_timestamp` for timing, `token_address` for fee token, allocation amounts (`dividend_amount`, `treasury_amount`, `team_amount`, `initiator_amount`), transaction identifiers for deduplication

### Component C: Fee aggregation and token address normalization
- **Purpose**: Aggregates individual fee allocations into daily totals and normalizes token addresses for accurate price lookups
- **Logic**: For regular betting fees, sums all allocation amounts (dividend + treasury + team + referral/partner/bank depending on version) grouped by day, chain, token, and other dimensions. For Russian Roulette fees, sums dividend + treasury + team amounts while tracking initiator amounts separately. Applies token address mapping logic: converts null addresses (representing native tokens) to wrapped token addresses for price calculations (ETH to WETH on Arbitrum, AVAX to WAVAX on Avalanche, BNB to WBNB on BSC, MATIC to WMATIC on Polygon), and maps Arbitrum BETS token address to Polygon BETS address due to better liquidity for pricing
- **Key fields**: Daily aggregated `amount` values, normalized `token_address` for price lookups, `chain` and `real_chain` for cross-chain price resolution

### Component D: Revenue consolidation and standardization
- **Purpose**: Combines regular betting and Russian Roulette revenues and applies standardization processes
- **Logic**: Unions aggregated fee data from both regular betting and Russian Roulette sources into a single revenue dataset. Applies the finalize metric macro which corrects token decimals based on token metadata, converts amounts to USD using end-of-day price feeds, fills missing date ranges with zero values for consistent time series, and populates project metadata fields. The process groups by timestamp, chain, business line, and other dimensional fields while summing the revenue expression
- **Key fields**: Combined `revenue` amounts, standardized `timestamp` and dimensional fields, USD-converted values with proper decimal correction

### Final aggregation
- **Combining components**: Regular betting fees and Russian Roulette fees are unioned together with identical schema structure, then processed through standardization macros
- **Currency conversion**: Token amounts are converted to USD using end-of-day price feeds, with special handling for cross-chain token price lookups (e.g., Arbitrum BETS uses Polygon pricing)
- **Time aggregation**: All revenue events are truncated to daily boundaries using timestamp truncation, with missing days filled with zero values to ensure complete time series
- **Final calculation**: Total daily revenue equals the sum of all fee allocation amounts (dividend + treasury + team + referral/partner/bank + initiator where applicable) converted to USD, filtered by chain availability settings, and aggregated by day, chain, and other business dimensions

*This methodology was automatically generated by Token Terminal's methodology analyzer.*

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

BetSwirlBETS

Archived

Revenue

Revenue

Competitive landscape

Chain breakdown