Security

Key handling

• Never ship an API key in client-side code. Anyone reading your app bundle can drain your CU budget and rate limits. Proxy RPC calls through your backend, or issue per-environment keys you can revoke fast.

  The RPC host sends no CORS headers — on purpose

  rpc.au.ro doesn't allow cross-origin browser requests, so a fetch straight from a web page fails CORS by design. That's the rule above enforced in the gateway rather than left to good intentions: if it worked, your key would be in the page. Call the RPC host from your server. (The dashboard and management API hosts do send CORS headers — they use short-lived JWTs, not API keys.)

• Environment variables over config files. Every snippet in these docs reads YOUR_API_KEY from the environment — copy that pattern.

• One key per deployable unit. Separate keys for staging/production/CI make revocation surgical and usage attributable. Keys are free.

• Rotate on suspicion, not on schedule. Create-new → deploy → revoke-old is zero-downtime (Authentication).

Blast-radius control

• Project chain scoping — a compromised key for an ["eth"]-scoped project cannot touch your Bitcoin traffic (how to).
• Projects as bulkheads — usage, quotas and keys are per project; split products or teams into projects rather than sharing one.

Account security

• Enable TOTP 2FA or add a passkey in the dashboard (Settings → Security). Recovery codes are shown once — store them offline.
• Review active sessions (GET /api/v1/auth/sessions) and revoke any you don't recognize; "log out everywhere" is POST /api/v1/auth/logout-all.
• The audit log (Settings → Audit) records logins, key operations and project changes with timestamps and IPs.

What we do on our side

• Keys are stored hashed; the plaintext exists only in the create response.
• 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, JSON-RPC -32012) even if the gateway layer lags — a revoked key inside a batch kills the whole batch before anything runs.
• TLS everywhere (Let's Encrypt, auto-renewed); plaintext HTTP is redirected (308).
• RPC nodes are never exposed directly — every request passes the authenticated gateway and the metering proxy.
• debug_* is disabled on /eth; expensive scan methods have per-plan budgets (Rate limits).
• Every response carries X-Correlation-ID — quote it in support tickets so we can trace the exact request without you sharing payloads.

Signup & account protection

Account creation is rate-limited per source IP and screens out malformed and disposable-mail addresses. Depending on deployment configuration, signup may require a CAPTCHA, and creating your first API key may require confirming your email address first — follow the link we send on registration. These exist to keep the free tier usable for real users; they don't affect your API traffic once your key is issued.

Device check

The dashboard sign-up and sign-in forms also run a browser device check and send its result with the form. What that means concretely:

• What is computed. Open-source FingerprintJS (MIT) hashes browser and device attributes into one pseudonymous identifier, plus BotD (MIT) flags automation (headless browsers, WebDriver). Both run in your browser.
• What is sent to us. The resulting identifier, a confidence score, the bot verdict, and a fixed, small set of device characteristics used to recognize the same machine across browsers: graphics adapter name, OS platform and architecture, CPU core count, screen resolution class, timezone, language list, touch capability, which of a fixed 52-name font probe list rendered, and hashed canvas/audio values. No browsing history, no page content, no free-form enumeration of what is installed. A one-shot server nonce accompanies the payload so a recorded submission cannot be replayed.
• What it is used for. Capping how many accounts one device may register (free-tier multi-account abuse), correlating devices that share a machine, and scoring sign-in risk — the strongest automatic consequence of a high score is an extra CAPTCHA, never a block. Operators see the linked accounts and every risk decision with its named reasons when investigating abuse. It is never used for advertising, never sold, and never shared with a third party — the check runs entirely on our own infrastructure, with no request to Fingerprint's servers.
• If it doesn't run. Sign-up works without it unless the operator of your deployment explicitly requires it; the per-IP limits above still apply. A missing check is treated as "no signal", not as suspicion.
• Retention. Associations are deleted with the account they belong to. The per-device registration counter and the device characteristics are kept without any account link, so deleting and re-creating accounts does not reset the quota.

This is a self-hosted platform: whether the check runs at all, and how strict it is, is a deployment setting (admin console → Rate Limits → Auto-protection).

Sending transactions

The platform never holds your private keys. Sign locally (ethers, bitcoinjs, xrpl.js, …) and submit the raw bytes via the chain's broadcast method. Treat any service that asks for a private key — including anything claiming to be us — as hostile.