[DBIP] Add sourceUrls column for offer evidence provenance

[EazyHood]

Proposal type

• Add column

Affected scope

• references/offers/*.csv
• Optional follow-up for listings/specific-networks/*/*.csv and listings/all-networks/*.csv only when a listing overrides inherited offer values.

Motivation / problem statement

Chain.Love contributors often update factual fields such as price, planName, planType, availableApis, limitations, securityImprovements, monitoringAndAnalytics, uptimeSla, and actionButtons. The current schema stores the normalized result, but it does not store the source evidence used to verify those values.

That creates recurring review and maintenance cost:

• Maintainers must re-open provider pages during review even when a contributor already verified them.
• Future refreshes cannot distinguish a stale value from a still-current value without repeating the research step.
• Automated and human contributors have no consistent place to attach compact evidence for fields that are hard to validate from the CSV alone.

A lightweight source column would improve reviewability without changing the visible product model or making every row verbose.

Detailed proposal

If proposing column change(s):

• Category/table: all offer reference tables under references/offers/ (apis, analytics, bridges, explorers, faucets, mcpservers, oracles, platforms, ramps, sdks, security, services, storages, wallets)
• Column name: sourceUrls
• Change type: add
• New/updated definition: Optional list of source URLs used to verify the row's non-obvious factual values. This is evidence for maintainers and future refreshes, not a replacement for actionButtons user-facing navigation.
• Value type and allowed values: JSON array of absolute HTTPS URLs, or blank.
• Examples:
  • ["https://docs.example.com/pricing","https://example.com/pricing"]
  • ["https://docs.example.com/api/reference"]
• Notes / normalization guidance:
  • Keep blank when the row is provider-only or the value is obvious from inherited context.
  • Prefer official provider documentation, pricing, status, API reference, or product pages.
  • Limit to the smallest useful set of URLs, normally 1-3 links.
  • Do not duplicate actionButtons automatically; include the same URL only when it actually served as evidence for factual row values.
  • Do not include private dashboards, login-only pages, screenshots, referral links, or unstable search-result URLs.
  • For inherited listings, the source should live on the referenced offer row unless the listing overrides factual values.

Why this fits the existing model

The wiki already separates provider -> offer -> listing and asks contributors to add only data they are 100% sure about. sourceUrls gives that verification step a structured home while preserving the existing normalized CSV model.

This also complements current actionButtons: those are end-user buttons with labels like Website/Docs/Buy, while sourceUrls would be maintainer-facing provenance for data quality.

Contact

GitHub: @EazyHood

Rewards address

0x06f44f4839fd5df4f4670036d028b29dec939363

[EazyHood]

I opened this through gh issue create, so I cannot apply repository labels from my account. Please add the DBIP label if this proposal fits the DBIP process. Rewards address remains:

[EazyHood]

Correction to my previous comment: the rewards address is 0x06f44f4839fd5df4f4670036d028b29dec939363 (USDT/USDC on Ethereum / ERC-20).