Read our whitepaper

Abstract

The rapid growth of blockchain ecosystems has led to significant fragmentation in the Web3 services. Each network today maintains its own collection of service providers—RPCs, indexers, oracles, explorers, bridges—often exposed through inconsistent APIs, formats, and documentation. This decentralization of access points, while aligned with Web3 principles, imposes practical barriers on developers and DevRel teams who must manually discover, test, and maintain connections across multiple providers and chains, wasting time on integration rather than innovation.

Chain.Love introduces a unified Web3 services layer that standardizes discovery, access, and accountability of blockchain services across ecosystems. It combines four modular components:

1. Toolbox for Chains, a registry and comparison hub that aggregates provider metadata and exposes it through embeddable interfaces and APIs;

2. Performance Module, which measures and verifies provider performance using EigenLayer’s Actively Validated Services (AVS), load-balancing the RPC requests

3. API Management Module – A full-featured API gateway that handles request routing, load balancing, caching, authentication, and usage monitoring.

4. Chain.Love Rewards (planned) – A reward mechanism designed to reimburse dApp creators with the accumulated Gas Fee spent by dApp consumers.

The system is blockchain-agnostic and is already integrated with networks such as Arbitrum, Ethereum, Filecoin, Base and more. It aims to provide the same level of transparency and automation for Web3 services that DNS and CDN systems provide for Web2 — while maintaining decentralization, verifiability, and interoperability.

Problem Statement

Developers building on new or emerging blockchains face a fragmented and inefficient Web3 services landscape. Key challenges include:

1. Fragmented Discovery: Each blockchain publishes separate (often outdated) documentation linking to service providers (Indexers, Oracles, Bridges, etc.). There is no unified registry or consistent metadata describing provider capabilities, pricing, or uptime.

2. Lack of Verifiable Performance: Developers and networks cannot easily verify whether providers deliver promised uptime, low latency, or reliability. Any uptime guarantees or SLA agreements are typically off-chain and opaque, reducing trust and accountability.

3. Manual Load Management: Applications must implement their own health checks and failover logic to maintain stability. Without objective metrics, routing between providers is often random or hardcoded. This leads to service interruptions and inefficient use of resources.

As blockchain ecosystems mature, this fragmentation limits scalability and discourages ecosystem growth. Developers lose time on non-core operations, while users experience inconsistent reliability even within the same chain.

A standardized and trusted service layer, capable of objectively verifying provider performance, is required to bridge these gaps.

System Overview

Figure 1: Chain.Love system context diagram, showing Chain.Love as a unified gateway between multiple blockchain service providers and developer applications.

Chain.Love provides a unified, modular gateway for discovering, consuming, and verifying Web3 services. It sits as an intermediary between blockchain service providers (e.g. RPCs, indexers, oracles) and consumers (developers, networks, and applications). By standardizing communication and accountability, Chain.Love enhances reliability without replacing existing providers.

Below, we describe each of the key 4 modules in detail, including its subcomponents and how they interact to provide a seamless developer experience.

1. Toolbox for Chains

The Toolbox for Chains is a blockchain-specific registry that aggregates all public and private service providers into a consistent, queryable catalog. This component addresses the discovery problem by serving as a one-stop directory for Web3 services on a given chain. Key features include:

• Unified Provider Metadata: It stores normalized metadata for providers – endpoints, geographic regions, pricing plans, rate limits, health status, supported API types (JSON-RPC, REST, GraphQL, etc.), and more. This data can be modified and curated by the community, ensuring information stays up-to-date. By consolidating provider information, the Toolbox ensures visibility and comparability. Developers can quickly compare providers before integrating them.

• Embeddable Data Access: The registry exposes this provider data in multiple formats. Developers can query it via JSON files/API, or networks can embed interactive widgets into their documentation sites (e.g. GitBook, Docsify) to display real-time provider info.

• Co-Branded Deployments: The Toolbox can be deployed under a network’s own domain with co-branding. This preserves the ecosystem's identity while still leveraging Chain.Love’s unified platform.

In summary, Toolbox for Chains simplifies the previously fragmented discovery process into a single reliable source of truth for service endpoints on each chain.

2. Performance module

Figure 2: Performance module context diagram

The Performance Module leverages EigenLayer’s Active Verification Service (AVS) to serve as a reliability and verification layer. Module acts as a control panel for developers to subscribe to Web3 services, monitor performance, and use financial leverage to motivate service providers to comply with an adjustable set of performance metrics. Developers can configure which endpoints to route their requests to, how to distribute load between them, and which endpoints to use as a failover.

