.svg)
We recently outlined the 2026 Strategy and the Foundation Operational Stack, making our direction clear: true decentralization is more than consensus alone, it’s the entire operational stack.
For a network to be resilient, it cannot rely on a single entity, including the Foundation, to host the infrastructure that allows users to interact with the ledger in a low friction way. We are now preparing the transition of critical auxiliary services to community and commercial operators.
The first step of this is opening Requests for Proposal (RFPs) for three core components: the Babylon Gateway, the Signalling Server, and the Connect Relay.
These are not grants for new experiments. These are contracts for experienced infrastructure operators to run the production-grade plumbing that powers the Radix Wallet, Dashboard and many other ecosystem services.
Here is the breakdown of the services and what is required.
Babylon Gateway
The Context: The Gateway is the entry point for almost all user-facing applications. It aggregates ledger data into a queryable PostgreSQL database and provides the API that wallets and explorers rely on.
The Requirement: We are seeking 1 or more operators to replace the current Foundation-run Gateway as a default provider.
- Scale: Must handle the current ~2TB database with monthly growth of ~60GB.
- Availability: Target 99.9% uptime. The current setup uses a Blue/Green deployment strategy to handle schema updates and re-indexing without downtime.
- Performance: <1s latency for standard queries, serving a global user base.
This is a heavy-lift role. It requires significant storage, robust DDoS protection, and the ability to manage complex database migrations without breaking service for the ecosystem.
Read the Babylon Gateway RFP on Radix Talk: https://radixtalk.com/t/foundation-rfp-babylon-gateway/2202
Signalling Server
The Context: This is the "matchmaker" for the Radix Wallet. It establishes the peer-to-peer WebRTC connections between the mobile wallet and the desktop Chrome connector. It does not touch private keys or transaction payloads; it simply introduces peers.
The Requirement:
- Speed: <300ms global latency is critical for the "instant" feel of Radix Connect.
- Privacy: Strict "untrusted relay" principle. No payload inspection, no logging of encrypted data.
- Architecture: Stateless design backed by Redis for session management. Must handle roughly 6,000 concurrent peak connections.
Read the Signalling Server RFP on Radix Talk: https://radixtalk.com/t/foundation-rfp-signalling-server/2204/1
Connect Relay (RCR)
The Context: The Relay supports mobile-to-mobile connection between a mobile web browser and the Radix Wallet app. It buffers encrypted messages between the browser and the wallet.
The Requirement:
- Throughput: Efficient handling of small, encrypted payloads (instructions between browser and mobile).
- Security: Aggressive rate limiting and TTL (Time-To-Live) settings (600s) to mitigate spam/DDoS while ensuring message delivery.
- Privacy: Like the Signalling Server, this must operate as a blind relay. End-to-End Encryption (E2EE) is mandatory; the server must never see the raw data.
Read the Connect Relay RFP on Radix Talk: https://radixtalk.com/t/foundation-rfp-connect-relay/2203/1
The Importance of P1 RFPs
These RFPs are the next logical step in the 2026 Strategy to decentralize the Radix network stack:
- Removing Central Reliance: We are systematically removing the Foundation as the default provider for auxiliary services as we move to a community-led model.
- Community-Led Operations: We are transferring control to the community. By engaging specialized operators, we ensure these services are maintained by those with the dedicated focus and expertise to run them sustainably.
Any successful proposal must guarantee the current usage levels for core "public good" services like the Radix Wallet and Dashboard. However, we are interested in sustainable economic models that go beyond simple hosting.
We explicitly encourage proposals that commercialize access for additional heavy consumers, such as data aggregators, established dApps, or institutional integrators, to offset costs for the broader community. If you can monetize high-volume access to subsidize the public good, that is a win for the network.
If you have the hardware, the team, and the operational maturity to handle production traffic for a Layer 1 protocol, we want to see your proposal that we can present to the Radix Community to become a default provider for these services.
Review the technical specifications in the PDFs above and submit your proposal on RadixTalk using these links:
