Testnet phase optitor runs on public testnets today. Mainnet follows an independent cryptography audit. Where we are
Request a demo
Request a demo Sign in to the console

Self-hosted MPC custody

Custody where the key is never whole.

optitor is the custody platform you run in your own cloud. Every withdrawal passes a quorum-signed policy, then two of three independent parties sign it — and the key behind your addresses is never assembled, on any machine, at any moment.

Request a demo Read the security model
  • Threshold ECDSA (CGGMP21)
  • Passkeys-only console
  • Runs in your cloud

  • 2 of 3

    independent parties sign every transaction. No single machine can.

  • 0

    machines ever hold the whole key — outside an offline, witnessed recovery.

  • 2 gates

    on every withdrawal: a quorum-signed policy and an MPC signing quorum.

  • 118

    EVM chains cataloged. One key controls the same address on all of them.

How a withdrawal moves

From request to settlement, nothing is trusted by default.

Policy and cryptography are two independent gates. Bypass the policy in the database and the signers still refuse; compromise one signer and it still cannot sign alone.

  1. 01

    Request

    A withdrawal arrives from the console or the API — authenticated with a passkey or a signed API request, and idempotent by key.

  2. 02

    Policy

    Rules are evaluated top-down; the first match decides. No match, no active policy or a stale price means the request is blocked.

  3. 03

    Approve

    Approvers confirm with a passkey step-up or a device key held in secure hardware. By default, nobody approves their own request.

  4. 04

    Sign & settle

    Two of three parties sign after each verifies the quorum-signed policy. The signature is checked against the custody address before broadcast.

Platform

Everything a custody operation needs, in one system you control.

Wallets, policy, approvals, gas, ledger and reconciliation share one data model and one audit trail — not a patchwork of vendors stitched together with spreadsheets.

Security model

No single system, vendor or person can move funds.

We design against named adversaries, not checklists. Each one is contained by a control that does not depend on the others — and we publish the one residual risk a single-operator deployment keeps.

Read the full security model
Adversary Contained by
Fully compromised backend Holds no key share; every signer verifies the quorum-signed policy itself.
Phished administrator Passkeys are bound to the console origin; privileged actions need a quorum.
One stolen signer server One share is useless alone, and shares are re-randomized every week.
Poisoned container image Images are signed and verified at deploy; one signer domain updates per day.
Illustrative

Co-signer app · iOS & Android

Approvals that show you exactly what you sign.

The co-signer app turns a phone into an approver device. It never trusts the server's summary: it rebuilds the digest from the rules on screen and refuses to sign if anything differs.

  • Paired by QR from the console. No password and no workspace credentials on the phone.
  • A key that cannot leave. Generated in the Secure Enclave or StrongBox, unusable without Face ID or a fingerprint.
  • Activated by your admins. A paired phone approves nothing until an admin activates it in the console.
About the co-signer app

Developers

An API built on the custody model your team already knows.

Vault accounts, asset wallets, transactions, policies, whitelists and webhooks — with every money-moving call signed, idempotent and auditable.

  • Mutual TLS and Ed25519-signed requests for API users, with timestamp and single-use nonce.
  • Idempotency-Key on every money movement, plus your own external transaction ID.
  • HMAC-signed webhooks with a 24-hour dual-signing window when you rotate secrets.
Explore the API
Create a withdrawal 
POST /api/v1/transactions
Idempotency-Key: <a UUID you generate per payout>
X-Auth-Timestamp: <unix seconds>
X-Auth-Nonce: <fresh UUID v4, used once>
X-Auth-Signature: <Ed25519 over the canonical request>

{
  "operation": "withdrawal",
  "chainId": 8453,
  "assetSymbol": "USDC",
  "vaultAccountId": "a3f1…",
  "destination": { "type": "whitelisted", "address": "0x5b2e…91c4" },
  "amount": "25000.00",
  "externalTxId": "payout-4821"
}

Deployment

Runs in your cloud. Answers to you.

Every key share lives in a trust domain you operate — separate accounts, regions and deploy identities — so no outage, insider or vendor in one domain can reach the others.

  • Reference deployment on Azure Container Apps, with PostgreSQL 16, Redis 7 and infrastructure as code.
  • Production signers run in Confidential VMs, verified by attestation before they join, with shares sealed by Managed HSM.
  • Compliance where you need it: KYC, screening and Travel Rule hooks run fail-closed when enabled.

Backend

API · worker · PostgreSQL · Redis

0 key shares

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
Required party

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.

No lock-in

Built so you can leave.

Encrypted share backups are exported at every key change to storage you choose. With your offline recovery key, the recovery tool rebuilds a standard BIP32 key on an air-gapped machine — one that any standard wallet imports.

It is the only sanctioned way the key is ever assembled: witnessed, offline and break-glass. Restore drills are part of the operating model — a quarterly check of every backup, and a full rehearsal on testnet each year — so the day you need it is not the first time it runs.

  1. 01

    Encrypted backupsone per signer, per key, per refresh — in storage you choose

  2. 02

    Your recovery keyheld offline, on an air-gapped machine, by your custodians

  3. 03

    A verified keyrebuilt and checked against the public key before it is used

  4. 04

    Any standard walletimports it — every address reachable, no optitor required

Questions

What buyers ask first.

Straight answers — including the ones that are “not yet”.

Is optitor a custodian?

optitor is custody software. You deploy it in cloud accounts you control, and the parties that hold key shares run in trust domains you choose — so the custody of your assets stays with you, not with a vendor.

Which assets and chains are supported?

EVM chains. The catalog covers 118 networks (79 mainnet, 39 testnet), and one key controls the same address on all of them. Tokens are credited only from a vetted allowlist — USDC by default, plus 50 well-known tokens wherever a contract is pinned. Native ETH or POL is used for gas, never credited. Non-EVM chains are not supported today.

Where are the keys?

Nowhere in one piece. Each signer holds one share of a 2-of-3 threshold key, sealed at rest by its own HSM key and, in production, protected in use by a Confidential VM. Shares are re-randomized weekly without changing a single address.

What happens if a signer goes offline?

Funds stay safe; signing waits. Any two of the three parties can sign, a faulty party is identified by the protocol, and replacing it is a quorum-approved change that never moves funds or changes addresses.

Is the cryptography audited?

Not yet, and we say so plainly. optitor runs on public testnets today. An independent audit of the MPC implementation is a hard gate before mainnet; the security page lists every pre-mainnet gate and where it stands.

Do you perform KYC, AML screening or Travel Rule?

Compliance is a pluggable layer, chosen per deployment. When enabled it runs fail-closed on deposits and withdrawals. Running without it is an explicit, recorded decision — the obligation then stays with the operator.

Can we leave?

Yes. The offline recovery kit rebuilds a standard BIP32 key — on an air-gapped machine, under your control — that any standard wallet can import. Your funds never depend on us staying in business.

See the security model working end to end.

Walk through a live testnet deployment with us: a policy publish approved on a phone, a withdrawal signed by two of three parties, and reconciliation against the chain.

Request a demo hello@optitor.com