The custody architecture, stated precisely

Signatures are produced with FROST (Flexible Round-Optimized Schnorr Threshold signatures, RFC 9591). The signing key exists only as shares. Each participant holds one share and contributes a partial signature; the partials aggregate into a single valid signature. At no point — key generation, signing, backup, migration, or any error path — does any process hold the complete private key.

This is not encryption-at-rest of a whole key, and it is not a sharded backup that gets reassembled to sign. There is no reconstruction step, because the protocol never needs one.

A threshold scheme is only as strong as the independence of its share-holders. Our signing quorum spans two deliberately different environments:

• A hardware-attested confidential-compute enclave: key shares are sealed such that they are released only to measured, attested workloads.
• Physically isolated bare metal: full-disk encryption bound to a hardware root of trust, default-deny networking, no shared operators or credentials with the first domain.

The two domains share no cloud account, no operator credential set, and no control plane. Correlating them would collapse a two-domain quorum into one domain — so we treat that correlation itself as a security failure, and the domains are administered separately. We do not publish hostnames, providers, regions, or attestation endpoints; those specifics are available to customers under NDA.

Generation

Keys are born distributed. A distributed key generation (DKG) ceremony runs across the trust domains; each participant derives its own share, and only the joint public key is ever visible outside a share-holder. Share material exchanged during the ceremony is encrypted end-to-end to its recipient — the coordinating service relays ciphertext and authenticated metadata, never plaintext shares.

Device shares

Where an end-user device participates in a quorum, its share is envelope-encrypted: sealed under keys derived from device-held credentials, so the share is useless in a backup, a sync service, or our own storage without the device-side unwrap.

Storage and memory

Shares are sealed at rest and zeroized in memory after use. Logs are structural — identifiers, counts, verdicts — and never contain key material.

Rotation, not reassembly

When membership changes or a share is suspected compromised, the answer is share rotation: a new sharing of the same key, after which old shares are worthless. There is no path that reconstructs the key to re-deal it.

A policy verdict precedes any use of a key share, on every path through the system, including the colocated low-latency path. The engine's design positions are:

• Invariants over value conservation, not destination allowlists. A policy states what a transaction may do to balances — value in versus value out — so a drain path that respects no allowlist still violates the equation and is denied. A spend cap bounds loss per transaction; a conservation invariant forbids the loss.
• Recursive decoding of nested cross-program invocations. The policy is evaluated against the full decoded tree of what the transaction does, not the top-level instruction a wallet UI happens to render.
• Deny by default. An instruction the engine cannot parse into a strictly-typed known form is denied. Coverage grows by adding typed decoders that reject unknown fields — never by adding a permissive catch-all.
• One decoder. The human-readable intent shown to an approver is derived from the same decode path the policy engine evaluates. Two decoders would allow an approver to be shown one thing while another is signed; we do not have two decoders.

Bearer tokens are sufficient for reads. They are not sufficient for operations that move value or change what can move value. Creating a signing request, approving one, and changing a policy are signed by the member's own device or API key over the request body, and the platform verifies that signature. Consequences:

• A stolen session or bearer token alone cannot initiate or approve a transfer.
• Each approval in a quorum is independently verifiable after the fact — it cannot be forged, even by a compromised control plane.
• Approval quorums are N-of-M across members holding the signer role, with self-approval off by default and mandatory expiry on pending requests.

Several absences below are the security model. They are commitments, not roadmap gaps.

• No support override for recovery. Our staff cannot reconstruct, export, or re-deal your key outside the protocol. A recovery flow that support can invoke is a backdoor with a friendlier name.
• No reduced-quorum fallback. If a trust domain is unavailable, signing waits. There is no emergency mode where fewer parties sign.
• No policy bypass on any path. The low-latency colocated path is a transport optimization; it passes through the same policy engine, the same checks, and writes the same audit records as every other request.
• No complete-key export. There is nothing to export; the complete key never exists.
• No silent widening of what parses. New instruction support ships as strictly-typed decoders, deny-by-default for anything unknown.

Every policy decision, approval, and key operation writes an append-only, per-tenant record with actor, timestamp, and outcome. Tenant admins can read and export their history; nobody — including us — edits it.

Our security reviews are conducted internally, with adversarial review gates on the cryptographic core, and review reports are available to customers under NDA. We do not hold, and do not claim, third-party audits or certifications such as SOC 2 — if a certification logo is a hard requirement for your procurement process, we are not the right vendor yet, and we would rather say so here than in a sales call.

What we offer instead is specificity: this page, protocol-level documentation, and direct access to the people who built the system. A security-literate reviewer should be able to evaluate the architecture from the written material alone.