Architecture & trust

What sits between your request and a blockchain node, what we hold, and what we don't. If you're evaluating the platform for production, this is the page to read alongside Security.

The path of a request

your app
  │  https://rpc.au.ro/<chain>        (header: apikey)
  ▼
API gateway ── TLS · key auth · per-plan rate limits · method guards
  ▼
RPC proxy ── chain routing · cache · Compute-Unit metering · failover
  ▼
blockchain node ── a full node we run, for that chain

Three hosts, three jobs:

Host	Purpose	Credential
rpc.au.ro	RPC traffic	API key (apikey header)
api.au.ro	Management API	JWT (Authorization: Bearer)
dash.au.ro	Dashboard	JWT (browser session)

Dedicated nodes, not a reseller

Every chain is a full node we operate — not a forwarded call to another provider. That's why each endpoint speaks its chain's native protocol (bitcoind JSON-RPC, ogmios for Cardano, the Cosmos SDK LCD, rippled, …) with no lowest-common-denominator wrapper, and why per-chain quirks are documented honestly on the chain pages instead of hidden.

Nodes are never reachable directly. Every request passes the authenticated gateway and the metering proxy.

Multiple locations

The platform runs as a control plane plus one or more data-plane locations. Consequences you can actually observe:

• Chain availability is per location. Each location serves a subset of the chain catalog. A chain that isn't served where you're connected answers -32601 chain not available at this location (WebSocket paths: 404). Your key is fine — see Errors.
• Chains move. Nodes migrate between locations for capacity or maintenance; a chain can be briefly withdrawn and come back.
• Multi-node chains are load-balanced at the gateway.

What happens when a node fails

• On a transport error (node unreachable, connection reset) the proxy re-routes to the next node for that chain — up to 3 attempts — before returning -32603 backend request failed.
• A valid response is never retried. If a node answers with a JSON-RPC error, you get that error; retrying application-level errors is your call (retry matrix).
• Nodes bootstrap from snapshots and re-sync from the chain's own p2p network, so a lost node is a capacity event, not a data-loss event.

Full detail: Platform limits → failover.

Response SLA ≠ uptime SLA

We publish support response commitments per plan (Support & SLA). We do not publish an uptime percentage, because we don't yet measure and publish one — and an unmeasured number would be worth nothing to you. Failover behaviour above is what we do commit to, and it's observable.

What we hold — and what we never do

Private keys	Never. The platform holds no accounts and cannot sign. You sign locally and submit raw bytes. Treat anything asking for a private key — including anything claiming to be us — as hostile.
API keys	Stored hashed. The plaintext exists only in the create response, once. Lost key → revoke and create a new one; there is no recovery path by design.
Your payloads	Proxied to the node and returned. Not mined for content.
Card details	Never touch the platform — card payment is a hosted Stripe checkout.
Usage records	Per (project, chain, method): request counts and Compute Units. This is what meters and bills your account.

Isolation you control

• Projects are bulkheads — keys, quotas and usage are per project. Split environments or teams into projects rather than sharing one key.
• Chain scoping — a project's chains allow-list restricts which chains its keys may call, so a leaked staging key can't touch production traffic on another chain (how to).
• The daily CU quota is a spending fuse — it turns a runaway client into -32005 instead of an invoice (Compute Units).

Transport & revocation

• TLS everywhere (Let's Encrypt, auto-renewed); plaintext HTTP is redirected (308). gRPC is TLS on both entry ports.
• Revocation takes effect within seconds, at two layers: the gateway credential is deleted, and every proxy replica holds a push-updated deny-list that refuses a revoked key (401, -32012) even if the gateway layer lags. A revoked key inside a batch kills the batch before anything runs.
• Every response carries X-Correlation-ID — quote it in a support ticket and we can trace your exact request across layers without you sharing payloads.

Account security

TOTP 2FA, passkeys and recovery codes; session listing and "log out everywhere"; an audit log of logins, key operations and project changes with timestamps and IPs. See Security → account security.

Caching, stated plainly

The gateway caches per method class and tells you every time — X-Cache: HIT|MISS on every response. Immutable data (confirmed transactions, blocks by hash) is cached indefinitely; head-of-chain data uses 1–30 s TTLs; every submit/broadcast is never cached. Cache hits are still metered — the CU weight pays for the API call. Full table: Endpoints → response caching.