data(providers): fill 50 missing link cells for 28 providers (batch 4 of 4)

[EazyHood]

Summary

Fills 50 empty cells across 28 providers in references/providers/providers.csv (stylus-sdk … ziion-linux-distro). No rows added or removed, and no cell that already had a value was changed.

column	cells filled
github	3
docs	5
x	23
discord	10
telegram	9

One of four batches (#3323, #3324, #3325, #3326) covering different providers; no cell appears in more than one of them. Rebased on current main — the earlier version conflicted after #3211, #3218, #2814 and #3309 touched this file, which is also why no workflow ran on it (GitHub does not trigger pull_request workflows on a conflicting PR).

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:

Overlap with #3250, stated up front. #3250 fills 450 provider cells and 37 of the cells in this PR are also in it — with the same value in every case; where the two disagreed, the cell was removed from here. Whichever lands second rebases and those cells become a no-op in it, so nothing is claimed twice. They are kept here because #3250 is large and has been cycling on link-check noise since 27 August, and these batches are small enough to clear a review cycle on their own.

Where the values come from. Two first-party sources, never a guess from the slug: the provider's own website (outbound links and twitter:site meta tag), and the provider's own GitHub organisation profile (twitter_username), plus the provider's own docs./developers. subdomain accepted only when the URL after redirects stays on the provider's registrable domain. A value was written only when unambiguous; where two plausible candidates existed, the cell was left empty. That is why these four PRs fill ~160 cells and not the ~650 that are empty.

Accuracy, measured before writing anything, by running the same extraction against providers whose value is already recorded:

github  64/67   agree   95.5%
x      114/117  agree   97.4%   (from the provider's site)
x      171/175  agree   97.7%   (from the GitHub org profile, after a name-similarity filter)

A third source was measured and rejected: the GitHub profile's blog field agrees with the recorded website only 80.7% of the time, so no website cell is touched.

Link checking. Every link in every touched row — the cells added here and the website/docs values already present in those rows — 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): across the four batches, 523 links, 0 failures. Three rows that could have been filled were left out because they carry a link that was already in the database and fails today (swing: expired certificate and a docs domain that no longer resolves; polyzoa: 404; learnweb3: 503) — since the check reads whole rows, touching them reports those failures against this PR. No linkedin cell is included, for the reason in #3347.

Style Guide conformance. docs as a full quoted URL; x, github, discord, telegram as value-after-domain only; discord as the bare invite code, matching 125 of the 136 existing values. Row order untouched, so the file stays A–Z by slug.

Links

• Related issue(s) / DB Improvement Proposal: none — data population, no schema change. See [DBIP] The link check cannot validate the x and linkedin columns: 60% of its errors are X and LinkedIn refusing CI, not broken links #3347 for why linkedin is excluded.

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 link was checked with an HTTP request as described above, not opened one by one in a browser. Every value in this PR returned an accepted status; everything that did not was removed before submitting.
• 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): https://x.com/del_mejia95726/status/2095272702319743473

[github-actions]

Summary

Status	Count
🔍 Total	164
🔗 Unique	164
✅ Successful	161
⏳ Timeouts	0
🔀 Redirected	7
👻 Excluded	0
❓ Unknown	0
🚫 Errors	3
⛔ Unsupported	0

Errors per input

Errors in ./references/providers/providers.csv

• [ERROR] https://developers.swing.xyz/ (at 68:1) | Connection failed. Check network connectivity and firewall settings
• [ERROR] https://swing.xyz/ (at 67:1) | SSL certificate error. Check certificate validity
• [404] https://www.polyzoa.xyz/ (at 49:1) | Rejected status code: 404 Not Found

Full Github Actions output

[USS-Supervisor]

Verdict: REQUEST_CHANGES
Risk: MEDIUM
Summary: The provider CSV remains structurally valid, but the current-cycle link-check found hard failures in touched provider rows, so the PR is not approval-ready.
Findings: MEDIUM - references/providers/providers.csv, rows swing and polyzoa: the link-check report flags https://swing.xyz with an SSL certificate error, https://developers.swing.xyz/ with a connection/DNS failure, and https://www.polyzoa.xyz/ as 404 Not Found; direct checks confirmed Swing's certificate failure, the Swing developer-docs DNS failure, and Polyzoa's site availability problem. Please update these provider URLs to working official endpoints, or leave the affected fields blank if no working official URL is available.
Confidence: HIGH

Required validation passed. Current-cycle link-check run 33375659246 reported 161 successful links, 3 errors, 0 timeouts, and 0 unsupported URLs.

[EazyHood]

