back to docs
contributions

chainfees-5

Fifth batch of multi-chain fee tracking contributions: 11 chains researched across two separate PRs, both merged directly without remake.

  • Type: Chain-level fees
  • Pattern: blockscoutFeeAdapter2 (centralized config)
  • Submitted: January 9-11, 2026
  • Merged: January 9-11, 2026
  • Chains: Loop, Stratis, OMAX, Q Protocol, VinuChain (PR #5524) + Rollux, TAC, Endurance, Swan, BitciChain, Perennial (PR #5547) = 11 total
Status

My PRs:

  • #5547, merged (January 9, 2026)
  • #5524, merged (January 11, 2026)

Merged by: @treeoflife2 (PR #5547), @noateden (PR #5524)

Outcome: All 11 chains merged. Second consecutive batch without PR remake!

Minor revisions: Both PRs had minor maintainer revisions before merge (code formatting cleanup + Q Protocol update)

1. Background story

a. What actually happened

Pattern continues: No remakes!

After the breakthrough in Batch 4, Batch 5 continues the trend with two separate PRs both merged without remake (though with minor revisions).

Timeline:

PR #5547 (6 chains):

  • Submitted: January 8, 2026
  • Revisions by @treeoflife2: Code formatting cleanup (removed empty spaces)
  • Merged: January 9, 2026 (next day)
  • Merged by: @treeoflife2
  • Chains: Rollux, TAC, Endurance, Swan, BitciChain, Perennial

PR #5524 (5 chains):

  • Submitted: January 11, 2026
  • Fix by me: Added missing comma in enum
  • Revision by @noateden: Updated Q Protocol adapter
  • Merged: January 11, 2026 (same day)
  • Merged by: @noateden
  • Chains: Loop, Stratis, OMAX, Q Protocol, VinuChain

What made this different:

  • Split into two PRs (6 + 5 chains)
  • Minor revisions instead of full PR remakes
  • Different maintainers handled each PR
  • All chains kept
  • Pattern continues from Batch 4

The significance:

  • Two consecutive batches without PR remake
  • Maintainers make minor fixes directly instead of closing + remaking
  • Shows increased trust. They work with my PR instead of replacing it
  • Multiple maintainers collaborate on my submissions

b. Why split into two PRs?

Strategy evolution:

  • Batch 2: 8 chains → remade
  • Batch 3: 11 chains → remade (1 removed)
  • Batch 4: 5 chains → merged directly
  • Batch 5: 6 + 5 chains → both merged directly

Reasons for splitting:

  1. Risk distribution

    • If one PR has issues, other still merges
    • Easier to review smaller batches
    • More maintainers can participate
  2. Faster processing

    • Smaller PRs reviewed faster
    • Less overwhelming for reviewers
    • Can submit as soon as ready
  3. Learning from Batch 4

    • 5 chains worked perfectly
    • 6 chains still manageable
    • Better than 8-11 chain mega-batches

The result: Both PRs merged quickly with minor revisions, validating the split strategy.

c. What revisions were made?

PR #5547 revisions (by @treeoflife2):

Commit 2: “remove empty space”

  • Code formatting cleanup
  • Removed unnecessary whitespace
  • No logic changes

Commit 3: “remove space”

  • Additional whitespace cleanup
  • Consistent formatting
  • No logic changes

Commit 4: “Merge branch ‘master’ into chain_fees_3”

  • Synced with latest master branch
  • Standard merge operation

PR #5524 revisions:

Commit 2 (by me): “fix: add missing comma in enum”

  • Fixed syntax error in helpers/chains.ts
  • Added missing comma after BITCICHAIN entry
  • Caught and fixed before maintainer review

Commit 3 (by @noateden): “update q”

  • Updated Q Protocol adapter implementation
  • Specific changes to q-protocol.ts
  • Maintainer refinement

What this shows:

  • PR #5547: Only formatting cleanup, no logic changes
  • PR #5524: One syntax fix by me, one adapter update by maintainer
  • Neither PR was closed/remade. Maintainers worked directly on my branches
  • This is very different from Batch 2 & 3 where entire PRs were remade

2. The chains (PR #5547)

a. Rollux

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/rollux.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.ROLLUX);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.ROLLUX]: {
  CGToken: "rollux",
  explorer: "https://explorer.rollux.com/"
},

Chain enum added to helpers/chains.ts:

ROLLUX = "rollux",

Test results:

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

🦙 Running ROLLUX.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

ROLLUX 👇
Daily fees: 0.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:

  • Rollux uses explorer.rollux.com
  • CoinGecko token ID: rollux
  • L2 solution with minimal initial activity

b. TAC

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/tac.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.TAC);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.TAC]: {
  CGToken: "tac",
  explorer: "https://explorer.tac.build/"
},

