PairKey Get started →

DOCS / SECURITY & STATUS

Understand the trust model.

Understand what the software verifies, what the deployment guarantees, and what still needs independent validation.

Implementation coverage

Tests establish the exercised software paths, not production security certification. The development demo now offers site-scoped passkey creation and Google sign-in; real passkey- and Google-authorized signing attempts are still needed to validate both complete live flows.

Independent checks and shared assumptions

Program commit makes the application state change and gateway approval atomic on Solana. Signing happens afterward; cross-chain execution is not part of that atomic transaction.

TEE deployment and key recovery

The target architecture has two independent TEE signers. Development workers use private provisioning files and report hardware_backed: false. Identity-signed receipts from those processes do not prove independent hardware providers or remote attestation.

Production gates include independent deployment governance, real attestation, protected entropy and time, authenticated state sources, rollback resistance, independent cryptographic review and root recovery. Permanent root-loss recovery is not implemented. Intact provisioning preserves keys across ordinary restarts.

“The full private key never exists” describes intended protocol execution: shares are created and used separately without assembling the key. It does not guarantee security after extraction of a complete threshold of shares. Static roots do not prevent sequential compromise of the full signing threshold.

Durability, nonces and uncertain outcomes

Request claims are persisted before signing randomness is used. Interrupted work becomes uncertain; recovery can only read matching saved public receipts from both workers. It never starts a fresh protocol round under the original request. Policy and negative-control fences survive ordinary process restarts.

Incident latches remain authoritative after restart. Do not delete journals or reset state to clear a refusal. File locking and atomic snapshots do not prevent restored backups, cloned workers or cross-replica rollback. A historical quorum with extracted keys can sign outside current policy.

Policies and revocations affect future issuance checks. They cannot retract an already issued signature. A cancelled or timed-out delivery does not prove signing never completed.

Read evidence at its actual scope

Repository tests cover canonical cross-language approvals, real two-party signing, policy changes, native passkey policy verification, program simulation/commit, restarts and recovery. The extracted downloadable program is built and exercised in SBF tests. A passing result only covers those tested paths.

Existing SBF dependency stack/syscall diagnostics require review; successful exercised paths do not certify every compiled code path. Custom root-derived FROST construction and DKLS donor realization/reuse obligations remain specialist cryptographic review work. The development EVM demo reuses one RAM-only donor for at most 100 attempts with no age expiry. This demo setting is not a cryptographically certified reuse limit.

Current implementation and rollout evidence is tracked in docs/offchain-approval-plan.md and docs/offchain-approval-api.md. Earlier reports in docs/implementation-status.md and docs/program-jobs-test-evidence.json describe their recorded versions.

Architecture references

For PairKey, read the current approval plan, API contract, source types and tests alongside the older lifecycle and multisuite guides. The homepage comparison references NEAR Chain Signatures and Turnkey’s architecture. NEAR has multichain outputs; Turnkey has a policy engine and multiple specialized enclave services. The comparison concerns where authority and signing power live, not whether another product offers programmable policy.

Latency and fees

Off-chain approval avoids a new Solana authorization transaction and its finality wait. It still includes identity verification, fresh policy reads, optional program simulation, queueing and two-party signing. On-chain approval also waits for its committed decision. Signature scheme and provider conditions affect latency; no apples-to-apples benchmark or production latency guarantee is published.

“Zero authorization transaction fees” means no Solana transaction is broadcast for an ordinary off-chain signing request. Policy creation/edits, program commits, RPC/service charges and destination execution are separate costs. It is not a promise of a zero-priced hosted service.

Hosted release and limits

The v2 guides require a coordinated gateway, controller, worker, coordinator and API release. They do not imply that an older live deployment has been upgraded. The client requires /api/v2/config and checks deployment identity; operators must preserve existing roots, keys, journals and incident latches during migration.

The development service uses one host and explicitly reports its hardware status. Limits include a shared 120-call/minute budget, a signing/enrollment gate, 16 enrolled keys per namespace and bounded retained keys/jobs. HTTP 429 calls for backoff with the original request ID; it does not authorize an automatic fresh attempt.

Namespace metadata, messages and signatures are public to callers with their identifiers. Private authentication proofs are excluded from persisted public job records and receipts. Do not submit confidential messages or valuable funds to the development demo. Backups and operational recovery remain operator responsibilities.