Thanks — this was useful, and it found more than the three links.

On the three flagged links: they were already in the database. None of them is a value this PR added. The rows are:

swing    website "https://swing.xyz"           <- already there
swing    docs    "https://developers.swing.xyz/" <- already there
polyzoa  website "https://www.polyzoa.xyz/"    <- already there

This PR added x and telegram to swing, and docs and linkedin to polyzoa. Because the link-check reads whole rows, filling an empty cell in a row makes that row's pre-existing rot show up against the PR. That is the reviewer's finding being correct and my scoping being wrong, so I have taken both rows out rather than leave them failing.

I did not substitute replacement URLs, because the obvious candidates are wrong:

• swing.io is a different company. It is a Solana perpetuals venue — "Open long and short positions with up to 5x leverage" — not the cross-chain bridge aggregator this row describes. Swing itself still exists: github.com/swing-xyz had a push in March 2026 and x.com/swing_xyz is live. Their site's certificate has expired and developers.swing.xyz no longer resolves in DNS, which is infrastructure rot rather than a dead company, so blanking the website of a live provider did not seem like my call to make.
• polyzoa.com is a parked domain, and Polyzoa looks defunct rather than moved: www.polyzoa.xyz is 404, x.com/Polyzoa_xyz is 404, and their surviving GitBook still links to the dead polyzoa.xyz. This may be a removal candidate under "providers that no longer exist", but that is a separate decision.

A third row, learnweb3, has the same problem (https://learnweb3.io/ → 503) and is also out.

Two further problems I found while checking, and fixed here:

1. Every linkedin cell is removed from all four PRs. The other two link-check failures in this batch were [999] on linkedin.com/company/base-l2 and linkedin.com/company/monad-foundation. 999 is LinkedIn's anti-bot response, and this repo's lychee invocation accepts 200,202,204,400,401,403,405,429 — 999 is not on that list, and 403, which would pass, is not what LinkedIn returns. So a linkedin value can fail the check regardless of whether it is correct. That removed 40 cells I had verified as valid, plus 14 further rows that carry a pre-existing linkedin value and would be exposed the same way. I will open a DBIP about this separately rather than argue it here.

2. Twenty cells appeared in two of my own PRs, seven of them with different values (bithomp.x was xrplexplorer in one and bithomp in the other). That came from running two extraction methods against the same snapshot without reconciling them, and it was mine to catch before submitting. All four PRs are now disjoint — no cell appears in more than one.

What changed across the four PRs

	before	now
cells	262	179
rows	154	127
link-check errors	9	0 expected

Every link in every touched row — the added values and the website/docs values already present — was re-requested against your accept list: 523 links, 0 failures. That re-check also runs with TLS certificate validation enabled; my first pass had it disabled, which is precisely why Swing's expired certificate was invisible to me and not to you.

Ready for another look.

[EazyHood]

One thing worth flagging before the link-check runs on this, because it is likely to report x.com URLs as errors and they will not be broken links.

X throttles GitHub-hosted runners. In the most recent link-check run on #2977 — 2663 links checked — 25 of the 42 errors were on x.com or linkedin.com, including:

[ERROR] <https://x.com/stripe>
[ERROR] <https://x.com/SuiNetwork>
[ERROR] <https://x.com/ton_blockchain>

Those accounts are live; all three return 200 from an ordinary connection. The same handle comes back as ERROR, 404 or 500 between runs depending on throttling, which is why #2977, #2978 and #2979 have been cycling on this since 16 August.

I have already removed every linkedin value from these four PRs for that reason — 40 cells I had verified — and opened #3347 proposing a configuration fix.

For the x values that remain here: each one was taken from the provider's own website or its GitHub organisation profile, and each returned 200 on x.com at submission time. I have not removed them because they are correct and because doing so would leave the column permanently unfillable. If the check flags a specific handle in this PR, say which one and I will drop that cell in the same hour — I would just rather not delete 75 verified values pre-emptively against an intermittent signal.

Everything else in these rows was re-checked against your accept list (200,202,204,400,401,403,405,429): 523 links across the four batches, 0 failures.

[github-actions]

Summary

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

Full Github Actions output

[USS-Supervisor]

Verdict: COMMENT
Risk: LOW
Summary: The provider-link batch is scoped to filling empty provider metadata cells, and the refreshed diff keeps provider CSV formatting intact.
Findings: None from static review. CSV width is stable, provider social/link fields use the expected repository formats, 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 33737231694, posted above at the same minute as the review — 111 links checked, 0 errors, 0 timeouts. https://github.com/Chain-Love/chain-love/actions/runs/33737231694