RADIX WikiRADIX Wiki

Overview

In February 2026 the Radix Foundation issued three Requests for Proposals (RFPs) asking outside operators to take over infrastructure it had always run itself: the Babylon Gateway, the Signalling Server and the Connect Relay. The Foundation was handing its responsibilities to the community ahead of winding itself down, and its map of that transition labels these three P1 services. By the end of April all three had moved to a standalone operation run by the engineers who had operated them inside the Foundation, pre-funded by the Foundation to the end of December 2026.

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.

Proposals and Status

The RFPs were posted to the RadixTalk governance forum on 3 February 2026 by Foundation representative Adam_XRD, alongside a blog announcement the same day. On 18 March 2026 the three individual service threads were merged into a single P1-architecture discussion, reflecting a decision to evaluate the services together as one operational stack rather than awarding them piecemeal.

Four proposals were tabled across that discussion and its companion RFC, spanning a wide range of scale and cost:

  • Community takeover (Michael, 9 February 2026): an RFC rather than a bid, sketching a decentralized, community-led operation in which no single entity holds the whole stack: pools of gateway servers all serving traffic at once, rotated out of the active pool one at a time for upgrades so that maintenance never takes the service down.
  • Shambu Pujar and Marek Karwacki (27 February 2026): the Radix Foundation DevOps team who already run the services, proposing to operate all three as a standalone operation: the PostgreSQL database and Kubernetes cluster on AWS, the Radix full nodes on OVH, blue/green deployment so that upgrades and full ledger resyncs happen with no user-visible downtime, and the relay and signalling server as add-on workloads on the same infrastructure. Production-ready within five to eight weeks of a project start.
  • mountaintop (1 March 2026): the low-cost end: around €300–400 per month for the full Gateway and roughly €100 for the relay and signalling server, about €500 per month for the entire P1 stack, charging nothing beyond server costs and funding them by asking the community to stake to and donate from his validator. The design is Hetzner bare metal, with two AX42-U servers for a primary and standby PostgreSQL instance with Patroni failover, plus a storage box for continuous backup, and maintenance handled by a volunteer on-call rotation.
  • LinkPool (23 and 28 April 2026): the only commercial infrastructure operator to bid, running Web3 infrastructure since 2017 from a cluster across three availability zones in Manchester, with Chainlink, Lido DVT and several foundation delegations as existing clients. It offered a 99.99% target SLA against the RFP's 99.9% floor, with blue/green and canary rollouts and offsite backup included in an operating retainer.

The forum never reached a decision of its own. Adam_XRD had said at the outset that the community would vote on the proposals, but the body meant to hold that vote did not exist yet. When LinkPool offered to walk the Foundation through its pricing, Magal36 replied on 25 April that "the foundation won't be your customer, as it's dismantling, the community DAO is", and on 27 April named the sitting members of the Radix Accountability Council as the people to coordinate with, and described the position as a limbo in which "these kinds of decisions are being taken very slowly". Several participants had raised the same concern in February: that a multi-year infrastructure contract signed before the DAO exists binds a community that never chose the operator, and that any award should carry break clauses for the eventual Xi'an rebuild.

The decision came from the Foundation instead. On 28 April 2026, in the post announcing its move to maintenance mode, it wrote that all three services had transferred to a standalone operation run by its previous DevOps team, on the pricing, service-level commitments and operating terms of the proposal Shambu Pujar and Marek Karwacki filed in February, and that it had pre-funded that operation through the end of December 2026. Because the same team was already running the services, the Foundation wrote, there was no handoff to an unknown operator and no gap in service. The forum thread has had no post since LinkPool published its full proposal on 28 April, and none records the award.

Why Decentralize Infrastructure?

Centralised infrastructure creates single points of failure and trust. If the public Gateway goes offline, the Radix Wallet and every dApp that reads the ledger through it 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 handover moved all three services to a single operator, so that concentration remains. 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.

After the handover

Running the servers and maintaining the software are separate jobs, and the RFPs covered only the first. On 18 May 2026 Pawel_XRD, who had developed the Gateway at RDX Works and then at the Foundation, opened a second RadixTalk thread asking whether the community or the DAO wants anyone to keep maintaining the Gateway's code: dependency upgrades, compatibility with changes elsewhere in the ecosystem, bug fixes, performance work and new features. It had no replies as of 15 September 2026.

The code still moves when the network needs it to. Gateway v1.10.7, released on 7 September 2026 while mainnet was halted after the Hyperlane asset drain, adds two new values, V4 and V5, to the system version the Gateway reads from a node, so that it can parse a node reporting either. 0xOmarA wrote the change and Marek Karwacki merged it. It was the first Gateway release since v1.10.6 on 7 April.

The funding runs to the end of December 2026. The Foundation's April post names the community DAO's legal entity as the one piece of its transition still missing, and says that once it exists, what comes next is the community's to shape.

HydrateLast updated Sep 15, 2026v1.3.07 revisionsVerified Sep 15, 2026