The custody architecture, stated precisely

Every signature requires independent participants to act together. Each holds only its own protected signing material, and neither can produce a valid result alone. 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 backup that gets reassembled to sign. There is no reconstruction step.

Distributed custody is only as strong as the independence of its participants. The launch profile requires two independent server domains, each with its own protected share and policy enforcement:

• A protected server signing domain, with signing material released only to its authorized workload.
• A second server signing domain with separate administration, deployment permissions, sealing roots and emergency access.

Qualification must verify administrative independence, including shared ownership and access risks. The coordinator holds no signing share, and each signing domain must independently verify the transaction and its authorization. Customers should evaluate the evidence for their intended custody profile.

Generation

Signing authority is created directly across the trust domains. Each participant receives only its own protected material, and only the joint public key is visible outside those domains. The coordinating service cannot recover or use the private material.

Future device-held custody

Launch custody uses server-held shares. Future iOS custody becomes non-custodial only when the device share is cryptographically mandatory and the old server-only quorum is permanently retired. A same-key transition must prove that the public key and wallet address are unchanged. Browser wallet custody is outside the launch profile.

Passkeys, App Attest, biometrics and device-protected wrapping help protect access. They do not make the device share mandatory by themselves. A two-of-three arrangement with two server shares still permits server-only signing.

Storage and memory

Signing material is protected at rest and wiped from controlled memory after use. Logs contain identifiers, counts, and verdicts — never secret material.

Migration and compromise

Same-key resharing can change authorized participants while preserving the wallet address. It requires a verified transition, retirement of old shares and permanent refusal of retired epochs by the signing service.

A stolen complete old quorum can still sign with the original key. Same-key resharing cannot revoke that ability. If enough old shares have been compromised to form a quorum, assets must move to a new wallet key.

A policy verdict precedes every signing attempt, 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.

Management approval keys authenticate these requests. They are separate from the threshold shares that sign wallet transactions.

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.

Independent comprehensive review of the frozen release candidate is required before any capped mainnet test. It covers cryptographic dependencies, transaction parsers, infrastructure, administrator independence, recovery, deployment configuration and supply chain. Internal review or passing tests alone does not close that gate.

We distinguish source completion, testing, deployment, independent review and rollout approval. We do not claim third-party audit or certification coverage on this page. Ask for the evidence applicable to the exact chain, region and custody profile you intend to use.