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

## 1. Overview

Weekly active addresses measures the number of unique wallet addresses that initiated at least one transaction on the Viction blockchain within a rolling 7-day period. This metric provides insight into user engagement and adoption by tracking how many distinct addresses are actively transacting on the network each week. The calculation uses a sliding window approach where each day's value represents the count of unique addresses that were active during that day and the previous 6 days.

## 2. Data sources

The calculation relies on the following raw data sources:

- **Viction blockchain transaction records**: Complete transaction history from the Viction blockchain, including transaction hashes, block timestamps, and sender addresses
- **Blockchain transaction metadata**: Transaction-level data containing sender addresses (`from_address`), recipient addresses, transaction hashes, and block timestamps
- **Time boundary data**: Daily timestamp boundaries used for aggregating transaction activity into daily periods
- **Chain configuration metadata**: Viction blockchain identification and categorization information including chain ID, market sector classification, and business segment data

## 3. Step-by-step calculation

### Component A: Daily user extraction
- **Purpose**: Identify all unique addresses that sent transactions each day
- **Logic**: Extract transaction sender addresses from Viction blockchain transaction records. Each transaction record contains a `from_address` field representing the wallet that initiated the transaction. The system groups all transactions by day using the `block_timestamp` field truncated to daily boundaries, then identifies all unique sender addresses for each day. Each unique address that appears as a transaction sender on a given day is counted as an active user for that day.
- **Key fields**: `block_timestamp` for daily grouping, `from_address` for user identification, `transaction_hash` for transaction linking, and derived fields like `chain` (set to 'viction'), `user_type` (set to 'Transaction sender')

### Component B: Daily active user aggregation  
- **Purpose**: Calculate the count of distinct active addresses per day
- **Logic**: Take the extracted daily transaction data and count distinct sender addresses for each day. The system creates daily snapshots where each day has a count of unique addresses that initiated transactions. This creates a time series of daily active user counts that serves as the foundation for the rolling window calculation.
- **Key fields**: `timestamp` (daily boundary), `timestamp_grain` (set to 'day'), `user_address` (the distinct sender addresses), and metadata fields for dimensional analysis

### Component C: HyperLogLog sketch creation
- **Purpose**: Convert daily address counts into efficient data structures for set operations
- **Logic**: Transform the daily distinct address counts into HyperLogLog (HLL) probabilistic data structures. HLL sketches allow for efficient approximate counting of unique elements and enable merging sets from different time periods without double-counting addresses that appear in multiple days. Each day's unique addresses are initialized into an HLL sketch with precision parameter 15.
- **Key fields**: `hll` (the HyperLogLog sketch containing the day's unique addresses), `timestamp`, and dimensional breakdown fields

### Component D: Rolling 7-day window creation
- **Purpose**: Create sliding windows for weekly calculations
- **Logic**: Generate a continuous date spine covering the entire analysis period, then create rolling 7-day windows for each date. For any given date, the system identifies the current day plus the previous 6 days (total of 7 days) to form the weekly window. This sliding window approach ensures that each day's weekly active user count reflects activity across the most recent 7-day period ending on that date.
- **Key fields**: `timestamp` (the end date of each 7-day window), `joinday` (each individual day within the window)

### Component E: Weekly unique address calculation
- **Purpose**: Calculate unique addresses active within each 7-day window
- **Logic**: For each 7-day window, collect all HLL sketches from the constituent days and merge them using HLL merge operations. The merge operation combines the probabilistic sets while avoiding double-counting addresses that were active on multiple days within the same 7-day period. After merging, extract the approximate count of unique addresses from the merged HLL sketch.
- **Key fields**: `user_wau` (weekly active users count), `timestamp` (window end date), dimensional fields for different breakdown levels

### Component F: Dimensional breakdown aggregation
- **Purpose**: Calculate weekly active addresses across different analytical dimensions
- **Logic**: Generate separate weekly active address calculations for different organizational levels. Create breakdowns by project level (aggregating all activity under the 'viction' project tag), by chain level (maintaining Viction chain-specific metrics), by user type (though all users are 'Transaction sender' type), and by product level (currently null for Viction). Each dimensional breakdown aggregates the HLL sketches appropriately and extracts unique counts.
- **Key fields**: `dimensions` (the breakdown level: 'project_dbt_tag', 'chain', 'user_type', 'product_id'), `chain_id`, `user_type`, `product_id`

### Final aggregation
- **Combining components**: The final model selects weekly active user data from the dimensional breakdowns, specifically filtering for 'chain' and 'project_dbt_tag' dimensions only. These represent the two primary analytical levels: individual blockchain performance and overall project performance.
- **Field transformation**: Rename the `user_wau` field to `active_addresses_weekly` to align with the specific metric naming convention for address-based metrics rather than user-based metrics.
- **Time series completion**: Apply zero-filling logic to ensure continuous time series data, filling any missing dates with zero values to maintain consistent reporting periods.
- **Final calculation**: The final metric value represents the approximate count of unique wallet addresses that initiated at least one transaction on the Viction blockchain during each rolling 7-day period, calculated using probabilistic counting methods for efficiency and accuracy.

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

Unique active addresses over a rolling 7-day window.

VictionVIC

Archived

Active addresses (weekly)

Active addresses (weekly)

Competitive landscape