chainfees-3

Third batch of multi-chain fee tracking contributions: 11 chains researched and implemented, with one removed during maintainer’s review.

• Type: Chain-level fees
• Pattern: blockscoutFeeAdapter2 (centralized config)
• Submitted: January 5, 2026
• Chains submitted: Neon, Shape, Superseed, Astar zkEVM, JOC, DOMA, Exsat, Bitgert, Cross, Numbers, Orderly Network (11 total)
• Chains merged: 10 (Astar zkEVM removed)

1. Background story

a. What happened

Same pattern as Batch 2:

My submission (PR #5508):

• Researched and identified 11 Blockscout chains
• Implemented all adapters using blockscoutFeeAdapter2
• Tested all chains locally
• Submitted PR #5508 on January 5, 2026
• 13 files changed, +60 lines

Maintainer’s actions:

• Closed PR #5508
• Created new PR #5520 with same chains
• Removed Astar zkEVM due to RPC availability issues
• Merged PR #5520 on January 6, 2026
• 12 files changed, +54 lines (6 fewer lines due to Astar removal)

The difference: Unlike Batch 2 where all chains were kept, this batch had one chain removed during the remake process.

b. Why Astar zkEVM was removed

The issue:

• Astar zkEVM had RPC provider availability issues during testing
• Test results showed: “error fetching block Error: Last block for astar_zkevm is X minutes behind”
• While fee data could still be fetched from Blockscout API, RPC reliability was questionable

Maintainer’s decision:

• Remove the chain rather than merge with known RPC issues
• Better to wait until RPC infrastructure is more stable
• Final commit (e298897) removed astar-zkevm adapter

Learning: Even if Blockscout API works, chains with unstable RPC providers may not be accepted. Infrastructure reliability matters.

2. The chains

a. Neon EVM

Implementation:

File: fees/neon.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.NEON);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.NEON]: {
  CGToken: "neon",
  explorer: "https://neon.blockscout.com/"
},

Test results:

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

🦙 Running NEON.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

NEON_EVM 👇
Daily fees: 15.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Neon EVM uses neon.blockscout.com
• CoinGecko token ID: neon
• EVM-compatible chain built on Solana

b. Shape

Implementation:

File: fees/shape.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.SHAPE);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.SHAPE]: {
  CGToken: "ethereum",
  explorer: "https://shapescan.xyz/"
},

Test results:

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

🦙 Running SHAPE.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

SHAPE 👇
Daily fees: 0.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Shape uses shapescan.xyz
• CoinGecko token ID: ethereum (uses ETH for fees)
• Fee variance suggests new/low-activity chain

c. Superseed

Implementation:

File: fees/superseed.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.SSEED);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.SSEED]: {
  CGToken: "ethereum",
  explorer: "https://explorer.superseed.xyz/"
},

Test results:

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

🦙 Running SUPERSEED.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

SSEED 👇
Daily fees: 2.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Superseed uses explorer.superseed.xyz
• CoinGecko token ID: ethereum (uses ETH for fees)
• Chain enum is SSEED, not SUPERSEED

d. Astar zkEVM

My implementation (not merged):

File: fees/astar-zkevm.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.ASTAR_ZKEVM);

Chain config (Not Merged):

[CHAIN.ASTAR_ZKEVM]: {
  CGToken: "astar",
  explorer: "https://astar.blockscout.com/"
},

Test issues:

• RPC provider showing: “Last block for astar_zkevm is X minutes behind”
• Inconsistent RPC availability
• Maintainer removed in final commit (e298897)

Why it was removed:

• Infrastructure reliability concerns
• Better to wait for stable RPC before adding
• Blockscout API alone isn’t enough if RPC is unreliable

Key Learning: Not every chain you implement will be merged, even if technically correct. Infrastructure stability matters.

e. JOC (Japan Open Chain)

Implementation:

File: fees/joc.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.JOC);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.JOC]: {
  CGToken: "japan-open-chain",
  explorer: "https://explorer.japanopenchain.org/"
},

Test results:

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

🦙 Running JOC.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

JOC 👇
Daily fees: 3.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• JOC uses explorer.japanopenchain.org
• CoinGecko token ID: japan-open-chain
• Regional blockchain for Japan

f. DOMA

Implementation:

File: fees/doma.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.DOMA);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.DOMA]: {
  CGToken: "ethereum",
  explorer: "https://explorer.doma.xyz/"
},

Test results:

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

🦙 Running DOMA.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

DOMA 👇
Daily fees: 9.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• DOMA uses explorer.doma.xyz
• CoinGecko token ID: ethereum (uses ETH for fees)

