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 (weekly) Methodology

## 1. Overview

Weekly active addresses measures the number of unique addresses that initiated at least one transaction on the Gravity Alpha blockchain during any 7-day rolling period. This metric provides insights into user engagement and network activity by tracking distinct transaction senders over weekly time windows. The calculation uses a rolling 7-day window approach with HyperLogLog sketches for efficient approximate distinct counting, ensuring that users who transact multiple times within the same week are only counted once.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Gravity Alpha transaction data**: Complete transaction records from the Gravity Alpha blockchain including transaction hashes, sender addresses (`from_address`), recipient addresses (`to_address`), timestamps, gas usage, and gas prices
- **Blockchain metadata**: Protocol-specific information including the native token address `0xbb859e225ac8fb6be1c7e38d87b767e95fef0ebd` and token symbol 'G'
- **Network classification data**: Market sector classification ('blockchains_l2') and business segment categorization ('blockchain') for the Gravity Alpha protocol

## 3. Step-by-step calculation

### Component A: Transaction data extraction
- **Purpose**: Extract and standardize raw transaction data from the Gravity Alpha blockchain
- **Logic**: The system processes raw transaction records from the Gravity Alpha network, extracting key fields including block timestamps, transaction hashes, sender addresses (`from_address`), recipient addresses (`to_address`), gas prices, and gas usage amounts. Each transaction is tagged with the hardcoded native token address `0xbb859e225ac8fb6be1c7e38d87b767e95fef0ebd`, token symbol 'G', and chain identifier 'gravityalpha'. Gas fees are calculated using the formula: gas fee = (gas used amount × gas price) ÷ 10^18. All transactions are classified under the 'blockchains_l2' market sector and 'blockchain' business segment.
- **Key fields**: `block_timestamp` for timing, `from_address` for user identification, `transaction_hash` for uniqueness, `gas_used_amount` and `gas_price` for fee calculation

### Component B: Daily active user identification
- **Purpose**: Identify unique transaction senders for each day
- **Logic**: For each calendar day, the system identifies all unique sender addresses (`from_address`) from Gravity Alpha transactions that occurred on that day. Each unique sender is categorized as a 'Transaction sender' user type. The process truncates transaction timestamps to day level to group transactions by date, then applies distinct logic to count each unique address only once per day, regardless of how many transactions they initiated. The system preserves metadata including market sector, business segment, and product classifications for each user.
- **Key fields**: `timestamp` (truncated to day), `from_address` as `user_dau`, `user_type`, `chain`, `market_sector_id`, `business_segment_id`

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily user counts into efficient data structures for rolling window calculations
- **Logic**: For each day's unique users, the system creates HyperLogLog sketches using BigQuery's `hll_count.init` function with precision parameter 15. This creates approximate distinct count data structures that can be efficiently merged across time periods without double-counting users who appear on multiple days. The sketches are grouped by timestamp, chain, user type, and product dimensions to enable breakdown analysis.
- **Key fields**: `hll` sketch objects containing approximate user counts, `timestamp`, `chain_id`, `user_type`, `product_id`

### Component D: Rolling window construction
- **Purpose**: Create 7-day sliding windows for weekly active user calculation
- **Logic**: The system constructs a datespine covering all days from the earliest transaction date to the present, then creates rolling 7-day windows using a self-join technique. For each target day, it identifies a 7-day period consisting of that day plus the previous 6 days (total 7 days). This is accomplished by generating a range of "join days" for each target day (from target_day - 6 days to target_day) and joining these with the daily HLL sketches. The datespine ensures complete time coverage even for days with no transactions, preventing gaps in the rolling window calculation.
- **Key fields**: `timestamp` for the target day, `joinday` for the days included in each window, merged `hll` sketches across the window period

### Component E: Weekly active user aggregation
- **Purpose**: Calculate unique users across each 7-day window and aggregate by different dimensions
- **Logic**: For each 7-day window, the system merges all HLL sketches within the window using `hll_count.merge_partial` and extracts the approximate distinct count using `hll_count.extract`. This provides the count of unique users who were active at least once during the 7-day period. The calculation is performed across multiple dimension breakdowns: by chain (aggregating all users for the Gravity Alpha chain), by project_dbt_tag (aggregating all users for the gravityalpha project), by user_type (breaking down by transaction sender type), and by product_id (breaking down by product classification). Each dimension breakdown groups data appropriately and applies the HLL merge and extract operations.
- **Key fields**: `user_wau` containing the weekly active user count, `dimensions` indicating the aggregation level, `chain_id`, `product_id`, `user_type`

### Final aggregation
- **Combining components**: The system takes the weekly active user (WAU) calculations and filters specifically for 'chain' and 'project_dbt_tag' dimensions, then renames the `user_wau` field to `active_addresses_weekly` to reflect that these represent unique addresses rather than conceptual users
- **Currency conversion**: No currency conversion is applied as this metric counts addresses rather than monetary values
- **Time aggregation**: The metric uses rolling 7-day windows calculated daily, meaning each day shows the count of unique active addresses over the preceding 7-day period (including that day)
- **Final calculation**: The final weekly active addresses value represents the approximate distinct count of unique Gravity Alpha addresses that initiated at least one transaction during any rolling 7-day period, calculated using HyperLogLog sketches for efficient processing and aggregated at both chain and project levels

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

Unique active addresses over a rolling 7-day window.

Gravity Alpha MainnetG

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape

Chain breakdown