chainfees-4

Fourth batch of multi-chain fee tracking contributions: 5 chains researched, submitted, and merged directly without remake.

• Type: Chain-level fees
• Pattern: blockscoutFeeAdapter2 (centralized config)
• Submitted: January 6, 2026
• Merged: January 6, 2026 (same day)
• Chains: MatChain, Saakuru, Genesys, Acala, Karura (5 total)

1. Background story

a. What actually happened

Breakthrough: direct merge!

After Batch 2 and Batch 3 being closed and remade by maintainer, Batch 4 was merged directly without any modifications.

Timeline:

• Submitted: January 6, 2026
• Reviewer assigned: 6 minutes after submission (@bheluga)
• Merged: January 6, 2026 (same day)
• No remake needed: First direct merge since Batch 1!

What made this different:

• Smaller batch (5 chains vs 8-11)
• Clean implementation (no issues)
• All tests passing
• Pattern already proven across 22 chains

The significance:

• Breaks the “remake pattern” from Batch 2 & 3
• Shows maintainer trust in my implementations
• Validates the research and code quality
• All 5 chains merged despite showing $0 fees

b. Why direct merge this time?

Possible reasons:

1. Established trust

   • 22 chains already merged (via remakes)
   • Pattern proven reliable
   • No issues in previous implementations

2. Smaller batch

   • 5 chains easier to review
   • Less risk than 8-11 chains
   • Quick to verify

3. Clean implementation

   • All tests passed
   • No RPC issues (unlike Astar zkEVM)
   • Standard pattern throughout

4. Zero fees acceptable

   • Despite all showing $0
   • Infrastructure tracking matters
   • Future activity expected

The lesson: Consistency and quality over multiple batches builds trust. Eventually, maintainers will merge directly instead of remaking.

2. The chains

a. MatChain

Implementation:

File: fees/matchain.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.MATCHAIN);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.MATCHAIN]: {
  CGToken: "binancecoin",
  explorer: "https://matchscan.io/"
},

Chain enum added to helpers/chains.ts:

MATCHAIN = "matchain",

Test results:

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

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

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

Key notes:

• MatChain uses matchscan.io
• CoinGecko token ID: binancecoin (uses BNB for fees)
• Zero fees during test period. Very new or less active chain

b. Saakuru

Implementation:

File: fees/saakuru.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.SAAKURU);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.SAAKURU]: {
  CGToken: "oasys",
  explorer: "https://explorer.saakuru.network/"
},

Chain enum added to helpers/chains.ts:

SAAKURU = "saakuru",

Test results:

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

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

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

Key notes:

• Saakuru uses explorer.saakuru.network
• CoinGecko token ID: oasys (Oasys token)
• Zero fees during test period

c. Genesys

Implementation:

File: fees/genesys.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.GENESYS);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.GENESYS]: {
  CGToken: "genesys",
  explorer: "https://gchainexplorer.genesys.network/"
},

Chain enum added to helpers/chains.ts:

GENESYS = "genesys",

Test results:

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

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

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

Key notes:

• Genesys uses gchainexplorer.genesys.network
• CoinGecko token ID: genesys
• Zero fees during test period

d. Acala

Implementation:

File: fees/acala.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.ACALA);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.ACALA]: {
  CGToken: "acala",
  explorer: "https://blockscout.acala.network/"
},

Test results:

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

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

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

Key notes:

• Acala uses blockscout.acala.network
• CoinGecko token ID: acala
• Official Blockscout subdomain
• Zero fees during test period

e. Karura

Implementation:

File: fees/karura.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.KARURA);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.KARURA]: {
  CGToken: "karura",
  explorer: "https://blockscout.karura.network/"
},

Test results:

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

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

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

Key notes:

• Karura uses blockscout.karura.network
• CoinGecko token ID: karura
• Official Blockscout subdomain
• Related to Acala ecosystem (Kusama parachain)
• Zero fees during test period

3. Technical details

a. Implementation summary

Files changed: 7

• 5 adapter files (acala.ts, genesys.ts, karura.ts, matchain.ts, saakuru.ts)
• 1 config file (helpers/blockscoutFees.ts)
• 1 enum file (helpers/chains.ts)

Lines added: +28

• 5 adapters × 4 lines = 20 lines
• 5 configs × ~1.5 lines = ~8 lines
• Total: 28 lines

Pattern: Same blockscoutFeeAdapter2 used across all chains

b. Chain configuration details

Notable:

• 2 chains with official Blockscout subdomains (Acala, Karura)
• 3 chains with custom explorer domains
• MatChain uses BNB for fees (binancecoin)
• Saakuru uses Oasys token

c. Zero fees analysis

All 5 chains showing $0 daily fees:

Possible reasons:

1. Very new chains. Recently launched, minimal adoption
2. Low transaction volume. Few users, minimal activity
3. Test period timing. Happened to test during quiet period
4. Free transactions. Some chains subsidize gas initially

Does this matter?

• Technically: Implementation is correct
• Practically: DefiLlama may prefer chains with actual activity
• Precedent: Batch 3 had some $0 chains that were still merged

What could happen:

• Reviewer might request testing different dates
• Reviewer might want to see some activity first
• Or might merge anyway (tracking infrastructure ready)

4. What happened: direct merge

a. The outcome

Scenario 1 happened: merged as-is!

What actually occurred:

• PR #5521 merged directly by @bheluga
• No remake needed
• All 5 chains accepted
• Zero fees were not an issue
• Merged same day (January 6, 2026)

Why this matters:

• First direct merge since Batch 1
• Breaks the “remake pattern” from Batch 2 & 3
• Shows established trust
• Validates consistent quality

b. What changed vs predictions

