[DBIP] Add validation guardrails for chain values in specific-network listings

[jaasieldelgado131]

Proposal type

Other

Affected scope (files/folders/chains)

listings/specific-networks/*/*.csv, especially rows with a chain column in the current bounty networks: Arbitrum, Ethereum, Filecoin, Algorand, and Somnia.

Motivation / problem statement

Some specific-network listings currently have a chain value that contradicts the folder network, row slug, or public URL evidence. This makes filtering and downstream consumption unreliable, and it lets obvious metadata drift pass review.

A lightweight validation guardrail would help contributors catch these contradictions before opening PRs, and would reduce review time for the Chain.Love team.

Concrete examples from current main:

• listings/specific-networks/ethereum/apis.csv

  • onfinality-sepolia-standard-plan-indexer has chain=mainnet, while the slug is Sepolia-specific.
  • subquery-hoodi-pay-as-you-go-indexer has chain=mainnet, while the slug is Hoodi-specific.

• listings/specific-networks/filecoin/apis.csv

  • chainup-cloud-mainnet-free has chain=calibnet, while the slug and public RPC URL are mainnet-oriented.
  • drpc-calibnet-public-full-archive has chain=mainnet, while the slug is Calibnet-specific.

• listings/specific-networks/arbitrum/apis.csv

  • onfinality-sepolia-free-plan-indexer has chain=one, while the slug and docs are Arbitrum Sepolia-oriented.
  • onfinality-sepolia-standard-plan-indexer has chain=one, while the slug and docs are Arbitrum Sepolia-oriented.

• listings/specific-networks/arbitrum/explorers.csv

  • blockscout-sepolia has chain=nova, while the explorer URL is https://arbitrum-sepolia.blockscout.com/.

Detailed proposal

Add a validation rule for listings/specific-networks/*/*.csv that checks rows with a chain column against available network signals.

Suggested behavior:

• For each row in a specific-network CSV, compare chain with:
  • the specific-network folder name;
  • obvious network tokens in the slug, such as mainnet, sepolia, hoodi, calibnet, nova, and one;
  • public URLs where the network is explicit.
• Report clear warnings or failures when those signals conflict, for example slug=sepolia but chain=mainnet.
• Allow an explicit allowlist or override mechanism for intentional cross-network rows, so valid edge cases are not blocked.
• Document the rule so contributors can fix metadata before submitting PRs.

Acceptance criteria:

• Running the validator reports the mismatches listed above.
• New rows with obvious folder/slug/chain contradictions are rejected or warned.
• Intentional cross-network rows can be allowlisted explicitly.
• The contributor-facing docs explain how to resolve a chain mismatch.

Contact (optional)

GitHub: @jaasieldelgado131

Rewards address (optional)

0xb43d90BB4E22A43D77e9bfbc2f1CA826ec1CaBF1

[ArseniiPetrovich]

@dumikau thoughts?

[elevasyncsolutions-jpg]

DBIP #1943 claim — implementation ready:

• Data PR: fix(listings): align chain values with canonical data (DBIP #1943) #2522 — fixed 17 chain cells (ethereum onfinality/subquery, optimism op-sepolia, sonic tatum, astar subscan, zcash crypto-apis) + README guardrail docs
• Tools PR: feat(validate): rule_chain_slug_consistency (DBIP #1943) #2521 — rule_chain_slug_consistency (mainnet/testnet family check on slug tokens) + tools/chain_allowlist.csv allowlist for intentional cross-network rows (brand-name slug parts like one/nova excluded)

Validator passes on the fixed data branch; full generate/validate pipeline clean.

Reward address: 0x0920555F38a7dfB2b8417262be2b82f7bCbf019c