Targeted RFP: Cosmos Hub Sponsored Endpoint Provider

Conversation Validation
1

Background

The ICF Ecosystem Growth Delegations tranche is an application-only part of the ATOM delegation program designed to advance key ecosystem initiatives and support critical infrastructure. Targeted RFPs allow the program to identify a specific need, define service standards, and invite qualified operators to propose how they would deliver it.

Why this service matters

Teams building on the Cosmos Hub need public RPC, API, and gRPC endpoints they can rely on while they develop, test, and integrate. Most public Hub endpoints are run voluntarily by validators and community operators. Those contributions remain valuable, but voluntary availability does not guarantee consistent uptime, documented capacity, WebSocket support, or complete transaction indexing.

This service is for builders, testers, and integrators trialing the Hub, including wallets, explorers, analytics tools, and exchanges testing an integration before committing to a paid provider. It is not intended to be an enterprise endpoint service. It gives these teams a dependable, documented starting point with guaranteed capacity, real-time data, and complete indexing of recent blocks.

This RFP is not intended to replace community providers or sponsor every existing endpoint. It will select one provider to operate a sponsored endpoint service under the standards below. Community-operated endpoints can continue to provide additional options and redundancy.

Required scope

The selected provider must:

  1. Provide public interfaces. Provide RPC with WebSocket, API, and gRPC for cosmoshub-4 over TLS, with no API key and with CORS, including OPTIONS preflight, enabled for browser apps. gRPC must return canonical status codes.
  2. Run a highly available service. Run at least two synced nodes behind a height-aware load balancer that removes nodes more than 3 blocks behind, and maintain 99.9% monthly availability outside network-wide chain halts. Client affinity, for example by IP hash, is recommended so repeated queries and sequential transactions from the same client reach the same node.
  3. Guarantee per-client capacity. Rate limiting is recommended. Limits must not throttle a client IP below 10 requests per second sustained with bursts to 50; 5 per second for tx_search, block_search, block_results, and API transaction search; 5 WebSocket subscriptions; and 1 transaction broadcast per second.
  4. Guarantee shared capacity. Sustain at least 100 requests per second across all clients, including 20 per second of the search calls above. Document your rate limits and return HTTP 429 with Retry-After, or RESOURCE_EXHAUSTED for gRPC, when a client exceeds them.
  5. Keep recent history. This is a pruned service, not an archive. Every node serving traffic keeps at least 1 day (about 15,000 blocks) of blocks and transaction index.
  6. Index every event. Set indexer = "kv" in config.toml and leave index-events empty in app.toml so every event is indexed across the retained window.
  7. Serve real-time data. Stay within 3 blocks of the network head, including any cached responses, and deliver WebSocket block and transaction events within 10 seconds of each block.
  8. Keep up with upgrades. Upgrade alongside your validator, ideally serving the first block after the upgrade height and no later than 300 blocks (about 30 minutes) after it.
  9. Monitor and communicate outages. Monitor every interface from an external location, alert your on-call operator when a check fails, and notify the service contact within 12 hours of detecting an outage, including the known impact and an estimated restoration time. Automated outage reports are welcome.

What to include in your proposal

Proposals should include:

  • Whether your team can meet every service requirement above.
  • Any requirements your team cannot meet, with an explanation of the limitations.
  • How you will enforce the capacity requirements, for example with HAProxy or nginx limits.
  • The setup work, infrastructure, and ongoing maintenance needed to operate the service.
  • The expected time needed to make the service available.
  • Relevant experience operating Cosmos Hub or other production infrastructure. Prior public endpoint experience is not required.
  • The additional ATOM delegation amount required to provide the service, above any default-tranche delegation for which the applicant qualifies.

One provider will be selected. Applicants do not need existing endpoints. Applicants must submit their proposal, including the proposed additional delegation amount, privately through the Ecosystem Growth Delegation application form.

For this RFP, applicants should propose only the additional ATOM delegation needed to operate the service, rather than their total combined delegation. Any delegation awarded through this RFP will be provided in addition to any default-tranche delegation for which the selected provider qualifies.

Proposals will be reviewed for their ability to meet every service requirement above, then compared primarily on the proposed additional delegation amount, along with operational experience and launch timing.

Please do not build the service or purchase infrastructure before selection. The selected provider builds the service after the award, and the delegation begins with the first quarterly delegation round after the delivered service has been tested and meets every requirement. The award runs for four quarterly rounds from the round it starts in.

How to apply

Submit the standard Ecosystem Growth Delegation application form and reference “Cosmos Hub sponsored endpoints” in the project title or project description.

For context on the broader program, read the ICF delegation program framework announcement.

1 Like
Active Ecosystem Growth Delegation RFPs