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 Active users (monthly) Methodology

## 1. Overview

The Friend.tech Monthly Active Users (MAU) metric measures the number of distinct users who have traded on the Friend.tech platform within any 30-day rolling window. This metric captures user engagement across both the original Friend.tech shares trading (v1) and the newer clubs trading functionality (v2). The calculation uses HyperLogLog (HLL) probabilistic data structures to efficiently compute approximate distinct user counts across rolling 30-day periods, providing insights into platform growth and user retention patterns.

## 2. Data sources

The MAU calculation relies on several blockchain data sources from the Base network:

- **Friend.tech v1 events**: Parsed `Trade` events from the original FriendtechSharesV1 contract, containing share trading activity with trader addresses, buy/sell indicators, and share amounts
- **Friend.tech v2 events**: Parsed `Buy` and `Sell` events from the Clubs contract, capturing the newer clubs trading functionality with user addresses, points amounts, and protocol fees
- **Base transaction records**: Transaction data providing the `from_address` field to identify the actual users initiating the trades, essential for accurate user counting
- **Blockchain metadata**: Block timestamps and transaction hashes for temporal ordering and deduplication

## 3. Step-by-step calculation

### Component A: User activity extraction
- **Purpose**: Identifies all users who have traded on Friend.tech platform and classifies them by activity type
- **Logic**: Extracts user addresses from both v1 `Trade` events and v2 `Buy`/`Sell` events. For v1 events, users are classified as 'Buyer' when `isBuy` is true and 'Seller' when false, filtering for positive share amounts. For v2 events, users are classified directly based on the event type (`Buy` events create 'Buyer' users, `Sell` events create 'Seller' users). Transaction records are joined to get the actual user address from the `from_address` field. All activity is tagged with 'social' market sector and business segment identifiers.
- **Key fields**: `user_address` (the trading user), `user_type` (Buyer/Seller classification), `block_timestamp` (for temporal analysis), `chain` (Base network), `transaction_hash` (for deduplication)

### Component B: Daily active users aggregation  
- **Purpose**: Aggregates user activity to daily granularity and creates distinct user lists per day
- **Logic**: Groups the user activity data by day (truncating `block_timestamp` to day granularity), chain, user type, and product dimensions. Creates distinct lists of active users for each day, removing duplicates where the same user had multiple transactions on the same day. This creates the foundation for the rolling MAU calculation.
- **Key fields**: `timestamp` (day-truncated), `timestamp_grain` (set to 'day'), `user_dau` (distinct user address for the day), dimensional fields for grouping

### Component C: HyperLogLog initialization
- **Purpose**: Converts daily user lists into HyperLogLog sketches for efficient approximate counting
- **Logic**: Takes the daily active user lists and initializes HyperLogLog sketches with 15-bit precision using `hll_count.init()`. This probabilistic data structure allows for efficient merging of user sets across different time windows without storing the actual user addresses, enabling scalable computation of distinct counts across rolling periods.
- **Key fields**: `hll` (the HyperLogLog sketch containing encoded user information), dimension fields preserved from daily aggregation

### Component D: Rolling 30-day window construction
- **Purpose**: Creates sliding 30-day windows for MAU calculation
- **Logic**: Generates a datespine covering all days from the earliest Friend.tech activity to the current date. For each day in the datespine, creates a 30-day lookback period by generating timestamps from 29 days prior through the current day. This creates a cartesian join where each target day is associated with all days in its 30-day window, enabling the aggregation of user activity across each rolling period.
- **Key fields**: `timestamp` (the MAU calculation date), `joinday` (each day within the 30-day window)

### Component E: HyperLogLog merging across windows
- **Purpose**: Combines daily HLL sketches across each 30-day window to calculate approximate MAU
- **Logic**: Joins the 30-day windows with the daily HLL sketches, matching each `joinday` to its corresponding daily HLL data. For each target timestamp, merges all HLL sketches from the 30-day period using `hll_count.merge_partial()`, which combines the probabilistic sketches while maintaining the distinct user count approximation. Extracts the final distinct count using `hll_count.extract()` to produce the MAU value.
- **Key fields**: `user_mau` (the approximate distinct user count for the 30-day period), dimensional grouping fields

### Final aggregation
- **Combining components**: Creates separate MAU calculations for four analytical dimensions: project-level (overall Friend.tech MAU), chain-level (Base network), user_type-level (Buyer vs Seller MAU), and product_id-level breakdowns. Each dimension aggregates HLL sketches differently, setting non-relevant dimension fields to null while preserving the target dimension for grouping.
- **Currency conversion**: Not applicable for this user-count metric
- **Time aggregation**: Uses rolling 30-day windows calculated daily, with each day representing the MAU for the trailing 30-day period ending on that date
- **Final calculation**: The final MAU value is the approximate distinct count of users extracted from the merged HyperLogLog sketches across the 30-day rolling window, providing separate MAU metrics for each analytical dimension while maintaining computational efficiency through probabilistic counting

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

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

friend.techFRIEND

Active users (monthly)

Active users (monthly)

Competitive landscape