Validators process transactions and receive fees from users (supply-side fees).

Viction is a smart contract platform for decentralized applications (a blockchain). Viction was founded by Ninety Eight and launched in 2018.

VIC holders own and govern the protocol. They currently don't take a cut of the total transaction fees paid by users (revenue). Ninety Eight's investors include Binance Labs, The Spartan Group, Multicoin Capital, etc.

website

twitter

Blockchains (L1)

Viction

# Viction Active users (weekly) Methodology

## 1. Overview

Weekly Active Users (WAU) measures the number of unique user addresses that initiated at least one transaction on the Viction blockchain within any 7-day period. This metric provides insight into user engagement and adoption trends on the Viction network. The calculation uses HyperLogLog (HLL) data structures to efficiently compute approximate distinct user counts across rolling 7-day windows, ensuring accurate unique user counting even when the same address appears multiple times within the week.

## 2. Data sources

The calculation relies on the following raw data sources:
- **Viction blockchain transaction records**: All transaction data from the Viction blockchain, containing transaction timestamps, transaction hashes, and sender addresses
- **Token Terminal's chain availability filters**: Quality assurance filters that ensure data completeness and availability across different time periods

## 3. Step-by-step calculation

### Component A: Daily active users extraction
- **Purpose**: Identify unique users who initiated transactions on each day
- **Logic**: The system extracts all transactions from Viction blockchain transaction records and identifies the sender address (`from_address`) for each transaction. Block timestamps are truncated to day-level granularity to create daily boundaries. For each day, distinct user addresses are collected, with each transaction sender classified as a "Transaction sender" user type. The data includes chain identification as 'viction' with market sector classification as 'blockchains_l1' and business segment as 'blockchain'
- **Key fields**: `block_timestamp` (truncated to day), `user_address` (from `from_address`), `user_type` (always "Transaction sender"), `chain` (always 'viction')

### Component B: HyperLogLog conversion  
- **Purpose**: Convert daily user sets into efficient approximate counting structures
- **Logic**: Daily active user addresses are transformed into HyperLogLog data structures using BigQuery's `hll_count.init()` function with precision parameter 15. This allows for efficient storage and merging of large user sets while maintaining high accuracy for distinct counting operations. Each day's HLL structure represents the set of unique users who were active on that specific day
- **Key fields**: `hll` (HyperLogLog structure containing daily user addresses), `timestamp` (day-level), `chain_id`, `user_type`, `product_id`

### Component C: Datespine creation
- **Purpose**: Ensure continuous daily timestamps for complete rolling window coverage
- **Logic**: A complete datespine is generated using BigQuery's `generate_timestamp_array()` function, creating daily timestamps from the earliest available data date through the day before current timestamp. This prevents gaps in the rolling window calculation that could occur due to days with zero transaction activity. The datespine serves as the foundation for creating consistent 7-day windows
- **Key fields**: `timestamp` (continuous daily timestamps covering the full data range)

### Component D: Rolling window construction
- **Purpose**: Create 7-day rolling windows for each target date
- **Logic**: For each day in the datespine, the system creates a 7-day window consisting of the target day plus the 6 preceding days. This is accomplished through a cross-join operation that generates an array of 7 consecutive dates ending on each target day. The `jointables` CTE creates the mapping between each target timestamp and its corresponding 7-day window dates, ensuring every day has a complete lookback period
- **Key fields**: `timestamp` (target date), `joinday` (each of the 7 days in the rolling window)

### Component E: Window aggregation
- **Purpose**: Join daily HLL data with rolling windows and merge user sets
- **Logic**: The rolling window date ranges are joined with the daily HLL data to associate each target day with the HyperLogLog structures from its 7-day window. HLL structures from the 7 days are merged using `hll_count.merge_partial()` to combine the daily user sets, then extracted using `hll_count.extract()` to produce the final unique user count for each 7-day period. This process maintains the approximate distinct counting properties while efficiently handling overlapping user activity across multiple days
- **Key fields**: `timestamp` (target date), `hll` (merged HyperLogLog from 7-day window), dimension fields for grouping

### Component F: Multi-dimensional breakdowns
- **Purpose**: Calculate WAU across different analytical dimensions
- **Logic**: The merged weekly user counts are aggregated across four different dimension levels. The project-level breakdown provides overall Viction WAU by setting dimension-specific fields to null and grouping only by timestamp. Chain-level breakdown maintains `chain_id` grouping for multi-chain analysis. User-type breakdown groups by `user_type` to distinguish different categories of users. Product-level breakdown groups by `product_id` for product-specific analysis. Each breakdown uses the same HLL merge and extract operations but with different GROUP BY clauses
- **Key fields**: `dimensions` (breakdown type), `chain_id`, `user_type`, `product_id`, `user_wau` (final count)

### Final aggregation
- **Combining components**: All dimensional breakdowns are combined using UNION ALL operations to create a comprehensive dataset with multiple analysis perspectives. Each row represents WAU for a specific date and dimension combination
- **Time aggregation**: Daily grain is maintained in the final output, with each timestamp representing a day and its corresponding 7-day WAU calculation ending on that date
- **Final calculation**: The `finalize_metric_user_wau` macro applies standardized schema formatting, fills missing dates with zero values where appropriate, and ensures consistent output structure. Chain availability filters are applied to maintain data quality standards across the full time series

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

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

VictionVIC

Archived

Active users (weekly)

Active users (weekly)

Competitive landscape