Your exchange access is encrypted, isolated, and never shared.

Your API key is encrypted with AES-256-GCM before being written to the database. It is never stored in plaintext at any point.

The encryption key lives only on the QARI server in an environment variable. It is never committed to the codebase or exposed in logs.

When QARI needs to place a trade, the key is decrypted in memory for that single operation and immediately discarded. The plaintext key is never written to disk, logged, or persisted.

API keys are never returned to your browser or any frontend client, ever. The dashboard shows connection status (connected / not connected / invalid) but never the key value.

If your connection shows as invalid, it means the key was revoked on the exchange side. You can add a new key at any time from the Exchange Settings page.

QARI only requests spot trading and read permissions when you connect an exchange. Withdrawal permission is never requested.

This is enforced at the API layer. QARI's order placement code only calls spot market buy/sell endpoints. It has no code path for initiating withdrawals.

QARI verifies your API key permissions at connection time. If withdrawal permission is accidentally included, you will be warned and prompted to create a new key without it.

Your funds remain in your exchange account. QARI never moves funds between wallets or exchanges.

QARI runs on a dedicated DigitalOcean Droplet in Frankfurt, Germany (EU jurisdiction). Server specs: Ubuntu 22.04, 4 vCPUs, 8 GB RAM, 80 GB SSD.

Automated daily backups are enabled on the Droplet. Database backups run via Supabase's managed PostgreSQL backup service.

All connections use TLS (HTTPS for the API, WSS for WebSocket connections to exchanges). No unencrypted data is transmitted.

The server IP is whitelisted in the exchange API key settings, exchange API calls originate from a known, fixed IP address.

Application logs never include API key values, user passwords, or personally identifiable information beyond what is necessary for debugging operational issues.

Authentication is handled by Supabase Auth, a production-grade auth service built on PostgreSQL with battle-tested JWT implementation.

All protected API routes validate the JWT token on every request. An expired or invalid token returns 401, no data is returned.

Admin routes have an additional tier check beyond the JWT validation. A valid user token is not sufficient to access admin endpoints.

Row Level Security (RLS) is enforced on all user-data tables in the database. Even if a query bypassed the API layer, it could not access another user's data, the database itself enforces isolation.

Sessions are managed by Supabase Auth with configurable token expiry. Refresh tokens rotate on use.

Beyond trade quality, the risk gate provides a security function: the capital_available check prevents QARI from placing orders that exceed your allocated capital, even if a bug in position sizing produced an incorrect order size.

The no_duplicate_position check prevents double-entry bugs from opening two positions in the same symbol.

The concurrency_lock prevents race conditions, two simultaneous scan cycles cannot both attempt to open the same position.

The within_tier_capacity check enforces subscription plan limits at the execution layer, not just the API layer.

Correlation checks prevent unintended portfolio concentration, if a bug caused QARI to over-trade a single correlated cluster, the correlation gate would block subsequent entries.