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 Revenue Methodology

## 1. Overview

FriendTech revenue represents the total protocol fees earned by the FriendTech platform from both v1 and v2 trading activities. The metric combines protocol fees from v1 share trading (denominated in ETH) with protocol fees from v2 club trading (denominated in FRIEND tokens), converting both to USD and aggregating daily. This metric answers how much revenue the FriendTech protocol generates from its social trading platform across both versions.

## 2. Data sources

- **v1 trading events**: Parsed `Trade` events from the FriendTech v1 contract on Base chain containing ETH amounts for volume and protocol fees
- **v2 club trading events**: Parsed `Buy` and `Sell` events from the FriendTech v2 Clubs contract on Base chain containing FRIEND token amounts and fee data
- **Fee configuration events**: Parsed function calls for `changeProtocolFee` and `changeBestFriendFee` from the v2 Clubs contract tracking fee rate changes over time
- **Transaction data**: Base chain transaction records to identify user addresses for trades
- **Price data**: End-of-day price feeds for WETH from Ethereum and daily CoinGecko market data for FRIEND token
- **Token metadata**: FRIEND token address and WETH address for price feed mapping

## 3. Step-by-step calculation

### Component A: v1 protocol revenue
- **Purpose**: Calculates protocol fees from FriendTech v1 share trading
- **Logic**: Extracts `Trade` events from the FriendTech v1 contract on Base chain. Each event contains `ethAmount`, `protocolEthAmount`, and `subjectEthAmount` fields representing total volume, protocol fees, and creator fees respectively. The `protocolEthAmount` field is converted from wei to ETH by casting to bignumeric. These ETH amounts are then converted to USD using end-of-day WETH price feeds from Ethereum, applying decimal correction and currency conversion through the standard macro
- **Key fields**: `protocolEthAmount` (protocol fee in wei), `block_timestamp` (for daily aggregation), WETH token address for price conversion

### Component B: v2 protocol revenue  
- **Purpose**: Calculates protocol fees from FriendTech v2 club trading using dynamic fee tiers
- **Logic**: Processes `Buy` and `Sell` events from the v2 Clubs contract separately due to different fee calculation methods. For buy trades, the calculation determines tokens received by dividing total volume by (1 + protocol fee rate + best friend fee rate). For sell trades, tokens sold are calculated by dividing volume received by (1 - protocol fee rate - best friend fee rate). Protocol fees are extracted directly from event data (`protocolFee` field) and converted from FRIEND token wei to standard units. Fee rates are determined by joining with time-based dimension tables that track protocol fee and best friend fee changes through function call events
- **Key fields**: `pointsIn`/`pointsOut` (volume amounts), `protocolFee` (direct protocol fee), `id` (club identifier), fee rate dimensions applied by timestamp

### Component C: Fee tier management
- **Purpose**: Provides time-based fee rate lookups for v2 calculations
- **Logic**: Two dimension tables track fee changes over time by parsing `changeProtocolFee` and `changeBestFriendFee` function calls from the Clubs contract. Each fee change creates a time interval using lead window functions to determine the next fee change timestamp. These intervals allow trades to be matched with the correct fee rates based on when they occurred
- **Key fields**: `newFee` (fee rate in wei), `block_timestamp` (effective date), time intervals for rate application

### Component D: USD conversion for v2 data
- **Purpose**: Converts FRIEND token amounts to USD values
- **Logic**: Since FRIEND tokens are non-transferrable and lack reliable on-chain price data, USD conversion uses CoinGecko daily market data. All FRIEND token amounts (volume, protocol fees, best friend fees, referral fees) are multiplied by the daily USD price from CoinGecko for the FRIEND token. Daily timestamps are used for price matching to ensure consistent end-of-day pricing
- **Key fields**: `price_usd` from CoinGecko, `daily_timestamp` for price matching, `coingecko_id` for FRIEND token

### Final aggregation
- **Combining components**: v1 protocol fees (converted to USD) are unioned with v2 protocol fees (converted to USD) to create a combined revenue stream. Both components are standardized to use 'base' as the chain identifier and daily timestamp truncation
- **Currency conversion**: v1 data uses Ethereum price feeds with the convert_to_USD macro, while v2 data uses pre-converted USD amounts from CoinGecko pricing
- **Time aggregation**: All revenue is aggregated to daily boundaries using timestamp truncation to day level
- **Final calculation**: The finalize_metric_revenue macro is applied with a fill_zeros strategy to ensure complete daily time series, handling any missing days by filling with zero values rather than nulls

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

fees * take_rate (illustrative — revenue is observed directly per project, not derived from take_rate)

Fee revenue retained after supply-side payouts. Before cost of revenue (e.g. L2 DA fees) and before operating expenses.

friend.techFRIEND

Revenue

Revenue

Competitive landscape