Liquidity providers deposit funds into Biswap and receive trading fees from traders (supply-side fees).

Biswap is a non-custodial exchange protocol built on BNB chain. Biswap was founded by an anonymous team and launched in 2021.

BSW tokenholders own and govern the protocol. They currently take a cut of the total trading fees paid by traders (revenue). Biswap’s investors include Binance Labs.

github

twitter

etherscan

website

Exchanges (DEX)

Biswap

# Biswap Tradeable pairs Methodology

## 1. Overview

The Biswap tradeable pairs metric measures the cumulative number of unique trading pairs available on the Biswap decentralized exchange. This metric tracks the growth of trading pair availability over time by counting each new trading pair when it's first created and maintaining a running total. The metric answers the business question: "How many trading pairs are available for trading on Biswap as of any given day?"

The calculation approach identifies new trading pair creation events from Biswap factory contracts, processes them daily, and maintains a cumulative count that represents the total number of tradeable pairs available on the platform.

## 2. Data sources

- **Blockchain events**: Parsed BSC blockchain event logs from Biswap factory contracts, including `Factory_NewPool` events from v3 contracts and `Factory_PairCreated` events from v1 contracts
- **Token metadata**: Token reference data containing symbols, decimals, and contract addresses for BSC tokens
- **Factory contract data**: Biswap v1 and v3 factory contract events that emit pair creation information with token addresses and fee structures

## 3. Step-by-step calculation

### Component A: Trading pair extraction
- **Purpose**: Extracts all unique trading pairs from Biswap factory contract events across v1 and v3 versions
- **Logic**: Processes `Factory_NewPool` events from v3 contracts to capture new pool creations with dynamic fee tiers stored in the `fee` field. Also processes `Factory_PairCreated` events from v1 contracts with hardcoded fee structures (0.2% for regular pairs, 0.1% for specific stable pools). Extracts `tokenX` and `tokenY` addresses from v3 events, and `token0` and `token1` addresses from v1 events. Applies special fee tier logic for three hardcoded stable pool addresses that use 0.1% instead of the standard 0.2% fee
- **Key fields**: `block_timestamp` for creation timing, `account_address` for unique pair identification, `token0_address` and `token1_address` for the paired tokens, `fee_tier` calculated from event data or hardcoded values

### Component B: Token metadata enrichment
- **Purpose**: Adds token symbols and decimals to create human-readable pair names and enable proper token handling
- **Logic**: Joins the trading pair data with token metadata using token contract addresses and chain identifiers. Creates `account_name` by concatenating token symbols with a hyphen separator. Adds `token0_decimals` and `token1_decimals` for proper token amount calculations
- **Key fields**: `symbol` fields from token metadata, `decimals` for each token, concatenated `account_name` for pair identification

### Component C: Daily pair creation tracking
- **Purpose**: Identifies when each trading pair first appeared and counts new pairs created each day
- **Logic**: Groups trading pairs by `account_address` and finds the minimum `block_timestamp` for each pair, truncated to daily boundaries. This identifies the first appearance date for each unique trading pair. Then aggregates by day to count how many new pairs were created on each date
- **Key fields**: `timestamp` truncated to day level, `pair_count` representing new pairs created each day

### Component D: Time series gap filling
- **Purpose**: Ensures continuous daily time series by filling missing dates with zero values
- **Logic**: Uses gap-filling logic to create entries for all days in the time range, setting `pair_count` to zero for days when no new trading pairs were created. This maintains data completeness for cumulative calculations
- **Key fields**: `timestamp` for continuous daily series, `pair_count` with zeros filled for missing days

### Final aggregation
- **Combining components**: The daily new pair counts are processed through a cumulative sum calculation partitioned by chain and ordered by timestamp
- **Time aggregation**: Data is aggregated at daily boundaries using timestamp truncation to day level
- **Final calculation**: The `tradeable_pairs` field is calculated as a running sum of daily new pair counts, representing the total cumulative number of unique trading pairs available as of each day. The finalization macro applies schema validation, ensures proper data types, and applies any necessary gap-filling strategies using a 'fill_zeros' approach for missing data points

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

Number of unique token pairs available for trading on the exchange.

BiswapBSW

Tradeable pairs

Tradeable pairs

Competitive landscape