back to docs
contributions

Taiko

Track Taiko chain fee/revenue

My first contribution to DefiLlama, a chain fees adapter for Taiko network using the Etherscan-compatible explorer.

  • Chain: Taiko
  • Type: Chain-level fees
  • Start Date: 2024-05-25
  • Approach: etherscanFeeAdapter helper
Status

Status: Merged

PR: #4911

Merged: December 4, 2024

1. Background story

a. How I started

This was my first attempt contributing to DefiLlama. I wasn’t confident and didn’t know where to start, so I reached out directly to reviewer treeoflife2 to ask if I should even try. He said “just do it”, so I did.

b. Initial research

I didn’t know DefiLlama had built-in helpers for common patterns. I started by looking for working explorers for Taiko:

Options found:

  1. TaikoScan (Etherscan-based) - Available
  2. Routescan - Worked, but required attribution that DefiLlama doesn’t support

After digging through the codebase, I found the etherscanFeeAdapter helper in ../helpers/etherscanFees.

2. Initial implementation

a. My original code

import { CHAIN } from "../helpers/chains";
import { etherscanFeeAdapter } from "../helpers/etherscanFees";

export default etherscanFeeAdapter(
  CHAIN.TAIKO,
  "https://taikoscan.io/chart/transactionfee?output=csv",
  "ethereum"
);

b. What I thought

I tested with specific past dates and got data back, so I thought it was working. The only issue I noticed was it couldn’t fetch today’s fees, but historical dates worked fine. I assumed this was acceptable. Output example:

> [email protected] test
> ts-node --transpile-only cli/testAdapter.ts fees taiko.ts

🦙 Running TAIKO.TS adapter 🦙
---------------------------------------------------
Start Date:	Tue, 02 Dec 2025 18:16:51 GMT
End Date:	Wed, 03 Dec 2025 18:16:51 GMT
---------------------------------------------------

------ ERROR ------
Error: no fee found for totay from etherscan
    at getEtherscanFees (/home/runner/work/dimension-adapters/dimension-adapters/helpers/etherscanFees.ts:17:15)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
no fee found for totay from etherscan
pnpm test fees taiko 2025/11/11

> [email protected] test D:\defiLlama\dimension-adapters
> ts-node --transpile-only cli/testAdapter.ts "fees" "taiko" "2025/11/11"

🦙 Running TAIKO adapter 🦙
---------------------------------------------------
Start Date:	Sun, 09 Nov 2025 17:00:00 GMT
End Date:	Mon, 10 Nov 2025 17:00:00 GMT
---------------------------------------------------

TAIKO 👇
Backfill start time: 25/5/2024
Daily fees: 188.00

3. The problem

a. CI/CD failure

When I submitted the PR, the automated CI workflow (llamabutler bot) ran tests and failed:

> [email protected] test
> ts-node --transpile-only cli/testAdapter.ts fees taiko.ts

🦙 Running TAIKO.TS adapter 🦙
---------------------------------------------------
Start Date:	Tue, 02 Dec 2025 18:16:51 GMT
End Date:	Wed, 03 Dec 2025 18:16:51 GMT
---------------------------------------------------

------ ERROR ------
Error: no fee found for totay from etherscan
    at getEtherscanFees (/home/runner/work/dimension-adapters/dimension-adapters/helpers/etherscanFees.ts:17:15)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
no fee found for totay from etherscan

Even though my local tests with historical dates showed data, something was wrong with the configuration.

b. What I wasn’t sure about

I’m still not entirely sure what the exact issue was. My implementation worked for past dates, but the error suggested:

  • Something wrong with how the helper was being called
  • Possibly incorrect parameters for the Etherscan adapter
  • Date handling issue for current day

The error message itself had a typo (“totay” instead of “today”), which was likely from the helper’s error handling.

4. The fix

a. Reviewer’s refactoring

treeoflife2 refactored the implementation. After the fix, tests showed:

Daily fees: 313.00
Daily revenue: 313.00
Daily protocol revenue: 313.00

b. What changed

The reviewer completely rewrote the adapter using a different approach:

My approach (using etherscanFeeAdapter helper):

export default etherscanFeeAdapter(
  CHAIN.TAIKO,
  "https://taikoscan.io/chart/transactionfee?output=csv",
  "ethereum"
);

Reviewer’s approach (manual implementation with getEtherscanFees):

const fetch = async (_a: any, _b: any, options: FetchOptions) => {
  const amount = await getEtherscanFees(
    options,
    'https://taikoscan.io/chart/transactionfee?output=csv'
  )
  const dailyFees = options.createBalances()
  dailyFees.addCGToken('ethereum', amount / 1e18)

  return {
    dailyFees,
    dailyRevenue: dailyFees,
    dailyProtocolRevenue: dailyFees
  };
}

const adapter: SimpleAdapter = {
  version: 1,
  fetch,
  chains: [CHAIN.TAIKO],
  start: '2024-05-25',
  protocolType: ProtocolType.CHAIN,
}

Key differences:

  • Used getEtherscanFees directly instead of the etherscanFeeAdapter wrapper
  • Manually created balances and added the fee amount with proper decimals (amount / 1e18)
  • Used version 1 adapter structure with explicit fetch function
  • Added protocolType: ProtocolType.CHAIN to identify it as a chain-level adapter

I tried using the higher-level helper (etherscanFeeAdapter), but the reviewer went with the lower-level approach (getEtherscanFees) for more control.

5. Key learnings

a. Technical

  • Read the helpers first: DefiLlama has helpers for common patterns (Etherscan, Uniswap V2, token tracking, etc.). Check ../helpers/ before writing custom logic.

  • Test edge cases: Testing only historical dates wasn’t enough. Current date handling matters.

  • Chain identifiers matter: The third parameter needs to match how the explorer categorizes the chain, not just use a default value.

b. Process

  • Just start: I was hesitant and lacked confidence, but the reviewer encouraged me to try anyway. The worst outcome is getting feedback.

  • Ask when stuck: Reaching out to reviewers directly helped. The community is supportive.

  • Reviewers will help: If your approach is reasonable but has issues, reviewers often refactor and fix it. This is a learning opportunity, not a failure.

  • Collaboration works: My initial attempt started the process. The reviewer’s expertise completed it. Both contributions mattered.

6. Resources

Command Palette
Search for a command to run...