Key entities and components in the Performance Module include:

Figure 3: EigenLayer usage explained

Monitoring Operator

• An independent entity (usually staking service provider, node operator, or institutional validator) who re-stake ETH (or LSTs like stETH, rETH, etc.) and run Actively Validated Services (AVSs) to secure additional networks, protocols, or applications on top of Ethereum.

• Scripts are open-source, so anyone could verify the methods used for tracking, and also modify it to add custom API verification, shall they need it. This way, Chain.Love allows tracking not only existing blockchain JSON-RPC, REST and Subgraphs health, but any API in the Web2/Web3 world.

• Submits signed proofs to the Upstream Health Proof Store.

Upstream Health

• Aggregates monitoring data from multiple operators.

• Normalizes and reconciles health proofs.

• Publishes data to Upstream Health DB and Upstream Health Proof Store.

Upstream Health DB

• Persists configuration of monitored targets.

• Stores a history of the Health statuses for analytics purposes.

Upstream Health Proof Store

• Temporarily stores proofs pending consensus. Because proofs themselves are duplicated on the Smart Contract level (see below), the Proof Store only needs to hold them short-term.

Smart Contracts

• Chain.Love utilizes smart contracts on Ethereum (L1, as required by EigenLayer) and potentially a Layer 2 to enforce the performance incentives logic:

  • L2 Contract – stores proof-history and evaluates consensus on provider performance. Relayer (see below) is used to pass data from L2 to L1.

  • L1 Ethereum Contract – Serves as the source of truth for SLA configuration and final verified uptime states. It triggers reward distributions or penalties based on performance. For example, if a user has claimed that “if the provider provides 99% uptime, I’ll pay him $100” and the provider fails to provide said uptime, the user can trigger a contract to initiate consequences (not awarding or partially awarding the provider with rewards).

  • EigenLayer – distributes rewards between monitoring operators and service providers.

Relayer

• Forwards updates from L2 smart contract to L1 smart contract, triggers consensus on L2 smart contract (in theory, both contracts could live on the same network, but this is economically impractical for the intended design. Using an L2 helps reduce costs for frequent updates, while the L1 provides finality and broad visibility).

Notifications

Intended to keep both consumers and operation teams informed in real time when a provider’s status changes, Chain.Love notifications include:

• Telegram Bot provides target health status updates to the subscribed user.

• Uptime Status Widget*:* An embeddable widget that can be placed on a dApp to display the live health status of that service.

Using the Performance Module, developers can verify uptime compliance and automate decisions (like switching providers) when performance drops. This brings trust and transparency to Web3 services, as all parties can rely on on-chain verified performance data rather than just verbal promises or off-chain agreements.

3. API Management Module

API management module is a comprehensive gateway that allows API providers (Blockchain node providers, dapps, or entire networks) to publish and maintain REST, JSON-RPC, GraphQL, Websocket and any other custom API at any scale. It provides developers with a unified access point for interacting with these APIs at scale, while giving providers fine-grained control over how their API is consumed. This module handles everything from request routing and load balancing to authentication, rate limiting, and analytics.

In practice, the API Management Module functions much like a modern API gateway, but tailored for Web3 needs. It allows configuration of custom routing, caching layers, security policies, pricing plans, and it manages the full payment lifecycle and usage monitoring for paid API services.

Core components of the API Management Module include:

UI

• A web-based dashboard where users (both providers and consumers) can manage their services.

• Displays analytics, subscription details.

• Sends requests to backend services (auth, proxy, statistics, etc.)

Auth

• Handles authentication using provided inputs.

• Issues and verifies session tokens for API access.

• Validates user identity before interacting with restricted endpoints.

• Verifies rate-limiting of the requests

Subscription

• Manages user plans, service entitlements and payment statuses.

• Communicates with DB API and Statistics to evaluate subscription limits and usage metrics.

Proxy

• The Proxy is the core request routing gateway through which all API calls pass

• Interacts with other services to perform authorization, payment checks, statistics writes, etc. Caches responses from these services if necessary.

• Responsible for forwarding users’ request to one of the backend provider endpoints

• Caches certain RPC requests (configurable) and Authorization status (to reduce latency). That leads to the fact that users may execute a few more requests than expected before hitting rate limiting, but this comes as an expected trade-off between latency and strict limitations.

