DefiLlama Contributions

This page documents my contributions to DefiLlama’s dimension-adapters repository. The adapters track fees, revenue, and volume data for DeFi protocols across multiple blockchains.

1. Repository overview

DefiLlama is the largest TVL and data aggregator in DeFi. The dimension-adapters repository specifically handles:

• Daily fees collected by protocols
• Revenue breakdown (protocol, supply-side, holders)
• Trading volume for DEXs and derivatives platforms

Adapters are written in TypeScript and run periodically on DefiLlama’s infrastructure to update defillama.com.

2. My adapters

a. Completed & merged

• track taiko fees
• track Solomon USDv Fee/Revenue
• track provenance chain Fee/Revenue
• track fees/revenue opentrade
• track fees/revenue aquabank
• track chain fees 1
• track chain fees 4
• track chain fees 5

b. Closed

• track variational vol & OI
• track fees/revenue hunnyswap
• track bitfi fees & revenue
• track chain fees 2
• track chain fees 3

c. Open

None

3. Adapter structure

Standard structure for dimension adapters (fees/revenue):

import { FetchOptions, SimpleAdapter } from "../adapters/types";
import { CHAIN } from "../helpers/chains";

const fetch = async (options: FetchOptions) => {
  const dailyFees = options.createBalances();
  const dailyRevenue = options.createBalances();
  const dailyProtocolRevenue = options.createBalances();
  const dailySupplySideRevenue = options.createBalances();
  const dailyHoldersRevenue = options.createBalances();

  // Track fees using helpers
  await addTokensReceived({
    options,
    targets: [feeWallet],
    tokens: [tokenAddress],
    balances: dailyFees,
  });

  return {
    dailyFees,
    dailyRevenue,
    dailyProtocolRevenue,
    dailySupplySideRevenue,
    dailyHoldersRevenue,
  };
};

const adapter: SimpleAdapter = {
  version: 2, // Always use v2 for new adapters
  adapter: {
    [CHAIN.ETHEREUM]: {
      fetch,
      start: "2024-01-01", // YYYY-MM-DD format
    },
  },
  methodology: {
    Fees: "Description of total fees calculation",
    Revenue: "Description of revenue breakdown",
    ProtocolRevenue: "Revenue going to protocol treasury",
    SupplySideRevenue: "Revenue distributed to LPs/depositors",
    HoldersRevenue: "Revenue for token holders/stakers",
  },
};

export default adapter;

Common metrics

• dailyFees - Total fees generated
• dailyRevenue - Total revenue (usually equals fees)
• dailyProtocolRevenue - Revenue to protocol treasury
• dailySupplySideRevenue - Revenue to LPs/depositors
• dailyHoldersRevenue - Revenue to token holders/stakers
• dailyUserFees - Fees paid by users (if different from dailyFees)

4. Development process

a. Testing

# Test adapter
pnpm test fees [protocol-name]

# Test specific date
pnpm test fees [protocol-name] 2024-01-01

b. Key implementation points

• Fee Wallets: Verify addresses from on-chain transactions, not just documentation
• Start Date: Check contract deployment date from block explorer
• Revenue Breakdown: Separate protocol revenue, supply-side, and holders revenue clearly
• Helpers: Use existing helpers like addTokensReceived, getUniV2LogAdapter when applicable
• Testing: Test multiple dates to ensure data consistency

5. Common challenges

a. Documentation gap

Problem: Protocol documentation often incomplete or outdated

Solution:

• Read smart contract source code directly on block explorers
• Check protocol Discord/Telegram for clarifications
• Study similar protocol implementations

b. Data consistency

Problem: Calculated values differ from official protocol website

Solution:

• Verify calculation methodology with protocol team
• Check for double-counting (e.g., LP token values)
• Validate with block explorer transaction data

c. Multi-chain deployments

Problem: Protocol deployed on multiple chains with different addresses

Solution:

• Use chain-agnostic approach where possible
• Handle chain-specific block numbers correctly
• Create separate fetch functions per chain if needed

6. Key learnings

Technical

• Always verify fee wallet addresses from actual transactions, not docs
• Use multicall patterns for efficient batch contract reads
• Test adapters with multiple historical dates for consistency
• Handle edge cases (zero values, missing data, etc.)

Process

• Research protocol thoroughly before writing code
• Study existing adapters for similar protocols
• Write clear methodology explaining each metric
• Respond quickly to reviewer feedback
• Be patient. Review processes take time.

7. Resources

• dimension-adapters Repository
• DefiLlama Dimension Docs
• DefiLlama Discord - Get help from maintainers