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:
etherscanFeeAdapterhelper
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:
- TaikoScan (Etherscan-based) - Available
- 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
getEtherscanFeesdirectly instead of theetherscanFeeAdapterwrapper - Manually created balances and added the fee amount with proper decimals (
amount / 1e18) - Used version 1 adapter structure with explicit
fetchfunction - Added
protocolType: ProtocolType.CHAINto 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.