Chain.Love ecosystem discovery bounty program

Hello everyone!

Chain.Love is running a contributor program aimed at helping developers discover our open Web3 infrastructure database through relevant ecosystem documentation, developer catalogs, and resource directories.

We intend to keep this program as a non-spammy one, but if you end up here because it has been abused - please, fill the complaint and we will tighten our policies => #3729

Summary

Contributors can:

1. Find a relevant official documentation page, developer catalog, or resource directory.
2. Prepare the proposed change in a fork or branch without contacting the destination project.
3. Submit the patch as a new Discussion in the Outreach program submissions category for internal validation.
4. Receive 1 USDC if the proposal is selected and approved for external outreach.
5. Receive an additional 5 USDC if your patch has been externally submitted, merged and published.

Only approved Chain.Love outreachers may open external issues, pull requests, emails, messages, or discussions under this program.

Exceptionally substantial integrations that leads us to making partnerships or significant audience outburst may be assigned a separate additional reward afterwards. Contributors should never assume a higher reward without written confirmation.

Critical rule: no external outreach

Contributors participating in this bounty must not independently:

• Open a pull request in the destination repository.
• Open an issue or discussion.
• Contact or tag maintainers.
• Send emails or direct messages.
• Post promotional comments.
• Ask someone else to submit the change.
• Follow up after silence or rejection.

The contributor’s job ends with preparing and submitting the patch as a new Discussion in the Outreach program submissions category. Any external activity performed without an explicit outreachers assignment is ineligible for rewards and may result in suspension from this program.

Although, we welcome all contributors to outreach to all the supported networks outside of the scope of this bounty program - the more people knows about this database, the more likely we can get more partnership and bring more awesome bounty programs to our contributors. But this work won't be compensated directly.

Eligible targets

Official ecosystem documentation

Documentation owned or maintained by a blockchain network, foundation, protocol, or official ecosystem organization may be eligible when:

• The network is supported by Chain.Love.
• The proposed location is directly relevant to infrastructure or developer resources.
• The change provides genuine value to documentation users.
• All claims are accurate and network-specific.
• The repository is active and accepts community contributions.

Official documentation generally requires a meaningful explanation, example, or integration. Usually, adding an isolated link to an unrelated page is not sufficient.

Developer resource directories

A link-only addition may be eligible when the destination page is genuinely intended to list relevant tools or services, such as:

• Official ecosystem resource directories
• Developer-tool catalogs
• Actively maintained “awesome” lists
• Infrastructure directories
• Integration galleries
• API or MCP registries

Technical integrations

The following may also be eligible:

• Chain.Love API usage examples
• Skills library integrations
• MCP integration instructions
• Documentation widget integrations
• Network-specific infrastructure discovery examples
• Tutorials requested or approved by destination maintainers

Non-github targets

Non-github targets may be eligible, but will be reviewed on an independent case-by-case basis.

Ineligible targets and activities

The following are not eligible:

• Blog comments
• Forum replies
• Promotional GitHub issue comments
• Q&A answers created primarily to place a link
• Wikipedia or Wikidata edits
• Social-media replies or mass mentions
• Reviews, ratings, likes, votes, or testimonials
• Guest-post websites created primarily for SEO
• Paid-link marketplaces
• Low-quality or bulk-submission directories
• Abandoned repositories (more than 4 weeks without updates)
• Unrelated documentation pages
• Contributor-owned catalogs presented as independent publications
• Footer, template, badge, or hidden links
• Link exchanges
• Repeated or overlapping submissions to the same organization without explicit approval
• Targets that previously rejected Chain.Love, unless the 90-day cooldown has expired and a new outreach has been explicitly authorized after review
• Targets that asked not to be contacted
• Changes requiring payment or incentives for destination maintainers
• Newly created repositories whose primary purpose is publishing the submitted link
• Copy-pasted versions of the same submission across multiple projects

This program does not reward independent LinkedIn, X, Reddit, Telegram, Discord, or other social-media posts.

Preparing the patch

Usual contribution flow looks the following way:

1. Fork the destination repository, then create a patch branch.
2. Prepare the proposed documentation change.
3. Run the repository’s relevant formatting, documentation, and build checks.
4. Create a separate Discussion for the proposal in the Outreach program submissions category.
5. Wait for an assigned outreacher.

Do not open a pull request to the destination repository.

The patch should:

• Be based on the current default branch.
• Follow the destination project’s style and contribution guide.
• Contain no unrelated changes.
• Use Chain.Love’s canonical URL.
• Use “Chain.Love” as the ordinary brand name.
• Avoid keyword-rich or promotional anchor text.
• Avoid unsupported words such as “best,” “leading,” or “most trusted.”
• Explain Chain.Love factually and concisely.
• Use information verified against the current Chain.Love product.
• Pass available documentation builds and formatting checks.
• Be specifically adapted to the destination network or catalog.

Using AI tools is allowed. The contributor remains responsible for verifying every claim and ensuring that the patch is appropriate for the target.

Patch submission format

Each proposal must be submitted as a separate Discussion in the Outreach program submissions category.

Do not submit new patch proposals as replies to this program announcement.

Submit the prepared patch using:

Fork:
Branch:
Base commit:
Changed files:
Patch summary:
Reward address:

Internal validation by outreachers

An outreacher will determine whether the patch:

• Is relevant to the destination.
• Provides genuine value to its users.
• Follows the destination’s rules.
• Uses accurate and current Chain.Love information.
• Is appropriately scoped.
• Contains neutral wording.
• Avoids duplicate or manipulative placement.
• Passes available checks.
• Is suitable for transparent external submission.

Outreachers may:

• Approve the patch.
• Request one revision.
• Rewrite minor wording.
• Reject the patch.
• Decide that it should not be submitted externally.
• Request maintainer consent before opening a PR.

Approval earns the contributor the initial 1 USDC reward and means that the proposal has been selected for external outreach.

Approval does not guarantee acceptance or publication by the destination project. An approved outreach may also become blocked if the destination provides no usable submission path.

Outreachers are not required to review or issue a decision on every submitted proposal. They should select the strongest available opportunities for approval.

External submission

Only an approved outreacher or authorized Chain.Love account may submit the change externally.

Outreach registry

All external outreach attempts under this program must be recorded in outreach/registry.csv.

Before starting an external outreach attempt, the assigned outreacher must check the registry and any pending registry updates to ensure that the destination organization is eligible for outreach.

After making an external submission, the same outreacher must:

1. Open a pull request to the Chain.Love repository adding the outreach to the registry with status submitted.
2. Reply to the contributor's original submission Discussion with a link to the external submission.

The external submission may be a pull request, issue, proposal, discussion, form, or another contribution mechanism required by the destination project.

If an approved outreach cannot be externally submitted because the destination currently provides no usable submission path, it must be recorded as blocked according to the registry rules.

When the destination submission is resolved, the outreacher must:

1. Open another pull request updating the registry entry to merged or rejected.
2. Reply to the contributor's original submission Discussion with the final outcome.

The status_date must be updated to the date of the corresponding status change.

If the destination project explicitly asks not to be contacted again, this must be recorded in the comment field using the DO_NOT_CONTACT: marker.

The registry must be kept up to date so that active submissions, previous rejections, blocked destinations, cooldowns, and no-contact requests can be checked before any new outreach.

External submissions will contain a disclosure similar to:

Disclaimer: This contribution was prepared through the incentivized Chain.Love community integration program and reviewed by a Chain.Love program maintainer.

Destination maintainers may:

• Accept the patch.
• Modify it.
• Request changes.
• Mark links as sponsored or nofollow.
• Reject or close the proposal.

These decisions must be respected. Contributors and outreachers must not pressure maintainers or repeatedly request reconsideration.

The reward is not reduced if a destination project applies nofollow, sponsored, redirects, or another reasonable link policy.

Outreachers

Becoming an outreacher

To apply, a contributor must:

• Have at least 3 bounty-eligible PRs merged during the previous 30 days.
• Have contributed over a period of at least 90 days.
• Write a reply in this discussion applying for participation.

The list of approved outreachers will be public. Chain.Love may accept, reject, suspend, or remove outreachers based on their performance.

Current approved outreachers:

• @harunsulaiman
• @EazyHood
• @Adisaok

Outreachers are compensated $40/month - through a fixed monthly arrangement rather than per approval, PR, or merge.

Outreachers compensation does not increase based on:

• Number of patches approved
• Number of external PRs opened
• Number of links published
• Number of successful merges

Outreachers are rewarded for careful participation and quality control, not for producing a particular outcome.

An outreacher may not validate their own submission. Potential conflicts of interest must be disclosed to the Chain.Love core team.

Rate limits

To protect destination projects and maintain submission quality:

• Each outreacher may approve and take forward no more than 5 new proposals per week.
• Each outreacher may submit no more than 5 new external outreach attempts per week.
• Outreachers must complete outstanding required actions on their approved backlog before approving new contributions.
• A submission waiting solely for a destination maintainer does not block new approvals once the outreacher has completed all required actions and recorded its current status.
• Clearly ineligible submissions may be rejected without counting toward the five approval slots.
• Outreachers are not required to review or decide on every submission and should prioritize the strongest available opportunities.
• Only one active proposal may exist per destination organization.
• A rejected organization enters a minimum 90-day cooldown.
• Silence will not trigger repeated follow-ups.
• Chain.Love may permanently block any organization from future outreach.
• Chain.Love may pause an entire target category if submissions produce consistently poor results.

Abuse and penalties

The following will result in zero compensation:

• Contacting a destination before authorization
• Opening an external PR without authorization
• Submitting duplicate work
• Fabricating data in any way
• Reusing a rejected submission against another target without approval
• Creating a website or repository solely to claim the reward

Appeals

A contributor may request one core-team review of a rejected internal patch.

The appeal must identify the outreacher's decision being challenged and provide new factual evidence. Disagreement about style, reward size, or the destination maintainer’s decision is not grounds for an appeal.

Program state

OPEN — new submissions are currently accepted.

Submit each new proposal as a separate Discussion in the Outreach program submissions category.

This announcement contains the program rules and may still be used for general program questions and outreacher applications, but new patch proposals should not be posted as replies here.

Help developers discover useful Web3 infrastructure—but please do it carefully, transparently, and without creating noise for the projects we want to work with.

[Frere527]

Before preparing a patch, could you confirm two payment/availability details for the pilot?

1. Is the initial 1 USDC for an internally approved patch settled through the same monthly Ethereum-mainnet USDC/USDT process used by the database grant, or does this pilot use a different payment method/timing?
2. May contributors submit patches now while the “Initial approved outreachers” list is still empty, and is there someone currently available to perform the internal validation?

I will not contact a destination project or open an external PR. This is only a payment-and-availability check before investing work.

[chain-love-sa]

1. Same processes, you will likely get a payment as a part of one batch even.
2. Yeah, we have @eugene17kotov and myself who are going to be the first outreachers.

[zekfer38-netizen]

Thanks for the approval. The comment appears to end mid-sentence at “to”, and the fork link in parentheses is empty. Could you please clarify the exact fork URL and destination repository for the external PR? I will not change fork access until those details are clear.

[EazyHood]

Patch submission — punkpeye/awesome-remote-mcp-servers (Aggregators)

Fork: https://github.com/EazyHood/awesome-remote-mcp-servers
Branch: add-chainlove-mcp
Base commit: 19abc7677636d3ceab76b1acb25fa337e6f0d739 (upstream main, 2026-09-08)
Changed files: README.md (+3 −0, single hunk)
Patch summary: Adds one entry for the Chain.Love MCP gateway to the Aggregators category, in the list's required three-line format (name + endpoint, Glama connector badge, auth marker + one-sentence description). Placed alphabetically before Fatstack. No other lines touched.
Reward address: 0x06f44f4839fd5df4f4670036d028b29dec939363

Diff: punkpeye/awesome-remote-mcp-servers@main...EazyHood:add-chainlove-mcp

The entry:

- [Chain.Love](https://www.chain.love/mcp-gateway) `https://app.chain.love/mcp`
  [![Chain.Love MCP connector](https://glama.ai/mcp/connectors/love.chain.app/chainlove-mcp/badges/score.svg)](https://glama.ai/mcp/connectors/love.chain.app/chainlove-mcp)
  🔓 - Discover and compare Web3 infrastructure services such as RPCs, indexers, oracles and storage across 50+ networks.

Why this list, and not punkpeye/awesome-mcp-servers. I checked the larger list first. Its CONTRIBUTING.md scopes it to servers "you install and run yourself" and states that a remote-only server "belongs in awesome-remote-mcp-servers instead". Chain.Love MCP is hosted and remote-only, so the larger list would have been the wrong venue. The destination here is active (last push 2026-09-08) and Chain.Love is not currently listed in it.

Checks run against the destination's contribution rules, all of which its CI enforces on PRs:

• Endpoint answers an MCP initialize request: returns serverInfo chain-love-mcp-gateway 0.1.0, protocol 2025-06-18, over Streamable HTTP.
• Usable anonymously — tools/list returned 5 tools (discover_networks, discover_categories, search, bind_credentials_bag, execute) with no credentials sent, which is why the entry carries the 🔓 marker rather than 🔑 or 🔐.
• Glama connector exists at love.chain.app/chainlove-mcp and the score badge resolves.
• Description is 114 characters (their limit is 120), ends in a period, no promotional wording.
• Alphabetical ordering within the category preserved.

One thing the assigned outreacher will need before opening the PR: that repository's CONTRIBUTING.md requires the account opening the PR to have starred the repo — "PRs are not merged unless the account opening them has starred the repo". It's a merge gate, so whichever account submits externally should star it first.

I linked the name to https://www.chain.love/mcp-gateway because the destination asks for the product's homepage or docs rather than a GitHub repo, and that page is specific to the gateway being listed. Happy to switch it to https://www.chain.love/ if you prefer the root URL.

No PR was opened and no maintainer was contacted, per the program's no-outreach rule.

[EazyHood]

@harunsulaiman one detail on punkpeye/awesome-remote-mcp-servers#457, which punkpeye pointed out again on 25 Sep: the added entry still starts with a double bullet, - - [Chain.Love](...), and there is an extra blank line right under the Aggregators heading. Dropping the first - and that blank line fixes both; the three approved lines in this submission are the exact target.

[Adisaok]

Hi, @EazyHood, I'm taking over the unfinished contribution while @harunsulaiman is temporarily unavailable. The outreach completion process has been initiated. Apologies for any inconvenience. Thank you for your contribution.

[EazyHood]

Thanks for taking this over, @Adisaok. One placement detail to double-check: your note on #457 says the entry is between Fatstack and FiatDock, but the contribution rules require alphabetical order. Chain.Love should go before Fatstack.

I cannot inspect your local correction, so this may just be a wording issue in the note. The original approved three-line entry is available in my submission above.

[Adisaok]

@EazyHood. The error has been corrected.

[Adisaok]

punkpeye,punkpeye/awesome-remote-mcp-servers,punkpeye/awesome-remote-mcp-servers#457 → Adisaok,"Originally submitted by harunsulaiman; follow-up ownership reassigned to Adisaok. Minimal correction prepared on Adisaok's fork. Awaiting destination maintainer guidance; do not open a replacement PR unless approved."

[og4kuan]

Patch proposal for internal review: awesome-algorand/awesome-algorand

Fork: Not published; submitting the diff below for internal review.
Branch: Local working copy of upstream main.
Base commit: 26f1819a4b88761fbc3250257016705c690f5a6c (2026-09-03).
Changed files: README.md (+5 lines).
Patch summary: Adds an Infrastructure Directories subsection and its table-of-contents entry. The single resource describes the Algorand-specific Chain.Love directory in neutral terms. A directory subsection avoids presenting Chain.Love as a node provider or an official Algorand resource.
Reward address: 0x5d4e1f68bd34be43102fa288e1826a77d3eb58a2 — USDC or USDT on Ethereum mainnet (ERC20) only. Please confirm the pilot payout timing and supported currency/network before payment.

Evidence:

• Target: https://github.com/awesome-algorand/awesome-algorand
• Contribution guide: https://github.com/awesome-algorand/awesome-algorand/blob/main/CONTRIBUTING.md
• Current Algorand product: https://algorand.chain.love/
• Official product documentation: https://chain-love.gitbook.io/chain-love-docs/blockchains/algorand
• Database source: https://github.com/Chain-Love/chain-love

Checks: The repository's alphabetical-list check passed with Python UTF-8 mode; git diff --check passed. The added description ends with a period and follows the existing resource format. No existing Chain.Love entry was found in the checked-out README. The two existing comments in this discussion do not propose this organization. A complete historical duplicate/rejection check remains for internal review; GitHub's PR search was unavailable through my research tool.

Validation limitation: awesome-lint could not start because the local package runner returned EPERM during path resolution. Markdown/spelling/link CI has not been fully run; please do not treat this as a fully CI-validated patch. AI assisted preparation; the directory claims were checked against the sources above. No external PR, issue, or maintainer contact has been made.

diff --git a/README.md b/README.md
--- a/README.md
+++ b/README.md
@@ -49,6 +49,7 @@
   - [Portfolio Trackers](#portfolio-trackers)
   - [Name Services](#name-services)
 - [Infrastructure & Ecosystem Services](#infrastructure--ecosystem-services)
+  - [Infrastructure Directories](#infrastructure-directories)
   - [Nodes & Consensus Participation](#nodes--consensus-participation)
   - [Blockchain Bridges](#blockchain-bridges)
   - [Oracles](#oracles)
@@ -387,6 +388,10 @@
 
 ## Infrastructure & Ecosystem Services
 
+### Infrastructure Directories
+
+- [Chain.Love](https://algorand.chain.love/) - Open-source directory for discovering and comparing Algorand APIs, wallets, explorers, and other infrastructure providers.
+
 ### Nodes & Consensus Participation
 
 - [Algorand - The Undocumented Docs](https://github.com/AlgoChads/algorand-undoc-docs) - Dev Notes for Archival Node, Indexer Setup (and more).

[Adisaok]

Hi, @og4kuan, thanks for the detailed submission and validation evidence.

Internal review

Revision required — validation completion only.

I reviewed the target repository, its current contribution guidelines, the proposed placement, and the Chain.Love the Algorand directory, the patch scope, and the public duplicate/history signals.

The proposal itself is well qualified:

awesome-algorand is an appropriate and active Algorand ecosystem destination.
The proposed Infrastructure Directories subsection is permitted by the repository's contribution guidelines, which explicitly welcome new categories and categorization improvements.
Chain.Love is not currently listed in the README, and I found no public matching Chain.Love PR or issue in the destination repository.
The Algorand-specific Chain.Love directory is directly relevant to the repository.
The proposed description is neutral, appropriately scoped, and consistent with Chain.Love's current Algorand product positioning.
The patch is minimal and contains no unrelated changes.
The supplied base commit is current with the public main history.
No external PR, issue, or maintainer contact has been made.

The remaining issue is validation completeness.

The destination's CONTRIBUTING.md specifies validation covering awesome-lint, Markdown formatting, spelling, list ordering, and link checks. The submission currently reports that the list-order and git diff --check validations passed, but awesome-lint could not start, and the Markdown/spelling/link checks have not been fully completed.

Please complete the destination's documented validation suite, or provide equivalent successful CI results, and update the submission with the results.

This is a validation-completion issue rather than a problem with the proposed Chain.Love placement itself.

Once the required checks are completed successfully, I would be comfortable approving the proposal for the internal stage and considering it for authorised external outreach.

[eugene17kotov]

@Adisaok thanks for the review.

For this kind of case, if the target and placement are valid and the remaining issues are minor, please don’t wait for the contributor to make another revision. As the assigned outreacher, you can make the necessary small fixes yourself and proceed with the external PR in accordance with the destination repository’s contribution requirements.

For this patch specifically, please:

• remove the trailing slash from https://algorand.chain.love/;
• consider simplifying the description to avoid the potentially ambiguous “open-source directory” wording;
• make sure the final patch satisfies the destination repo’s documented validation and formatting requirements.

Once the external PR is opened, please also follow the updated outreach process:

• add the outreach to outreach/registry.csv with status submitted;
• reply to the contributor’s original submission here with the external PR link;
• once the external PR is resolved, update the registry status to merged or rejected and post the final outcome in the original thread.

The idea is that minor wording, formatting, or validation fixes should not unnecessarily block an otherwise valid outreach opportunity.

[Adisaok]

@eugene17kotov, Ok.

[Adisaok]

awesome-algorand,awesome-algorand/awesome-algorand,awesome-algorand/awesome-algorand#201 → Adisaok,"Originally submitted by harunsulaiman; follow-up ownership reassigned to Adisaok. PR remains open. Keep #201 as the sole active Algorand proposal; duplicate #202 should be closed."

[Equinox7379]

Patch for internal review: ahmet/awesome-web3

Fork: Not published; submitting the complete diff below for internal validation.
Branch: Local working copy of upstream main.
Base commit: 332c4c6fad10e323e166e5d26bf64dc9f219f5ea (September 7, 2026).
Changed files: README.md (+1 line).
Patch summary: Add Chain.Love to the existing Datasets section, before Codex in alphabetical order. The entry describes the open-source infrastructure-provider dataset rather than presenting Chain.Love as an RPC provider. This gives developers looking for Web3 datasets a source for cross-network service discovery.
Reward address: 0x1f28ad64aa4ad781c23ec72a22aac7e443ed7b41 — supplied by the account owner for USDC on Ethereum mainnet (ERC20). Please confirm the pilot payout network/currency before sending; do not use a different network without confirmation.

Target: https://github.com/ahmet/awesome-web3
Product: https://www.chain.love/
Dataset source: https://github.com/Chain-Love/chain-love

Checks: The destination's CONTRIBUTING.md was checked; this adds one link, preserves the existing section's alphabetical order, and uses the existing entry format. The new URL returned HTTP 200. git diff --check passed. Searches for both "chain.love" and "chain-love" in the destination's issues/PRs returned no results, and the upstream README did not already contain the resource. The existing comments in this pilot thread do not propose this organization. The destination's repository-wide link-check workflow and website build were not run locally; validation was limited to the added link and Markdown diff.

AI assisted preparation; the description was checked against the product homepage and database README. No external PR, issue, or maintainer contact has been made.

diff --git a/README.md b/README.md
index e7e2014..c29c074 100644
--- a/README.md
+++ b/README.md
@@ -314,6 +314,7 @@
 
 ### Datasets
 
+- [Chain.Love](https://www.chain.love/) - Open-source dataset of Web3 infrastructure providers, including RPCs, indexers, wallets and explorers, for cross-network service discovery.
 - [Codex](https://www.codex.io) - Blockchain data API for accessing on-chain data across multiple networks.
 - [Indexed.xyz](https://indexed.xyz) - Raw and decoded logs, transactions, and blocks for many EVM chains.
 - [OpenChainBench](https://openchainbench.com) - Open, reproducible benchmarks for crypto infrastructure (aggregators, bridges, blockchains, perps) with live data, public methodology, and a JSON API. Data is CC-BY-4.0.

[Adisaok]

Hi, @Equinox7379 thanks for the detailed submission and validation evidence.

Internal review

Approved.

I reviewed the target repository, its Datasets section, and the proposed Chain.Love placement, the description, patch scope, duplicate/history signals, and the validation evidence provided.

The proposal satisfies the internal review requirements:

• ahmet/awesome-web3 is an active and relevant Web3 ecosystem destination.
• The existing Datasets section is an appropriate placement for Chain.Love because Chain.Love provides an open-source dataset/database of Web3 infrastructure providers rather than being presented as an individual infrastructure provider itself.
• The proposed description is neutral, factual, and consistent with Chain.Love's current positioning.
• The entry is correctly placed alphabetically before Codex.
• The patch is appropriately scoped to a single README addition with no unrelated changes.
• The Chain.Love URL was validated successfully.
• No existing Chain.Love entry was identified in the destination README.
• No public evidence of a competing Chain.Love proposal, previous placement, or rejection was identified in the destination repository.
• No external PR, issue, or maintainer contact has been made.

The supplied base commit is appropriate for the September 7 submission date, so subsequent upstream changes after the submission do not constitute a defect in the contributor's patch.

The reported local validation, including the added-link check and git diff --check, is also satisfactory for internal review. The destination's repository-wide CI and website build can provide additional validation at the external-submission stage.

Final internal status: APPROVED.

If this proposal is selected for external outreach, I, the authorised outreacher, will perform a final freshness and destination-rule check against the current upstream state before submitting the external PR.

No external outreach should be undertaken independently before authorisation under the Chain.Love ecosystem discovery programme.
Thank you.

[eugene17kotov]

@Adisaok thanks for the review. I agree that this looks suitable for external outreach.

One important point for future reviews: please don't treat passing validation as sufficient by itself for approval. We don't need to approve every technically valid submission. The goal is to select the strongest outreach opportunities from the proposals we receive.

When several submissions are valid, please be selective and prioritize destinations with stronger signals of real ecosystem value, such as:

• active and ongoing repository maintenance;
• meaningful community usage and visibility;
• a healthy number of stars and forks where applicable;
• clear relevance to Chain.Love and its users;
• a natural placement rather than a merely technically acceptable one;
• a realistic chance that the contribution will be useful and welcomed by the destination maintainers.

This is also important because each outreacher is limited to reviewing no more than 5 patches per week and submitting no more than 5 new external PRs per week. So the intention is not to approve the first five patches that happen to pass validation, but to use your own judgment and select the best opportunities among the available submissions.

For approved patches like this one, please don't wait for an additional selection or authorisation step. As the assigned authorised outreacher, perform the final freshness and destination-rule check, make any minor wording or formatting adjustments you consider necessary, and proceed with the external PR.

For this specific patch, I would also consider changing “open-source dataset of Web3 infrastructure providers” to the slightly more precise “open-source database of Web3 infrastructure services,” but this is a minor wording improvement rather than a blocker.

Once the external PR is opened, please also follow the updated outreach process:

• add it to outreach/registry.csv with status submitted;
• reply to the contributor's original submission here with the external PR link;
• once resolved, update the registry to merged or rejected and post the final outcome in the original thread.

[Adisaok]

Hi, @Equinox7379, the prepared patch has now completed the transition from internally validated to externally submitted.

[Adisaok]

ahmet,ahmet/awesome-web3,https://github.com/ahmet/awesome-web3/pull/809,submitted,2026-09-21,Adisaok,"External PR #809 submitted and awaiting maintainer review."

[Adisaok]

@Equinox7379 Merged confirmed

[harunsulaiman]

Dear maintainer @ArseniiPetrovich

Having been contributing for the chain.love database for over 90 days and met all the requirements for this program, i am hereby applying to join the program.

however, I am appealing beforehand regarding the reward. I urge you to up the reward to 50$ monthly rather than 30$. 30 is so tight honestly.

Faithfully
Harun Sulaiman.

[chain-love-sa]

The pilot is set to be at $30, then we will see depending on the result.
You are welcome to join the program.

[harunsulaiman]

Okay noted. And thank you for welcoming me, my pleasure to be a part.

Gracias

[edigeh]

Prepared patch for internal review: ethereum/ethereum-org-website

Fork: https://github.com/edigeh/ethereum-org-website
Branch: docs/ethereum-api-directory
Base commit: 619807aa1aeec7be359f92dbcb60411f06685291 (current upstream dev when published)
Changed files: public/content/developers/docs/nodes-and-clients/nodes-as-a-service/index.md (+2 lines)
Patch: edigeh/ethereum-org-website@619807a...fd9b563

Patch summary: Adds a short paragraph beside the existing Ethereum node-provider comparison guidance. It identifies Chain.Love as an open-source directory of Ethereum API services and explains how plan/limit information can help shortlist providers, while directing readers to verify current details with each provider. It does not list Chain.Love as a hosted-node provider or claim endorsement by Ethereum.

Reward address: To be provided privately through an official channel if approved. Please advise how to supply it securely. USDT on Ethereum mainnet is preferred, consistent with the payment-process clarification earlier in this discussion; please confirm before payment.

Verification:

• Read the destination's AGENTS.md, CONTRIBUTING.md, public contributing guide, and Markdown lint configuration/custom rules.
• Destination is active: its default branch was updated on September 9, 2026. Searches for chain.love and chain-love across its issues/PRs returned no results; code search for chain.love also returned none. The current pilot comments do not include another Ethereum-organization proposal.
• Confirmed the directory description against https://www.chain.love/ and Ethereum entries at https://github.com/Chain-Love/chain-love/blob/main/listings/specific-networks/ethereum/apis.csv . Used the canonical homepage URL and neutral wording.
• markdownlint-cli2@0.22.0 with the destination's unchanged config and all four custom rules checked both the original and edited document: 2 files, 0 errors.
• The patch applies cleanly to its pinned source with whitespace checking. Only the English document changes. No headings, anchors, components, dependencies, or translations change. The full Next.js application build was not run for this prose-only patch.

This submission is for the pilot's internal validation. No external PR, issue, or maintainer contact has been made. Please assess destination fit and any historical organization restriction before assigning outreach.

[Adisaok]

Hi, @edigeh, thanks for the detailed submission and verification evidence.

Internal review

Approved.

I reviewed your submission against #3731 requirements and the proposed destination, the relevant Ethereum.org contribution requirements, the target documentation page, the proposed placement and wording, the duplicate/history checks, and the validation evidence provided.

The proposal satisfies the internal review requirements:

ethereum/ethereum-org-website is an active, high-authority Ethereum developer documentation destination, and the proposed Nodes as a Service page is directly relevant to Ethereum API/node infrastructure discovery.

The proposed placement is contextually appropriate because the page already discusses third-party node/API services and provider selection.

Chain.Love is correctly presented as an open-source directory for discovering and comparing Ethereum API services, rather than as a node/RPC provider or as an Ethereum-endorsed resource.

The proposed wording is neutral and factual and appropriately directs readers to verify current provider information with the individual providers.

No existing Chain.Love entry or public evidence of a competing Chain.Love proposal was identified.

No public evidence of a previous Chain.Love rejection or destination-level restriction was identified.

The patch is tightly scoped to the relevant English documentation page and introduces no unrelated changes, dependencies, components, headings, anchors, or translations.

The destination's Markdown lint configuration and applicable custom rules were successfully checked, with 0 errors reported.

The patch applies cleanly and passes whitespace validation.

No external PR, issue, or maintainer contact has been made, which is compliant with the #3731 internal-validation process.

The absence of a full Next.js application build is not considered a blocker for this two-line prose-only documentation change, particularly given the successful targeted Markdown validation.

Final internal status: APPROVED.

If this proposal is selected for external outreach, I, the authorised Outreacher, will perform a final freshness and destination-rule check against the current dev branch before submitting the external PR. Any final external wording should continue to preserve the distinction between Chain.Love as an infrastructure discovery directory and the individual providers it lists.

No external outreach should be undertaken independently before authorisation under the Chain.Love ecosystem discovery programme.

Thank you.

[edigeh]

Thank you for the internal approval. Please confirm that the initial 1 USDC reward is recorded for @edigeh and the private channel for providing the receiving address for the normal monthly payout. Please also confirm the payout network and that no claim or payout fee applies. I will leave any external submission to the assigned outreacher.

[Adisaok]

Ethereum.org: 🟢 External issue submitted → awaiting triage

[eugene17kotov]

@Adisaok thanks - I see the external issue has already been submitted, so no additional outreach is needed while it is awaiting triage.
ethereum/ethereum-org-website#19270

Since this is now an active external proposal, please also add it to outreach/registry.csv with status submitted. For this case, the external issue URL can be used as the external submission URL. If the maintainers approve the proposal and ask for a PR, please update the same registry entry accordingly when the outreach progresses and eventually mark the final outcome as merged or rejected.

One suggestion for the eventual PR, if the ethereum.org maintainers are open to the addition: please reconsider the exact placement rather than applying the original patch unchanged.

A more natural option may be the existing Further reading section, which already contains a directory-style resource (List of Ethereum node services). That would preserve the page structure and present Chain.Love as a discovery/comparison resource rather than giving it a separate placement above the provider list.

Of course, if the ethereum.org maintainers suggest a different location during issue triage, please follow their preferred placement.

[Adisaok]

@eugene17kotov @ArseniiPetrovich "This issue is stale because it has been open 30 days with no activity." What do you suggest?

[remystr]

[ArseniiPetrovich]

Yes

[EazyHood]

Patch submission — solana-foundation/solana-com (Solana developer docs)

Fork: https://github.com/EazyHood/solana-com
Branch: docs/clusters-rpc-provider-directory
Base commit: c976f45500bd1604e2aa0919b9cadb66f70bab75 (upstream main, 2026-09-09)
Changed files: apps/docs/content/docs/en/references/clusters.mdx (+10 −0, single hunk, English source only)
Patch summary: Adds a short "Finding a dedicated RPC provider" section to the Clusters and Public RPC Endpoints page, after the note that public endpoints are not for production. It says applications either run their own node or use a dedicated provider, and points to the Chain.Love directory for Solana RPC/API providers, indexers, oracles, explorers and bridges.
Reward address: 0x06f44f4839fd5df4f4670036d028b29dec939363

Diff: solana-foundation/solana-com@main...EazyHood:docs/clusters-rpc-provider-directory

Why this page. That page tells the reader twice to stop using the public endpoints — "Please use dedicated/private RPC servers when you launch your application" and, under error 403, "It is time to run your own RPC server(s) or find a private service" — and never says where to find one. The section fills that gap rather than adding a link to an unrelated page. It names running your own node first, so it reads as an answer to the question the page raises, not as a pointer to a single vendor.

Why Solana, checked against the dataset rather than assumed. I counted the rows in listings/specific-networks/solana/: 396 entries across 10 categories, 213 of them APIs/RPC providers, plus analytics (27), ramps (39), bridges (33), MCP servers (31), SDKs (17), explorers (12), platforms (11), oracles (9) and faucets (4). I checked NEAR and Celo too and dropped them — NEAR has four files and a 751-byte apis.csv, which would not have supported a claim of coverage.

Destination checks:

• Active, and active in the way that matters: 358 pull requests merged in the last 90 days, all from outside the owner, the most recent today. (I also screened awesomedata/awesome-public-datasets — 78,880 stars and daily commits, but zero merged PRs in 90 days, because its commits are automated. Stars and pushes are not the same as a maintainer who merges.)
• Chain.Love is not currently mentioned anywhere in the repository.
• Formatting matches their toolchain: their .prettierrc is printWidth: 80, proseWrap: "always", endOfLine: "lf". I ran Prettier over the file with those settings and diffed against upstream — only the new section appears, nothing else was reformatted, so the change will not fight their CI.
• English source only. The repo keeps 18 other locales under content/docs/<lang>/; I did not touch them, since translations are handled by their own pipeline.

On wording: no superlatives, the anchor text is just the product name, and the link is the canonical https://www.chain.love/. There is no per-network deep link on the site — I checked /solana, /networks/solana and app.chain.love/solana, all 404 — so the root is the correct URL here.

No PR was opened and no maintainer was contacted, per the program's no-outreach rule.

[EazyHood]

@harunsulaiman done: you have a pending invitation with Write access to EazyHood/solana-com, so it should be in your GitHub notifications.

I also brought the branch up to date before handing it over. docs/clusters-rpc-provider-directory is now one commit on top of today's upstream main, with nothing behind:

Base commit:   a578adba  (upstream main, 2026-09-24)
Branch:        docs/clusters-rpc-provider-directory -> 51cf8272
Status:        ahead 1, behind 0
Changed files: apps/docs/content/docs/en/references/clusters.mdx (+11 -0, same hunk as approved)

The link in the section, https://mainnet.solana.chain.love/toolbox/apis, still loads the Solana APIs directory. I won't push to that branch while you have it.

[harunsulaiman]

Add me as a collaborator i am still not yet a collaborator that is why I cannot push the pr @EazyHood

[EazyHood]

@harunsulaiman the invitation is there, but it is still pending on your side: GitHub only makes you a collaborator once you accept it. You can accept it here:

https://github.com/EazyHood/solana-com/invitations

It grants Write access. I sent it on 24 Sep at 20:03 UTC, and GitHub lets an invitation expire after 7 days, so it is valid until 1 Oct. Once you accept, you can push to docs/clusters-rpc-provider-directory, which is still at 51cf8272, the same commit as in my previous comment.

[harunsulaiman]

Thanks @EazyHood pr is submitted @ solana-foundation/solana-com#2191

Will update the registry soon

[Adisaok]

solana-foundation,solana-foundation/solana-com,solana-foundation/solana-com#2191 → Adisaok,"External PR #2191 remains open and awaits code-owner review. Follow-up responsibility reassigned from harunsulaiman to Adisaok; preserve original submission history."

[patchharbor-dev]

Prepared patch for internal review: mcp-use/mcp-use — TypeScript infrastructure discovery example

Fork: Not published; the complete diff is included below for internal review.
Branch: Local docs/typescript/chainlove-discovery.
Base commit: f56d61db3b96f9c12ddc2a8409b6c4685d9e1da2 (upstream main, checked again September 10).
Changed files:

• libraries/typescript/packages/client/examples/node/chainlove-discovery.ts
• libraries/typescript/packages/client/examples/README.md
• libraries/typescript/packages/client/tests/unit/chainlove-discovery.test.ts
• libraries/typescript/.changeset/tidy-rivers-discover.md

Patch summary: Adds a runnable example to the existing @mcp-use/client examples collection. It discovers supported network and category identifiers, then requests at most three service records through Chain.Love's public MCP gateway. It accepts optional network/category arguments, validates structured responses (with a JSON-text fallback), handles tool and transport failures, and closes the client. It reads registry metadata only; it does not bind credentials or execute provider services. No library behavior or dependencies change.

Reward address: Pending a private handoff. If approved, please identify an official private channel for supplying payment information; no address is included publicly.

Why this destination: The existing basic HTTP example uses echo/add demo tools. This adds a real remote workflow in which subsequent requests use the network/category identifiers returned by discovery. The contribution guide welcomes examples, and the repository was updated September 9. The example uses existing client APIs and includes the required changeset. Organization-wide issue/PR searches for chain-love, chain.love and chainlove returned no results, and this discussion had no other mcp-use proposal when rechecked before submission. Please assess destination fit and any historical organization restriction during internal review.

Validation:

• Client package build passed.
• Strict TypeScript checking, ESLint and Prettier passed for the added code and tests.
• All 358 client tests passed, including 11 new tests covering successful discovery, JSON-text fallback, unknown selections, malformed/tool-error responses, connection/transport failures and empty results. Tests use fixtures; no paid APIs are involved.
• Both documented live commands passed with client telemetry disabled: Filecoin APIs returned three of 252 records; Filecoin storage returned three of 42. Counts are observations, not hard-coded expectations.
• git diff --check passed. Full builds for unrelated monorepo packages were not run.

No destination PR, issue, or maintainer contact has been made. This submission is solely for the pilot's internal validation and assigned outreach process.

Complete patch (four files)

diff --git a/libraries/typescript/.changeset/tidy-rivers-discover.md b/libraries/typescript/.changeset/tidy-rivers-discover.md
new file mode 100644
index 0000000..4069030
--- /dev/null
+++ b/libraries/typescript/.changeset/tidy-rivers-discover.md
@@ -0,0 +1,5 @@
+---
+"@mcp-use/client": patch
+---
+
+Add a runnable Chain.Love infrastructure-discovery example with bounded metadata queries, response validation, and offline tests.
diff --git a/libraries/typescript/packages/client/examples/README.md b/libraries/typescript/packages/client/examples/README.md
index 3cc17c5..700e803 100644
--- a/libraries/typescript/packages/client/examples/README.md
+++ b/libraries/typescript/packages/client/examples/README.md
@@ -28,6 +28,9 @@ Run the complete matrix:
 ## Feature examples
 
 - `node/basic-http.ts` — tools + automatic v1/v2 negotiation.
+- `node/chainlove-discovery.ts` — a remote, anonymous discovery workflow that
+  validates network/category names, queries service metadata, and handles tool
+  errors. See [Chain.Love infrastructure discovery](#chainlove-infrastructure-discovery).
 - `node/ai-sdk-openai/` — a runnable AI SDK `generateText` tool loop against a
   remote MCP server. It is an isolated example package, so AI SDK dependencies
   are not dependencies of `@mcp-use/client`.
@@ -50,5 +53,30 @@ Run the complete matrix:
 - `cli/` — name-scoped CLI scripts.
 - `conformance/` — official MCP conformance harness clients.
 
-Individual examples use ports 3103/3104 by default and accept
+Local demo-server examples use ports 3103/3104 by default and accept
 `MCP_SERVER_URL` / `MCP_SERVER_V2_URL` overrides.
+
+## Chain.Love infrastructure discovery
+
+[Chain.Love](https://www.chain.love/) provides a public infrastructure registry.
+This example connects to its [MCP gateway](https://www.chain.love/mcp-gateway),
+discovers supported networks and categories, then displays up to three service
+records. It defaults to Filecoin APIs; network and category slugs can be supplied
+as positional arguments. Unknown slugs produce an error listing available values.
+
+After installing workspace dependencies, run from `libraries/typescript`:
+
+```bash
+pnpm --filter @mcp-use/client build
+cd packages/client
+node --experimental-strip-types examples/node/chainlove-discovery.ts
+node --experimental-strip-types examples/node/chainlove-discovery.ts filecoin storages
+```
+
+Use Node.js 22.22.2 or newer. Discovery requires internet access but no LLM,
+account, API key, or wallet. The example disables automatic OAuth and only reads
+registry metadata; it does not bind credentials or execute provider services.
+Results can change as the registry updates, and inclusion does not imply a
+recommendation. Check current capabilities and terms with the provider before
+using a service. This live example is separate from the local demo-server matrix;
+its unit tests use fixtures and do not access the network.
diff --git a/libraries/typescript/packages/client/examples/node/chainlove-discovery.ts b/libraries/typescript/packages/client/examples/node/chainlove-discovery.ts
new file mode 100644
index 0000000..47d9340
--- /dev/null
+++ b/libraries/typescript/packages/client/examples/node/chainlove-discovery.ts
@@ -0,0 +1,112 @@
+/**
+ * Discover infrastructure services through Chain.Love's public MCP gateway.
+ * See https://www.chain.love/mcp-gateway for the service documentation.
+ *
+ * From packages/client, after building @mcp-use/client:
+ *   node --experimental-strip-types examples/node/chainlove-discovery.ts
+ *   node --experimental-strip-types examples/node/chainlove-discovery.ts filecoin storages
+ */
+import { MCPClient, type MCPConnection } from "@mcp-use/client";
+import { pathToFileURL } from "node:url";
+import { z } from "zod";
+
+const networksSchema = z.object({
+  networks: z.array(z.object({ chain: z.string() })),
+});
+const categoriesSchema = z.object({
+  exists: z.boolean(),
+  categories: z.array(z.object({ name: z.string() })),
+});
+const searchSchema = z.object({
+  results: z.array(
+    z.object({
+      service_id: z.string(),
+      provider: z.string(),
+      title: z.string(),
+    })
+  ),
+  total: z.number().int().nonnegative(),
+});
+
+interface DiscoveryClient {
+  connect(name: string): Promise<Pick<MCPConnection, "callTool">>;
+  close(): Promise<void>;
+}
+
+function readResult(
+  name: string,
+  result: Awaited<ReturnType<MCPConnection["callTool"]>>
+): unknown {
+  // MCP tool failures may arrive in a successful transport response.
+  if (result.isError) throw new Error(`${name} returned a tool error`);
+  if (result.structuredContent !== undefined) return result.structuredContent;
+
+  const text = result.content.find((item) => item.type === "text");
+  if (!text) throw new Error(`${name} returned no JSON content`);
+  return JSON.parse(text.text) as unknown;
+}
+
+export async function discoverInfrastructure(
+  client: DiscoveryClient,
+  chain = "filecoin",
+  category = "apis"
+): Promise<z.infer<typeof searchSchema>> {
+  try {
+    const connection = await client.connect("chainlove");
+    const call = async (
+      name: string,
+      args: Record<string, unknown> = {}
+    ): Promise<unknown> =>
+      readResult(
+        name,
+        await connection.callTool(name, args, { timeout: 30_000 })
+      );
+
+    const { networks } = networksSchema.parse(await call("discover_networks"));
+    if (!networks.some((network) => network.chain === chain)) {
+      throw new Error(
+        `Unknown network "${chain}". Available: ${networks.map((n) => n.chain).join(", ")}`
+      );
+    }
+
+    const { exists, categories } = categoriesSchema.parse(
+      await call("discover_categories", { chain })
+    );
+    if (!exists || !categories.some((item) => item.name === category)) {
+      throw new Error(
+        `Unknown category "${category}" for ${chain}. Available: ${categories.map((c) => c.name).join(", ")}`
+      );
+    }
+
+    // This reads registry metadata only; it does not execute provider services.
+    return searchSchema.parse(
+      await call("search", { chain, category, limit: 3 })
+    );
+  } finally {
+    await client.close();
+  }
+}
+
+if (
+  process.argv[1] &&
+  import.meta.url === pathToFileURL(process.argv[1]).href
+) {
+  const client = new MCPClient({
+    mcpServers: {
+      chainlove: {
+        url: "https://app.chain.love/mcp",
+        oauth: false,
+        timeout: 30_000,
+      },
+    },
+  });
+  discoverInfrastructure(client, process.argv[2], process.argv[3])
+    .then(({ results, total }) => {
+      console.log(`Showing ${results.length} of ${total} matching services.`);
+      console.table(results);
+    })
+    .catch((error: unknown) => {
+      console.error(error instanceof Error ? error.message : String(error));
+      process.exitCode = 1;
+    });
+}
diff --git a/libraries/typescript/packages/client/tests/unit/chainlove-discovery.test.ts b/libraries/typescript/packages/client/tests/unit/chainlove-discovery.test.ts
new file mode 100644
index 0000000..a9b71d3
--- /dev/null
+++ b/libraries/typescript/packages/client/tests/unit/chainlove-discovery.test.ts
@@ -0,0 +1,108 @@
+import { describe, expect, it, vi } from "vitest";
+import { discoverInfrastructure } from "../../examples/node/chainlove-discovery.js";
+
+const networks = { networks: [{ chain: "filecoin" }] };
+const categories = { exists: true, categories: [{ name: "apis" }] };
+const search = {
+  results: [
+    { service_id: "example", provider: "Example", title: "Example API" },
+  ],
+  total: 1,
+};
+
+function fixture(data: unknown[] = [networks, categories, search]) {
+  const callTool = vi.fn();
+  for (const item of data) {
+    callTool.mockResolvedValueOnce({ content: [], structuredContent: item });
+  }
+  const client = {
+    connect: vi.fn().mockResolvedValue({ callTool }),
+    close: vi.fn().mockResolvedValue(undefined),
+  };
+  return { client, callTool };
+}
+
+describe("Chain.Love discovery example", () => {
+  it("discovers a network and category before a bounded metadata search", async () => {
+    const { client, callTool } = fixture();
+    await expect(discoverInfrastructure(client)).resolves.toEqual(search);
+    expect(callTool.mock.calls).toEqual([
+      ["discover_networks", {}, { timeout: 30_000 }],
+      ["discover_categories", { chain: "filecoin" }, { timeout: 30_000 }],
+      [
+        "search",
+        { chain: "filecoin", category: "apis", limit: 3 },
+        { timeout: 30_000 },
+      ],
+    ]);
+    expect(client.close).toHaveBeenCalledOnce();
+  });
+
+  it("supports servers returning JSON text instead of structured content", async () => {
+    const { client, callTool } = fixture([]);
+    for (const item of [networks, categories, search]) {
+      callTool.mockResolvedValueOnce({
+        content: [{ type: "text", text: JSON.stringify(item) }],
+      });
+    }
+    await expect(discoverInfrastructure(client)).resolves.toEqual(search);
+  });
+
+  it("stops before searching when the requested category is absent", async () => {
+    const { client, callTool } = fixture();
+    await expect(
+      discoverInfrastructure(client, "filecoin", "missing")
+    ).rejects.toThrow(
+      'Unknown category "missing" for filecoin. Available: apis'
+    );
+    expect(callTool).toHaveBeenCalledTimes(2);
+    expect(client.close).toHaveBeenCalledOnce();
+  });
+
+  it("reports unknown networks without making dependent calls", async () => {
+    const { client, callTool } = fixture();
+    await expect(discoverInfrastructure(client, "missing")).rejects.toThrow(
+      'Unknown network "missing". Available: filecoin'
+    );
+    expect(callTool).toHaveBeenCalledOnce();
+    expect(client.close).toHaveBeenCalledOnce();
+  });
+
+  it.each([
+    { content: [], isError: true },
+    { content: [] },
+    { content: [{ type: "text", text: "not JSON" }] },
+    { content: [], structuredContent: { networks: "unexpected" } },
+  ])(
+    "rejects unsuccessful or malformed tool responses and closes",
+    async (result) => {
+      const { client, callTool } = fixture([]);
+      callTool.mockResolvedValueOnce(result);
+      await expect(discoverInfrastructure(client)).rejects.toThrow();
+      expect(callTool).toHaveBeenCalledOnce();
+      expect(client.close).toHaveBeenCalledOnce();
+    }
+  );
+
+  it("closes after a transport failure", async () => {
+    const { client, callTool } = fixture([]);
+    callTool.mockRejectedValueOnce(new Error("connection lost"));
+    await expect(discoverInfrastructure(client)).rejects.toThrow(
+      "connection lost"
+    );
+    expect(client.close).toHaveBeenCalledOnce();
+  });
+
+  it("closes after a connection failure", async () => {
+    const { client } = fixture([]);
+    client.connect.mockRejectedValueOnce(new Error("unavailable"));
+    await expect(discoverInfrastructure(client)).rejects.toThrow("unavailable");
+    expect(client.close).toHaveBeenCalledOnce();
+  });
+
+  it("accepts an empty search result", async () => {
+    const empty = { results: [], total: 0 };
+    const { client } = fixture([networks, categories, empty]);
+    await expect(discoverInfrastructure(client)).resolves.toEqual(empty);
+  });
+});

[Adisaok]

Hi @patchharbor-dev, thank you for your contributions.

Internal validation

Approved.

I reviewed the target repository, the proposed patch, the contribution requirements, the stated validation results, and the submission history for this pilot.

The proposed integration is highly relevant to mcp-use: it adds a runnable TypeScript @mcp-use/client example demonstrating a real Chain.Love MCP infrastructure-discovery workflow rather than a simple link or directory entry.

The destination repository is active and explicitly welcomes documentation and example contributions. The submission also follows the repository's TypeScript contribution requirements, including the changeset, while remaining tightly scoped to the example, documentation, tests, and related release metadata.

The implementation is appropriately bounded: it discovers supported networks/categories and retrieves a small number of public infrastructure records. It does not bind credentials, execute downstream provider services, modify library dependencies, or alter existing library behaviour.

The reported validation is strong, including build/type checks, linting, formatting, the existing client test suite plus the new tests, and live Chain.Love discovery validation and a clean diff check.

I found no public evidence of a previous Chain.Love submission or rejection involving mcp-use, and no competing mcp-use proposal is currently visible in this pilot discussion.

The patch is therefore approved for the internal validation stage and is a strong candidate for authorised external submission.

No external outreach should be undertaken until it is selected and authorised through the Outreacher process.

@ArseniiPetrovich will respond to the payment issue you raised. Thank you.

[patchharbor-dev]

Hi @ArseniiPetrovich, following up on my mcp-use TypeScript example, approved here by Adisaok on 10 September. Could you please confirm:

• Whether the initial 1 USDC reward has been recorded for patchharbor-dev, and which monthly payout batch/date it is expected in.
• The official private channel for providing the receiving address.
• Whether an approved outreacher has been assigned, and whether anything further is needed from me.

Thanks for your help.

[Adisaok]

"External PR #2669 submitted and awaiting maintainer review."

[Adisaok]

mcp-use,mcp-use/mcp-use,https://github.com/mcp-use/mcp-use/pull/2669,rejected,2026-09-28,Adisaok,"Maintainer explicitly declined the contribution: 'we're not interested in this.'"

[inunanba]

Prepared patch for internal review: bekatom/awesome-ethereum — Ethereum infrastructure discovery

Fork: Not published; complete diff supplied below.
Branch: No remote branch; local working copy of upstream master.
Base commit: edbd34d72626ce64f0d63c4c7e3de24bd60e6558 (upstream master, rechecked 2026-09-10)
Changed files: README.md (+1 −0)
Patch summary: Adds Chain.Love to Developer Tools as a directory for finding and comparing Ethereum RPC/API providers and other infrastructure services. Complements existing provider/benchmark links without describing Chain.Love as a node provider.
Reward address: 0xe376Db1ccF80F77d280ba76501231d4A632755E6 — USDC or USDT on Ethereum mainnet (ERC20) only. Please confirm pilot payout timing/currency before payment.

Target: https://github.com/bekatom/awesome-ethereum
Product: https://www.chain.love/
Artifact (mission mirror): https://github.com/inunanba/test-mon/blob/main/experiments/work-chainlove-pilot-06/chainlove.patch

Verification (rechecked before this draft):

• Destination active within the pilot’s 4-week window (last push 2026-08-26; PR upd lens wallets #86 merged a comparable Developer Tools one-liner the same day).
• Tree has no CONTRIBUTING/CI; patch follows existing Markdown list style; only one line added.
• Upstream README had no Chain.Love entry; public issue/PR title+body scan and code search returned no matches.
• Visible Chain.Love ecosystem discovery bounty program #3731 proposals do not include this organization. Please check any private restriction or past rejection before assigning outreach.
• Local apply/reverse checks and blob hashes match the delivered validation record. AI-assisted preparation; contributor verifies claims.

No destination PR, issue, discussion, message, or maintainer contact has been made. This is for internal validation only.

diff --git a/README.md b/README.md
index cc0548a..fcbaa6b 100644
--- a/README.md
+++ b/README.md
@@ -93,6 +93,7 @@ decided that it has value.
 - [zig-evm: High-performance, embeddable EVM in Zig with wave-based parallel transaction execution, 96+ opcodes, and precompiles (blake2f, BN254, ripemd160). MIT-licensed; targets L2/Rollup execution with C/Python/Rust/JS FFI bindings.](https://github.com/cryptuon/zig-evm)
 - [Octav: Multi-chain crypto portfolio tracking API](https://octav.fi/api) - Multi-chain crypto portfolio tracking API. Track wallet holdings, DeFi protocol positions, transaction history, and token analytics across 20+ blockchains.
 - [OpenChainBench: Independent open-source benchmarks for Ethereum and L2 RPC providers, gas oracles, and L2 finality across 22 chains. CC BY 4.0 data.](https://openchainbench.com)
+- [Chain.Love](https://www.chain.love/) - Directory for discovering and comparing Ethereum RPC/API providers and other infrastructure services.

[Adisaok]

Hi @inunanba ,

Thanks for the submission and the verification notes.

I reviewed the target repository and Chain.Love's current Ethereum pages.

Internal validation

Approved.

Reasoning:

The target repository is active and falls within the pilot's eligibility window.
I found no public evidence that Chain.Love has previously been submitted to, rejected by, or is currently listed in bekatom/awesome-ethereum.
I found no competing or active #3731 proposal for this destination organisation, so the one-active-proposal rule is not currently triggered.
The proposed placement under "Developer Tools" is relevant. The section already curates Ethereum developer infrastructure, APIs, RPC-related resources, and tooling, making Chain.Love a natural fit as an infrastructure discovery directory.
The patch is appropriately scoped (single-line addition), uses neutral wording, and does not position Chain.Love as an RPC provider.

The submission satisfies the pilot's internal review requirements and is approved for the initial review stage.

[harunsulaiman]

since i found no external submission for this patch in the registry, i sent the external pr bekatom/awesome-ethereum#103

[inunanba]

Hi @harunsulaiman @Adisaok — follow-up on our internally approved bekatom/awesome-ethereum patch (comment 18384086, approved 2026-09-10).

1. External assignment: I see @harunsulaiman already opened Add Chain.Love to Ethereum Infrastructure Resources bekatom/awesome-ethereum#103 (noted in-thread 2026-09-24). Please confirm that PR is the authorized external submission for this patch, and whether any further action is needed from us (we will not touch the destination repo).

2. Settlement: The patch recorded payout address 0xe376Db1ccF80F77d280ba76501231d4A632755E6 (USDC/USDT on Ethereum mainnet). Could you confirm when/how the internally approved 1 USDC will be settled to that address (batch/date/network), and whether any extra step is required on our side?

Thank you — no destination contact from us.

[Adisaok]

Hi, @inunanba @ArseniiPetrovich will update you on your earnings. Rest assured that nothing approved by this program will go unrewarded. And for the external submission of your patch, @harunsulaiman will update you on the progress ASAP. Thank you for your contributions.

[EazyHood]

Hi @inunanba, I've taken over follow-up of this submission after the backlog split.

To answer your earlier question: bekatom/awesome-ethereum#103, opened by harunsulaiman on Sep 24, is the external submission for your patch. It adds your line unchanged, at the top of the Developer Tools list. It's still open with no review, and nothing is needed from you. I'll post the outcome here once the maintainer decides.

[kingnews2015]

Patch submission — stellar/stellar-docs (official Stellar developer documentation)

Fork: https://github.com/kingnews2015/stellar-docs
Branch: docs-chain-love-stellar-toolbox
Base commit: db501fe9f2d856f2b38c4da7bf57b325806fe842 (upstream main, 2026-09-09)
Changed files: docs/tools/developer-tools/node-operator-tools.mdx (+4, −0)
Patch: kingnews2015/stellar-docs@main...docs-chain-love-stellar-toolbox

Patch summary: Adds a neutral Chain.Love Stellar Toolbox entry to the existing community developer-tools catalog. The description identifies it as a searchable directory for discovering and comparing Stellar infrastructure providers across APIs, wallets, explorers, analytics, and other categories, and notes that the directory exposes public discovery API endpoints. It does not present Chain.Love as a Horizon/RPC provider or imply endorsement by Stellar.

Reward address: 0x95ac0188d8a55465babb8bb0d0987ee871dcbc3d

Validation:

• Target is official Stellar documentation, active within the four-week eligibility window, and explicitly accepts descriptive third-party tools on pages built for ecosystem tooling.
• Upstream repository and the visible submissions in this discussion were checked; no existing Stellar/stellar-docs Chain.Love proposal was found.
• The canonical Stellar-specific URL https://stellar.chain.love/toolbox/apis returned HTTP 200.
• The public categories endpoint responded successfully and confirms the provider-category discovery data used by the description.
• One MDX file changed; existing heading/paragraph style was preserved and no unrelated content was modified.
• AI assisted preparation; product and destination claims were verified against the live Stellar-specific toolbox/API and the repository contribution guide.

No external PR, issue, discussion, message, or maintainer contact has been made. This patch is submitted only for internal validation under the pilot rules.

[Adisaok]

Hi, @kingnews2015, thanks for the detailed submission and validation evidence.

Internal review

Revision required.

I reviewed your contribution against #3731 and the proposed destination, the relevant Stellar documentation and contribution requirements, the proposed placement and wording, and the Chain.Love Stellar Toolbox, the duplicate/history checks, and the validation evidence provided.

The target itself is highly relevant and potentially a strong Tier 1 outreach destination. However, two points need to be resolved before the patch can be approved for the internal stage.

1. Destination contribution workflow

The Stellar documentation contribution guidance indicates that suggestions for missing content or structural changes should be discussed through an issue before implementation.

This submission adds new ecosystem content, but no prior issue or maintainer discussion is identified in the proposal.

Please confirm whether an existing issue/discussion or other documented maintainer approval covers this addition. If not, please identify the appropriate issue-first route required by the destination before proceeding with the patch.

2. Proposed page placement

The patch targets:

docs/tools/developer-tools/node-operator-tools.mdx

The page is specifically focused on Node Operator Tools, while the proposed Chain.Love entry describes a broader infrastructure discovery directory covering APIs, wallets, explorers, analytics, and other categories.

Please confirm that the maintainers' intended scope for this page includes broader ecosystem infrastructure directories, or identify a more appropriate existing Stellar developer-tools location for the Chain.Love entry.

The Chain.Love product positioning itself is appropriate: the proposal correctly presents Chain.Love as a discovery/comparison directory rather than as a Horizon/RPC provider or a Stellar-endorsed resource. The patch is also appropriately scoped, and no external PR, issue, discussion, message, or maintainer contact has been made.

The public duplicate/history checks also show no public evidence of an existing Chain.Love proposal or listing for this destination.

Once the destination workflow and placement questions are resolved, please update the submission with the supporting evidence, and we can complete the internal validation.

Current status: REVISION REQUIRED: destination workflow and placement clarification.

Please do not undertake external outreach while this proposal remains under internal review.

[kingnews2015]

Revision completed.

Updated branch: https://github.com/kingnews2015/stellar-docs/tree/docs-chain-love-stellar-toolbox
Updated comparison: stellar/stellar-docs@main...kingnews2015:stellar-docs:docs-chain-love-stellar-toolbox

Changes:

• Removed the Chain.Love entry from docs/tools/developer-tools/node-operator-tools.mdx.
• Moved the reference to docs/data/apis/rpc/providers.mdx, the existing page specifically built for third-party Stellar RPC providers.
• Narrowed the wording to RPC/API discovery and added a clear instruction to verify network support, interfaces, limits, and pricing in each provider's current documentation.

Destination workflow evidence: Stellar's CONTRIBUTING.md says third-party tools and services belong on pages built for them and that, when a project clearly fits one of those list pages, contributors may directly open a PR. The revised placement is the dedicated RPC provider page, so this is no longer a new structural category or a broad ecosystem-tool insertion. If the reviewer still determines an issue is required, that issue-first step remains for an authorized Chain.Love outreacher; I have not opened an external issue or PR and have not contacted Stellar maintainers.

Validation:

• The public comparison currently shows 3 commits and 1 file changed.
• git diff --check passed.
• The earlier Node Operator Tools addition has been reverted, leaving only the RPC Providers page changed in the net diff.
• The canonical Stellar Chain.Love URL remains reachable.

No external PR, issue, discussion, message, or maintainer contact has been made.

[harunsulaiman]

Hi @kingnews2015 since the Patch is approved, kindly add me @harunsulaiman as a contributor with write access so that I can push the Pull request. Thank you

[Adisaok]

Hi @kingnews2015, thanks for completing the revision.

I’ve reviewed the updated comparison, and moving the Chain.Love entry to docs/data/apis/rpc/providers.mdx addresses the earlier placement concern. The revised wording is also appropriately scoped and avoids presenting Chain.Love as an RPC provider.

One item remains before we can complete internal validation: Stellar’s issue-first contribution workflow.

Stellar’s contribution guidance indicates that proposals involving missing content should generally begin with an issue. Please complete this part of the internal submission by:

1. Checking the relevant sections of Stellar Docs’ CONTRIBUTING.md and identifying the exact guidance that applies to adding a third-party resource to an existing RPC provider list.
2. Checking for an existing issue or discussion covering this type of addition.
3. Updating your submission with the relevant links and a brief explanation of whether an issue is required before the proposed PR.

Please do not open an external issue or PR, contact Stellar maintainers, or undertake other external outreach while this contribution remains under internal review. If an issue is required, I will handle that step as an authorized Chain.Love outreacher after internal approval.

Once you have updated the evidence, please reply here so we can complete the final internal validation.

Thank you for the work you’ve put into refining the patch.

[jianqiang8977-create]

Internal patch submission: Ethereum infrastructure discovery resource

Destination: https://github.com/OffcierCia/DeFi-Developer-Road-Map
Fork / branch: none; the complete unified diff is included below for internal review.
Base commit: 482c3bf574f45b582508224aae78d6c047dd5389 (current main, checked 2026-09-10 16:01 UTC).
Changed files: README.md (+1 line, no deletions).
Reward address: 0xd454791f7138C97dC212e97851FDF8BB7BD1091a (Ethereum mainnet).

Patch summary: Add Chain.Love to the existing Ethereum Tools directory, describing it as an open-source infrastructure directory. The entry links to the canonical homepage and does not present Chain.Love as an RPC operator or make performance claims.

Checks: The README welcomes documentation/tool contributions. The current repository is not archived; its latest push is 2026-08-16 23:17:39 UTC, within four weeks at submission preparation time. No existing Chain.Love entry was found. This one-line patch passes git apply --check --whitespace=error; the applied text exactly matches the proposed file after normalizing Windows line endings. The repository tree exposes no documentation build or lint workflow. Product wording was checked against https://www.chain.love/ . Please recheck activity and duplicate proposals before external submission.

This patch was prepared with AI assistance and reviewed against the source. No destination PR, issue, maintainer message, or other outreach has been made. No repository star was added for a reward. Please confirm whether the pilot accepts this submission without a star, and whether the monthly payment process has a minimum payout threshold. I understand that submitting does not establish approval or payment.

--- a/README.md
+++ b/README.md
@@ -769,6 +769,7 @@
 
 - [OpenChainBench](https://openchainbench.com) - Live, neutral benchmarks for crypto infrastructure: public RPC latency across 22 EVM chains plus Solana, oracle deviation, bridge quote fees, perp DEX all-in cost, gas oracle accuracy. Open methodology, CC BY 4.0 data.
 - [Node Stats](https://ethernodes.org)
+- [Chain.Love](https://www.chain.love/) - Open-source directory for discovering and comparing Ethereum RPC providers and other Web3 infrastructure.
 - [solidity-by-example.org](https:/solidity-by-example.org)
 - [EVM Networks List](https://chainid.network)
 - [BIP39 Derivation](https://iancoleman.io/bip39)

[jianqiang8977-create]

Hi @harunsulaiman, thank you. The complete one-line unified diff and base commit 482c3bf574f45b582508224aae78d6c047dd5389 are in my September 10 submission above; I did not create a fork. I checked upstream main today (September 27): its latest commit is August 16, 42 days ago. The pilot excludes repositories with more than four weeks without updates. Could you confirm whether this destination remains eligible for external outreach, or whether we should stop this external step? If it still qualifies, I can prepare an isolated fork and branch. I have not contacted the destination or opened a PR.

[harunsulaiman]

@jianqiang8977-create you should create an isolated fork, prepare the patch(diff) and do not push PR. Add me as a contributor with write access so that I can push the PR as the external outreacher

[harunsulaiman]

@jianqiang8977-create pr is submitted at OffcierCia/DeFi-Developer-Road-Map#175 thanks

[eugene17kotov]

@harunsulaiman, please make sure that all outreach proposals you handled during the month are recorded in outreach/registry.csv, as required by the program rules.

This should include every external outreach you processed during the reporting period, not only the currently active or successfully merged ones. Please add any missing entries and make sure their statuses reflect the actual outcomes.

The registry is intended to provide a complete record of the outreach activity, so these entries need to be present there in order to be taken into account for the monthly outreach work.

Please submit the corresponding registry update PR when ready. Thank you.

[EazyHood]

@jianqiang8977-create, I've taken over Harun's remaining cases after eugene17kotov's split (#3731 (reply in thread)). The owner closed OffcierCia/DeFi-Developer-Road-Map#175 on October 12 without merging it or leaving a comment. I'm recording it in the outreach registry as rejected with that date (#4435). Under the program rules that organization can't be contacted again for at least 90 days, so this one is closed.

[EazyHood]

Patch submission — ava-labs/builders-hub (Avalanche Builder Hub, build.avax.network)

Fork: https://github.com/EazyHood/builders-hub
Branch: add-chain-love-integration
Base commit: 8a1be905ec30915b9e07c8ed84f34dcb6446481a (upstream master, 2026-09-10)
Changed files: content/integrations/chain-love.mdx (new, 51 lines) and public/images/chain-love.png (new, 200×200)
Patch summary: Adds Chain.Love to the Avalanche integrations directory under Developer Tooling, as an infrastructure directory for Avalanche C-Chain. The page follows the repository's own integration template: frontmatter, Overview, Features, Getting Started with two runnable curl calls against the public discovery endpoints, Documentation, Use Cases and Conclusion.
Reward address: 0x06f44f4839fd5df4f4670036d028b29dec939363

Diff: ava-labs/builders-hub@master...EazyHood:add-chain-love-integration

Why this destination, and why a PR is the right door here. The last target I looked at was OffchainLabs/arbitrum-docs, and I dropped it: its third-party-docs/contribute.mdx only admits products already listed in the Arbitrum portal, entry to the portal is a Google form, and it states the content is not meant to drive traffic to a product. A PR there would bypass their stated process. Avalanche is the opposite case. content/integrations/README.md is titled "Publish your integration", documents the frontmatter, the logo path and the categories, and ends with "Submit a Pull Request". The intake is the PR.

Destination checks, measured rather than assumed:

• Active: 175 pull requests merged in the last 90 days, most recent yesterday. The integrations directory itself is smaller and slower but alive — 8 commits since 12 June, including docs: add Avail Nexus integration from an outside contributor on 6 July.
• Not a stale name: ava-labs/avalanche-docs now redirects to ava-labs/builders-hub. The patch targets the canonical repository.
• Chain.Love is not mentioned anywhere in the repository today (code search across the default branch, 0 hits).
• The frontmatter validates against their schema. source.config.ts defines the integrations collection with category required and available, logo, developer, website and documentation optional; the file supplies all of them.
• Category Developer Tooling already exists in the directory (8 entries), so no new category is invented.
• Logo: the official mark from Chain.Love's own og:image, cropped to its alpha bounds and scaled to 200×200 with a transparent background, which is the size their README recommends. Checked on light and dark, and at the 40×40 the grid actually renders.

Every number on the page comes from the Avalanche deployment's own public endpoint, so a reviewer can re-derive them:

curl -sS "https://mainnet.avalanche.chain.love/api/infrastructure-providers/categories"

370 API and RPC entries from 47 providers, 152 MCP servers, 88 SDKs, 64 wallets, 58 analytics, 57 security, 51 platforms, 41 ramps, 40 storages, 37 bridges, 24 explorers, 12 oracles, 8 faucets, across 15 categories. I checked the wording against the data twice: the page says "the advertised uptime SLA where a provider publishes one" rather than claiming measured uptime, because in the Avalanche rows verifiedUptime, verifiedLatency and verifiedBlocksBehindAvg are all NULL today. The dataset licence is stated as CC BY-SA 4.0, which is the licence on the Chain-Love/chain-love repository.

The two curl examples in the Getting Started section were run before submitting: both return HTTP 200 with no API key and no account. Every link on the page was requested individually and returns 200.

No PR was opened, no issue filed, and no maintainer contacted, per the program's no-outreach rule.

[eugene17kotov]

@Adisaok, please continue this outreach rather than treating the closed PR as the final outcome.

The destination maintainer did not reject the proposed Chain.Love addition. The issue raised was technical: this repository requires signed commits, and the maintainer explicitly asked for the commits to be signed so the contribution could be merged.

Since the original PR has now been closed, please recreate the external PR with the requested commit-signing requirement properly satisfied and make sure the new submission follows the repository's current contribution requirements.

Please also reply here with the new external PR link once it is opened and update the corresponding outreach/registry.csv entry so that it points to the current submission and reflects its actual status.

This outreach should only be treated as resolved once the destination reaches a final decision on the corrected submission.

[Adisaok]

Hi, @eugene17kotov

I'd like to provide an update on the ongoing Avalanche Builders Hub outreach.

Last week, I contacted [@owenwahlgren](https://github.com/owenwahlgren) regarding the restriction preventing me from opening the replacement PR for [ava-labs/builders-hub#4542](ava-labs/builders-hub#4542). In that message, I explained that I had recreated the contribution on a clean branch based on the current master, verified both commit signatures, and asked for guidance on obtaining an authorised submission route.

My prepared branch remains available here:
https://github.com/EazyHood/builders-hub/tree/resubmit/chain-love-integration

I have not received a response yet. The comparison page confirms that both commits are verified and the changes are mergeable, but GitHub still restricts PR creation to repository collaborators.

Would you recommend sending one brief reminder to Owen, or should I continue waiting for his response? I want to complete the resubmission as instructed while respecting the destination maintainer's communication preferences and Chain.Love's outreach guidelines.

The replacement PR has not yet been opened. I will preserve the prepared branch and update the registry once the submission route is resolved and the new PR is actually created.

Thank you for your guidance.

[Adisaok]

@eugene17kotov @ArseniiPetrovich The maintainer did not respond to the comment addressed to him on the closed PR. Should I open another PR, or I should continue waiting?

[Adisaok]

@eugene17kotov @ArseniiPetrovich The maintainer did not respond to the comment addressed to him on the closed PR. Should I open another PR, or I should continue waiting?

[Adisaok]

@eugene17kotov @ArseniiPetrovich The maintainer did not respond to the comment addressed to him on the closed PR. Should I open another PR, or I should continue waiting?

[Airmaliel]

Patch submission — filecoin-project/filecoin-docs (Filecoin JSON-RPC reference)

Fork: https://github.com/Airmaliel/filecoin-docs
Branch: patch-1
Base commit: 1afa554524f18c3ed41c0d2163906acda1efa1af (upstream main, checked 2026-09-10)
Changed files: reference/json-rpc/README.md (+2 lines, one hunk)
Commit: Airmaliel/filecoin-docs@35fe4ae
Diff: filecoin-project/filecoin-docs@main...Airmaliel:filecoin-docs:patch-1

Patch summary: Adds a short, neutral reference to the Filecoin-specific Chain.Love API directory after the existing public Glif example, so readers can compare network-specific provider metadata before selecting an endpoint. It does not imply endorsement or replace provider documentation.

Verification:

• The destination repository is active and accepts documentation contributions; recent external contributor documentation PRs have merged.
• I checked this Chain.Love discussion and the destination repository’s current open PR/issue searches; there is no existing Filecoin proposal or Chain.Love outreach to this target.
• The Filecoin-specific directory is publicly accessible at https://mainnet.filecoin.chain.love/toolbox/apis and is directly relevant to the page’s provider-selection context.
• This is a single focused Markdown change. No external PR, issue, discussion, maintainer contact, or other outreach was made.

Reward address: 0x9db622fda1f74d77674344b4b199dbb21ddd947e (USDC/USDT on Ethereum mainnet)

AI-assisted patch; claims and links were checked against the live destination and directory.

[Adisaok]

Hi, @Airmaliel, thanks for the detailed submission and validation evidence.

Internal review

Approved.

I reviewed the proposal against [#3731](#3731), including the destination's contribution expectations, the proposed placement and wording, and Chain.Love's current product positioning, duplicate/history checks, patch scope, and the validation evidence provided.

The proposal satisfies the internal validation requirements:

filecoin-project/filecoin-docs is an active and relevant official Filecoin documentation destination within the pilot's activity window.

The proposed reference/json-rpc/README.md page is directly relevant to the Chain.Love Filecoin API directory because the page provides JSON-RPC reference information and discusses public endpoint/provider selection.

The destination accepts documentation contributions through pull requests, and no issue-first requirement preventing this type of documentation addition was identified.

The proposed Chain.Love reference is appropriately Filecoin-specific and links to the Filecoin Chain.Love API directory.

The proposed wording is neutral and accurately presents Chain.Love as an infrastructure discovery directory that can help readers review provider metadata before selecting an endpoint. It does not imply endorsement of Chain.Love or any individual provider and does not present Chain.Love as an RPC provider itself.

The canonical Filecoin Chain.Love API directory is used.

No existing Chain.Love entry was identified on the proposed JSON-RPC reference page, and the proposed placement does not duplicate the existing Chain.Love reference elsewhere in the Filecoin documentation.

No public evidence of a competing Chain.Love proposal, a previous proposal for this specific placement, or a rejection was identified in the destination repository.

The patch is appropriately scoped to a two-line Markdown addition in a single hunk, with no unrelated changes.

The linked Chain.Love Filecoin API directory is publicly accessible and directly relevant to the destination page's provider-selection context.

The contributor has stated that the claims and links were checked against the live destination and Chain.Love directory.

No external PR, issue, discussion, maintainer message, or other outreach has been made, which is compliant with the [#3731](#3731) internal-validation process.

The contributor's stated upstream base commit was checked against the destination's main branch at the time of preparation. Any subsequent upstream changes will be handled during the final pre-submission refresh and do not affect the contributor's internal qualification.

Final internal status: APPROVED.

If this proposal is selected for external outreach, I, the authorised Outreacher, will perform a final check against the current upstream state, including repository activity, duplicate status, placement, and the live Chain.Love URL, and any changes to the destination's contribution requirements before submitting externally.

The destination's required documentation/link checks should also be allowed to pass as part of the external PR process.

No external outreach should be undertaken independently before authorisation under the Chain.Love ecosystem discovery programme.

Thank you for the thorough work.

[Adisaok]

Hi, @Airmaliel, thank you for your contribution.

Your prepared patch has completed the transition from internally validated to externally submitted.

[Adisaok]

External PR #2487 submitted and still awaiting maintainer review.

[zaguzovmaksim0-hue]

Patch submission — DROOdotFOO/awesome-web3-data (Infrastructure)

Fork: https://github.com/zaguzovmaksim0-hue/awesome-web3-data
Branch: add-chain-love-infrastructure
Base commit: 2a2d55cb16377e163ce4cbf4f6da3eb9854969f3
Changed files: README.md (+1, -0)
Patch summary: Adds Chain.Love to the existing Infrastructure section as an open-source directory and dataset for comparing Web3 infrastructure providers across multiple networks. The entry uses the list's required neutral one-line format, the canonical Chain.Love URL, and alphabetical placement between Censorship.pics and Checkpoint Sync Endpoints.
Reward address: 0x75eA41b47Ca3c3c3F1A87C7EcE30CFEa708Bda0D (USDC/USDT on Ethereum mainnet)

Diff: DROOdotFOO/awesome-web3-data@main...zaguzovmaksim0-hue:add-chain-love-infrastructure

Why this target: The repository is specifically a curated list of Web3 data resources, tools, APIs and infrastructure. Its contribution guide explicitly accepts data/infra resources and requires a name, reachable URL, neutral one-line description and alphabetical placement. The repository was pushed on 2026-08-26, within the pilot's four-week activity window, and external contributions #23 and #27 were merged on 2026-08-26. Chain.Love is not currently listed, and live code/PR/issue searches found no existing Chain.Love entry or proposal in the destination.

Verification:

• https://www.chain.love/ and the public Chain-Love/chain-love repository both returned HTTP 200 immediately before preparation.
• The wording is factual and contains no ranking, endorsement, or superlative claim.
• markdownlint-cli2 '**/*.md': 0 issues.
• git diff --check: passed.
• awesome-lint reports the same pre-existing baseline result on pristine upstream and on this patch: 17 spelling warnings plus remark-lint:awesome-github ("Awesome list must reside in a valid git repository"). The patch introduces no additional awesome-lint finding.
• No destination PR, issue, discussion, maintainer message, email, or other outreach has been made.

Prepared and verified with AI assistance against the live destination and current Chain.Love product. This submission is only for internal validation under the outreach pilot; I will not submit it externally unless the program assigns/authorizes an outreacher.

[Adisaok]

Hi, @zaguzovmaksim0-hue, thanks for the detailed submission and validation evidence.

Internal review

Approved.

I reviewed the proposal against [#3731](#3731), including the destination's contribution expectations, the proposed placement and wording, and Chain.Love's current product positioning, duplicate/history checks, patch scope, and the validation evidence provided.

The proposal satisfies the internal validation requirements:

DROOdotFOO/awesome-web3-data is an active and relevant Web3 data and infrastructure resource destination within the pilot's activity window.

The existing Infrastructure section is an appropriate location for Chain.Love as an open-source infrastructure discovery directory and dataset for discovering and comparing Web3 infrastructure providers across networks.

The destination's contribution guidelines explicitly accept data and infrastructure resources and require a resource name, reachable URL, neutral one-line description, and alphabetical placement.

The proposed Chain.Love entry follows the destination's required one-line format and is correctly positioned alphabetically between Censorship.pics and Checkpoint Sync Endpoints.

The proposed description is neutral and accurately presents Chain.Love as an open-source directory and dataset for discovering and comparing Web3 infrastructure providers. It does not contain ranking, endorsement, or superlative claims.

The canonical Chain.Love URL is used.

No existing Chain.Love entry was identified in the destination README.

No public evidence of a competing Chain.Love proposal, previous placement, or rejection was identified in the destination repository.

The patch is appropriately scoped to a single README addition with no unrelated changes.

markdownlint-cli2 '**/*.md' passed with 0 issues.

git diff --check passed.

The reported awesome-lint findings are pre-existing destination baseline findings: the same 17 spelling warnings and remark-lint:awesome-github warning were present on pristine upstream and on the proposed patch. No additional awesome-lint finding was introduced by the Chain.Love change. This does not constitute a contributor-introduced validation blocker.

The Chain.Love website and public repository were verified as reachable, and the proposed Chain.Love URL was checked against the current product.

No external PR, issue, discussion, maintainer message, email, or other outreach has been made, which is compliant with the [#3731](#3731) internal-validation process.

The contributor's upstream base commit was checked during preparation. Any subsequent upstream changes will be handled during the final pre-submission refresh and do not affect the contributor's internal qualification.

Final internal status: APPROVED.

If this proposal is selected for external outreach, I, the authorised Outreacher, will perform a final check against the current upstream state, including repository activity, duplicate status, placement, and the live Chain.Love URL, and any changes to the destination's contribution requirements before submitting externally.

The destination's available lint, link, and CI checks should also be revalidated during the external PR process. The existing baseline awesome-lint findings should not be treated as contributor-introduced failures unless the destination's current CI establishes otherwise.

No external outreach should be undertaken independently before authorisation under the Chain-Love ecosystem discovery programme.

Thank you for the thorough work.

[Adisaok]

Hi @zaguzovmaksim0-hue, external outreach has been successfully submitted as PR #32.

[Adisaok]

Merged into main; the maintainer thanked the contributor.

[jiaruihz]

Patch submission — ton-blockchain/docs (TON hosted API discovery)

Fork: https://github.com/jiaruihz/docs
Branch: docs/add-chain-love-ton-directory
Base commit: cba0529c319dd3b258afdaa66dbf5375c4e5556e (upstream main, checked 2026-10-05)
Patch commit: be4979abc797219f553f29b9a762c6637126d7da
Changed files: content/api/overview.mdx (+2, -0)
Patch summary: Adds one neutral paragraph to the official TON API overview for discovering hosted services beyond the TON Center and liteserver implementations documented on the page. It links the TON-specific Chain.Love API directory and instructs readers to verify network support, API version, archival coverage, rate limits, and current pricing in provider documentation before integrating.
Reward address: 0x4B689c62992FCcC63525d32D70696E45190d260A

Diff: ton-blockchain/docs@main...jiaruihz:docs:docs/add-chain-love-ton-directory

Destination fit:

• The page is the official overview for choosing how to access TON data and already contrasts public liteservers, hosted APIs, and self-hosted options.
• The patch describes Chain.Love only as an additional discovery directory, not as an RPC provider or official TON service.
• The repository is active and the wording follows its neutral, precise, reader-first style guide.
• No existing Chain.Love entry or active proposal for the TON organization was found immediately before submission.

Verification:

• https://ton.chain.love/toolbox/apis returned HTTP 200 and was opened manually.
• git diff --check: PASS.
• Repository formatting check for the changed MDX: PASS.
• Repository spelling check for the changed MDX: PASS, zero issues.
• Full npm run build: PASS, including type, link, navigation, redirect, MDX, Next.js production build, and static generation of 1,244 pages.
• Final branch is one commit ahead and zero behind its recorded upstream base; no lockfile or generated-file changes.

AI assistance was used for discovery and drafting. Every claim, link, destination rule, duplicate check, and final diff was manually verified.

No external pull request, issue, discussion, comment, email, or maintainer contact was created. This submission is for internal validation only.

[Adisaok]

Hi, @jiaruihz,

Thank you for the detailed submission for ton-blockchain/docs.
I have completed the internal review of the proposed Chain.Love contribution against the requirements and validation standards for the Chain.Love ecosystem discovery program.
Review outcome: APPROVED FOR NEXT-STAGE OUTREACH REVIEW
The submission demonstrates a strong fit with the program for the following reasons:

1. Strong destination relevance
   ton-blockchain/docs is the official TON developer documentation repository and is actively maintained. The proposed contribution is therefore being made in an authoritative destination serving TON developers.
2. Natural placement
   The proposed change targets:
   content/api/overview.mdx
   This is a particularly appropriate location because the page is concerned with options for accessing TON data and interacting with TON from the off-chain environment. Introducing the TON-specific Chain.Love API directory at this point provides an additional discovery path precisely where developers may be evaluating hosted API options.
3. Appropriate role for Chain.Love
   The contribution does not present Chain.Love as another API provider or as a replacement for TON Center, liteservers, or individual infrastructure providers.
   Instead, it presents Chain.Love as an additional network-specific discovery directory for hosted services.
   This distinction is important and makes the contribution complementary to the existing TON documentation.
4. Neutral and responsible wording
   The proposed wording avoids unsupported claims about provider quality, performance, pricing, reliability, or preference.
   The additional guidance to independently verify:

• TON network support;
• API version;
• archival coverage;
• rate limits; and
• pricing
  is appropriate and helps ensure that Chain.Love is presented as a discovery resource rather than an authoritative source for provider-specific technical or commercial terms.

5. Minimal and focused change
   The proposed modification is limited to two added lines in the relevant API overview page.
   There are no unrelated documentation changes, generated files, lockfile changes, configuration changes, or code changes associated with the submission.
6. Validation evidence
   The submitted validation evidence is satisfactory:

• git diff --check — PASS
• formatting validation — PASS
• spelling validation — PASS
• full documentation build — PASS
• MDX compilation — PASS
• link/navigation checks — PASS
• production build/static generation — PASS
  The reported build also successfully generated the documentation site without requiring unrelated changes.

7. External outreach status
   It is also good that no external pull request, issue, discussion, comment, email, or maintainer contact has been initiated at this stage.
   This preserves the required internal-validation workflow before external outreach.

[Adisaok]

External PR #2336 submitted and awaiting maintainer review.

[jiaruihz]

Patch submission — starknet-io/starknet-docs (Starknet provider directory)

Fork: https://github.com/jiaruihz/starknet-docs
Branch: docs/add-chain-love-starknet-directory
Base commit: c1fb35198225d7c439b521e28d37181248ff755f (upstream main, checked 2026-10-05)
Patch commit: ff695aa9335a6f1f3bcee1c9c42303b2a7ca09e5
Changed files: learn/cheatsheets/integrations.mdx (+3, -1; the deletion is only replacement of the pre-existing missing final newline)
Patch summary: Adds a Provider directories bullet directly after the existing Starknet RPC providers list. It identifies Chain.Love as a directory of Starknet API/RPC offerings with provider-documentation links and tells readers to verify network and RPC-version support, rate limits, and current pricing before integrating.
Reward address: 0x4B689c62992FCcC63525d32D70696E45190d260A

Diff: starknet-io/starknet-docs@main...jiaruihz:starknet-docs:docs/add-chain-love-starknet-directory

Destination fit:

• The official Developer integrations page is explicitly continuously updated and asks contributors to edit it when a project is missing.
• The new bullet sits in Infrastructure next to the RPC provider list but keeps directories separate from providers, avoiding any endorsement claim.
• The wording is network-specific, concise, neutral, and directs readers back to provider documentation for operational facts.
• No existing Chain.Love entry or active proposal for the Starknet organization was found immediately before submission.

Verification:

• https://starknet.chain.love/toolbox/apis returned HTTP 200 and was opened manually.
• git diff --check: PASS.
• Repository python scripts/validate_llms_txt.py: PASS (45 links, 6 sections, no format or link errors).
• Mintlify strict validate: PASS.
• Mintlify broken-links: PASS, no broken links found.
• docs.json parses successfully.
• Final branch is one commit ahead and zero behind its recorded upstream base; only one documentation file changed.

AI assistance was used for discovery and drafting. Every claim, link, destination rule, duplicate check, and final diff was manually verified.

No external pull request, issue, discussion, comment, email, or maintainer contact was created. This submission is for internal validation only.

[EazyHood]

Hi @jiaruihz, thanks for the submission, and sorry for the wait.

Internal review
Not approved for external submission at this time.

What passed:

• starknet-io/starknet-docs is the official Starknet docs repo, with commits on Oct 15, and the Developer integrations page asks readers to add what's missing.
• The bullet keeps Chain.Love separate from the RPC providers, links the Starknet API view (https://starknet.chain.love/toolbox/apis), and the wording is neutral.
• The patch still applies to main. No Chain.Love mention in the repo or in Starknet's issues and PRs, no Starknet row in the outreach registry or its open PRs, and no earlier contact with the destination.

Why it isn't going out now:

• Outside additions to that page haven't been getting reviews. Three are open with no maintainer review: starknet-io/starknet-docs#1778 (PublicNode, Sep 23), starknet-io/starknet-docs#1772 (node101, Aug 21) and starknet-io/starknet-docs#1739 (Codex, Feb 28). The only change merged on that page this year is a Pathfinder link update (starknet-io/starknet-docs#1776, Sep 22).
• A smaller point: the bullet sits between the RPC providers list and the note that belongs to it (open endpoints and version suffixes), so it would have to move below that note.

The second point is easy to fix, but the first wouldn't change, so I'd rather not ask you for more work now. If outside additions start landing on that page, this can be looked at again.

Please don't open a PR or contact the Starknet maintainers yourself.

Final internal status: NOT APPROVED (not submitted externally for now).

[jiaruihz]

Patch submission — tronprotocol/documentation-en (TRON hosted node and API discovery)

Fork: https://github.com/jiaruihz/documentation-en
Branch: docs/add-chain-love-tron-directory
Base commit: 8caa129215ae26edc2f55238ad09897fddb378cf (upstream master, checked 2026-10-05)
Patch commit: 7afe65287c285132b46e0e5733c5771a10653243
Changed files: docs/getting_started/getting_started_with_javatron.md (+4, -1; the deletion is only removal of the pre-existing extra blank line at EOF)
Patch summary: Adds a neutral, TRON-specific resource directly after the getting-started guide introduces public nodes. It identifies the Chain.Love TRON API directory as a way to compare hosted node and API plans, links readers to provider documentation, and tells them to verify endpoint/API coverage, historical-data availability, rate limits, and current pricing before integrating.
Reward address: 0x4B689c62992FCcC63525d32D70696E45190d260A

Diff: tronprotocol/documentation-en@master...jiaruihz:documentation-en:docs/add-chain-love-tron-directory

Destination fit:

• The official guide presents public nodes as the recommended beginner path immediately before this placement.
• The addition provides practical selection criteria and does not present Chain.Love as a node provider or official TRON service.
• The repository is active, accepts documentation contributions against master, and has no existing Chain.Love entry or active TRON proposal found immediately before submission.

Verification:

• https://tron.chain.love/toolbox/apis returned HTTP 200 and rendered the title Tron Chain.Love Toolbox APIs Directory.
• git diff --check: PASS.
• mkdocs build --strict: PASS; the edited page rendered with the new link and guidance.
• The official workflow currently pins mkdocs-git-revision-date-localized-plugin==1.5.1, which is unavailable on PyPI; the strict local build used the available adjacent version 1.5.0 with all other workflow-pinned versions unchanged.
• Final remote branch is one commit ahead and zero behind the recorded upstream base; only one documentation file changed.

AI assistance was used for discovery and drafting. Every claim, link, destination rule, duplicate check, and final diff was manually verified.

No external pull request, issue, discussion, comment, email, or maintainer contact was created. This submission is for internal validation only.

[EazyHood]

Hi @jiaruihz, thanks for the submission, and sorry for the wait.

Internal review
Not approved.

What passed:

• tronprotocol/documentation-en is official and active, with commits on Oct 14.
• The wording is neutral and links the TRON API view (https://tron.chain.love/toolbox/apis).
• No Chain.Love mention in the repo or in TRON's issues and PRs, no TRON row in the outreach registry or its open PRs, and no earlier contact with the destination.

Why it isn't approved:

• There's no natural place for it in this repo. It holds the java-tron documentation, no page lists third-party node or API providers, and for public nodes it links out to developers.tron.network. The chosen spot is in the getting-started tutorial, where readers choose between a public Nile testnet node and their own node right before the wallet-cli examples. A directory of hosted plans and pricing doesn't fit that step.
• The patch no longer applies: that part of the guide was rewritten in tronprotocol/documentation-en#672, merged on Oct 9.

Moving the line wouldn't fix the first point, so I'm not asking for a revision. Please don't open a PR or contact the TRON maintainers yourself.

Final internal status: NOT APPROVED.

[jiaruihz]

Patch submission — XRPLF/xrpl-dev-portal (XRPL hosted API discovery)

Fork: https://github.com/jiaruihz/xrpl-dev-portal
Branch: docs/add-chain-love-xrpl-directory
Base commit: 32de8e338ccccf5c28ec5b54e948f318b901623d (upstream master, checked 2026-10-05)
Patch commit: 1e27afb82859a224b4501bf821aabcceddca03a5
Changed files: docs/tutorials/public-servers.md (+3, -0)
Patch summary: Extends the official Public Servers page immediately after its commercial provider table with a neutral XRPL-specific comparison resource. It links the Chain.Love XRPL API directory and instructs readers to verify Mainnet/Testnet support, JSON-RPC/WebSocket availability, ledger-history coverage, rate limits, and current pricing in provider documentation before integrating.
Reward address: 0x4B689c62992FCcC63525d32D70696E45190d260A

Diff: XRPLF/xrpl-dev-portal@master...jiaruihz:xrpl-dev-portal:docs/add-chain-love-xrpl-directory

Destination fit:

• The official page is specifically for choosing public XRPL servers and already separates non-commercial, commercial, and test-network access.
• The new paragraph sits after the commercial table, adds concrete evaluation criteria, and does not imply endorsement or claim that Chain.Love operates an XRPL server.
• The repository is active and accepts community documentation contributions; no existing Chain.Love entry or active XRPL Foundation proposal was found immediately before submission.

Verification:

• https://xrpl.chain.love/toolbox/apis returned HTTP 200 and rendered the title Xrpl Chain.Love Toolbox APIs Directory.
• git diff --check: PASS.
• Targeted Markdown content and delimiter check: PASS.
• Full npx realm build was attempted but the Redocly Realm CLI stopped before content compilation because this environment has no valid Plan Gates token (Plan gates token is not valid or empty).
• Final remote branch is one commit ahead and zero behind the recorded upstream base; only one documentation file changed.

AI assistance was used for discovery and drafting. Every claim, link, destination rule, duplicate check, and final diff was manually verified.

No external pull request, issue, discussion, comment, email, or maintainer contact was created. This submission is for internal validation only.

[Adisaok]

Hi @jiaruihz,
I reviewed your XRPLF/xrpl-dev-portal submission for the Chain.Love ecosystem discovery bounty, specifically the proposed change to:
docs/tutorials/public-servers.md
I’m approving this submission for internal validation / progression to the external-outreach stage if there is no external limitation.
The proposal has a particularly strong fit because the target page is already focused on XRPL public servers and provider selection. Placing the Chain.Love reference immediately after the existing commercial-provider section makes the contribution natural rather than promotional or merely technically acceptable.
I also verified the following points:

• xrpl.chain.love provides an XRPL-specific Chain.Love infrastructure directory.
• The proposed link is network-specific and relevant to the page.
• The wording presents Chain.Love as a discovery/comparison resource rather than as an XRPL infrastructure provider.
• The proposed change is narrowly scoped to the relevant documentation page.
• The XRPL Developer Portal is an active, high-value ecosystem destination with a substantial developer audience.
• The repository's contribution model supports community documentation contributions.
• No unrelated changes are included in the proposed patch.
• git diff --check and the targeted content/delimiter checks passed.
  I also noted the documented limitation that the full Redocly Realm build could not be completed because the validation environment lacked a valid Plan Gates token. Since the limitation is environmental rather than caused by the proposed change, and the targeted validation passed, I don't consider it sufficient reason to block the submission.
  Internal validation decision: APPROVED.

[Adisaok]

Added a contextual reference to the Chain.Love XRPL API provider directory in docs/tutorials/public-servers.md. The placement is directly relevant to the page's public XRPL server/API infrastructure purpose. Documentation-only change; git diff --check passed. No maintainer reviews yet.

[ArseniiPetrovich]

Locked the discussion as the initial pilot is over. We will analyze the statistics, rewards, update the rules and re-launch the program. I'll keep you posted :)

[EazyHood]

Ecosystem discovery pilot results and program updates

TL;DR

Program is paused for submissions, outreachers will work on existing backlog. Payments will be patched through early next week. Once backlog is cleared, we will restart the intake - follow this thread for further updates. @harunsulaiman is excluded from outreachers list for at least 1 month and can reapply later. We welcome those fulfilling program criteria to join the outreach team and help us with the backlog.

Summary

Our first pilot ran from September 9 to October 9. Thank you to everyone who prepared patches, reviewed proposals, and helped with outreach.

Top three contributors are @zaguzovmaksim0-hue, @zekfer38-netizen and @valimikayilov. First 2 contributors are the only ones who are having their submissions merged externally.
Below is a funnel breakdown.

The pilot funnel

59 patch proposals from 35 contributors → 32 recorded approvals → 19 external submissions → 2 accepted and published placements.

15 external submissions remain open;
1 was rejected;
1 was closed over a technical requirement and needs correction before resubmission.

The publication results are below what we want from the program. The next phase will focus on completing approved work and improving follow-through.

Future of the program

The outreach program submissions intake will be paused for ~1 month, while @Adisaok and @eugene17kotov are catching up with all the backlog they are currently having. We are welcoming more contributors to apply to become outreachers. Then we will restart the program in a slightly modified way (read more below).

Key changes

Submission

Currently it is extremely hard to navigate through this discussion page, so we need to split this program into multiple discussions - GitHub supports Q&A flow that matches our expectations pretty good. Contributors will be asked to post their submissions as a new discussion threads here => https://github.com/Chain-Love/chain-love/discussions/categories/outreach-program-submissions

Outreach approvals

We are seeing now, that out of 40+ submissions approved by our outreachers - only half were actually submitted. For that to not to happen further we introduce a new program rule:

• Outreachers must complete outstanding actions on their approved backlog before approving new contributions.

So, the expected workflow under this program regulations would look the following way:

1. Contributors submit their proposals in https://github.com/Chain-Love/chain-love/discussions/categories/outreach-program-submissions
2. Outreachers select not more than 5 proposals a week to be approved. They may or may not explicitly reject some of the others.
3. Outreachers work on those five contributions throughout the week: refresh patches, complete destination requirements, submit authorized outreach, and address actionable maintainer feedback.
4. At the end of the week/beginning of the next one - submit a PR updating the outreach registry for the five contributions, with external links, accurate statuses, and any blockers or remaining actions.
   Clarification: A submission waiting solely for a destination maintainer does not block new approvals once the outreacher has completed all required actions and recorded its status.

For @Adisaok, the immediate priority is to work through existing approvals, complete outstanding submission and revision steps, and correct the registry. After that, return to the existing unreviewed queue.

Compensation and participation

Fixed monthly compensation for active outreachers increases from $30 to $40 in the next phase. We are not increasing it to $50 or more yet because the publication results are not satisfactory and a subject of review one month later. Compensation remains fixed rather than paid per approval or merge.

Outreachers team

@harunsulaiman is excluded from the program for now because his activity and follow-through fell below expectations. During the pilot, he completed five approvals and four external submissions, compared with @Adisaok’s 27 approvals and 15 external submissions. He may reapply after one month. His unfinished assignments are reassigned to @eugene17kotov and @Adisaok. Obviously, pilot phase payment of $30 still will be paid.

Status

This thread is locked until the Monday for everyone to see the updates. Then I'll unlock it so we can continue the work on the existing queue and review outreach team join request. No new submissions will be reviewed.

[EazyHood]

Thanks, @Adisaok. Here's the Gnosis PR: #4936. As #4750 did for Optimism, it brings the available APIs, regions and security labels on the GetBlock rows in line with what GetBlock publishes for Gnosis, with a source for each value. It also gives the two Enterprise rows a Contact Sales button and removes the three shared-plan archive rows, since GetBlock doesn't offer shared archive nodes on Gnosis. Cronos stays with you.

[EazyHood]

@eugene17kotov, #4633 is live now, so I went ahead with C56 as you said on Oct 21: rsksmart/devportal#589, with its registry row in #4948. The Oct 26 data releases include the fix (json-20261026-184126 was built from 44c26bb, which contains 8eb8529), and https://rootstock.chain.love/toolbox/apis shows the corrected GetBlock and NOWNodes values (checked Oct 29, 19:08 UTC).

One thing for whoever looks after the site: on Oct 29, between about 18:02 and 18:05 UTC, that page's data API (/api/infrastructure-providers/rows?category=apis) went back to the old values for a few minutes (Algorand APIs on GetBlock, MPoolPush on NOWNodes), then returned to the new ones. It was stable in every check after that, but since outreach PRs link these pages, it seemed worth mentioning.

[EazyHood]

@ArseniiPetrovich @eugene17kotov, four things on what's next for my part:

1. Algorand: algorandfoundation/docs#1296 is still open (Eugene's request to close it). The last commit on algorandfoundation/devportal is from Oct 16, so unless it gets new ones, the three devportal proposals fall outside the 4-week activity window on Nov 13. If you'd rather keep that PR open, tell me and I'll let the three contributors know their proposals won't go ahead.
2. Also Algorand: all three proposals link to Chain.Love's Algorand directory, and its API page, https://algorand.chain.love/toolbox/apis, shows 86 "EVM JSON-RPC" rows out of 197 (checked Oct 30). All 86 come from the all-networks listings, for example Alchemy's enterprise plans, on a network without an EVM. Should that hold the Algorand outreach the way the GetBlock/NOWNodes rows held Rootstock, or is it fine once the Algorand-specific rows are right? Five Blockdaemon "Algorand REST" rows also list eth/web3/net. data(algorand): correct availableApis on the Blockdaemon dedicated plans #4819 covers the two dedicated ones, and data(algorand): set native Algod/Indexer APIs on 12 listing rows #4107, open since Oct 2, covers the other three.
3. New destinations: while intake is paused, can an outreacher propose new ones? I've checked four against the registry and this thread: the MCP Servers table in public-apis/public-apis, the Web3 category in marcelscruz/dev-resources, VoltAgent/official-mcp-servers, and the Public Endpoints page on ethereumclassic.org, which already points readers to ChainList and OpenChainBench. Since they'd be my own patches, I'd post each one as a normal proposal for Adisaok or you to review, and whoever approves it would also open the external PR and handle its follow-up, as Eugene set for my earlier patches on Oct 13. The Ethereum Classic one would also wait until its five GetBlock rows, which list Algorand APIs, are fixed and live. If you'd rather keep new destinations for when intake reopens, I'll hold them until then.
4. Optimism: ethereum-optimism/optimism#23458 got the stale label from the repo's bot today ("will be closed in 5 days if no updates") and still has no review. data(optimism): correct availableApis and inherited values on the GetBlock and NOWNodes rows #4750, the Optimism data fix, was merged on Oct 26 after that day's two data releases, so the page the PR links, https://optimism.chain.love/toolbox/apis, still shows Algorand APIs on its 14 GetBlock rows (checked Oct 30). Once a release includes data(optimism): correct availableApis and inherited values on the GetBlock and NOWNodes rows #4750, would one comment on that PR saying the linked page is now correct be OK, or should I let it close and record it as rejected? I wouldn't comment there only to keep it open.

[EazyHood]

@eugene17kotov, an update on item 4 of my Oct 30 note: #4750 is live now. json-20261102-214318 came from this run (first attempt, not a re-run), built from 9e3491ad, which contains the #4750 merge fba9a958. https://optimism.chain.love/toolbox/apis now shows eth, net, web3, WebSocket, GraphQL on the GetBlock mainnet rows instead of the Algorand APIs, and no MPoolPush on NOWNodes (checked Nov 3).

ethereum-optimism/optimism#23458 still has no review, and the repo's stale bot will most likely close it around 04:09 UTC on Nov 4. Without a yes from you I won't comment there. If it closes, I'll record it as rejected with that date, as outreach/README.md defines it, and tell the contributor.

Separately, for whoever looks after the site: https://celestia.chain.love and https://agoric.chain.love have expired certificates (since Oct 30 and Oct 29), and https://zetachain.chain.love/toolbox/apis returns 502 (checked Nov 3). No outreach case depends on them today.

[EazyHood]

@Adisaok, three notes on cases that stay with you, in case they save you time. I haven't touched any of them.

1. gnosischain/documentation#881 shows merge conflicts against its base today (checked Nov 3), so it can't be merged as it stands.
2. Stellar (kingnews2015's proposal), on your Oct 17 question: stellar/stellar-docs CONTRIBUTING.md, under "Promotional and third-party content", says a project that clearly fits a list page can open a PR directly, and stellar/stellar-docs#2950 (Chainstack, merged Nov 2) and stellar/stellar-docs#2822 (node101, merged Sep 8) went into that same page with no linked issue. Both are RPC providers, though. The closer case is stellar/stellar-docs#2761 (OpenChainBench, same page), waiting since Oct 6 on a team decision about linking a third-party ranking there. The page still shows Algorand APIs on its 9 GetBlock rows until Update Getblock & Nownodes for Steller in apis.csv #4862 or Enhance Blockdaemon, Getblock, & Quicknode API Canonical Data #4987 is live.
3. On your Oct 26 question about the stale label on ethereum/ethereum-org-website#19270: that repo's stale workflow closes issues 150 days after the label (days-before-issue-close: 150), so around Mar 13, 2027. Nothing needs doing for that reason now.

[ArseniiPetrovich]

Unlocked the conversation, so we could continue working on existing proposals. Please note that submission intake is still paused and no new intakes will be considered in the meanwhile.

[harunsulaiman]

Dear maintainer @ArseniiPetrovich,

I noticed that I am excluded from the chain.love ecosystem outreach program due less activity in the last month(September).

The month of September 2026 was a very busy month for me and I had to attend to some important events. I wrote my final exams and graduated.

I am writing to seek for a reconsideration on the suspension decision. I am passionate about working on this project and now that I have more time to work, I believe I will do something significant.

I appreciate Your decision to include me in the pilot phase payment. If given the chance, I intend to complete all the external Outreach and approval backlogs of September and still take on the tasks for October. I believe I can do it right now and better.

I really hope you take this into consideration and will be hoping for a postive response.

Faithfully
Harun Sulaiman

[ArseniiPetrovich]

Unfortunately, the decision is final. This program, unlike the others, doesn't have a specific "per outcome" result, and this is why the proactivity is very important here.
Looking forward to see you next month.

[EazyHood]

Hi @ArseniiPetrovich,

I'd like to apply to join the outreach team and help complete the existing proposal backlog, following the October 9 invitation for additional outreachers.

I've been contributing to Chain.Love since June 26. My recent merged database contributions include the Folks Finance TestNet faucet, RedStone Filecoin price feeds, and provider link corrections, all merged on September 29. I also participate in the database validation program.

I've already prepared proposals under this outreach program, including the remote MCP directory proposal, and followed up internally on corrections needed for its external submission. That experience showed me how much the work depends on carrying an approved proposal through the destination's requirements and keeping its status traceable.

If selected, I'd focus on:

• Reconciling assigned proposals, external PRs, and registry entries, with a clear next action for each case.
• Refreshing patches against the destination's current branch and contribution requirements, addressing actionable maintainer feedback, and recording outcomes or blockers accurately.
• Completing outstanding actions before taking on new approvals, while respecting weekly limits, existing ownership, and no-contact restrictions.

I'd be happy to start with a small batch of existing cases assigned by the team, with the scope and status visible in the registry.

Two details I left out above:

• Validation: I joined the validation program (Database validation bounty program #2691) on October 5, and USS-Supervisor has recorded 26 completed assignments for me as of October 12. eugene17kotov has audited 6 of those reviews so far: 5 assessed as approved (though on fix(oracles): clarify Pyth Core integration metadata #4166 he disagreed with my final verdict) and 1, data(filecoin): add Banxa website link and Filecoin-specific restricted geos #4142, not approved, which I re-reviewed after his feedback.
• Conflict of interest: three of my own patches from this thread are still in the backlog (punkpeye/awesome-remote-mcp-servers, solana-foundation/solana-com, ava-labs/builders-hub). I would not review, submit or record any of them myself.

[ArseniiPetrovich]

You are approved to join the team. Feel free to help Adisaok with the current backlog so we could re-enable the program faster.

[williamleewilliam1-star]

Hi @ArseniiPetrovich, following up on my previously approved CryptoToolsDirectory contribution in this pilot (approval October 2, external PR CryptoToolsDirectory/Awesome-Crypto-Tools-Directory#29) and merged Chain.Love PR #4111. I already sent my private payout details to the Chain.Love support contact on October 2. Could you clarify whether either contribution qualifies for contributor compensation under the pilot rules, whether any payment is pending, and who handles settlement? I understand the $30/$40 figures concern active outreachers rather than automatically each merged PR. No payment is assumed. Thank you!

[ArseniiPetrovich]

By the way, I just remembered that when we started we created a Telegram group => https://t.me/chainloveweb3
Feel free to join, it may be easier to communicate things there.
Especially concerned @Adisaok @harunsulaiman and @EazyHood, I think we could use it for better communication.

[Adisaok]

Hi @ArseniiPetrovich, please, why am I restricted on the Telegram group => https://t.me/chainloveweb3

[eugene17kotov]

@Adisaok, are you still experiencing any restrictions in the Chain.Love Telegram group, or has this issue already been resolved?

[Adisaok]

Yes! I'm still restricted.

[eugene17kotov]

@Adisaok, I checked this on our side, and I couldn't find any restrictions applied to your account since your welcome message in the group.
I've made some adjustments to the group settings now that should hopefully resolve whatever was causing the issue.
Please try again and let me know whether you're still experiencing any restrictions.

[Adisaok]

@eugene17kotov it's fine now. Thank you

[ArseniiPetrovich]

Payment batch went out today. Next week we will distribute 2nd batch with all the patches if there are any complaints, and with all the pending rewards for which we will have confirmations. After that all the complaints/patches are going to be scheduled for the payment in November.

[cyzcz]

[eugene17kotov]

Hi @cyzcz, thank you for preparing these proposals and for including the detailed verification results.

We have just updated the program rules and moved new patch submissions to a dedicated category, with one separate Discussion per proposal. The main rules were updated after you posted these patches, so this is only a routing request—there is no need to redo the patches or repeat the checks.

Could you please repost the following three proposals as separate Discussions in the Outreach program submissions category?

• Sagargupta16/awesome-mcp-servers
• yjjnls/awesome-blockchain
• AlexMili/Awesome-MCP

https://github.com/Chain-Love/chain-love/discussions/categories/outreach-program-submissions

You can reuse the existing submission text as-is. Separate Discussions will allow each proposal to be reviewed, answered, and tracked independently.

Thank you for helping us transition to the new workflow, and apologies that the updated routing was not yet visible when you submitted them.

[cyzcz]

[eugene17kotov]

@cyzcz, thank you for preparing this proposal as well.

There is no need to repost the filecoin-project/awesome-filecoin proposal in the new category at this time.

The program allows only one active proposal per destination organization. Chain.Love already has an active external outreach attempt with the filecoin-project organization:

filecoin-project/filecoin-docs#2487

That outreach is still open and is recorded as submitted in the Chain.Love outreach registry. Although your proposal targets a different repository, both repositories belong to the same filecoin-project organization, so we cannot take forward another proposal to that organization while the existing attempt remains active.

This is a temporary eligibility restriction rather than a negative assessment of the quality of your patch. Once the existing outreach reaches a final outcome, a new proposal to the organization may be reconsidered subject to the current program rules and a fresh eligibility check.

Thank you for checking the repository-level history and for preparing the patch carefully.

[eugene17kotov]

New submissions are open again.

The program rules and submission workflow have been updated following the previous intake pause.

From now on:

• each new outreach proposal should be submitted as a separate Discussion in the [Outreach program submissions](https://github.com/Chain-Love/chain-love/discussions/categories/outreach-program-submissions) category;
• please use the pinned [How to submit an outreach proposal](https://github.com/Chain-Love/chain-love/discussions/categories/outreach-program-submissions) guide before submitting;
• new patch proposals should no longer be posted as replies to this program Discussion.

The main post above has been updated to reflect the current rules and workflow.

Thanks everyone — we are accepting new high-quality outreach proposals again.

[EazyHood]

@eugene17kotov, two notes on the 19 proposals cyzcz posted today in Outreach program submissions.

1. Conflict disclosure: Outreach proposal: VoltAgent/official-mcp-servers (Chain.Love MCP) #5104 targets VoltAgent/official-mcp-servers, which I mentioned on Oct 30 as a destination I might propose myself. I never prepared a patch for it and I'm dropping that idea, so I reviewed cyzcz's proposal on its own merits and approved it.

2. Accuracy: five of the proposals report verification results I can't reproduce. Outreach proposal: tolkonepiu/best-of-mcp-servers (Chain-Love/chain.love-mcp in developer-tools) #5124, Outreach proposal: bhavyshekhaliya/awesome-public-mcp-servers (Chain.Love MCP in Developer Tools) #5127, Outreach proposal: fewwwww/awesome-web3-skills (Chain.Love MCP in MCP Servers & On-Chain Data) #5137 and Outreach proposal: JustInCache/awesome-mcp-collection (Chain.Love MCP in Finance & Fintech) #5140 list the npm package @chain-love/mcp as HTTP 200, but it returns 404, and Outreach proposal: wundercorp/awesome-mcp (Chain.Love MCP in Data) #5114 reports a live endpoint at mcp.chain.love, a hostname that doesn't resolve (checked Nov 6). I've rejected those five with the evidence in each thread. The four I approved (Outreach proposal: VoltAgent/official-mcp-servers (Chain.Love MCP) #5104, Outreach proposal: Sagargupta16/awesome-mcp-servers (Chain.Love MCP) #5106, Outreach proposal: yjjnls/awesome-blockchain (Chain.Love Tools Directory) #5107, Outreach proposal: AlexMili/Awesome-MCP (Chain.Love MCP in Finance & Crypto) #5108) I checked independently and they don't contain such claims. Flagging it in case it matters under "Fabricating data in any way"; that call is yours.