Chain enum added to helpers/chains.ts:

TAC = "tac",

Test results:

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

🦙 Running TAC.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

TAC 👇
Daily fees: 2.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:

  • TAC uses explorer.tac.build
  • CoinGecko token ID: tac
  • Showing modest initial activity ($1-2 daily fees)

c. Endurance

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/endurance.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.ENDURANCE);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.ENDURANCE]: {
  CGToken: "endurance",
  explorer: "https://explorer-endurance.fusionist.io/"
},

Chain enum added to helpers/chains.ts:

ENDURANCE = "endurance",

Test results:

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

🦙 Running ENDURANCE.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

ENDURANCE 👇
Daily fees: 0.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:


d. Swan

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/swan.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.SWAN);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.SWAN]: {
  CGToken: "ethereum",
  explorer: "https://mainnet-explorer.swanchain.io/"
},

Chain enum added to helpers/chains.ts:

SWAN = "swan",

Test results:

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

🦙 Running SWAN.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

SWAN 👇
Daily fees: 0.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:


e. BitciChain

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/bitcichain.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.BITCICHAIN);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.BITCICHAIN]: {
  CGToken: "bitcicoin",
  explorer: "https://v3.bitciexplorer.com/"
},

Chain enum added to helpers/chains.ts:

BITCICHAIN = "bitcichain",

Test results:

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

🦙 Running BITCICHAIN.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

BITCICHAIN 👇
Daily fees: 0.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:

  • BitciChain uses v3.bitciexplorer.com
  • CoinGecko token ID: bitcicoin
  • Note: Explorer version in URL (v3)

f. Perennial

Status

PR: #5547, merged

Merged: January 9, 2026

Implementation:

File: fees/perennial-chain.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.PERENNIAL);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.PERENNIAL]: {
  CGToken: "ethereum",
  explorer: "https://explorer.perennial.foundation/"
},

Chain enum added to helpers/chains.ts:

PERENNIAL = "perennial",

Test results:

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

🦙 Running PERENNIAL-CHAIN.TS adapter 🦙
---------------------------------------------------
Start Date:	Thu, 08 Jan 2026 00:00:00 GMT
End Date:	Fri, 09 Jan 2026 00:00:00 GMT
---------------------------------------------------

PERENNIAL 👇
Daily fees: 0.00
End timestamp: 1767830400 (2026-01-08T00:00:00.000Z)

Key notes:

  • Perennial uses explorer.perennial.foundation
  • CoinGecko token ID: ethereum (uses ETH for fees)
  • File named perennial-chain.ts (possible naming consideration)

3. The chains (PR #5524)

a. Loop

Status

PR: #5524, merged

Merged: January 11, 2026

Implementation:

File: fees/loop.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.LOOP);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.LOOP]: {
  CGToken: "loopnetwork",
  explorer: "https://explorer.mainnetloop.com/"
},

Chain enum added to helpers/chains.ts:

LOOP = "loop",

Test results:

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

🦙 Running LOOP.TS adapter 🦙
---------------------------------------------------
Start Date:	Fri, 09 Jan 2026 00:00:00 GMT
End Date:	Sat, 10 Jan 2026 00:00:00 GMT
---------------------------------------------------

LOOP 👇
Daily fees: 0.00
End timestamp: 1767916800 (2026-01-09T00:00:00.000Z)

Key notes:


b. Stratis

Status

PR: #5524, merged

Merged: January 11, 2026

Implementation:

File: fees/stratis.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.STRATIS);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.STRATIS]: {
  CGToken: "stratis",
  explorer: "https://explorer.xertra.com/"
},

Chain enum added to helpers/chains.ts:

STRATIS = "stratis",

Test results:

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

🦙 Running STRATIS.TS adapter 🦙
---------------------------------------------------
Start Date:	Fri, 09 Jan 2026 00:00:00 GMT
End Date:	Sat, 10 Jan 2026 00:00:00 GMT
---------------------------------------------------

