Babylon Gateway Operator Proposal

Submitted by: TrellisTech (Shambu Pujar and Marek Karwacki) Date: February 2026 Version: 1.0

Executive Summary

TrellisTech team , comprising of Shambu Pujar and Marek Karwaki (Both part of Foundation DevOps team) , proposes to operate the Babylon Mainnet Gateway for the Radix ecosystem, delivering a production-grade, highly available API service that meets or exceeds the performance and reliability standards established by the current Foundation-operated Gateway.

Our approach is built on AWS managed services deployed in eu(Ireland/London), combining the operational simplicity of fully-managed infrastructure with the flexibility of Kubernetes-native traffic management:

Amazon EKS (Managed Kubernetes) for orchestrating Gateway API and Data Aggregator workloads with automated scaling and self-healing
Istio service mesh(Or other Alternate Ingress) for intelligent traffic routing and Active/Passive traffic switching; future home for cluster-level rate limiting.
- Istio is different to Nginx Ingress controller, which foundation gateway uses now and that is being deprecated with no further support or upgrades. Istio isn’t finalised, but being evaluated with other options to replace this deprecated service
Amazon RDS for PostgreSQL on dedicated instances for database high availability — built-in automated failover, point-in-time recovery, and managed backups eliminate the need for a custom HA stack
AWS WAF or Cloudflare for application-layer rate limiting and threat protection (initial phase)
Dedicated Radix full nodes on OVH UK for low-latency ledger access, connected via secured public endpoints

Key commitments:

Metric	Our Target	RFP Requirement
SLA / Uptime	99.5%	99.9% minimum
Gateway API p95 latency	< 1 second	< 1 second
Submit/Preview p95 latency	< 3 seconds	< 3 seconds
Data Aggregator lag	< 60 seconds	< 60 seconds
Error rate	< 0.1%	< 0.1%
Europe latency (/health)	< 50ms	< 100ms
North America latency (/health)	< 300ms	< 400ms
Asia latency (/health)	< 800ms	< 1,000ms

Soft SLA: All performance and availability targets above are best-effort commitments rather than hard contractual guarantees. The Babylon Gateway is a public, unauthenticated service for all endpoints— any wallet user or application can access it without restriction, although application of rate limits is an option, but is not completely fool proof. This exposes the service to intentional abuse (e.g. request floods, scraping bots) and unintentional overload (e.g. poorly optimised clients, sudden ecosystem growth) that cannot be fully anticipated or prevented without introducing authentication, which is outside the scope of this proposal. The operator will make every reasonable effort to meet or exceed the stated targets and will be transparent about any shortfall and its cause. Where degradation is directly attributable to abuse or unauthenticated traffic patterns beyond normal operational bounds, this shall be treated as an out-of-scope SLA exclusion (see Section 1 — Service Scope & Boundaries).

Service Scope and Boundaries

This is an infrastructure operations proposal. The scope is explicitly limited to deploying, operating, and maintaining the Babylon Gateway software as released any team/member supporting Gateway. It does not include software development, code changes, or architectural redesign of the Gateway application itself.

In scope:

Deploying and operating official Gateway releases (Data Aggregator, Gateway API, database migrations) on the infrastructure described in this proposal
Infrastructure-level security hardening — OS patching, WAF rule updates, TLS certificate renewal, dependency upgrades that are drop-in compatible and require no code changes