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

## 1. Overview

Sudoswap earnings represents the protocol's net profit, calculated as revenue minus expenses. Revenue comes from protocol fees charged on NFT trading across Sudoswap V1 and V2, while expenses currently consist only of token incentives (which are zero). This metric answers the business question: "How much profit does the Sudoswap protocol generate from its NFT marketplace operations after accounting for operational costs?"

The calculation follows the formula: Earnings = Protocol Fee Revenue - Token Incentive Expenses. Since Sudoswap currently has no token incentive programs, earnings effectively equals protocol fee revenue.

## 2. Data sources

The calculation uses several types of raw blockchain data:

- **Ethereum transaction traces**: Function call traces for Sudoswap V1 and V2 smart contract interactions, including token-to-NFT swaps, NFT-to-token swaps, and pair creation events
- **Bonding curve function traces**: Ethereum traces from various bonding curve contracts (`ExponentialCurve`, `LinearCurve`, `GDACurve`, `XykCurve`) that calculate trading fees and protocol fees for V2 trades
- **Royalty engine traces**: Function call traces to the `RoyaltyEngine_getRoyalty_function` that determine royalty amounts for NFT trades
- **Pair creation events**: Transaction traces from `LSSVMPairFactory` contract functions that create new trading pairs and establish fee tiers
- **End-of-day price feeds**: Daily token price data for USD conversion of trading volumes and fees
- **Token metadata**: Decimal precision information for proper amount normalization

## 3. Step-by-step calculation

### Component A: V1 trading volume extraction
- **Purpose**: Extract trading volumes from Sudoswap V1 pair interactions to calculate protocol revenue
- **Logic**: Process three types of Ethereum function call traces from V1 pair contracts: token-to-specific-NFT swaps using `Pair_swapTokenForSpecificNFTs_function`, token-to-any-NFT swaps using `Pair_swapTokenForAnyNFTs_function`, and NFT-to-token swaps using `Pair_swapNFTsForToken_function`. For token-to-NFT swaps, use the `inputAmount` field directly as the trade volume. For NFT-to-token swaps, adjust the `outputAmount` by dividing by (1 - 0.005) to account for the protocol fee that was already deducted from the output amount. Filter to only successful transactions where `status` equals true. Cross join with NFT IDs for transactions involving multiple NFTs to capture individual trade volumes.
- **Key fields**: `block_timestamp` for daily aggregation, `transaction_hash` and `trace_address` for unique identification, `inputAmount` and `outputAmount` for trade values, `account_address` for the trading pair, and arrays of `nftIds` for multi-NFT transactions

### Component B: V1 pair metadata enrichment
- **Purpose**: Enrich V1 trades with token addresses and fee tier information from pair creation data
- **Logic**: Combine pair creation events from `LSSVMPairFactory_createPairERC20_function` and `LSSVMPairFactory_createPairETH_function` traces. For ERC20 pairs, extract the token address from the `token` parameter. For ETH pairs, use the hardcoded WETH address. Extract fee tiers from the `fee` parameter and convert from wei to decimal by dividing by 10^18. Also include fee changes from `Pair_changeFee_function` traces, which update existing pair fee tiers. Use lead timestamps to handle time-based fee tier logic, allowing different fee rates to apply at different time periods for the same pair.
- **Key fields**: `account_address` for pair identification, `token_address` for the trading token, `fee_tier` for the percentage fee charged, and `block_timestamp` ranges for when each fee tier was active

### Component C: V2 trading volume extraction  
- **Purpose**: Extract trading volumes and fee information from Sudoswap V2 pair interactions
- **Logic**: Process four types of V2 function call traces covering ERC721 and ERC1155 swaps with ETH: token-to-NFT swaps and NFT-to-token swaps for both standards. Extract trade amounts from `anon0` output parameter for buy transactions and `outputAmount` for sell transactions. Parse trace addresses to match trades with their corresponding fee calculation calls from bonding curve contracts. Join with buy info and sell info dimensions to get calculated protocol fees and LP fees from the respective bonding curve function traces. Also join with royalty engine traces to capture royalty amounts. For NFT-to-token swaps, adjust the final trade amount by adding royalty amounts and protocol fees to get the gross trade value.
- **Key fields**: `amount` for trade values, `protocol_fee_amount` from bonding curve calculations, `lp_fee_amount` for liquidity provider fees, `royalty_amount` from royalty engine calls, and `trade_type` to distinguish buy vs sell operations