• Modifies the request according to the configured set of middlewares.

Middlewares

These are extension points in the Proxy that allow custom processing of requests or responses. Middlewares can be a part of a proxy, or a separate service. That depends on API priorities - for extremely quick responses we minimize the network traversal.

API Controllers

• Specialized middlewares or extensions that handle specific API patterns or protocols. Examples:

  • Custom Graph controller:

    • Reflects factual state of managed subgraphs in the application database (so we can attach owning user, subscription ID and other app data to it later)

    • Controls versions of the subgraphs

    • Proxy the user-issued requests to restart, rewind or perform any other relevant action over the subgraph.

  • Custom EAS controller: Provides API to interact with the Ethereum Attestation Service.

Delegation middleware

• Delegates certain tasks or checks to other services. For instance, a delegation middleware might call out to the Auth service, Subscription service, or Statistics service to validate something about the request (like checking if the user has enough credits or logging the request asynchronously).

Transformer middleware

• Transforms requests and responses according to the configuration provided. Adds, deletes or modifies:

  • Headers

  • Path

• Sets proper CORS headers for the responses to ensure we avoid errors.

• Can redirect or mirror certain RPC requests to the separate set of endpoints. Useful for the blue-green deployment strategy and for using several blockchain clients under the hood where one of them may be more effective in certain things than the other.

Load Balancer

• Fetches health information from the SLA Layer.

• Ensures high availability by avoiding unresponsive or degraded endpoints.

• Distributes incoming requests among healthy backend targets.

Cache

• Stores recently fetched RPC and Graph API responses.

• Reduces latency and load on backend infrastructure.

Statistics

• Aggregates usage data from Subscription service.

• Stores metrics in Statistics DB (InfluxDB).

• Exposes metrics to UI and External API for analytics.

External API

• Exposes a public JSON RPC interface for end users. End users are able to programmatically monitor their API usage and generate query keys.

  • For instance, a developer could write a script to automatically alert when their app is nearing a subscription limit by querying this API.

DB API

• The internal data management interface.

• Provides unified access to the application database.

Cron

• A scheduler service that handles periodic tasks and maintenance. For example, cron jobs periodically prune users pending deletion, reset free-tier credits at the start of each billing cycle, or perform other routine housekeeping tasks to keep the system running smoothly.

Together, these components of the API Management Module give developers a seamless experience: they get a single endpoint to interact with multiple endpoints or even providers, and the platform handles behind-the-scenes tasks like auth, billing, performance optimization, and failover.

Conclusion & Future Work

Chain.Love began as a collection of independent Web3 tools and evolved into a unified ecosystem under the Chain.Love domain. It combines years of operational experience with a clear, forward-looking vision for the Web3 services space. By standardizing how services are discovered, monitored, and consumed, Chain.Love lowers the barrier for developers entering new blockchain ecosystems and improves reliability for end users.

Looking ahead, our next milestones focus on expanding functionality and deepening ecosystem integration:

• Chain.Love Rewards – a forthcoming module that enables blockchain networks to reward dApp creators proportionally to the gas fees spent by their users.

  • This creates a feedback loop where popular dApps (which drive network usage) get compensated, encouraging further development and adoption.

• Guidance Module – an interactive onboarding layer that helps users navigate the Web3 ecosystem to set a sustainable developer pipeline.

  • As a part of this module we plan to introduce a UI-based way to contribute into our open-source database.

• Unified Dashboard – a marketplace-style interface for managing purchased services, plans, and providers in one place.

  • This involves a modular system allowing service providers to automate user onboarding through the Chain.Love ecosystem.

• Transparent Review System – A mechanism for open, verifiable feedback on Web3 service providers. By allowing developers to leave reviews or ratings—backed by on-chain verification that they actually used the service—Chain.Love can reinforce trust and accountability. Providers will gain reputational incentives to maintain quality, and users will have an easier time choosing trustworthy services.

Chain.Love is continuously growing as a unifying service layer for Web3 — bridging networks, developers, and service providers through transparency, automation, and shared incentives. By focusing on practical solutions and developer-first design, Chain.Love aims to accelerate the growth of the Web3 ecosystem and foster a more connected, reliable infrastructure for everyone.

Appendix

Figure 4: Services break-down of Chain.Love (detailed view)

Figure 5: Services break-down of Performance Module