Architecture

RelayGuard is a thin, stateless data plane in front of the RPC providers you already use, backed by a control plane that holds your configuration. Your application talks to one endpoint; everything else is internal.

Components

• Gateway (data plane) — terminates your one endpoint, authenticates the API key, applies your policy, and forwards or fans out to your providers. It is effectively stateless: it derives everything from a config snapshot and holds only in-memory health state.
• Control plane — owns the database (accounts, workspaces, encrypted provider URLs, policy). It builds the config snapshot the gateway fleet polls. Your dashboard talks to the control plane; your RPC traffic never does.
• Your providers — unchanged. You bring the keys; RelayGuard routes to them.

Request path

1. Your app sends a JSON-RPC request to POST /rpc/:chain with your API key.
2. The gateway authenticates the key and resolves your workspace + policy.
3. Policy decides the path: proxy (route to the healthiest provider, fail over on error) or quorum (fan out to independent providers and require agreement).
4. The response is returned with X-RelayGuard-* receipt headers describing what was verified. See Security Mode.

Reliability posture

• High availability — gateway and control plane each run multiple always-on machines.
• Degrade-in-place — if the control plane is briefly unreachable, the gateway keeps serving the last known-good config (and can boot from a local cache), rather than failing.
• Automatic failover — read methods route around unhealthy or lagging providers; eth_sendRawTransaction is never silently retried.
• Fail closed — security-critical reads return an error when independent providers can't agree, instead of a possibly-bad answer.
• Backups — the control-plane database has automated incremental + daily backups.

Security architecture

• Provider URLs are encrypted at rest with AES-256-GCM, decrypted only in memory at request time.
• API keys and account passwords are hashed (bcrypt), never stored in plaintext.
• The gateway↔control-plane link runs over a private network; gateways pull config, they don't expose your data.
• Provider credentials are never logged or returned from any API.

Full detail on the Security and Data boundary pages.

Self-hosted & enterprise

For teams that need provider keys and traffic to stay entirely inside their own infrastructure — custodians, exchanges, regulated fintech — a customer-hosted gateway with a managed control plane is on the roadmap. Custom SLAs, SSO, audit logging, and a DPA are available for enterprise engagements. Email [email protected].