Skip to main content
Demo mode — no real funds.

Security

Security architecture

What actually protects an account, described in the same terms our engineers use.

Server-side sessions

Authentication uses a server-side session stored in Redis and referenced by an httpOnly, Secure, SameSite cookie — not a bearer token in browser storage. Because the state lives on the server, a session can be revoked the moment you ask, on one device or all of them. Every session is listed with its device, address and last-seen time.

Two-factor and step-up

Two-factor authentication uses TOTP. The shared secret is encrypted at rest with AES-256-GCM and ten single-use backup codes are stored only as hashes. Beyond sign-in, sensitive actions — withdrawing, investing, changing security settings — require a fresh proof issued within the last five minutes, so a walked-away browser cannot move money.

Immutable double-entry ledger

Balances are derived, never edited. Each movement posts a set of entries that sums to zero per asset, enforced by a deferred database constraint; update and delete are blocked by triggers. User accounts cannot go negative — the check runs inside a row-level lock. A reconciliation job recomputes every balance from the entries and compares it against on-chain treasury holdings.

Custody separation

Deposit addresses are derived from watch-only extended public keys. Private key material never reaches the API, the worker or the indexer: signing happens in a separate service on an internal network, authenticated per request. In production that service is backed by a KMS or HSM, and the same interface accepts an external qualified custodian.

Approvals and separation of duties

Staff access is permission-based and resolved on the server; the interface only hides what a role cannot use. Staff accounts must have two-factor enabled to reach the admin area at all. Large withdrawals and any manual ledger adjustment require two distinct approvers, and neither can approve their own request.

Platform hardening

Strict content security policy, CSRF protection combining a SameSite cookie with origin checks and a required custom header, per-IP and per-account rate limiting, brute-force lockout, idempotency keys on every financial write, and structured logs carrying a request identifier through every layer.

Reporting a vulnerability

If you believe you have found a security issue, write to us before disclosing it publicly. We will confirm receipt and keep you updated while we investigate.

Contact