STRATIS 👇
Daily fees: 0.00
End timestamp: 1767916800 (2026-01-09T00:00:00.000Z)

Key notes:


c. OMAX

Status

PR: #5524, merged

Merged: January 11, 2026

Implementation:

File: fees/omax.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.OMAX);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.OMAX]: {
  CGToken: "omax-token",
  explorer: "https://omaxscan.com/"
},

Chain enum added to helpers/chains.ts:

OMAX = "omax",

Test results:

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

🦙 Running OMAX.TS adapter 🦙
---------------------------------------------------
Start Date:	Fri, 09 Jan 2026 00:00:00 GMT
End Date:	Sat, 10 Jan 2026 00:00:00 GMT
---------------------------------------------------

OMAX 👇
Daily fees: 0.00
End timestamp: 1767916800 (2026-01-09T00:00:00.000Z)

Key notes:

  • OMAX uses omaxscan.com
  • CoinGecko token ID: omax-token
  • Dedicated scan domain

d. Q Protocol

Status

PR: #5524, merged

Merged: January 11, 2026

Note: Updated by @noateden before merge (commit: “update q”)

Implementation:

File: fees/q-protocol.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.Q_PROTOCOL);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.Q_PROTOCOL]: {
  CGToken: "q-protocol",
  explorer: "https://explorer.q.org/"
},

Chain enum added to helpers/chains.ts:

Q_PROTOCOL = "q_protocol",

Test results:

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

🦙 Running Q-PROTOCOL.TS adapter 🦙
---------------------------------------------------
Start Date:	Fri, 09 Jan 2026 00:00:00 GMT
End Date:	Sat, 10 Jan 2026 00:00:00 GMT
---------------------------------------------------

Q_PROTOCOL 👇
Daily fees: 0.00
End timestamp: 1767916800 (2026-01-09T00:00:00.000Z)

Key notes:

  • Q Protocol uses explorer.q.org
  • CoinGecko token ID: q-protocol
  • Clean .org domain for explorer

e. Vinu Chain

Status

PR: #5524, merged

Merged: January 11, 2026

Implementation:

File: fees/vinu.ts (4 lines)

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

export default blockscoutFeeAdapter2(CHAIN.VINUCHAIN);

Chain config added to helpers/blockscoutFees.ts:

[CHAIN.VINUCHAIN]: {
  CGToken: "vinuchain",
  explorer: "https://vinuexplorer.org/"
},

Chain enum added to helpers/chains.ts:

VINUCHAIN = "vinuchain",

Test results:

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

🦙 Running VINU.TS adapter 🦙
---------------------------------------------------
Start Date:	Fri, 09 Jan 2026 00:00:00 GMT
End Date:	Sat, 10 Jan 2026 00:00:00 GMT
---------------------------------------------------

VINU 👇
Daily fees: 0.00
End timestamp: 1767916800 (2026-01-09T00:00:00.000Z)

Key notes:

  • VinuChain uses vinuexplorer.org
  • CoinGecko token ID: vinuchain
  • File named vinu.ts (shortened from vinuchain)

4. Technical details

a. Implementation summary

PR #5547:

  • Files changed: 8
  • Lines added: +30
  • Chains: 6 (Rollux, TAC, Endurance, Swan, BitciChain, Perennial)
  • Merged: January 9, 2026

PR #5524:

  • Files changed: 7
  • Lines added: +30
  • Chains: 5 (Loop, Stratis, OMAX, Q Protocol, VinuChain)
  • Merged: January 11, 2026

Total:

  • Files changed: 15
  • Lines added: ~60
  • Chains: 11
  • Pattern: Same blockscoutFeeAdapter2 used across all chains

b. Chain configuration details

PR #5547:

ChainEnumCoinGecko TokenExplorer Type
RolluxROLLUXrolluxCustom domain
TACTACtacCustom (.build)
EnduranceENDURANCEenduranceFusionist subdomain
SwanSWANethereumSwanChain subdomain
BitciChainBITCICHAINbitcicoinVersion 3 explorer
PerennialPERENNIALethereumFoundation domain

PR #5524:

ChainEnumCoinGecko TokenExplorer Type
LoopLOOPloopnetworkMainnet subdomain
StratisSTRATISstratisXertra domain
OMAXOMAXomax-tokenCustom scan domain
Q ProtocolQ_PROTOCOLq-protocol.org domain
VinuChainVINUCHAINvinuchain.org domain

