Fraxtal batches users' transactions and submits them to Ethereum, paying a share of the transaction fees to Ethereum validators (expense).

Fraxtal is an Ethereum Layer 2 (L2) blockchain built on the OP Stack by Frax Finance. It uses frxETH as the gas token and features a blockspace incentive system called Flox. Fraxtal launched in February 2024.

Frax Finance team owns and governs the protocol. Frax Finance's investors include Dragonfly Capital, Mechanism Capital, Galaxy Digital, etc.

twitter

discord

etherscan

website

Blockchains (L2)

Fraxtal

# Fraxtal Active addresses (monthly) Methodology

## 1. Overview

Monthly active addresses measures the number of unique addresses that initiated at least one transaction on the Fraxtal blockchain within any 30-day rolling window. This metric answers the business question "How many distinct users are actively engaging with the Fraxtal network on a monthly basis?" The calculation treats each transaction sender address as an active user and uses HyperLogLog probabilistic data structures to efficiently count distinct addresses across rolling monthly windows.

## 2. Data sources

The metric relies on the following underlying data sources:
- **Fraxtal transaction records**: Complete transaction history from the Fraxtal blockchain containing transaction timestamps, transaction hashes, and sender addresses
- **Chain metadata**: Configuration data that classifies Fraxtal as a Layer 2 blockchain in the blockchain business segment

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identify and classify all transaction senders as active users
- **Logic**: Raw Fraxtal transaction records are processed to extract key transaction details. Each transaction sender address (`from_address`) is treated as an active user with the classification "Transaction sender". The system adds blockchain metadata including chain identifier "fraxtal", market sector "blockchains_l2", and business segment "blockchain". Transaction timestamps are cast to proper timestamp format and transaction hashes are converted to strings for consistency.
- **Key fields**: `block_timestamp` (transaction time), `transaction_hash` (unique transaction identifier), `from_address` (sender address treated as user), `chain` (blockchain identifier), `user_type` (classification as "Transaction sender")

### Component B: Daily active user calculation  
- **Purpose**: Calculate daily snapshots of distinct active users
- **Logic**: Transaction data is grouped by day using timestamp truncation to day boundaries. For each day, the system counts distinct sender addresses that initiated transactions, treating each unique address as one daily active user. The calculation preserves dimensional breakdowns including chain, user type, and product identifiers while creating daily user activity snapshots.
- **Key fields**: `timestamp` (day boundary), `user_address` (distinct sender address), `user_dau` (daily active user identifier)

### Component C: Rolling monthly window construction
- **Purpose**: Build 30-day rolling windows for monthly active user calculation
- **Logic**: A datespine approach creates the foundation for rolling monthly calculations. The system generates a complete sequence of daily timestamps from the earliest transaction date to yesterday. For each day in this sequence, it creates a 30-day lookback window by generating timestamps from 29 days prior to the current day. This creates overlapping windows where each day represents the end of a unique 30-day period. Daily user data is converted to HyperLogLog sketches with precision 15 to enable efficient distinct counting across large datasets.
- **Key fields**: `timestamp` (window end date), `joinday` (each day within the 30-day window), `hll` (HyperLogLog sketch of daily users)

### Component D: Monthly active user aggregation
- **Purpose**: Count distinct users across 30-day rolling windows using probabilistic methods
- **Logic**: For each 30-day window, the system merges HyperLogLog sketches from all days within the window using HyperLogLog merge operations. This probabilistic approach efficiently handles the challenge of counting distinct users who may be active on multiple days within the month. The merged sketches are then processed to extract the final distinct user count. The calculation produces multiple dimensional breakdowns including chain-level aggregation (users across the entire Fraxtal chain), project-level aggregation (users across the project), user-type-level aggregation (users by transaction type), and product-level aggregation (users by specific products).
- **Key fields**: `user_mau` (monthly active users count), `dimensions` (aggregation level), `chain_id` (chain identifier), `user_type` (user classification)

### Final aggregation
- **Combining components**: The monthly active user calculation is filtered to include only chain-level and project-level dimensions, excluding user-type and product-level breakdowns for the final active addresses metric
- **Currency conversion**: Not applicable - this metric counts addresses rather than monetary values
- **Time aggregation**: Uses rolling 30-day windows where each day represents the end date of a unique monthly period, providing daily updates of monthly active address counts
- **Final calculation**: The `user_mau` field is renamed to `active_addresses_monthly` to represent the final metric value. Missing periods are filled with zero values using the finalize metric macro, and chain availability filters ensure data quality and consistency across the reporting period.

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

Unique addresses active over a rolling 30-day window.

FraxtalFXTL

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown