Users deposit ETH or LSTs on Ethena and can mint a USDe synthetic stablecoin in return. USDe generates yield from the staked Ethereum as well as the funding & basis spread from perpetual and futures' markets. A portion of this yield is then distributed to USDe stakers (expense).

Ethena is a stablecoin issuer and asset management protocol built on Ethereum. Ethena was founded by Guy Young and launched in 2024.

ENA tokenholders own and govern the protocol. They currently take a cut of the total yield generated (revenue). Ethena's investors include Dragonfly, Franklin Templeton, Brevan Howard Digital, etc.

github

twitter

website

etherscan

Stablecoin issuers

Ethena

# Ethena Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with Ethena protocol products within any 30-day rolling window. This metric tracks user engagement across Ethena's stablecoin ecosystem, including Ethena USDe minting/redemption activities and USDtb token operations. The calculation uses HyperLogLog aggregation to efficiently count distinct users across multiple dimensions while maintaining accuracy for large user sets.

## 2. Data sources

The MAU calculation relies on the following blockchain data sources:

- **Ethereum token transfer events**: `Transfer` events for the USDtb token contract (`0xc139190f447e929f090edeb554d95abb8b18ac1c`), used to identify minting and burning activities
- **Parsed Ethena contract events**: `Mint` and `Redeem` events from the Ethena v1 Minter contract on Ethereum, capturing Ethena USDe issuance and collateral redemption activities
- **Transaction metadata**: Ethereum block timestamps and transaction hashes for temporal and transactional context
- **User interaction data**: Ethereum addresses from event logs representing users performing protocol operations

## 3. Step-by-step calculation

### Component A: USDtb mint identification
- **Purpose**: Identifies USDtb token minting events from transfer data
- **Logic**: Filters `Transfer` events for the USDtb token contract where the `from_address` is the null address (`0x0000000000000000000000000000000000000000`), indicating new token creation. Extracts the recipient address (`to_address`), transaction metadata, and transfer amount. Classifies these operations under the 'usdtb' product with user type 'Depositor'.
- **Key fields**: `to_address` as user identifier, `amount` as transfer value, `block_timestamp` for timing

### Component B: USDtb redemption identification  
- **Purpose**: Identifies USDtb token burning events from transfer data
- **Logic**: Filters `Transfer` events for the USDtb token contract where the `to_address` is either the null address or dead address (`0x000000000000000000000000000000000000dead`), indicating token destruction. Extracts the sender address (`from_address`), transaction metadata, and transfer amount. Classifies these operations under the 'usdtb' product with user type 'Withdrawer'.
- **Key fields**: `from_address` as user identifier, `amount` as transfer value, `block_timestamp` for timing

### Component C: Ethena USDe user activity identification
- **Purpose**: Identifies users interacting with Ethena USDe minting and redemption
- **Logic**: Parses `Mint` events from the Ethena Minter contract to extract the `benefactor` field as the user address, classifying them as 'Depositor' user type under the 'Ethena USDe' product. Similarly processes `Redeem` events to identify users withdrawing collateral, classifying them as 'Withdrawer' user type. Combines both event types with transaction timestamps and chain identification.
- **Key fields**: `benefactor` as user identifier from contract events, `block_timestamp` for timing

### Component D: Daily active user aggregation
- **Purpose**: Consolidates all user interactions into daily distinct active user counts
- **Logic**: Combines USDtb mints, redemptions, and Ethena USDe activities into a unified user activity dataset. Groups interactions by daily timestamp boundaries (using `timestamp_trunc` to day level), chain, user type, and product ID. Creates distinct user address counts for each combination, establishing the foundation for MAU calculation.
- **Key fields**: Daily `timestamp`, `chain`, `user_type`, `product_id`, distinct `user_address` count

### Component E: HyperLogLog initialization and windowing
- **Purpose**: Prepares daily user data for efficient 30-day rolling aggregation
- **Logic**: Converts daily distinct user sets into HyperLogLog sketches with precision parameter 15 for scalable set operations. Creates a complete datespine covering all days from the earliest data to yesterday. Generates 30-day join arrays for each day, creating relationships between each target day and its preceding 29 days. Joins the datespine with HLL-encoded daily user data to build comprehensive 30-day windows.
- **Key fields**: HLL-encoded user sets (`hll`), 30-day date ranges (`joinday` arrays)

### Component F: Multi-dimensional MAU calculation
- **Purpose**: Calculates MAU across different analytical dimensions
- **Logic**: Processes the 30-day windowed data through four parallel aggregation paths:
  1. **Project-level MAU**: Merges all HLL sketches regardless of chain, product, or user type to get total protocol MAU
  2. **Chain-level MAU**: Groups by chain to show MAU distribution across different blockchains
  3. **User type MAU**: Groups by user type ('Depositor' vs 'Withdrawer') to show engagement patterns
  4. **Product-level MAU**: Groups by product ID ('Ethena USDe' vs 'usdtb') to show product-specific adoption
  
  Each dimension uses HLL merge operations (`hll_count.merge_partial`) to combine user sets within the 30-day window, then extracts final distinct counts (`hll_count.extract`).
- **Key fields**: Dimension-specific `user_mau` counts, null-safe dimension identifiers

### Final aggregation
- **Combining components**: All dimensional MAU calculations are combined using `union all` operations to create a comprehensive MAU dataset with consistent schema across dimensions
- **Schema standardization**: The `finalize_metric_user_mau` macro applies consistent formatting, fills missing periods with zeros according to the fill strategy, and ensures proper data typing and metadata assignment
- **Time boundaries**: Incremental processing uses monthly partition boundaries with configurable lookback periods to ensure data freshness while maintaining historical accuracy
- **Final calculation**: Each row represents MAU for a specific day and dimensional combination, calculated as the distinct count of users active within the 30-day period ending on that day

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

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

EthenaENA

Active users (monthly)

Active users (monthly)

Competitive landscape

Chain breakdown