data(providers): fill 15 missing github organisations, matched by website domain (batch 1 of 1)

[EazyHood]

Summary

Fills 15 empty github cells across 15 providers in references/providers/providers.csv (airtm … zerohash). No rows added or removed, and no cell that already had a value was changed.

Type of change

• Add data rows
• Update data rows
• Remove data rows
• Schema change
• Documentation/metadata only

Scope

• Networks affected: global (provider identities, not listings)

• Categories affected: references/providers

• Additional notes, additional context / screenshots:

How each organisation was found, and the rule that decides whether it is written. For every provider with a website and an empty github, GitHub's user search was queried for organisations by the provider's name. A candidate was accepted only if the organisation profile's own website field resolves to the same registrable domain as the provider's recorded website. A name match alone was never enough; where no candidate carried the provider's domain, the cell was left empty. That is why this fills 15 cells and not the ~250 that are empty.

Accuracy, measured before writing anything. The same procedure was run against 40 providers whose github is already recorded, chosen at random:

decided by domain match   24
   agree with recorded    23
   disagree                1    (chainstack: recorded `chainstacklabs`, found `chainstack` — the same company)
no domain match           16    (left empty)

So on the cells it decides, the rule agrees with the existing data 95.8% of the time, and the one disagreement is a second organisation of the same provider rather than a wrong provider.

Link checking. Every link in every touched row — the existing website, docs, x, discord and telegram values, plus the new organisation via the GitHub API — was requested with TLS verification on and compared against the accept list this repo's link-check uses (200,202,204,400,401,403,405,429). Rows carrying any link that fails today were left out entirely, since the check reads whole rows. Rows with a pre-existing linkedin value were also left out (#3347).

No overlap with other open PRs. Rows touched by #3250, #3323, #3324, #3325 and #3326 were excluded up front, so none of these cells is claimed twice and whichever lands first does not conflict with this one.

Style Guide conformance. github is written as the organisation login only (value after domain), matching the 466 existing values. Row order is untouched, so the file stays A–Z by slug.

Links

• Related issue(s) / DB Improvement Proposal: none — data population, no schema change.

Validation checklist

• I followed the Style Guide and Column Definitions. I'm aware of what is !provider syntax, and that entities in /networks sub-folders inherits records from /providers folder
• I personally opened and verified every new link I'm adding. I can confirm, that all the links I'm adding are valid.
  • To be exact about what "verified" means here: every organisation was confirmed through the GitHub API (profile exists, and its website matches the provider's domain), and every other link in the touched rows was re-requested as described above — not opened one by one in a browser.
• If I added new entries - I personally confirmed that the provider I'm adding (modifying) currently supports the adjusted network(s). I've also verified that value in every cell I'm changing is correct according to my best understanding
• This PR is not a blind AI-generated submission

Optional

• Rewards address (for data patching rewards): 0x06f44f4839fd5df4f4670036d028b29dec939363
• Twitter (X) post link (for +10% of rewards to this PR):

[github-actions]

Summary

Status	Count
🔍 Total	49
🔗 Unique	49
✅ Successful	49
⏳ Timeouts	0
🔀 Redirected	4
👻 Excluded	0
❓ Unknown	0
🚫 Errors	0
⛔ Unsupported	0

Full Github Actions output

[USS-Supervisor]

Verdict: COMMENT
Risk: LOW
Summary: The provider batch is limited to filling previously empty GitHub organization cells in references/providers/providers.csv.
Findings: None from static review. CSV width is stable, the changed github values are stored in the expected domain-relative format, and no unrelated files are touched. I am not approving this cycle because I could not verify a current-cycle link-check success before cleanup.
Confidence: MEDIUM

[EazyHood]

For the next review cycle: the current-cycle link-check on this head is run 33737239201, posted above at the same minute as the review — 49 links checked, 0 errors, 0 timeouts. https://github.com/Chain-Love/chain-love/actions/runs/33737239201