Security model
Security you can check, not just trust.
optitor is designed so that no single compromised system, vendor or person can move funds. This page states the model, the controls behind it, the risk it does not remove, and exactly where the project stands.
The invariant everything serves
The address that receives funds is the key that signs — and that key is never assembled, on any machine, at any moment.
Addresses come from the shared public key
Every deposit address is derived from the vault's distributed public key, so the address and the signing key are the same object by construction.
Checked before every broadcast
optitor recovers the signer from each signature and refuses to broadcast unless it equals the custody address — it never guesses.
Shares never meet
Key generation, signing and address derivation all run without any party seeing another's share. No online system ever holds two in usable form.
Two independent gates
A signature needs a signed policy and a cryptographic quorum.
Either gate alone would be a single point of failure. Together, bypassing the policy in the database still yields no signature, and stealing one key share still yields nothing.
Gate 1 · Policy
Your admin quorum signs the policy.
- Publishing a policy collects M-of-N signatures from quorum members' device keys.
- Signatures bind the exact version, so an old permissive policy cannot be replayed.
- Every signer verifies the bundle on every request and keeps an anti-rollback high-water mark.
Gate 2 · Cryptography
Two of three parties sign — one of them required.
- Threshold ECDSA (CGGMP21): any two shares sign; one share alone is useless.
- An independent co-signer is a required party for every signature.
- Every node — not only the co-signer — refuses a session that leaves it out.
Trust domains
No two shares live where one person can reach both.
A trust domain is an isolation boundary: its own cloud account or subscription, region, operator and deploy identity. The backend holds no share at all, and the co-signer lives in a domain the backend never controls.
- Backend — API, worker, database: zero shares, cannot sign.
- Signers A and B — one share each, different accounts and regions.
- Co-signer — the required independent party, ideally under a separate principal.
- Approvers — device keys that sign policies and approvals, never a blockchain transaction.
- Offline recovery — air-gapped, break-glass only.
Backend
API · worker · PostgreSQL · Redis
Evaluates policy, routes signing rounds as ciphertext it cannot read, runs the ledger. A fully compromised backend cannot sign.
Signer A
Your cloud · account A
- One key share
- Sealed by its own HSM key
- Confidential VM in production
Signer B
Another region / subscription
- One key share
- Sealed by its own HSM key
- Confidential VM in production
Co-signer
Separate account or principal
- Required in every signature
- API co-signer in its own VM
- Checks each request itself
Offline recovery — your RSA-4096 recovery key stays air-gapped. Encrypted share backups are exported at every key change; reconstruction is a witnessed, break-glass ceremony.
Key protection
Every share is protected four ways.
-
At rest
Each signer seals its share under its own HSM key — Azure Managed HSM (FIPS 140-2 Level 3) in production. Shares are never co-located and never share a key.
-
In use
Production signers run inside Confidential VMs (AMD SEV-SNP or Intel TDX) that encrypt process memory; attestation is verified before a node can join. Plaintext shares are locked in memory and zeroized.
-
Over time
Shares are re-randomized every week with the public key unchanged. A thief has to breach two trust domains within the same week, or start over.
-
In transit
Signers talk over mutual TLS with pinned peer keys. Every signing request carries the quorum-signed policy bundle, which each node verifies.
People & access
Phishing-resistant by design, least privilege by default.
No person or integration signs in with a password — not to the console, not for approvals, not to the API.
Console users
- Passkeys only, user-verified, bound to your console's origin — a phishing page gets nothing usable.
- Single-use step-ups bound to the action and resource — for a withdrawal, the transaction and its amount.
- Seven roles, from owner to viewer; nobody can change their own roles.
- IP allowlists per user, enforced on every request.
- Lost passkeys are reset only with identity re-verification, a quorum for privileged users, a 24-hour delay and an email notice.
Systems and integrations
- API users authenticate with a client certificate and an Ed25519 signature over every request.
- Replay-proof: a timestamp window of five minutes and a single-use nonce per request.
- Webhooks are signed with HMAC-SHA256 and rotate with a 24-hour overlap.
- Rate limits fail closed on authentication and money routes when their store is unavailable.
- Secrets live in Key Vault; missing secrets stop the service from starting in production.
Threat model
Named adversaries, and what contains each one.
The design target is that no single compromised system, vendor or person can move funds. Each row lists the controls that still hold after that adversary has done their worst.
| Adversary | What they reach | Contained by |
|---|---|---|
| Fully compromised backend | Forged transactions, approvals and policy rows; sessions | Signers verify the quorum-signed policy and refuse rollbacks; a required co-signer must take part; audit and ledger exports are immutable. |
| Malicious coordinator | Party selection and message routing | Every node refuses a session that omits the required party or does not match the sealed key topology; the coordinator holds no share. |
| Insider in one signer domain | One sealed share, its HSM and deploy rights | One share is useless alone; weekly refresh time-boxes theft; in production the Confidential VM keeps the share unreadable even to root. |
| Poisoned build or registry | Code in every domain that deploys it | Signed images verified at deploy, pinned by digest, with provenance; signer domains deploy separately, at most one per 24 hours. |
| Phished or stolen admin sign-in | A console session and its role | Passkeys are bound to the console origin and user-verified; step-ups are single-use and bound to the action; privileged actions need a quorum. |
| Lost or stolen approver phone | The device approval key | The key sits in secure hardware behind biometrics; revoking the device in the console removes it from every approval. |
| Network attacker | Traffic in transit | Mutual TLS with pinned keys between signers; API requests signed with Ed25519, a timestamp and a single-use nonce. |
| Database administrator | The ledger and audit tables | Append-only grants and triggers; hash-chained exports to immutable storage; reconciliation against on-chain balances. |
| Faulty or malicious RPC provider | Chain data and broadcasts | Finality and reorg guards on every credit, fallback providers, a signature check against the custody address, and drift-triggered freezes. |
The residual risk we do not remove
If two trust domains collude, they hold a signing threshold. Cryptography cannot prevent that — governance has to. The decisive control is to hold the co-signer domain under a separate principal: another legal entity, an independent operator, or the customer. A single-operator deployment does not get that separation for free, so optitor asks you to record the decision at go-live: separate the principal, or formally accept the risk.
Recovery
A way back that does not depend on us.
Because you are the custodian, disaster recovery cannot be a support ticket. optitor's recovery kit is yours, offline and testable.
- 01
An offline recovery key
An RSA-4096 key pair generated on an air-gapped machine. The private key never touches optitor infrastructure.
- 02
Encrypted backups at every key change
Each node exports its share, encrypted to the recovery key, after every key generation and every refresh — to two independent, immutable stores.
- 03
Watched and drilled
An inventory flags any key without a complete, current backup set. Drills verify the kits quarterly and rehearse a full reconstruction on testnet yearly.
- 04
A standard key at the end
The offline tool rebuilds a standard BIP32 key that any standard wallet imports, checks it against the public key, and the key is then retired.
Supply chain & operations
What runs in production is exactly what was built and signed.
Every build starts from an exact commit, passes the release gate and is signed before it can be deployed.
- Every image is signed with a key held in Key Vault, carries build provenance, and is verified before rollout — deployed by digest, never by tag.
- The release gate runs formatting, vet, lint, gosec, gitleaks, govulncheck, race-detector tests, coverage thresholds and migration round-trips on the exact commit being shipped.
- Signer domains never share a deploy pipeline or credential, and at most one updates per 24 hours.
- The application's database role can only insert and read ledger and audit rows — never update or delete them.
Where we are
optitor is in its testnet phase.
We publish our pre-mainnet gates instead of a badge wall. Nothing below is marked done until it is — and mainnet waits for all of it.
- Built Application layer — wallets, policy, approvals, ledger, reconciliation Built and hardened on testnet.
- Live Running on public testnets Production infrastructure in its testnet phase.
- Pending Independent cryptography audit of the MPC implementation Hard gate before mainnet.
- Pending Production PKI and witnessed key-generation ceremony Offline root CA, per-node keys.
- Pending Confidential-VM signers with attestation verified at provisioning Required for production signers.
- Pending Recovery-kit restore drill, completed and documented Before any mainnet key holds value.
- Pending Penetration test of the API and authorization model Scope derived from the threat model.
- Planned Mobile co-signer as a signing party Phones approve today; MPC participation follows the audit.
Vulnerability disclosure
Found something? Tell us first.
Write to hello@optitor.com with the steps to reproduce, the impact you expect, and how to reach you. Our contact details are also published in security.txt.
- Give us reasonable time to investigate and fix before you disclose publicly.
- Stay within your own data — do not access, change or delete anything that is not yours.
- Avoid degrading service for others: no denial-of-service and no social engineering.
- We acknowledge every report and keep you informed until it is resolved.
Bring your security team. We will bring the threat model.
We are happy to go through the design with your CISO and auditors — the trust domains, the signed-policy verification, the recovery drill and the gates still open before mainnet.