Closed Agreements for RPCs

SubQuery Mainnet Node Operators
,
1

Hello Node Operators!

We are excited to share insights into our selection process for Closed Agreements for RPCs. Below are the key details:

Selection Process:

  • The selection of Node Operators for Closed Agreements is based on availability and performance during the previous 14-day Closed Agreement period.
  • Diversity is encouraged, favoring Node Operators who have not yet secured Closed Agreements.
  • Our team will announce the selection for each period, providing transparent data supporting the decisions made.
  • The selection process will be conducted across three primary regions: U.S, EU, & Asia.

Closed Agreement Details:

  • The currently enabled template runs for a 14-day period, with a daily request cap of 2 million and a rate limit of 250 requests per second.
  • Node Operators will be selected based on availability, performance/capacity metrics and diversity consideration.

Performance Metrics:
Node Operators will be evaluated based on availability and latency scores, performance in benchmark tests, and evidence of running nodes locally. Details here.

For Node Operators who have not secured Closed Agreements, they may still be incentivized via

  • Traffic may still be routed to operators not selected if the primary operator faces issues or exceeds specified caps.
  • Node Operators who have not secured Closed Agreements still have the chance to win in future selection rounds.

Thank you for your dedication and commitment to the SubQuery Network. Should you have any questions or require further clarification, please do not hesitate to reach out.

=======================================================
Current RPC Closed Agreement Status
Last Update: 18 Apr 2025

Autonity Piccadilly Archive Node (Active)
Darwinia Archive Node (Inactive)
Gnosis Chain RPC - Archive Node (Inactive)

=======================================================

7

For the Performance Metrics, SubQuery uses a variety of methods to assess and decide what Node Operators receive a fortnightly agreement for a given project deployment, primarily we rank Node Operators on a combination of two factors:

  • Historic response time and availability - we assess this by sending a variety of RPC requests to each node operators at a semi regular interval, measuring the average response time of a consecutive number of tests
  • Node operators score - this is a synthetic score that we determine that considers:
    • How up to date the versions of the Indexer Services that the Node Operator runs
    • The price of the Node Operator’s advertised flex plan
    • If the Node Operators has enabled SSL and has an ENS domain registered
    • The number of delegators of the Node Operator

We also use a specialised test to establish if the Node Operators are in fact running a local node, or if they are simply forwarding requests off to a third party RPC endpoint. This is to prevent us from selecting any Node Operators that are primarily forwarding RPC requests. This test uses a number of different items to assess, including a fingerprint of the RPC endpoint, and the metrics endpoint that the RPC runner provides. In the near future, RPC runners will be required to provide a metrics endpoint in order to pass this test.

2 Likes