# User Wau Methodology

## 1. Overview

Active users (weekly) is defined as the number of unique addresses that make a revenue-generating transaction with a project over a 7-day rolling window. For Meteora Liquidity Pools, this metric is used to gauge user engagement, adoption, and overall economic activity within the dynamic automated market maker (AMM) and dynamic liquidity market maker (DLMM) pools. By tracking the weekly count of unique transaction signers, the growth and retention of the user base can be analyzed over time. Only trades occurring within the dynamic AMM and DLMM pools that do not originate from bonding curve graduations and are not flagged as inorganic wash trading are attributed to Meteora Liquidity Pools.

## 2. Data sources

- **Blockchain events**: Trade instructions from the dynamic automated market maker programs (`Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB` and `cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`) and the dynamic liquidity market maker program (`LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`), `DBC_Migration` instructions from the bonding curve program, and asset balance changes from vault accounts, covering Solana

## 3. Step-by-step calculation

### Component A: Trade extraction and program filtering

- **Purpose**: Extract raw trade data and filter for Meteora dynamic AMM and DLMM programs
- **Logic**: Trade instructions are parsed from Solana decentralized exchange trade records. Transactions are filtered to include only those where the executing account or outer executing account matches the dynamic AMM V1 program (`Eo7WjKq67rjJQSZxS6z3YkapzY3eMj6Xy8X5EQVn5UaB`), the dynamic AMM V2 program (`cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`), or the dynamic liquidity market maker program (`LBUZKhRxPF3XUpBCjp4YzTKgLccjZhTSDM9YuVaPwxo`). For each trade, the transaction signer, pool account, and block timestamp are extracted.
- **Key fields**: `block_timestamp` (timing), `signer` (user identification), `pool_address` (pool account identification)

### Component B: Pool origin verification and product attribution

- **Purpose**: Exclude graduated bonding curve pools to isolate Meteora Liquidity Pools
- **Logic**: `DBC_Migration` instructions from the bonding curve program are analyzed to identify liquidity pools that originated from a bonding curve graduation. These graduated pools are mapped to a pool origin dimension. During product attribution, trades occurring in pools identified as graduated are routed to Meteora Launchpad. Only trades occurring in dynamic AMM pools that do not have a matching graduation record, along with all DLMM trades, are attributed to Meteora Liquidity Pools.
- **Key fields**: `pool_address` (pool account identification), `instruction_type` (migration type)

### Component C: Wash trading filtration

- **Purpose**: Exclude inorganic trading activity from dynamic AMM V2 pools
- **Logic**: Weekly quote-leg trading volume is compared against weekly quote-leg reserves for dynamic AMM V2 pools. Pool-weeks where the weekly volume exceeds 20 times the reserve are flagged as wash trading. Trades occurring in these flagged pool-weeks are excluded from the active user calculation.
- **Key fields**: `pool_address` (pool account identification), `timestamp` (timing), `turnover` (volume-to-reserve ratio)

### Component D: Weekly unique user aggregation

- **Purpose**: Calculate the weekly count of unique active users
- **Logic**: The transaction signers associated with the attributed Meteora Liquidity Pools trades are aggregated. The number of unique transaction signers is calculated over a 7-day rolling window, truncated to UTC day boundaries. The active users (weekly) metric is generated for the product.
- **Key fields**: `block_timestamp` (timing), `signer` (user identification)

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

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

Active users (weekly)