Liquidity providers deposit NFTs and funds into Sudoswap and receive trading fees, and creators receive royalties from users (supply-side fees).

Sudoswap is a non-custodial NFT marketplace protocol built on Ethereum. Sudoswap was founded by Owen Shen and launched in 2022.

Team and investors own and govern the protocol. They currently take a cut of the total fees paid by users (revenue).

github

twitter

discord

website

NFT marketplaces

Sudoswap

# Sudoswap Average fees per user (AFPU) Methodology

## 1. Overview

Average fees per user (AFPU) for Sudoswap measures the average amount of fees generated per daily active user on the NFT marketplace. This metric provides insight into user monetization efficiency by dividing total daily fees (including both protocol revenue and supply-side fees) by the number of unique users who traded on that day. The calculation covers both Sudoswap v1 and v2 protocols operating on Ethereum.

## 2. Data sources

The AFPU calculation relies on several key data sources:

- **Ethereum transaction traces**: Function calls to Sudoswap v1 and v2 trading contracts including swap operations, pair creation, and fee management functions
- **Sudoswap contract events**: Parsed event logs from pair factory contracts, trading pairs, and royalty systems
- **NFT trading data**: Function call parameters and outputs from various swap methods (token-to-NFT, NFT-to-token, specific vs any NFT swaps)
- **Fee configuration data**: Pair creation events and fee update function calls that establish trading fee tiers
- **Bonding curve calculations**: Function calls to pricing curve contracts (Exponential, Linear, GDA, XYK) that determine trading fees
- **Royalty engine data**: Function calls to royalty calculation systems that determine NFT creator fees
- **End-of-day token price feeds**: External price data for USD conversion of fee amounts
- **Token metadata**: Information about token decimals and addresses for proper amount calculations

## 3. Step-by-step calculation

### Component A: User identification and counting
- **Purpose**: Identify and count unique daily active users across Sudoswap v1 and v2
- **Logic**: Extract user addresses from successful swap function calls by capturing recipient parameters (`nftRecipient` for NFT buyers, `tokenRecipient` for NFT sellers). Users are identified from both v1 functions (swapTokenForAnyNFTs, swapNFTsForToken, swapTokenForSpecificNFTs) and v2 functions (various pair-specific swap methods for ERC721 and ERC1155 tokens). All addresses are truncated to daily timestamps and deduplicated using HyperLogLog sketching across multiple dimensional breakdowns (project-level, chain-level, user-type-level, product-level)
- **Key fields**: User addresses extracted from `nftRecipient` and `tokenRecipient` parameters, aggregated as `user_dau` counts

### Component B: Protocol revenue calculation
- **Purpose**: Calculate protocol fees earned by Sudoswap
- **Logic**: For v2 trades, extract protocol fee amounts directly from bonding curve function outputs (`protocol_fee_amount`). For v1 trades, calculate protocol fees by applying a fixed 0.5% fee rate to trading volumes. Trading volumes come from swap function outputs (`inputAmount`, `outputAmount`) with proper adjustments for fee inclusions. All amounts are converted from native token decimals to USD using end-of-day price feeds
- **Key fields**: Protocol fee amounts (`protocol_fee_amount`), trading volumes with fee adjustments, USD conversion rates

### Component C: Supply-side fees calculation  
- **Purpose**: Calculate fees paid to liquidity providers and NFT creators
- **Logic**: Combine LP fees and royalty payments from multiple sources. LP fees for v1 come from applying pair-specific fee tiers to trading amounts, with temporal logic to handle fee tier updates over time. LP fees for v2 are extracted directly from bonding curve calculations (`lp_fee_amount`). Royalty fees are captured from v1 royalty events (`RoyaltyIssued`) and v2 royalty engine function calls. All fee amounts are converted to USD and aggregated daily
- **Key fields**: LP fee amounts (`lp_fee_amount`), royalty amounts (`royalty_amount`), pair fee tiers (`fee_tier`)

### Component D: Trading volume processing
- **Purpose**: Calculate accurate trading volumes for fee calculations
- **Logic**: Extract trade amounts from swap function calls across both versions. For v1, use function outputs like `inputAmount` and `outputAmount`, adjusting for protocol fee inclusions where necessary. For v2, extract amounts from function outputs and join with bonding curve calculations to get comprehensive fee breakdowns. Link trades to pair metadata to determine token addresses and fee configurations. Handle both ETH and ERC20 token trades with proper decimal corrections
- **Key fields**: Trade amounts (`amount`, `trade_amount`), token addresses, pair associations, timestamp truncation for daily aggregation

### Final aggregation
- **Combining components**: Total daily fees are calculated by summing protocol revenue and supply-side fees. Daily active users are counted using HyperLogLog aggregation across all swap activities. Both metrics are aggregated to daily grain using timestamp truncation
- **Currency conversion**: All fee amounts are converted to USD using the `convert_to_usd_and_correct_decimals` macro, which applies proper decimal corrections and end-of-day exchange rates
- **Time aggregation**: Data is aggregated to daily boundaries using timestamp truncation, with gap filling applied to ensure continuous time series
- **Final calculation**: AFPU is computed using the `calculate_arpu` macro, which divides total daily fees by daily active users. The result is formatted using `finalize_metric_afpu` with zero-filling for missing days to maintain complete time series continuity

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

SudoswapSUDO

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape