Synapse allows users to send tokens from one chain to another almost immediately by using AMMs deployed across 16+ EVM and non-EVM blockchains. 

Synapse is a cross-chain liquidity network that enables fully non-custodial transfers between EVM and non-EVM compatible chains and L2 systems. Synapse was launched in 2021.

SYN tokenholders own and govern the protocol. They currently take a cut of the transaction fees paid by the users (revenue). Synapse’s investors include CMS Holdings, Alameda Research, Primitive Ventures, etc.

github

twitter

discord

etherscan

website

Bridges

Synapse

# Synapse Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) for Synapse measures the number of unique users who performed cross-chain bridge transactions within any 30-day rolling window. This metric quantifies user engagement with Synapse's bridge infrastructure across multiple blockchains and provides insights into protocol adoption and retention patterns.

The calculation uses HyperLogLog sketching for efficient distinct user counting and generates multiple dimensional breakdowns including project-level totals, individual chains, user types, and products.

## 2. Data sources

- **Synapse bridge events**: Parsed smart contract events from Synapse bridge contracts deployed across 8 blockchains (Ethereum, Arbitrum, Optimism, Base, Polygon, Avalanche, Fantom, BSC)
- **Bridge operation events**: Multiple event types including `TokenMint`, `TokenMintAndSwap`, `TokenWithdraw`, `TokenWithdrawAndRemove`, `TokenDepositAndSwap`, `TokenRedeemAndSwap`, `TokenRedeemAndRemove`, `TokenRedeem`, `TokenRedeemV2`, and `TokenDeposit`
- **CCTP events**: Circle Cross-Chain Transfer Protocol events (`CircleRequestFulfilled` and `CircleRequestSent`) on supported chains (Ethereum, Arbitrum, Optimism, Avalanche)
- **Transaction metadata**: Blockchain transaction records containing timestamps and transaction hashes

## 3. Step-by-step calculation

### Component A: User extraction from bridge events
- **Purpose**: Identifies all users who performed cross-chain bridge operations
- **Logic**: Extracts user addresses from various Synapse bridge event parameters across all supported chains. Events capture deposit operations (where users send tokens to be bridged), withdrawal operations (where users receive tokens on destination chains), mint/redeem operations (for synthetic token bridges), and swap operations (combined bridge and AMM swaps). CCTP events track Circle's native USDC transfers. User addresses are extracted from different event parameters: `to` field for mint/withdraw events, `sender` field for CCTP sent events, and `recipient` field for CCTP fulfilled events. All users are classified as `user_type` 'Trader'
- **Key fields**: `block_timestamp` for timing, `transaction_hash` for deduplication, `chain` for chain identification, `user_address` for user counting, and classification fields like `market_sector_id` ('bridges'), `business_segment_id` ('amm'), and `user_type` ('Trader')

### Component B: Daily active user aggregation
- **Purpose**: Converts individual bridge events into daily distinct user counts
- **Logic**: Aggregates the extracted user addresses by truncating timestamps to day granularity and taking distinct users per day. Groups data by chain, user type, and product dimensions to enable later breakdowns. Each day's data contains the unique set of users who performed any bridge operation on that specific day
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` ('day'), `chain`, `user_type`, `product_id`, and `user_dau` (the distinct user address)

### Component C: HyperLogLog sketch initialization
- **Purpose**: Converts daily active users into HyperLogLog sketches for efficient aggregation
- **Logic**: Initializes HyperLogLog sketches for each day's user count using precision 15. HLL sketches enable approximate distinct counting that scales efficiently for large datasets and can be merged across time windows without double-counting users who appear on multiple days
- **Key fields**: `hll` (HyperLogLog sketch), maintaining all dimensional groupings from the DAU data

### Component D: 30-day rolling window creation
- **Purpose**: Creates overlapping 30-day windows for MAU calculation
- **Logic**: Uses a datespine approach to ensure complete time series coverage. For each day in the date range, generates the previous 29 days to create a 30-day lookback window. Joins the datespine with daily HLL sketches to create a window dataset where each day is associated with its own HLL sketch and the sketches from the previous 29 days. This approach ensures no days are skipped even if there were no users on certain days
- **Key fields**: `timestamp` (the end date of the 30-day window), `joinday` (each day within the window), and associated dimensional fields and HLL sketches

### Component E: MAU calculation through HLL merging
- **Purpose**: Calculates distinct users across each 30-day window
- **Logic**: For each 30-day window, merges all HLL sketches from the window period using `hll_count.merge_partial()` and extracts the final distinct count using `hll_count.extract()`. This provides an approximate count of distinct users who were active at any point during the 30-day period, effectively calculating MAU for each day
- **Key fields**: `user_mau` (the extracted distinct user count from merged HLL sketches)

### Component F: Dimensional breakdowns
- **Purpose**: Creates multiple views of MAU data for different analysis needs
- **Logic**: Generates four separate breakdowns by aggregating the MAU windows differently: project-level (combining all chains and dimensions), by individual chain, by user type, and by product. Each breakdown sets irrelevant dimensions to null and groups by the relevant dimension. Uses UNION ALL to combine all breakdowns into a single dataset
- **Key fields**: `dimensions` (indicates the breakdown type), with relevant dimensional fields populated and others set to null

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a single comprehensive dataset
- **Schema standardization**: The `finalize_metric_user_mau` macro applies standardized schema, adds metadata fields like `data_id` ('synapse'), and implements the fill strategy
- **Time boundary handling**: Uses incremental processing with monthly partitions and safety margins for data freshness
- **Final calculation**: Each row represents the MAU for a specific date and dimensional combination, calculated as the distinct count of users active within the 30-day window ending on that date

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

Unique revenue-generating users over a rolling 30-day window.

SynapseSYN

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown