Users are able to buy “keys” of other users X (Twitter) accounts. By owning a “key” the user gets access to a private chat with the person whose “key” one owns. When a “key” of a users account is traded the user earns a commission (supply-side fees).

friend.tech is a crypto native social media application built on Base. friend.tech was founded by pseudonymous developers known as Racer and Shrimp and launched in 2023.

friend.tech team and investors own the protocol. They currently take a cut of the total trading volume (revenue). friend.tech’s investors include Paradigm.

twitter

website

Social

friend.tech

# friend.tech Average revenue per user (ARPU) Methodology

## 1. Overview

Average Revenue Per User (ARPU) for Friend.tech measures the daily revenue generated per active user on the platform. This metric divides total daily protocol revenue by the number of daily active users, providing insight into monetization efficiency across both V1 (share trading) and V2 (club trading) versions of the protocol. ARPU helps assess user value and platform economics by combining revenue from trading fees with user engagement levels.

## 2. Data sources

- **Base blockchain event logs**: Parsed `FriendtechSharesV1_Trade_event` logs capturing V1 share trading activity, `Clubs_Buy_event` and `Clubs_Sell_event` logs capturing V2 club trading activity
- **Base blockchain function logs**: Parsed `Clubs_changeProtocolFee_function` and `Clubs_changeBestFriendFee_function` logs for fee rate updates
- **Base blockchain transaction data**: Transaction records to identify user addresses and validate successful transactions
- **External price feeds**: End-of-day CoinGecko price data for FRIEND token USD conversion, and end-of-day Ethereum token price feeds for ETH-denominated fee conversion
- **Token metadata**: FRIEND token contract address (`0x0bd4887f7d41b35cd75dff9ffee2856106f86670`) and WETH contract address for price lookups

## 3. Step-by-step calculation

### Component A: V1 revenue calculation
- **Purpose**: Calculate protocol revenue from V1 share trading fees
- **Logic**: Extract protocol fee amounts from `FriendtechSharesV1_Trade_event` logs where trades occurred successfully. Protocol fees are collected in ETH and stored in the `protocolEthAmount` field. These ETH amounts are converted to USD using end-of-day Ethereum price feeds, with proper decimal correction (division by 1e18). V1 trades are mapped to the Base chain for consistency with the overall platform metrics.
- **Key fields**: `protocolEthAmount` (protocol fee in ETH), `block_timestamp` (trade timing), `trader` (user address)

### Component B: V2 club trading revenue calculation  
- **Purpose**: Calculate protocol revenue from V2 club trading fees
- **Logic**: Process `Clubs_Buy_event` and `Clubs_Sell_event` logs to extract trading volumes and protocol fees. For each trade, determine the applicable fee rates by matching the trade timestamp against historical fee tier changes from protocol admin functions. Calculate protocol fees and best friend fees based on time-windowed fee rates. Convert FRIEND token amounts to USD using end-of-day CoinGecko price data for the 'friend-tech' token. Buy and sell trades use different formulas for fee calculation due to the direction of value flow.
- **Key fields**: `pointsIn`/`pointsOut` (trading volumes), `protocolFee` (explicit protocol fee), fee rate tiers, `block_timestamp` (trade timing)

### Component C: Fee rate determination
- **Purpose**: Apply correct fee rates based on historical changes
- **Logic**: Create time-windowed fee rate tiers using `changeProtocolFee` and `changeBestFriendFee` function logs. Each fee change creates a time interval during which that rate applies. For each trade, match the trade timestamp against these intervals to determine the applicable protocol fee rate and best friend fee rate. Fee rates are stored as decimal values (divided by 1e18) and applied as percentages to calculate fee amounts.
- **Key fields**: `newFee` (updated fee rate), `block_timestamp` (when fee change took effect)

### Component D: Daily active user calculation
- **Purpose**: Count distinct users active each day across both V1 and V2
- **Logic**: Identify unique user addresses from both V1 share trading events and V2 club trading events. Extract trader addresses from V1 `Trade_event` logs and user addresses from V2 buy/sell event transaction records. Classify users as 'Buyer' or 'Seller' based on trade direction. Use HyperLogLog (HLL) algorithm for efficient distinct counting across multiple dimensions including chain, user type, and product. Aggregate daily by truncating timestamps to day boundaries.
- **Key fields**: `trader` (V1 user address), `user_address` (V2 user address), `isBuy` (trade direction), `block_timestamp` (activity timing)

### Component E: USD conversion processing
- **Purpose**: Convert all revenue components to USD for consistent calculation
- **Logic**: V1 ETH-denominated fees are converted using end-of-day Ethereum price feeds from the token price database. V2 FRIEND token-denominated fees are converted using end-of-day CoinGecko price data for the 'friend-tech' token ID. Price lookups match the daily timestamp of each trade to the corresponding daily price record. All amounts undergo decimal correction by dividing raw blockchain values by 1e18 to convert from wei/smallest unit to standard token units.
- **Key fields**: `price_usd` (daily token price), `daily_timestamp` (price date), volume and fee amounts in token units

### Final aggregation
- **Combining components**: Sum all USD-converted revenue from V1 protocol fees and V2 protocol fees by day. Aggregate distinct active users by day using HyperLogLog merge operations across all V1 and V2 trading activity.
- **Currency conversion**: All revenue values are expressed in USD using end-of-day price feeds matched to trade dates
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation to day granularity
- **Final calculation**: ARPU equals total daily revenue divided by total daily active users. Days with zero users result in null ARPU values, while days with zero revenue result in zero ARPU. Missing days are filled with zero values for both revenue and user counts, resulting in zero ARPU for those periods.

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

friend.techFRIEND

Average revenue per user (ARPU)

Average revenue per user (ARPU)

Competitive landscape