g. Exsat

Implementation:

File: fees/exsat.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.EXSAT);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.EXSAT]: {
  CGToken: "bitcoin",
  explorer: "https://scan.exsat.network/"
},

Test results:

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

🦙 Running EXSAT.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

XSAT 👇
Daily fees: 11.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Exsat uses scan.exsat.network
• CoinGecko token ID: bitcoin (uses BTC for fees)
• Bitcoin-related chain

h. Bitgert

Implementation:

File: fees/bitgert.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.BITGERT);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.BITGERT]: {
  CGToken: "bitrise-token",
  explorer: "https://brisescan.com/"
},

Test results:

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

🦙 Running BITGERT.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

[... RPC provider warnings ...]
BITGERT 👇
Daily fees: 0.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Bitgert uses brisescan.com
• CoinGecko token ID: bitrise-token (BRISE)
• Had RPC provider issues during testing but was still merged
• Very low or zero activity

i. Cross

Implementation:

File: fees/cross.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.CROSS);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.CROSS]: {
  CGToken: "cross-2",
  explorer: "https://www.crossscan.io/"
},

Test results:

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

🦙 Running CROSS.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

CROSS 👇
Daily fees: 2.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Cross uses crossscan.io
• CoinGecko token ID: cross-2 (note the “-2” suffix)

j. Numbers Protocol

Implementation:

File: fees/numbers.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.NUMBERS);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.NUMBERS]: {
  CGToken: "numbers-protocol",
  explorer: "https://mainnet.num.network/"
},

Test results:

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

🦙 Running NUMBERS.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

NUMBERS 👇
Daily fees: 0.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Numbers Protocol uses mainnet.num.network
• CoinGecko token ID: numbers-protocol
• Zero activity during test period

k. Orderly Network

Implementation:

File: fees/orderly-network.ts (4 lines)

import { blockscoutFeeAdapter2 } from "../helpers/blockscoutFees";
import { CHAIN } from "../helpers/chains";

export default blockscoutFeeAdapter2(CHAIN.ORDERLY);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.ORDERLY]: {
  CGToken: "ethereum",
  explorer: "https://explorer.orderly.network/"
},

Test results:

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

🦙 Running ORDERLY-NETWORK.TS adapter 🦙
---------------------------------------------------
Start Date:	Mon, 05 Jan 2026 00:00:00 GMT
End Date:	Tue, 06 Jan 2026 00:00:00 GMT
---------------------------------------------------

ORDERLY 👇
Daily fees: 1.00
End timestamp: 1767571200 (2026-01-05T00:00:00.000Z)

Key notes:

• Orderly Network uses explorer.orderly.network
• CoinGecko token ID: ethereum (uses ETH for fees)
• File named orderly-network.ts to avoid conflict with existing fees/orderly (application-level fees)

3. Key differences: my PR vs maintainer’s PR

a. What changed

Files:

