Repository navigation
Chain.Love ecosystem discovery bounty program #3731
Replies: 78 comments 257 replies
|
Before preparing a patch, could you confirm two payment/availability details for the pilot?
I will not contact a destination project or open an external PR. This is only a payment-and-availability check before investing work. |
|
|
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. |
|
Patch submission — Fork: https://github.com/EazyHood/awesome-remote-mcp-servers 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`
[](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 Checks run against the destination's contribution rules, all of which its CI enforces on PRs:
One thing the assigned outreacher will need before opening the PR: that repository's 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. |
|
@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, |
|
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. |
|
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. |
|
@EazyHood. The error has been corrected. |
|
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." |
|
Patch proposal for internal review: awesome-algorand/awesome-algorand Fork: Not published; submitting the diff below for internal review. Evidence:
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). |
|
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:
The remaining issue is validation completeness. The destination's 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. |
|
@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:
Once the external PR is opened, please also follow the updated outreach process:
The idea is that minor wording, formatting, or validation fixes should not unnecessarily block an otherwise valid outreach opportunity. |
|
@eugene17kotov, Ok. |
|
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." |
|
Patch for internal review: ahmet/awesome-web3 Fork: Not published; submitting the complete diff below for internal validation. Target: https://github.com/ahmet/awesome-web3 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. |
|
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:
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 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. |
|
@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:
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:
|
|
Hi, @Equinox7379, the prepared patch has now completed the transition from internally validated to externally submitted. |
|
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." |
|
@Equinox7379 Merged confirmed |
|
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 |
|
The pilot is set to be at $30, then we will see depending on the result. |
|
Okay noted. And thank you for welcoming me, my pleasure to be a part. Gracias |
|
Prepared patch for internal review: Fork: https://github.com/edigeh/ethereum-org-website 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:
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. |
|
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:
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 No external outreach should be undertaken independently before authorisation under the Chain.Love ecosystem discovery programme. Thank you. |
|
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. |
|
Ethereum.org: 🟢 External issue submitted → awaiting triage |
|
@Adisaok thanks - I see the external issue has already been submitted, so no additional outreach is needed while it is awaiting triage. Since this is now an active external proposal, please also add it to 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 Of course, if the ethereum.org maintainers suggest a different location during issue triage, please follow their preferred placement. |
|
@eugene17kotov @ArseniiPetrovich "This issue is stale because it has been open 30 days with no activity." What do you suggest? |
|
Yes |
|
Patch submission — Fork: https://github.com/EazyHood/solana-com 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 Destination checks:
On wording: no superlatives, the anchor text is just the product name, and the link is the canonical No PR was opened and no maintainer was contacted, per the program's no-outreach rule. |
|
@harunsulaiman done: you have a pending invitation with Write access to I also brought the branch up to date before handing it over. 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. |
|
Add me as a collaborator i am still not yet a collaborator that is why I cannot push the pr @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 |
|
Thanks @EazyHood pr is submitted @ solana-foundation/solana-com#2191 Will update the registry soon |
|
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." |
|
Prepared patch for internal review: Fork: Not published; the complete diff is included below for internal review.
Patch summary: Adds a runnable example to the existing 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 Validation:
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);
+ });
+}); |
|
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 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 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. |
|
Hi @ArseniiPetrovich, following up on my
Thanks for your help. |
|
"External PR #2669 submitted and awaiting maintainer review." |
|
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.'" |
|
Prepared patch for internal review: Fork: Not published; complete diff supplied below. Target: https://github.com/bekatom/awesome-ethereum Verification (rechecked before this draft):
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. |
|
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. The submission satisfies the pilot's internal review requirements and is approved for the initial review stage. |
|
since i found no external submission for this patch in the registry, i sent the external pr bekatom/awesome-ethereum#103 |
|
Hi @harunsulaiman @Adisaok — follow-up on our internally approved bekatom/awesome-ethereum patch (comment 18384086, approved 2026-09-10).
Thank you — no destination contact from us. |
|
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. |
|
Hi @inunanba, I've taken over follow-up of this submission after the backlog split. To answer your earlier question: |
|
Patch submission — stellar/stellar-docs (official Stellar developer documentation) Fork: https://github.com/kingnews2015/stellar-docs 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:
No external PR, issue, discussion, message, or maintainer contact has been made. This patch is submitted only for internal validation under the pilot rules. |
|
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:
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. |
|
Revision completed. Updated branch: https://github.com/kingnews2015/stellar-docs/tree/docs-chain-love-stellar-toolbox Changes:
Destination workflow evidence: Stellar's Validation:
No external PR, issue, discussion, message, or maintainer contact has been made. |
|
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 |
|
Hi @kingnews2015, thanks for completing the revision. I’ve reviewed the updated comparison, and moving the Chain.Love entry to 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:
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. |
Internal patch submission: Ethereum infrastructure discovery resourceDestination: https://github.com/OffcierCia/DeFi-Developer-Road-Map 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 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) |
|
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. |
|
@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 |
|
@jianqiang8977-create pr is submitted at OffcierCia/DeFi-Developer-Road-Map#175 thanks |
|
@harunsulaiman, please make sure that all outreach proposals you handled during the month are recorded in 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. |
|
@jianqiang8977-create, I've taken over Harun's remaining cases after eugene17kotov's split (#3731 (reply in thread)). The owner closed |
|
Patch submission — Fork: https://github.com/EazyHood/builders-hub 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 Destination checks, measured rather than assumed:
Every number on the page comes from the Avalanche deployment's own public endpoint, so a reviewer can re-derive them: 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 The two No PR was opened, no issue filed, and no maintainer contacted, per the program's no-outreach rule. |
|
@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 This outreach should only be treated as resolved once the destination reaches a final decision on the corrected submission. |
|
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 My prepared branch remains available here: 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. |
|
@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? |
|
@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? |
|
@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? |
|
Patch submission — filecoin-project/filecoin-docs (Filecoin JSON-RPC reference) Fork: https://github.com/Airmaliel/filecoin-docs 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:
Reward address: 0x9db622fda1f74d77674344b4b199dbb21ddd947e (USDC/USDT on Ethereum mainnet) AI-assisted patch; claims and links were checked against the live destination and directory. |
|
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:
The proposed 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 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. |
|
Hi, @Airmaliel, thank you for your contribution. Your prepared patch has completed the transition from internally validated to externally submitted. |
|
External PR #2487 submitted and still awaiting maintainer review. |
|
Patch submission — Fork: https://github.com/zaguzovmaksim0-hue/awesome-web3-data 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:
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. |
|
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:
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.
The reported 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 No external outreach should be undertaken independently before authorisation under the Chain-Love ecosystem discovery programme. Thank you for the thorough work. |
|
Hi @zaguzovmaksim0-hue, external outreach has been successfully submitted as PR #32. |
|
Merged into main; the maintainer thanked the contributor. |
|
Patch submission — Fork: https://github.com/jiaruihz/docs Diff: ton-blockchain/docs@main...jiaruihz:docs:docs/add-chain-love-ton-directory Destination fit:
Verification:
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. |
|
Hi, @jiaruihz, Thank you for the detailed submission for ton-blockchain/docs.
|
|
External PR #2336 submitted and awaiting maintainer review. |
|
Patch submission — Fork: https://github.com/jiaruihz/starknet-docs Diff: starknet-io/starknet-docs@main...jiaruihz:starknet-docs:docs/add-chain-love-starknet-directory Destination fit:
Verification:
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. |
|
Hi @jiaruihz, thanks for the submission, and sorry for the wait. Internal review What passed:
Why it isn't going out now:
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). |
|
Patch submission — Fork: https://github.com/jiaruihz/documentation-en Diff: tronprotocol/documentation-en@master...jiaruihz:documentation-en:docs/add-chain-love-tron-directory Destination fit:
Verification:
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. |
|
Hi @jiaruihz, thanks for the submission, and sorry for the wait. Internal review What passed:
Why it isn't approved:
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. |
|
Patch submission — Fork: https://github.com/jiaruihz/xrpl-dev-portal Diff: XRPLF/xrpl-dev-portal@master...jiaruihz:xrpl-dev-portal:docs/add-chain-love-xrpl-directory Destination fit:
Verification:
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. |
|
Hi @jiaruihz,
|
|
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. |
|
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 :) |
Ecosystem discovery pilot results and program updatesTL;DRProgram 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. SummaryOur 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. The pilot funnel59 patch proposals from 35 contributors → 32 recorded approvals → 19 external submissions → 2 accepted and published placements. 15 external submissions remain open; 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 programThe 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 changesSubmissionCurrently 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 approvalsWe 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:
So, the expected workflow under this program regulations would look the following way:
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 participationFixed 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. StatusThis 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. |
|
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. |
|
@eugene17kotov, #4633 is live now, so I went ahead with C56 as you said on Oct 21: One thing for whoever looks after the site: on Oct 29, between about 18:02 and 18:05 UTC, that page's data API ( |
|
@ArseniiPetrovich @eugene17kotov, four things on what's next for my part:
|
|
@eugene17kotov, an update on item 4 of my Oct 30 note: #4750 is live now.
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. |
|
@Adisaok, three notes on cases that stay with you, in case they save you time. I haven't touched any of them.
|
|
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. |
|
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 |
|
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. |
|
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:
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:
|
|
You are approved to join the team. Feel free to help Adisaok with the current backlog so we could re-enable the program faster. |
|
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! |
|
By the way, I just remembered that when we started we created a Telegram group => https://t.me/chainloveweb3 |
|
Hi @ArseniiPetrovich, please, why am I restricted on the Telegram group => https://t.me/chainloveweb3 |
|
@Adisaok, are you still experiencing any restrictions in the Chain.Love Telegram group, or has this issue already been resolved? |
|
Yes! I'm still restricted. |
|
@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. |
|
@eugene17kotov it's fine now. Thank you |
|
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. |
|
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?
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, thank you for preparing this proposal as well. There is no need to repost the The program allows only one active proposal per destination organization. Chain.Love already has an active external outreach attempt with the filecoin-project/filecoin-docs#2487 That outreach is still open and is recorded as 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. |
|
New submissions are open again. The program rules and submission workflow have been updated following the previous intake pause. From now on:
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. |
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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:
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:
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:
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:
Technical integrations
The following may also be eligible:
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:
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:
Do not open a pull request to the destination repository.
The patch should:
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:
Outreachers may:
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:
submitted.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
blockedaccording to the registry rules.When the destination submission is resolved, the outreacher must:
mergedorrejected.The
status_datemust 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
commentfield using theDO_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:
Destination maintainers may:
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:
The list of approved outreachers will be public. Chain.Love may accept, reject, suspend, or remove outreachers based on their performance.
Current approved outreachers:
@harunsulaimanOutreachers are compensated $40/month - through a fixed monthly arrangement rather than per approval, PR, or merge.
Outreachers compensation does not increase based on:
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:
Abuse and penalties
The following will result in zero compensation:
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.
All reactions