Overcollateralized borrowers deposit funds into Vesta Finance and borrow VST stablecoin.

Vesta Finance is a non-custodial stablecoin protocol built on Arbitrum. Vesta Finance was founded by Mikey Milken and launched in 2022.

VSTA tokenholders own and govern the protocol. They currently take all of the total interest paid by borrowers (revenue).

governance

github

twitter

discord

etherscan

website

Stablecoin issuers

Vesta Finance

# Vesta Finance Active users (monthly) Methodology

## 1. Overview

Monthly Active Users (MAU) measures the number of unique users who interact with the Vesta protocol within a 30-day rolling window. Vesta is a stablecoin issuer protocol where users can create and manage borrowing positions called "troves." This metric captures user engagement by tracking addresses that create or update their troves, providing insight into protocol adoption and user retention over time. The calculation uses HyperLogLog (HLL) aggregation for efficient distinct user counting across multiple dimensional breakdowns.

## 2. Data sources

The calculation relies on the following blockchain data sources:
- **Arbitrum event logs**: Parsed events from the Vesta V1 BorrowerOperations smart contract deployed on Arbitrum
- **Protocol events**: Specifically `TroveCreated` and `TroveUpdated` events that capture user interactions with borrowing positions
- **Blockchain metadata**: Block timestamps and transaction hashes for temporal analysis

## 3. Step-by-step calculation

### Component A: User identification
- **Purpose**: Extract and classify unique user addresses from Vesta protocol interactions
- **Logic**: Parse `TroveCreated` and `TroveUpdated` events from the BorrowerOperations contract on Arbitrum. Extract the `borrower` address parameter from each event. Classify users into two types: "Trove Creator" for addresses that create new borrowing positions, and "Trove Updater" for addresses that modify existing positions. Each user interaction includes metadata like block timestamp, transaction hash, chain identifier, and business classification (market sector as "stablecoin_issuers" and business segment as "stablecoin_issuer")
- **Key fields**: `borrower` address from events, `block_timestamp`, `transaction_hash`, `chain`, `user_type`, `market_sector_id`, `business_segment_id`

### Component B: Daily active user calculation
- **Purpose**: Aggregate unique user addresses by day to create Daily Active Users (DAU) metrics
- **Logic**: Group the user interaction data by truncated daily timestamps. Count distinct user addresses within each day, maintaining dimensional breakdowns by chain, user type, and product ID. This creates the foundational daily user activity data that will be used for the rolling 30-day MAU calculation
- **Key fields**: `timestamp` (truncated to day), `timestamp_grain` (set to "day"), `chain`, `user_type`, `product_id`, `user_dau` (the user address for distinct counting)

### Component C: HLL initialization and datespine creation
- **Purpose**: Prepare daily user data for efficient MAU calculation using HyperLogLog and create a complete date range
- **Logic**: Initialize HyperLogLog sketches for each daily user count to enable efficient distinct counting across 30-day windows. Create a datespine covering the full date range from the earliest user activity to the current date minus one day, generating daily timestamps to ensure no missing dates in the rolling window calculation. The datespine prevents gaps in the time series that could affect MAU accuracy
- **Key fields**: `hll` (HyperLogLog sketch), `timestamp` from datespine, all dimensional fields (`chain_id`, `user_type`, `product_id`)

### Component D: Rolling window generation
- **Purpose**: Create 30-day rolling windows for each date in the analysis period
- **Logic**: For each date in the datespine, generate an array of 30 consecutive dates ending on that date (29 days prior through the current date). Join this rolling window data with the HLL-aggregated daily user data to capture all user activity within each 30-day period. This creates overlapping windows where each date represents the MAU calculation for users active in the preceding 30 days
- **Key fields**: `timestamp` (window end date), `joinday` (individual days within the window), `hll` (user data for each day in the window)

### Component E: Dimensional MAU aggregation
- **Purpose**: Calculate MAU across four different dimensional breakdowns
- **Logic**: Merge HyperLogLog sketches within each 30-day window and extract the distinct user count for four separate aggregation levels: 1) Project level - overall MAU across all dimensions, 2) Chain level - MAU broken down by blockchain, 3) User type level - MAU by user classification (Trove Creator vs Trove Updater), 4) Product ID level - MAU by product identifier. Each breakdown nullifies unused dimensional fields and uses HLL merge and extract functions to calculate accurate distinct user counts
- **Key fields**: `timestamp`, `timestamp_grain`, `dimensions` (breakdown type), `chain_id`, `product_id`, `user_type`, `user_mau` (final distinct user count)

### Final aggregation
- **Combining components**: Union all four dimensional breakdowns into a single result set with consistent schema structure
- **Currency conversion**: Not applicable for user count metrics
- **Time aggregation**: Daily timestamps represent 30-day rolling windows ending on each date
- **Final calculation**: The final MAU value is the distinct count of user addresses that interacted with the Vesta protocol (through trove creation or updates) within any 30-day rolling period, calculated efficiently using HyperLogLog aggregation and presented across multiple dimensional breakdowns

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

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

Vesta FinanceVSTA

Active users (monthly)

Active users (monthly)

Competitive landscape