### Component D: Bonding curve fee calculations
- **Purpose**: Calculate protocol fees and LP fees for V2 trades using mathematical bonding curve formulas
- **Logic**: Process function call traces from four bonding curve contracts that implement different pricing algorithms. Extract input parameters including spot price, delta for price changes, number of items, fee multipliers for LP and protocol fees. The bonding curve functions calculate and return `tradeFee` for LP fees and `protocolFee` amounts based on the mathematical curve formulas and fee multipliers. These calculated fee amounts are then joined back to the corresponding trade transactions using trace address matching.
- **Key fields**: `tradeFee` and `protocolFee` output amounts, `feeMultiplier` and `protocolFeeMultiplier` input parameters, `spotPrice` and `delta` for pricing calculations

### Component E: V1 revenue calculation
- **Purpose**: Calculate protocol revenue from V1 trading activity
- **Logic**: Apply a fixed 0.5% protocol fee rate to all V1 trading volumes. Since V1 pairs don't have direct protocol fee extraction in the smart contracts, the protocol fee is calculated as a percentage of total trading volume. Convert trading volumes to USD using end-of-day price feeds and apply decimal corrections based on token metadata. Aggregate daily by summing all V1 trade volumes multiplied by the 0.5% fee rate.
- **Key fields**: `trading_volume` in native token amounts, USD-converted values after price feed application, and daily aggregated `revenue` amounts

### Component F: V2 revenue calculation  
- **Purpose**: Calculate protocol revenue from V2 trading activity using direct protocol fee amounts
- **Logic**: Sum the `protocol_fee_amount` values extracted from V2 trades, which come directly from bonding curve contract calculations rather than percentage-based calculations. Convert these protocol fee amounts to USD using end-of-day price feeds and apply decimal corrections. Aggregate daily by summing all protocol fees across V2 trades.
- **Key fields**: `protocol_fee_amount` from bonding curve calculations, USD-converted protocol fee values, and daily aggregated `revenue` amounts

### Component G: Expenses calculation
- **Purpose**: Calculate total protocol expenses, primarily token incentives
- **Logic**: Currently set all token incentive expenses to zero, as Sudoswap does not operate any token incentive programs. This creates a baseline expenses structure that can accommodate future incentive programs if implemented. The expenses model takes the same dimensional structure as other metrics (daily timestamps, chain, product identifiers) but populates all expense values with zero.
- **Key fields**: `token_incentives` set to zero, `timestamp` for daily periods, `chain_id` and `product_id` for dimensional consistency

### Final aggregation
- **Combining components**: Union V1 revenue (trading volume × 0.5%) with V2 revenue (direct protocol fees) to create combined protocol revenue. Expenses (currently zero) are calculated separately and then subtracted from total revenue using the earnings calculation macro.
- **Currency conversion**: All amounts are converted to USD using end-of-day price feeds joined on token address and date. Decimal corrections are applied using token metadata to ensure proper unit conversion from wei or other native formats.
- **Time aggregation**: All data is aggregated to daily boundaries using timestamp truncation to day level. Missing days are filled with zeros to ensure continuous time series data.
- **Final calculation**: Earnings equals combined protocol revenue minus total expenses. Since expenses are currently zero, earnings effectively equals the sum of V1 revenue (trading volume × 0.5%) plus V2 revenue (direct protocol fees), all converted to USD and aggregated daily.

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

Net profit (also profits, net income, profitability) — revenue remaining after subtracting expenses.

SudoswapSUDO

Earnings

Earnings

Competitive landscape