Notable:

  • 3 chains using ethereum for fees (Swan, Perennial from #5547)
  • 2 chains with .org domains (Q Protocol, VinuChain)
  • Variety of explorer naming conventions
  • Some shortened filenames (vinu.ts for VinuChain)

c. Revisions summary

PR #5547 revisions:

By @treeoflife2 (maintainer):

  1. Removed empty spaces (2 commits)
  2. Merged master branch into feature branch
  3. Impact: Formatting only, no logic changes

PR #5524 revisions:

By me (Commit 2):

Commit 37b6821: “fix: add missing comma in enum”

The problem:

  • Missing comma after BITCICHAIN entry in helpers/chains.ts
  • Would cause TypeScript compilation error
  • Caught during testing phase

The fix:

// Before (error):
BITCICHAIN = "bitcichain"
ENDURANCE = "endurance"

// After (correct):
BITCICHAIN = "bitcichain",
ENDURANCE = "endurance"

By @noateden (maintainer, Commit 3):

Commit 6419079: “update q”

  • Updated Q Protocol adapter
  • Refinement to fees/q-protocol.ts
  • Specific implementation details adjusted by maintainer

Learning:

  • Syntax errors can happen. I caught and fixed mine quickly
  • Maintainers may refine specific adapters before merge
  • Minor revisions are normal, full PR remakes are not

d. Zero fees analysis

All 11 chains showing $0 daily fees (except TAC with $1-2):

Possible reasons:

  1. Very new chains. Recently launched, minimal adoption
  2. Low transaction volume. Infrastructure ready, waiting for users
  3. Test period timing. Tested during quiet period
  4. Early tracking. Better to track before activity spikes

Precedent from previous batches:

  • Batch 4: All 5 chains had $0, all merged
  • Batch 3: 3 chains had $0, all merged
  • Pattern: Zero fees don’t block acceptance
  • DefiLlama prefers early infrastructure tracking

5. What happened: two PRs merged without remake

a. The outcome

Both PRs merged without being closed/remade!

PR #5547:

  • Submitted: January 8, 2026
  • Revisions: Code formatting cleanup by maintainer
  • Merged: January 9, 2026 (next day)
  • Merged by: @treeoflife2
  • Result: 6 chains added

PR #5524:

  • Submitted: January 11, 2026
  • Revisions: Enum fix by me + Q Protocol update by maintainer
  • Merged: January 11, 2026 (same day)
  • Merged by: @noateden
  • Result: 5 chains added

Why this matters:

  • Second consecutive batch without PR remake
  • Split strategy validated (6 + 5 works)
  • Maintainers collaborate on my PRs instead of remaking them
  • Pattern shift: Batch 2-3 (remade) → Batch 4-5 (revised in place)

b. Split strategy success

Why splitting worked:

  1. Easier reviews

    • 6 chains more digestible than 11
    • 5 chains even faster to review
    • Different maintainers could handle each
  2. Risk mitigation

    • If one PR had issues, other still safe
    • Can iterate on smaller batches
    • Less pressure on single submission
  3. Faster throughput

    • Submit when ready (don’t wait for 11)
    • Same-day merges for both
    • More continuous contribution

The result: 11 chains merged across 3 days (Jan 8-11) with minor revisions vs waiting to batch all 11.

c. Revisions vs remakes: the key difference

What happened in Batch 2 & 3 (remakes):

  1. I submit PR
  2. Maintainer reviews
  3. Maintainer closes my PR
  4. Maintainer creates new PR with same code
  5. Maintainer merges their own PR
  6. My PR contribution credit lost

What happened in Batch 5 (revisions):

  1. I submit PR
  2. Maintainer reviews
  3. Maintainer commits directly to my PR branch
  4. Makes minor fixes/formatting
  5. Merges my PR
  6. My PR contribution credit preserved

The trust evolution:

  • Batch 1: Merged directly (4 PRs, no changes needed)
  • Batch 2-3: Closed and remade (maintainer wants full control)
  • Batch 4: Merged directly (1 PR, no changes needed)
  • Batch 5: Revised and merged (2 PRs, minor fixes applied)

This is a new pattern: Maintainers now trust my work enough to:

  • Keep my PR open
  • Make fixes directly on my branch
  • Merge my PR (not remake it)
  • Preserve my contribution attribution

6. What I learned

a. Split vs batch strategy

Evolution of strategy:

Batch 1 (4 chains):

  • Strategy: 4 separate PRs, rapid succession
  • Result: All merged directly
  • Learning: Small PRs work

Batch 2 (8 chains):

  • Strategy: 1 large PR
  • Result: Closed, remade
  • Learning: Too large, maintainer wants control

Batch 3 (11 chains):

  • Strategy: 1 large PR
  • Result: Closed, remade, 1 chain removed
  • Learning: Infrastructure screening matters

Batch 4 (5 chains):

  • Strategy: 1 smaller PR
  • Result: Merged directly
  • Learning: 5 chains is sweet spot

Batch 5 (11 chains):

  • Strategy: Split into 2 PRs (6 + 5)
  • Result: Both merged with minor revisions
  • Learning: Split strategy optimal, minor fixes acceptable

New strategy going forward:

  • Optimal size: 5-6 chains per PR
  • Large batches: Split into multiple PRs
  • Don’t wait: Submit when ready
  • Result: Faster merges, less risk

b. Maintainer trust indicators

Signs of established trust:

  1. Multiple maintainers merge my work

    • @bheluga (Batch 4)
    • @treeoflife2 (Batch 5, PR #5547)
    • @noateden (Batch 5, PR #5524)
  2. Quick merges with direct collaboration

    • PRs merged within 1-2 days
    • Maintainers fix issues directly on my branch
    • No PR closure/remake
  3. Revisions instead of remakes

    • Batch 4: No changes needed
    • Batch 5: Minor fixes applied directly
    • My PRs kept and merged (not replaced)

What built this trust:

  • 22 chains merged in Batch 1-3 (via remakes)
  • 5 chains merged in Batch 4 (direct)
  • 11 chains merged in Batch 5 (direct)
  • Total: 38 chains, consistent quality

7. Current statistics

a. Across all batches

Updated statistics:

MetricTotal
Batches submitted5
Chains researched39
Chains merged38
Chains removed1 (Astar zkEVM)
Overall success rate97.4%
PRs NOT remade7/9 PRs (77.8%)
PRs remade2 (Batch 2 & 3)
PRs merged without changes5 (Batch 1: 4 PRs, Batch 4: 1 PR)
PRs merged with minor revisions2 (Batch 5: 2 PRs)

Total lines of code: ~170 lines for 38 chains

Merge pattern:

  • Batch 1: 4 PRs merged without changes
  • Batch 2: 1 PR closed, remade by maintainer
  • Batch 3: 1 PR closed, remade by maintainer
  • Batch 4: 1 PR merged without changes
  • Batch 5: 2 PRs merged with minor revisions

b. Fee activity summary

Chains with significant fees (>$10):

  • From previous batches: Onus ($125), Prom ($93), Zilliqa ($49), Neon ($15), Exsat ($11)
  • Batch 5: None (all $0 except TAC at $1-2)

Chains with low fees ($1-10):

  • From previous batches: 5 chains
  • Batch 5: TAC ($1-2)

Chains with zero fees:

  • Previous batches: 8 chains
  • Batch 5: 10 chains (Rollux, Endurance, Swan, BitciChain, Perennial, Loop, Stratis, OMAX, Q Protocol, VinuChain)
  • Total: 18 chains with $0 fees (47% of all submissions)
  • All zero-fee chains were accepted and merged

Key insight: Fee activity is not a requirement. Infrastructure tracking matters more than immediate revenue.

8. Resources

a. Pull requests

b. Chain explorers (PR #5547)

c. Chain explorers (PR #5524)

d. Documentation

9. Key insights

a. The trust progression

How trust was built:

Phase 1: Initial Trust (Batch 1)

  • 4 separate PRs
  • All merged directly
  • Established initial pattern

Phase 2: Testing Phase (Batch 2 & 3)

  • Larger batches (8-11 chains)
  • Both remade by maintainer
  • Quality verified but maintainer wants control

Phase 3: Established Trust (Batch 4 & 5)

  • Batch 4: 5 chains merged without changes
  • Batch 5: 6 + 5 chains merged with minor revisions
  • Multiple maintainers trust implementation
  • Quick merges (1-2 days)
  • Key shift: Maintainers now revise my PRs instead of remaking them

The progression:

Submit → Review → Remake → Verify → Trust → Revise & Merge

After 22 chains via remakes, maintainers now collaborate directly on my PRs.

b. Optimal PR strategy

What works best:

  1. Size: 5-6 chains per PR

    • Easy to review
    • Low risk
    • Fast merge
  2. Split large batches

    • Don’t submit 11 chains in one PR
    • Split into 6 + 5 or 5 + 6
    • Submit separately
  3. Submit when ready

    • Don’t wait to batch everything
    • Submit as soon as 5-6 chains researched
    • Faster throughput
  4. Consistent quality

    • Same pattern every time
    • All tests pass
    • Minor errors acceptable (will be fixed)

The result: Faster merges, less risk, more maintainer trust, direct collaboration.

10. Key takeaways

a. Final status

What I did:

  • Researched 11 Blockscout chains
  • Implemented all adapters correctly
  • Split into 2 PRs (6 + 5 chains)
  • All tests passed
  • Submitted PR #5547 and PR #5524

What happened:

  • Both PRs merged within 1-2 days
  • Minor revisions made directly on my branches
  • No PR closure/remake
  • All 11 chains accepted
  • Zero fees were not an issue
  • Different maintainers handled each PR

The significance:

  • Second consecutive batch without PR remake
  • Split strategy validated
  • Maintainers now collaborate on my PRs (not remake them)
  • Trust level: revisions instead of remakes
  • 38 chains total contribution

b. Patterns confirmed

Across 5 batches:

  • Batch 1: 4 PRs merged without changes (small, separate)
  • Batch 2: Closed, remade (too large)
  • Batch 3: Closed, remade (too large, 1 removed)
  • Batch 4: Merged without changes (optimal size)
  • Batch 5: 2 PRs merged with minor revisions (split strategy)

The evolution of trust:

  1. Direct merge (Batch 1, 4): No changes needed
  2. PR remake (Batch 2, 3): Maintainer takes control
  3. Direct revision (Batch 5): Maintainer collaborates on my PR ← NEW

The winning formula:

  1. Size: 5-6 chains per PR (optimal)
  2. Quality: Consistent pattern, tests pass, minor errors OK
  3. Strategy: Split large batches
  4. Trust: Built through consistent delivery
  5. Collaboration: Accept maintainer revisions gracefully

c. What actually matters

Proven through 5 batches:

  1. Consistency over time

    • Same pattern every submission
    • Same code quality
    • Same testing rigor
    • Result: Maintainer trust
  2. Infrastructure tracking > Activity

    • 18 chains with $0 fees, all merged
    • Tracking matters more than revenue
    • Early infrastructure better than late
  3. Quality > Attribution

    • Some via direct merge
    • Some via remake
    • All 38 chains count as contribution
  4. Strategy evolution

    • Started: 4 separate PRs
    • Tried: Large batches (8-11 chains)
    • Learned: Split strategy (5-6 chains)
    • Result: Optimal throughput

d. Final numbers

Total contribution:

  • 38 chains added to DefiLlama
  • 97.4% success rate (38/39)
  • ~170 lines of code
  • 5 batches completed
  • 77.8% direct merge rate (7/9 PRs)
  • 2 remakes (both kept most/all chains)
  • 1 chain removed (infrastructure issues)

The progression:

Individual protocols (complex, slow)
         ↓
Chain fees - Rapid succession (Batch 1, all merged)
         ↓
Chain fees - Large batches (Batch 2 & 3, remade)
         ↓
Chain fees - Optimal size (Batch 4, merged clean)
         ↓
Chain fees - Split strategy (Batch 5, revised & merged)
         ↓
Trusted collaborator pattern established

The key insight about Batch 5:

This batch shows the highest level of trust:

  • Batch 4’s message: “Your code is perfect”
  • Batch 5’s message: “Your code is good enough that we’ll fix it ourselves instead of remaking your PR”

Why this matters:

  • Batch 2-3: Maintainers didn’t trust my PR → closed and remade
  • Batch 5: Maintainers trust my PR → fixed directly and merged

This is what systematic contribution and trust-building in open source looks like.

Next evolution: Continue with split strategy (5-6 chains per PR), submit when ready, maintain quality, expect/accept minor revisions. Collaboration pattern established.

Command Palette
Search for a command to run...