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 Expenses Methodology

## 1. Overview

Betswirl expenses represent token-based incentives paid to users by the protocol. This metric measures the cost of user acquisition and retention programs through token rewards, airdrops, or other incentive mechanisms. For Betswirl, the current methodology sets all expenses to zero, indicating the protocol does not currently operate token incentive programs. The metric inherits its time series structure from the protocol's fee calculation to ensure consistent coverage across all active chains and time periods.

## 2. Data sources

The expenses calculation is built upon the following data sources:

- **Betswirl revenue allocation events**: Parsed `Bank_AllocateHouseEdgeAmount_event` logs from Betswirl contracts across versions v1-v4 on BSC, Polygon, Avalanche, and Arbitrum networks
- **Russian Roulette allocation events**: Parsed `RussianRoulette_AllocateHouseEdgeAmount_event` logs from Betswirl v1 contracts on Arbitrum, Avalanche, BSC, and Polygon
- **End-of-day token price feeds**: Used in the underlying fee structure for USD conversion capabilities
- **Token metadata**: Symbol and decimal information for proper token handling and display

## 3. Step-by-step calculation

### Component A: Revenue allocation event processing
- **Purpose**: Extract and process all revenue allocation events from Betswirl's various contract versions and game types
- **Logic**: Parse `Bank_AllocateHouseEdgeAmount_event` logs from Betswirl contracts v1-v4 across multiple chains, extracting allocation amounts for different stakeholders including `dividend_amount`, `treasury_amount`, `team_amount`, `referral_amount`, `partner_amount`, and `bank_amount` fields. Also process `RussianRoulette_AllocateHouseEdgeAmount_event` logs with additional `initiator_amount` field. Filter events by contract version and chain, handling differences in allocation field availability across versions
- **Key fields**: Event timestamp (`block_timestamp`), transaction identifiers, chain information, token addresses, and various allocation amount fields that vary by contract version

### Component B: Token address normalization
- **Purpose**: Standardize token addresses for consistent price lookups and cross-chain handling
- **Logic**: Convert null addresses (native tokens) to their wrapped equivalents using predefined mappings for each chain. For Arbitrum's null address, use wrapped ETH address `0x82af49447d8a07e3bd95bd0d56f35241523fbab1`. For Avalanche, use WAVAX address `0xb31f66aa3c1e785363f0875a1b74e27b85fd66c7`. For BSC, use WBNB address `0xbb4cdb9cbd36b01bd1cbaebf2de08d9173bc095c`. For Polygon, use WMATIC address `0x0d500b1d8e8ef31e21c99d1db9a6444d3adf1270`. Special handling for BETS token on Arbitrum, mapping to Polygon BETS address for better price liquidity
- **Key fields**: Original `token_address` field transformed to standardized token addresses for price calculations

### Component C: Fee aggregation and structure creation
- **Purpose**: Aggregate all revenue allocation amounts to create daily fee totals that serve as the structural foundation
- **Logic**: Sum all allocation amounts from both regular Betswirl games and Russian Roulette games by day, chain, and token. Combine supply-side fees (from Russian Roulette `initiator_amount`) with protocol revenue (sum of all other allocation amounts). Group results by timestamp truncated to day, chain, and product identifiers to create a consistent time series structure
- **Key fields**: Daily aggregated `fees` amounts, `timestamp` truncated to day grain, `chain_id`, and `product_id` for grouping

### Component D: Token incentives assignment
- **Purpose**: Set token incentive amounts for the expense calculation
- **Logic**: Use the fee aggregation structure as a foundation and assign zero values to the `token_incentives` field for all records. This approach ensures expenses data exists for all time periods and chains where Betswirl has recorded activity, while explicitly indicating that no token incentives are currently provided
- **Key fields**: `token_incentives` field set to 0, inheriting `timestamp`, `timestamp_grain`, `chain_id`, and `product_id` from fee structure

### Final aggregation
- **Combining components**: The token incentives (set to zero) are directly used as the expenses value without additional aggregation needed
- **Currency conversion**: No currency conversion is required since all values are zero, but the underlying structure maintains USD conversion capabilities through the fee calculation foundation
- **Time aggregation**: Daily grain maintained throughout, with proper timestamp truncation to day boundaries
- **Final calculation**: Expenses equal the token incentives amount, which is consistently zero across all records, indicating Betswirl does not currently operate token-based incentive programs

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

Total project operating and incentive expenses.

BetSwirlBETS

Archived

Expenses

Expenses

Competitive landscape

Chain breakdown