Lenders deposit funds into Shoebill Finance and receive interest payments from borrowers (supply-side fees).

Shoebill Finance is a non-custodial lending protocol built on Manta Pacific. Shoebill Finance was founded by the pseudonymous Paguinfo and launched in 2023.

Shoebill Finance’s team own and govern the protocol. They currently take a cut of the total interest paid by borrowers (revenue).

github

twitter

website

Lending

Shoebill Finance

# Shoebill Finance Average fees per user (AFPU) Methodology

## 1. Overview

Average Fees Per User (AFPU) measures the average daily fee revenue generated per active user on the Shoebill lending protocol. This metric answers how much fee revenue each user generates on average, providing insights into user value and protocol monetization efficiency. The calculation divides total daily fees by the number of daily active users, where fees include both protocol revenue and supply-side fees from lending interest accruals.

## 2. Data sources

- **Interest accrual events**: Parsed `AccrueInterest` events from four Shoebill lending market contracts on Manta chain (sbEth, sbStone, sbUsdc, sbwUsdm)
- **User interaction events**: Parsed lending interaction events including `Borrow`, `Mint` (deposits), `Redeem` (withdrawals), and `RepayBorrow` events from the same four Shoebill contracts
- **Reserve factor configuration events**: Parsed `NewReserveFactor` events that set fee split parameters for each lending market
- **End-of-day price feeds**: Token price data for converting amounts to USD values
- **Token metadata**: Token symbol and decimal information for proper amount normalization

## 3. Step-by-step calculation

### Component A: Interest accrual tracking
- **Purpose**: Captures when borrowers pay interest to the protocol, generating fee revenue
- **Logic**: Extract all `AccrueInterest` events from four Shoebill lending contracts on Manta chain. Each event contains the total interest amount accumulated since the last accrual. Events are filtered to lending business line and include contract address, timestamp, and interest amount. All events are aggregated daily by truncating timestamps to day boundaries.
- **Key fields**: `interestAccumulated` (total interest amount), contract `address` (lending market identifier), `block_timestamp` (event timing)

### Component B: Reserve factor application
- **Purpose**: Determines fee split between protocol revenue and supply-side rewards using configurable reserve factors
- **Logic**: Track `NewReserveFactor` events that set the percentage of interest going to protocol versus suppliers. Use temporal logic to match each interest accrual with the correct reserve factor by finding the most recent reserve factor update before the accrual timestamp. Apply lead timestamp logic to handle reserve factor changes over time. Calculate protocol revenue as reserve factor multiplied by accrued interest, and supply-side fees as (1 - reserve factor) multiplied by accrued interest.
- **Key fields**: `newReserveFactorMantissa` (reserve factor as 18-decimal number), `address` (market contract), `block_timestamp` (factor update timing)

### Component C: User activity tracking
- **Purpose**: Identifies daily active users across all lending interactions
- **Logic**: Extract user interaction events from four types: `Borrow` events (users taking loans), `Mint` events (users depositing collateral), `Redeem` events (users withdrawing deposits), and `RepayBorrow` events (users repaying loans). Each event type identifies the user address performing the action. Classify users by interaction type (Borrower, Depositor, Withdrawer, Repayer). Truncate timestamps to daily boundaries and count distinct users using HyperLogLog aggregation to handle large-scale distinct counting efficiently.
- **Key fields**: `borrower` (borrowing user), `minter` (depositing user), `redeemer` (withdrawing user), `payer` (repaying user), `block_timestamp` (interaction timing)

### Component D: Fee aggregation and currency conversion
- **Purpose**: Combines protocol revenue and supply-side fees into total fees and converts to USD
- **Logic**: Sum protocol revenue and supply-side fees for each market and day to get total daily fees. Join with token metadata to get decimal places for each market's underlying token. Apply decimal correction by dividing amounts by 10^decimals. Convert corrected token amounts to USD using end-of-day price feeds matched by token address and date. Aggregate fees across all markets to get total daily protocol fees.
- **Key fields**: `revenue` (protocol's share), `fees_supply_side` (supplier rewards), `token_address` (market token), `timestamp` (daily boundary)

### Final aggregation
- **Combining components**: Join daily fee totals with daily active user counts on date, ensuring both metrics use the same daily time boundaries. Handle cases where fees exist but no users (set AFPU to 0) or users exist but no fees (set AFPU to 0).
- **Currency conversion**: All fee amounts are normalized to USD using end-of-day price feeds and decimal-corrected token amounts before aggregation
- **Time aggregation**: Both fees and user counts use daily boundaries created by truncating timestamps to day level, ensuring consistent time alignment
- **Final calculation**: Divide total daily fees (in USD) by daily active user count to get average fees per user. Apply zero-filling for missing days to create continuous time series. The final AFPU represents the average USD fee revenue generated per active user each day.

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

Shoebill Finance

Average fees per user (AFPU)

Average fees per user (AFPU)

Competitive landscape