Expected (based on Batch 2 & 3):

• High likelihood of remake
• Low likelihood of direct merge
• Possible concern about zero fees

Reality:

• Merged directly
• No remake
• Zero fees accepted
• Trust established

Key factors:

1. Consistent quality across 22 previous chains
2. Smaller batch (5 chains) easier to verify
3. No infrastructure issues
4. Proven pattern reliability

5. What I learned

a. Zero fee consideration

New factor to consider:

• Actual chain activity, in addition to technical correctness and RPC stability

Updated research checklist:

Trade-off:

• Submit early (get infrastructure tracked)
• vs Submit with activity (proven usage)

b. Batch size strategy

Evolution:

• Batch 1: 4 chains (all merged)
• Batch 2: 8 chains (all kept in remake)
• Batch 3: 11 chains (1 removed)
• Batch 4: 5 chains (smaller, focused)

Why smaller this time:

• Found fewer Blockscout chains
• All showing zero fees
• Testing waters with smaller batch
• Faster to research and implement

c. Submission timing

Pattern emerging:

• Submit PR
• Bheluga self-assigns quickly (6 minutes this time)
• Wait for decision

No control over:

• Whether PR gets merged directly
• Whether PR gets remade
• Whether chains get removed

What I control:

• Research quality
• Implementation correctness
• Testing thoroughness
• Response speed to feedback

6. Current statistics

a. Across all batches

Final statistics:

Total lines of code: ~110 lines for 27 chains

Merge pattern:

• Batch 1: 4 PRs merged directly (100%)
• Batch 2: 1 PR closed, remade
• Batch 3: 1 PR closed, remade
• Batch 4: 1 PR merged directly (100%)

b. Fee activity summary

Chains with significant fees (>$10):

• Batch 2: Onus ($125), Prom ($93), Zilliqa ($49)
• Batch 3: Neon ($15), Exsat ($11)
• Total: 5 chains

Chains with low fees ($1-10):

• Batch 3: DOMA ($9), JOC ($3), Cross ($2), Superseed ($2), Orderly ($1)
• Total: 5 chains

Chains with zero fees:

• Batch 3: Shape, Bitgert, Numbers (3 chains)
• Batch 4: MatChain, Saakuru, Genesys, Acala, Karura (5 chains)
• Total: 8 chains (30% of all submissions)
• All zero-fee chains were accepted and merged

7. Resources

a. Pull request

• My PR #5521: Track multiple chain fees, merged

b. Chain explorers

• MatChain Scan
• Saakuru Explorer
• Genesys Explorer
• Acala Blockscout
• Karura Blockscout

c. Documentation

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

8. Key insights from direct merge

a. What led to direct merge

Trust building over time:

1. Batch 1: 4 PRs merged directly, initial trust
2. Batch 2 & 3: PRs remade, maintainer wants control
3. Batch 4: Merged directly, trust re-established

The progression:

• Start: Direct merges (no history)
• Middle: Remakes (establishing pattern)
• Now: Direct merges (proven reliability)

What mattered:

• 22 chains successfully merged via remakes
• Zero issues in previous implementations
• Consistent code quality
• Same pattern every time

b. Lessons learned

Zero fees don’t matter:

• All 5 chains had $0 fees
• All 5 were merged anyway
• Infrastructure tracking > immediate activity
• Future usage expected

Smaller batches work:

• 5 chains easier to review than 8-11
• Faster verification
• Less risk
• More likely to merge directly

Consistency pays off:

• Same pattern across all batches
• Same code quality
• Same testing rigor
• Built maintainer trust over time

9. Key takeaways

a. Final status

What I did:

• Researched 5 Blockscout chains
• Implemented all adapters correctly
• All tests passed
• Submitted PR #5521

What happened:

• Merged directly by @bheluga
• No remake needed
• All 5 chains accepted
• Zero fees were not an issue

The significance:

• First direct merge since Batch 1
• Proves trust has been established
• Validates consistent quality approach
• Shows zero fees don’t block acceptance

b. Patterns confirmed

Across 4 batches:

• Batch 1: 4 PRs merged directly
• Batch 2: Closed, remade, all 8 kept
• Batch 3: Closed, remade, 10/11 kept
• Batch 4: Merged directly (breakthrough!)

The actual pattern:

• Initial submissions: Direct merge (establishing quality)
• Middle submissions: Remakes (maintainer control)
• Later submissions: Direct merge (trust re-established)

Key insight: Consistency over multiple batches builds trust. Eventually, the remake pattern breaks and direct merges resume.

c. What actually matters

Proven through 4 batches:

1. Consistency wins

   • Same pattern every time
   • Same code quality
   • Same testing rigor
   • Result: Trust built over time

2. Infrastructure > Activity

   • 8 chains with $0 fees all merged
   • Tracking infrastructure matters
   • Future activity expected
   • DefiLlama prefers early tracking

3. Quality > Speed

   • Not about submitting fast
   • About submitting correctly
   • Every single time
   • No exceptions

4. Impact over attribution

   • 27 chains added to DefiLlama
   • Some via direct merge
   • Some via remake
   • All count as contribution

d. Final numbers

Total contribution:

• 27 chains added to DefiLlama
• 96.4% success rate (27/28)
• ~110 lines of code
• 4 batches completed
• 71.4% direct merge rate (5/7 PRs)
• 2 remakes (both kept all chains)
• 1 chain removed (infrastructure issues)

The progression:

Individual protocols (complex)
         ↓
Chain fees - Rapid succession (Batch 1)
         ↓
Chain fees - Batch submission (Batch 2 & 3, remade)
         ↓
Chain fees - Trusted contributor (Batch 4, direct merge)

This is what building trust in open source looks like.