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 fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average daily fees generated per active user on the Friend.tech social trading platform. This metric is calculated by dividing total daily fees by daily active users across both v1 (shares trading) and v2 (club trading) versions of the protocol. AFPU helps assess user monetization efficiency and the platform's ability to generate revenue per user engagement.

## 2. Data sources

The calculation utilizes several blockchain and external data sources:

- **Friend.tech v2 events**: Parsed `Buy` and `Sell` events from the Clubs contract on Base blockchain containing trade volumes, protocol fees, and user addresses
- **Friend.tech v1 events**: Parsed `Trade` events from the FriendtechSharesV1 contract on Base blockchain containing share trading data, protocol fees, and creator fees  
- **Base transaction records**: Transaction metadata to identify user addresses and transaction timestamps
- **Protocol configuration events**: Function call logs for `changeProtocolFee` and `changeBestFriendFee` operations that establish fee rate tiers over time
- **End-of-day price feeds**: CoinGecko daily price data for FRIEND token used in v2 trades
- **Ethereum price feeds**: End-of-day WETH price data for v1 trade conversions
- **Token metadata**: Contract addresses and decimal configurations for proper amount calculations

## 3. Step-by-step calculation

### Component A: User activity tracking
- **Purpose**: Identifies and counts unique daily active users across both protocol versions
- **Logic**: Extracts user addresses from v1 `Trade` events (both buyers and sellers when `shareAmount` > 0) and v2 `Buy`/`Sell` events. Classifies users as "Buyer" or "Seller" based on trade direction. Aggregates daily using HyperLogLog algorithms to efficiently count distinct users per day while handling potential overlaps between buyer and seller categories.
- **Key fields**: `user_address` from transaction originators, `block_timestamp` truncated to day boundaries, `user_type` classification, and `chain` identification

### Component B: Fee rate configuration
- **Purpose**: Establishes time-based fee rate tiers for accurate fee calculations
- **Logic**: Processes `changeProtocolFee` and `changeBestFriendFee` function calls to create time intervals with specific fee rates. Uses lead window functions to determine when each fee rate is active. Converts fee rates from wei to decimal format by dividing by 1e18. Creates lookup tables matching timestamps to applicable fee rates.
- **Key fields**: `protocol_fee_rate` and `best_friend_fee_rate` as decimal percentages, `block_timestamp` ranges for fee tier applicability

### Component C: V2 club trading fees
- **Purpose**: Calculates comprehensive fees from v2 club Buy and Sell operations
- **Logic**: For buy trades, calculates the underlying `tokens_in` value by dividing `volume_amount_total` by (1 + protocol_fee_rate + best_friend_fee_rate). For sell trades, uses (1 - protocol_fee_rate - best_friend_fee_rate) in denominator. Multiplies `tokens_in` by respective fee rates to derive `best_friend_fee` amounts. Calculates `referral_fee` as residual between total volume and sum of tokens_in, best friend fees, and protocol fees. Joins with fee rate tiers based on transaction timestamps.
- **Key fields**: `protocol_fee_amount` directly from events, calculated `best_friend_fee` and `referral_fee` amounts, `volume_amount_total` as basis for calculations

### Component D: V1 share trading fees  
- **Purpose**: Captures fees from legacy v1 share trading system
- **Logic**: Extracts `protocol_fee_amount` and `creator_fee_amount` directly from `Trade` events. Sums protocol and creator fees as total fees per transaction. Uses WETH as the fee token since v1 operates on Ethereum-based pricing. Maps transactions to daily boundaries for aggregation.
- **Key fields**: `protocol_fee_amount` and `creator_fee_amount` from Trade events, `volume_amount` for context

### Component E: USD conversion
- **Purpose**: Normalizes all fee amounts to USD for consistent measurement
- **Logic**: For v2 fees, joins daily aggregated amounts with CoinGecko FRIEND token prices using `coingecko_id` = 'friend-tech'. Multiplies native FRIEND amounts by corresponding daily USD prices. For v1 fees, uses WETH price feeds to convert protocol and creator fees to USD. Applies decimal correction (dividing by 1e18) to normalize wei amounts to token units before price multiplication.
- **Key fields**: Daily price data joined on `daily_timestamp`, converted USD amounts for all fee types

### Final aggregation
- **Combining components**: Unions v1 and v2 fee data after USD conversion, summing `protocol_fee_amount`, `creator_fee_amount`, `best_friend_fee`, and `referral_fee` by day. Merges user activity data using HyperLogLog to get distinct daily active user counts across all protocol versions and trade types.
- **Currency conversion**: All fees converted to USD using end-of-day price feeds, with appropriate decimal corrections applied before price multiplication
- **Time aggregation**: Data aggregated to daily boundaries using `timestamp_trunc(block_timestamp, day)`, ensuring consistent time-based grouping across all components
- **Final calculation**: Applies the `calculate_arpu` macro which divides total daily fees (revenue_metric_id = 'fees') by daily active users (user_metric_id = 'user_dau') to produce the average fees per user metric. The result is processed through `finalize_metric_afpu` with zero-filling for missing days to ensure complete time series coverage.

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

friend.techFRIEND

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape