How Keylay compares.
Several projects recognize the importance of remote multisig coordination and are working on solutions. This page compares Keylay with the closest of them — including where they are ahead today.
The same problem, different trade-offs.
The problem is shared: multisig participants who are not in the same room need to exchange wallet setup data and partially signed transactions without emailing files, breaking air gaps, or trusting a coordination server. At least three other projects address it seriously.
Nunchuk offers group wallets inside its mobile and desktop apps, with end-to-end encrypted coordination relayed through Nunchuk's servers. It supports asynchronous signing — members can act whenever they come online — and is the most mature product in this list. It requires an account, its coordination server is not published, and its group encryption key is derived from the wallet descriptor, so anyone who ever obtains the wallet's BSMS file can decrypt past coordination traffic.
SigningRoom is architecturally the closest project to Keylay: browser-based, no accounts, client-side AES-256-GCM encryption, a relay that sees only ciphertext, open source, and donation-funded. It handles n-signer PSBT merging in real time today and generates a client-side audit trail. Its decryption key travels in the URL fragment — a bearer secret, so anyone who ever obtains the link can decrypt the room — and its relay runs on Cloudflare Durable Objects, which self-hosting also requires. It covers signing only, not wallet setup.
Bitcoin Safe is an open-source desktop wallet with built-in encrypted chat and PSBT sync over Nostr relays, supporting both synchronous and asynchronous signing. It is a full wallet application rather than a coordination layer — participants adopt Bitcoin Safe as their software, and coordination happens inside it.
Established coordinators — Sparrow, Specter, Caravan — handle setup and signing well but leave the transport between remote participants to the user: files, messaging apps, or in-person exchange. Keylay exists to be that transport.
Feature and threat-model comparison.
The rightmost column describes Keylay's roadmap, not shipped software. Cells describing other projects are based on their public documentation and code as of July 2026 — corrections are welcome at contact@keylay.org.
| Nunchuk (group wallets) |
SigningRoom | Bitcoin Safe | Keylay (today, alpha) |
Keylay roadmap (planned, not shipped) |
|
|---|---|---|---|---|---|
| Platform | Mobile + desktop apps; account required | Browser; no accounts | Desktop app; no accounts | Browser; no accounts, no install | Unchanged; PWA install planned |
| Works with existing wallet software | All cosigners must use the Nunchuk app (hardware signers vary) | Any PSBT-capable wallet | All participants must run Bitcoin Safe (hardware signers vary) | Any wallet or coordinator that exchanges PSBTs, descriptors, or BSMS files | Unchanged; a published protocol spec would let wallets implement the session layer natively |
| Wallet setup coordination (xpubs, descriptors, BSMS) |
Free and paid tiers; members join via server-resolved invite links | Signing only | Within the app | Descriptors, BSMS files, xpubs | Slot-based multi-party key collection with in-browser descriptor assembly (Phase 2) |
| PSBT signing coordination | Supported | Real-time n-signer merging | Supported | Encrypted PSBT transport between two parties | Unchanged |
| Participants per session | n | n, in real time | n | 2 — enforced at the relay | n, via numbered signer slots (Phase 2) |
| Asynchronous signing (participants online at different times) |
Supported | Within a 24-hour room lifetime | Supported | Participants must be online together | Store-and-forward over Nostr — relays hold encrypted messages until participants reconnect; named, resumable sessions |
| Encryption and key model | NaCl; group key derived from the wallet descriptor; persistent per-device keys | AES-256-GCM; decryption key carried in the shared URL | Encrypted messages over Nostr relays | Ephemeral X25519 handshake → AES-256-GCM; HMAC-authenticated public keys | Same model over Nostr transport |
| Forward secrecy | The descriptor/BSMS file decrypts past traffic | The link decrypts the room | Not documented | Session keys are ephemeral and never stored | Preserved over Nostr transport |
| Replay protection | Not documented | Not documented | Not documented | Counter-bound messages reject replayed ciphertext | Preserved over Nostr transport |
| Air-gapped QR workflows | Hardware QR support in-app | Not offered | Hardware signers via the app | BBQr animated sequences (encode + decode); UR decode | UR encode planned |
| Transport, infrastructure, and decentralization | Nunchuk's servers; invite links resolved server-side (centralized) | WebSocket on Cloudflare Workers / Durable Objects (centralized) | Public Nostr relays (decentralized) | Encrypted WebSocket relay (single relay today, self-hostable) | Nostr relays as primary transport, WebSocket fallback (decentralized) |
| Self-hosting the relay | Server code not published | On a Cloudflare account | Any Nostr relay | Relay code published; any WebSocket host | Any Nostr relay |
| Open source | Client apps published; server not | AGPL-3.0 | GPL-3.0 | MIT | MIT |
| Status | Production; paid plans add assisted features (roles, health checks, inheritance) | v2.x; PWA, embeddable SDK, whitepaper, draft BIP | Released desktop app | Alpha; primary workflow verified across real devices | Phase 1 scope: Nostr transport, wallet guides, usability testing |
Last reviewed July 2026. Sources: Nunchuk's group wallet announcement and published client code; SigningRoom's repository and site; Bitcoin Safe's collaboration documentation. If any cell is out of date or wrong, tell us and we will fix it.
What others do better today.
Nunchuk and Bitcoin Safe support asynchronous signing — cosigners act whenever they come online — which Keylay cannot do yet. SigningRoom merges signatures from n signers in real time and produces a verifiable audit trail; Keylay sessions are currently limited to two participants, with multi-party sessions on the roadmap. All three are further along in product maturity than Keylay's alpha.
What Keylay is for.
In adversarial environments, the cryptographic layer comes before the feature set. Properties like forward secrecy and authenticated key exchange constrain a protocol's design from the start and are difficult to retrofit; features like multi-party sessions and asynchronous signing can be added to an existing cryptographic core. The current feature gap relative to the other projects on this page is a consequence of that ordering. Keylay is the only project in this list that combines a forward-secret, mutually authenticated handshake (rather than a bearer link or a descriptor-derived key), coverage of the setup phase — where key-substitution attacks live — alongside signing, animated-QR bridges for air-gapped signers inside a remote session, and a transport plan that removes every single point of infrastructure control. The security model spells out these claims, including their limits and the hardening still missing.