Trust CenterBuilt like financial infrastructure

Security

Custody stays with you. Everything we can verify on-chain, you can verify too. Everything we claim, we document. This page describes the controls actually in place — not aspirations dressed up as facts.

Last updated · 22 July 2026

Security architecture

OnyxOne is built on a conventional, dependable stack: hosted and delivered on Vercel, with data, authentication and storage on Supabase. The design principle is simple — sensitive material stays on the server, and the client is treated as untrusted.

High-level platform architectureSchematic
Your browser + walletOnly ever receives the public anon key — never a secretVercel — edge delivery & hostingHTTPS/HSTS, cached SSR, hardened security headersApplication layer — server components & API routesServer-only secrets · SIWE verify · signed sessions · fail-safe adaptersSupabaseDatabase · auth · storagePublic blockchainsRead-only ownershipCard partnerPlanned · not yet engaged

Your browser only ever receives a public key. Secrets, sign-in verification and adapters run server-side. The card partner is planned, not engaged.

Platform controls

  • Non-custodial by design — we never hold your private keys and cannot move your assets.
  • Server-side secrets only; the service-role database key and other secrets never reach the browser, which only ever receives a public key.
  • Single-use, domain-bound sign-in nonces that are consumed on use, with signed, httpOnly, tamper-evident sessions and constant-time signature checks.
  • Encryption in transit and at rest, with session and device controls on every account.
  • Hardened HTTP security headers — HSTS, frame-ancestors none (anti-clickjacking), nosniff, and strict referrer and permissions policies.
  • Fail-safe integrations — capabilities that aren't configured (such as the card program) refuse rather than fake success; errors return safe envelopes with no internal detail leaked.
  • Smart contracts for drops and memberships are designed to be audited before deployment, with reports published here once complete.

How sign-in works

Signing in proves you control a wallet address — nothing more. The server issues a one-time challenge, you sign it in your own wallet, and the nonce is consumed so it can't be replayed. We never see your seed phrase and never ask for it.

Wallet sign-in flowSchematic
1Connect walletChoose a self-custody wallet2Single-use nonceServer issues a one-time challenge3Sign to verifyYou sign; the nonce is consumed4Signed sessionHardened, httpOnly, tamper-evidentOnyxOne never sees your seed phrase and never asks for it. A signature proves control of the address — nothing more.

A signature authenticates you without moving funds. The session that follows is hardened and tamper-evident.

Data handling

We collect the minimum needed to run a compliant, non-custodial platform, and we're explicit about what leaves your device. Personal and compliance data is retained only as long as the law and the Service require, then deleted or anonymised. Full detail is in our Privacy Policy and Data Processing Agreement.

Certifications & roadmap

We build to recognised security standards. SOC 2 and ISO 27001 are on our roadmap and are not yet held — we will publish attestations here once they are complete rather than claim them in advance.

Your part

  • Use a hardware or reputable self-custody wallet.
  • Verify every transaction before you sign — signatures are final and on-chain actions are irreversible.
  • Never share your seed phrase; OnyxOne, and any legitimate service, will never ask for it.

Reporting a vulnerability

Found a vulnerability? See our Bug Bounty policy and report it responsibly. We don't pursue legal action against good-faith researchers who follow it.