Radix Infrastructure RFPs

Overview

In February 2026, the Radix Foundation issued three Requests for Proposals (RFPs) to hand off the operation of core network infrastructure to community operators. The three services — the Babylon Gateway, the Signalling Server, and the Connect Relay — have been operated centrally by the Foundation and are now being decentralized as part of the broader drive to reduce single points of failure in the Radix ecosystem.

Operators who submit successful proposals gain the right to run these services commercially, with the ability to charge heavy users while subsidizing or providing free access for public goods such as the Radix Wallet and Dashboard.

Babylon Gateway

The Babylon Gateway is the primary API endpoint used by wallets, dashboards, dApps, and developer tooling to query ledger state. It indexes the Radix ledger into a PostgreSQL database and exposes a REST API.

Technical requirements per the RFP:

• 2 TB PostgreSQL database (current size); ~60 GB/month growth rate
• Query latency under 1 second for 99th percentile
• 99.9% uptime SLA
• Full indexing from genesis to current ledger tip
• Public API endpoint accessible to all Radix ecosystem participants

Operators may charge enterprise or heavy-volume users for access while providing free-tier access for the Radix Wallet, Radix Dashboard, and other public infrastructure. Proposals are submitted via RadixTalk with technical specs provided on Google Drive.

Signalling Server

The Signalling Server facilitates WebRTC peer-to-peer connection establishment between the Radix Wallet and dApps (the Radix Connect protocol). It is stateless except for in-memory session state held briefly during handshake.

Technical requirements per the RFP:

• Global latency under 300 ms (P95)
• Stateless architecture with Redis for ephemeral state
• ~6,000 concurrent connections at peak
• No payload inspection — the server relays encrypted messages only
• DDoS mitigation at the network layer

The Signalling Server handles no user data beyond ephemeral session tokens and encrypted payloads it cannot read. This makes it a suitable service for community operators to run with minimal privacy risk.

Connect Relay

The Connect Relay provides persistent message delivery for the Radix Connect protocol when direct WebRTC connections cannot be established (e.g., strict NAT environments). Messages are encrypted end-to-end and stored temporarily until delivered.

Technical requirements per the RFP:

• Encrypted payload storage with 600-second TTL
• DDoS mitigation
• Message delivery guarantees with retry logic
• No ability to read message contents (end-to-end encrypted)

Like the Signalling Server, the Connect Relay processes only encrypted payloads. Operators gain no access to transaction contents or user identity — making this infrastructure suitable for trustless community operation.

Why Decentralize Infrastructure?

Centralised infrastructure creates single points of failure and trust. If the Foundation's Gateway goes offline, the Radix Wallet and all Foundation-operated dApps lose ledger access. If the Signalling Server is unavailable, wallet-to-dApp connections cannot be established.

By distributing these services to multiple independent operators, the ecosystem gains resilience. Multiple Gateway operators mean no single downtime affects all users. Community operators have commercial incentives to maintain high availability — failure costs them revenue from enterprise customers.

The RFP model gives operators clear technical requirements and commercial rights while giving the Foundation a structured way to evaluate proposals against security, reliability, and decentralization standards.

External Links

• Radix Blog — Infrastructure RFP announcement (Feb 3, 2026)
• RadixTalk — Proposal submission forum
• Radix Foundation