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

Gravity Alpha is an L2 smart contract platform for decentralized applications on Ethereum. Gravity Alpha was founded by Galxe and launched in 2024.

G tokenholders own and govern the protocol. Galxe's investors include Arbitrum Foundation, Multicoin Capital, Dragonfly Capital, etc.

github

twitter

discord

website

Blockchains (L2)

Gravity Alpha Mainnet

# Gravity Alpha Mainnet Active addresses (monthly) Methodology

## 1. Overview

GravityAlpha's monthly active addresses metric measures the number of unique wallet addresses that have sent at least one transaction on the GravityAlpha blockchain within a rolling 30-day period. This metric serves as a key indicator of user engagement and network activity. The calculation uses HyperLogLog probabilistic data structures to efficiently compute unique address counts across overlapping time windows, providing an approximate but highly accurate count of distinct users.

## 2. Data sources

- **GravityAlpha transaction records**: Raw blockchain transaction data containing sender addresses, receiver addresses, timestamps, gas usage, and transaction metadata
- **Table modification metadata**: Timestamps tracking when source tables were last updated, used for efficient incremental processing

## 3. Step-by-step calculation

### Component A: Transaction processing
- **Purpose**: Extract and standardize raw transaction data from the GravityAlpha blockchain
- **Logic**: Process all GravityAlpha blockchain transactions to extract key fields including sender address (`from_address`), receiver address (`to_address`), block timestamp, transaction hash, gas price, and gas usage. Add standardized metadata including token address (hardcoded as `0xbb859e225ac8fb6be1c7e38d87b767e95fef0ebd`), token symbol ('G'), chain identifier ('gravityalpha'), and business classification markers. Calculate gas fees by multiplying gas usage by gas price and dividing by 1e18 to convert from wei to token units.
- **Key fields**: `from_address` (transaction sender), `to_address` (transaction receiver), `block_timestamp` (transaction time), `transaction_hash` (unique identifier), `gas_price` and `gas_used_amount` (fee calculation inputs)

### Component B: Daily active user identification
- **Purpose**: Identify unique addresses that sent transactions each day
- **Logic**: Extract distinct sender addresses from processed transactions, grouped by calendar day. Truncate timestamps to daily granularity using timestamp truncation. Classify all addresses as "Transaction sender" user type. Apply incremental processing logic to only process recent data when updating existing calculations.
- **Key fields**: `user_dau` (unique daily sender address), `timestamp` (calendar day), `user_type` (classification as transaction sender)

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily unique addresses into probabilistic data structures for efficient computation
- **Logic**: Transform daily unique address lists into HyperLogLog sketches using precision parameter 15. Group addresses by timestamp, chain, user type, and product dimensions. HyperLogLog sketches allow approximate counting of unique items with constant memory usage, enabling efficient computation of rolling window metrics.
- **Key fields**: `hll` (HyperLogLog sketch of daily addresses), dimensional grouping fields for later aggregation

### Component D: Rolling window construction
- **Purpose**: Create 30-day rolling windows for each day to calculate monthly active users
- **Logic**: Generate a complete datespine covering all days from the earliest available data to yesterday. For each day in the datespine, create a 30-day window spanning that day plus the previous 29 days. Use array generation and unnesting to create all day-to-window mappings. Join window definitions with daily HLL sketches to prepare for aggregation across time periods.
- **Key fields**: `timestamp` (target day), `joinday` (days included in each window), window boundary definitions

### Component E: HLL sketch merging and extraction
- **Purpose**: Combine HLL sketches across 30-day windows to calculate unique address counts
- **Logic**: For each 30-day window, merge all HLL sketches from constituent days using HLL merge operations. Extract the final unique count estimate from merged sketches using HLL count extraction. This process provides an approximate but highly accurate count of unique addresses active within each 30-day period.
- **Key fields**: `user_mau` (monthly active user count from merged HLL sketches)

### Component F: Dimensional breakdowns
- **Purpose**: Calculate monthly active users across different analytical dimensions
- **Logic**: Aggregate monthly active user counts separately for different dimensional breakdowns including project-level ('project_dbt_tag'), chain-level ('chain'), user type level ('user_type'), and product level ('product_id'). Each breakdown groups data differently and merges HLL sketches accordingly to provide multiple analytical perspectives on user activity.
- **Key fields**: `dimensions` (breakdown type), dimension-specific grouping fields, `user_mau` (count for each dimension)

### Final aggregation
- **Combining components**: Select monthly active user counts specifically for 'chain' and 'project_dbt_tag' dimensional breakdowns, filtering out user type and product level breakdowns
- **Currency conversion**: No currency conversion required as this metric counts addresses rather than financial values
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with each day representing the count of unique addresses active in that day plus the previous 29 days
- **Final calculation**: Rename the `user_mau` field to `active_addresses_monthly` to reflect the specific nature of this metric. Apply finalization macro to standardize schema and metadata, and fill any missing days with zero values to ensure complete time series continuity

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

Unique addresses active over a rolling 30-day window.

Gravity Alpha MainnetG

Active addresses (monthly)

Active addresses (monthly)

Competitive landscape

Chain breakdown