• My PR (#5508): 13 files changed, +60 lines
• Maintainer’s PR (#5520): 12 files changed, +54 lines
• Difference: 1 file removed (astar-zkevm), 6 fewer lines

Chains:

• My PR: 11 chains submitted
• Maintainer’s PR: 10 chains merged (Astar zkEVM removed)
• Success rate: 10/11 (90.9%)

Code:

• Implementation pattern: identical (blockscoutFeeAdapter2)
• Explorer URLs: identical
• CoinGecko token IDs: identical
• Only difference: Astar zkEVM completely removed

b. The Astar zkEVM situation

Why I included it:

• Blockscout explorer exists and works
• API returns fee data correctly
• Follows same pattern as other chains

Why maintainer removed it:

• RPC provider reliability issues
• Test showed: “Last block for astar_zkevm is X minutes behind”
• Infrastructure not stable enough for production tracking

The lesson: Technical implementation correctness isn’t enough. Infrastructure reliability is a requirement for chain acceptance.

4. Submission results

a. Timeline

My submission, January 5, 2026:

• Researched 11 Blockscout chains
• Implemented all adapters
• Tested all chains locally
• Submitted PR #5508
• 13 files changed, +60 lines

Maintainer’s actions, January 6, 2026:

• Closed PR #5508
• Created PR #5520
• Removed Astar zkEVM (commit e298897)
• Merged PR #5520
• 12 files changed, +54 lines
• 10 chains added to DefiLlama

b. Efficiency metrics

Key insight: Not all researched chains will make it to production. Infrastructure stability can block otherwise correct implementations.

5. Key learnings

a. Infrastructure matters more than code

Technical correctness isn’t enough:

• Astar zkEVM implementation was correct
• Blockscout API worked fine
• Pattern was identical to other chains

Infrastructure reliability required:

• RPC provider must be stable
• Block indexing must be current
• Network availability must be consistent

The decision criteria:

b. RPC vs Blockscout API

Two different things:

• Blockscout API: HTTP API for querying indexed blockchain data
• RPC Provider: Node endpoint for real-time blockchain queries

Why both matter:

• Blockscout API can work even if RPC is slow
• But unreliable RPC suggests infrastructure issues
• DefiLlama prefers chains with stable infrastructure

Astar zkEVM case:

• Blockscout API: Working
• RPC Provider: Unstable
• Result: Removed from PR

c. Naming conflicts

Orderly Network special case:

The problem:

• fees/orderly already exists (tracks application fees)
• Can’t use fees/orderly.ts for chain fees (path conflict)

The solution:

• Named file orderly-network.ts instead
• Chain enum still ORDERLY
• Avoids filesystem conflict

Learning: Check for existing files before naming new adapters. Application-level and chain-level tracking can conflict.

d. Fee activity insights

Daily fees from merged chains:

Observations:

• Most chains have low to very low activity
• Three chains with zero fees during test period (Shape, Bitgert, Numbers), likely less active or new chains with minimal transactions
• Neon has the highest fees at $15
• Total daily fees: ~$43 (much lower than Batch 2’s $283)

6. Comparison across batches

a. Evolution summary

Total across 3 batches:

• Chains researched: 23
• Chains merged: 22
• Overall success rate: 95.7%
• Direct PR merges: 4/6 (66.7%)
• Contribution impact: 22 chains added to DefiLlama

b. What changed between batches

Batch 1 → Batch 2:

• Strategy: Rapid succession → True batch
• Outcome: All chains kept
• Learning: Batch submission works

Batch 2 → Batch 3:

• Strategy: Same batch approach
• Outcome: 1 chain removed
• Learning: Infrastructure stability screening

New reality:

• Maintainer now reviews infrastructure in addition to code
• Chains with RPC issues get removed
• 90.9% success rate still very good

7. Resources

a. Pull requests

• My PR #5508: Track fees for 11 chains, closed
• Maintainer’s PR #5520: Track fees for 10 chains by @bheluga, merged

b. Chain explorers (merged)

• Neon Explorer
• Shape Scan
• Superseed Explorer
• JOC Explorer
• DOMA Explorer
• Exsat Scan
• Bitgert Scan
• Cross Scan
• Numbers Network
• Orderly Explorer

c. Chain explorer (removed)

• Astar zkEVM had RPC issues, not merged

d. Documentation

• blockscoutFeeAdapter2 Helper
• Chain Fees Batch 1
• Chain Fees Batch 2

8. Key takeaways

a. What worked and what didn’t

What worked:

• Research methodology: Found 11 valid Blockscout chains
• Implementation: Correct pattern for all chains
• Testing: All chains tested locally
• Batch submission: Efficient workflow

What didn’t work:

• Astar zkEVM: RPC provider instability
• Assumption: Thought Blockscout API alone was enough

What actually matters:

• Infrastructure reliability. More than API availability
• RPC stability. Required for chain acceptance
• 10/11 success. Still excellent outcome
• Total impact: 22 chains across 3 batches

b. The reality of open source

Expectations vs reality:

Expected:

• Submit 11 chains
• All technically correct
• All merged

Reality:

• Submit 11 chains
• 10 technically correct
• 1 has infrastructure issues
• Maintainer removes problematic chain
• 10 merged

Learning: Perfect code doesn’t guarantee perfect outcomes. External factors (RPC reliability, infrastructure) matter just as much as implementation quality.

c. Continuous improvement

What I’m learning across batches:

Batch 1:

• Pattern recognition (blockscoutFeeAdapter2)
• Rapid submission works

Batch 2:

• Batch submission more efficient
• Maintainers may remake PRs

Batch 3:

• Infrastructure stability matters
• Not every chain will make it
• 90% success rate is still very good

Overall:

• 22 chains added to DefiLlama
• 95.7% success rate across all batches
• Understanding that contribution impact matters more than PR attribution
• Infrastructure reliability is now part of my research checklist

d. Moving forward

Updated research checklist:

Next batches:

• Pre-check RPC stability before implementing
• Test for “block behind” warnings
• Accept that some chains won’t make it
• Focus on impact: chains added, not PRs merged