DOCS / ARCHITECTURE

One authority. Two signers.

An authority defines permission. Two independent signers enforce it and jointly produce one signature.

Source → derive → sign

Source: an account wallet, a program-controlled PDA, a passkey identity, or an issuer/audience/subject OIDC identity. A passkey or OIDC login binds a short-lived Ed25519 key to that identity and namespace. It does not delegate unrestricted signing permission.

Derive: the authority, deployment, namespace ID, destination, suite and numeric path identify the key. Public metadata is obtained lazily; no registration transaction is needed in v2. Account and existing controller-PDA authority encodings are preserved. Changing source identity or deployment can change keys.

Sign: authenticate the exact request and satisfy the current policy. Both signers check it independently. The coordinator routes encrypted protocol traffic and returns the signature and public receipts.

Follow one request

1. ApplicationChooses a key and message, verifies the canonical approval, and saves public recovery metadata.
2. AuthoritySigns the exact request. A program also authenticates its caller and either evaluates read-only rules or commits a state change and exact approval in one Solana transaction.
3. Signer A + signer BIndependently verify identity, policy, expiry and program evidence. Each persists its request claim before signing randomness is used.
4. Threshold signingThe two parties participate with separate shares. Both recheck authorization before releasing output.
5. ApplicationVerifies the signature and receipts, then uses the result in the appropriate destination flow.

Separate shares throughout

FROST Ed25519, DKLS23 ECDSA, FROST RedPallas and FROST secp256k1 (BIP-340) share the authorization model. FROST share construction and the DKLS Spike D integration have distinct cryptographic assumptions. New multi-suite keys require both signers’ enrollment; Ed25519 also has offline public derivation.

The target deployment places the two parties in independent TEEs. Development processes and identity-signed receipts alone do not establish hardware attestation or independent providers. See the security model.

Two approval paths

Off-chain approval: a wallet or bound ephemeral key signs the exact request. Optional policy is read from Solana. For a program, each signer runs authenticated pairkey_approve simulation against finalized state and pinned immutable code. No authorization transaction is broadcast.

On-chain approval: pairkey_approve_commit changes application state and records approval through PDA CPI in one transaction. Use it to consume an allowance or nonce. It supports upgradeable programs. This commit path is for program sources; account, passkey and OIDC approvals remain off-chain. Neither path makes later signing or destination execution atomic with Solana state.

Policy storage and approval execution are separate choices. A policy can live on Solana while ordinary approval happens off-chain. See Policy & rules.

Issuance and recovery

Workers persist request claims and order policy changes and negative controls with local issuance checks. A newer denial cannot be replaced with an older observed policy to authorize the same prepared request. RPC failure is not interpreted as absent policy.

After interruption, a job remains uncertain unless both workers’ saved public receipts establish completion. Recovery reads those records; it never assigns fresh signing randomness. A later policy change cannot retract an issued signature. File locking and atomic persistence do not protect against cloned machines or rolled-back snapshots.

Build on the model

Continue to program integration, policy management, and job recovery. V2 sessions are deferred; the session page documents the older native-transfer integration.