DOCS / INTERACTIVE DEMO

See the rules in action.

Connect your authority, choose a chain and follow a real threshold signature from approval to verification.

Sign your first message

Select Solana account, Solana program, Passkey or, when configured, OAuth / OIDC. No namespace registration transaction is needed.
For a program, select the hosted example or enter your own v2 program and set its policy. For a passkey, create a credential on this site or reuse one saved in this browser. For Google, select your account first; a second Google prompt approves the exact message.
Choose Solana, EVM, Zcash, NEAR or Bitcoin and a path index. Load and inspect the derived public key.
Enter up to 256 UTF-8 bytes. Approve the exact request with a wallet message signature, passkey assertion or nonce-bound Google ID token. Program on-chain mode also asks for a transaction.
Follow the two signers and inspect the returned signature and receipts.
Select Verify signature. Change a message character and verify again to see the mismatch.

Choose a source

An account source uses the connected wallet as authority. A program source uses an owner-scoped PDA and authenticated application rules. A passkey uses its P-256 public key, site origin and RP ID; the browser stores only public credential metadata. Google uses the configured OIDC issuer, client ID and stable subject. Each source has its own namespace and keys. The hosted example program selects on-chain mode to support upgradeable code; immutable programs can use read-only off-chain evaluation.

The new flow has no sessions. The demo’s passkey ceremony is for a self-owned site credential; production applications need their own verified registration and recovery flow. Policy changes and on-chain commits need devnet SOL. Ordinary account, passkey and Google off-chain message approvals need no SOL or destination funds. See the passkey and OAuth/OIDC guides for bound ephemeral-key approval.

Five destinations, four signature schemes

Solana and NEAR use FROST Ed25519; EVM uses DKLS23 ECDSA with EIP-191; Zcash uses FROST RedPallas; Bitcoin uses FROST secp256k1 and a BIP-340 signature over PairKey’s tagged message digest. Solana and NEAR have distinct destination-separated keys.

The verification box shows the exact signed message. Approval additionally binds identity, key, destination/path, request ID, rules revision and expiry. The audit trail includes that public request. Read Signing schemes for the target chain-to-scheme map.

Progress follows evidence

A wallet, passkey or Google prompt is not signer completion. Both signer cards remain pending during authorization, show joint work after job admission, and become verified only after the hosted result and matching receipt pair return. Individual MPC round timings are not reported.

History is retained in this browser tab. Saved results are labelled as saved until recovered; a stored success flag does not establish fresh receipt verification. Failure after submission can be uncertain. “Recover last submitted job” reads the saved attempt without another approval, commit or signing round.

Fresh signature verification

The Verify button asks the service to recompute verification from the displayed message, public key and signature. Editing an input invalidates the previous verification status. This checks mathematical signature validity, not an independent trust anchor for the service.

For independent verification of the original approval, signature and both signer receipts, save the transcript from the audit trail and use the offline Rust verifier with trusted deployment identities.

Use your signature

A message signature can be verified by a relying application off-chain. It is not a transaction and does not require broadcasting. To execute a chain transaction, construct and authorize the correct chain-specific payload and submit separately.

Development status

This page requires the coordinated v2 backend. Development workers report hardware_backed: false; independent TEE deployment is a separate production requirement. Wallet, passkey and Google sources use the visitor’s own authority rather than the legacy shared demo owner. The page never receives either signer’s private shares or the operator wallet key. Live passkey signing still needs end-to-end acceptance.