What fails today
- Trusted servers become coordination chokepoints
- Communication channels reveal participant relationships
- Air-gapped workflows do not translate cleanly across distance
- Existing tools often assume proximity or infrastructure trust
Remote multisig coordination
Coordinate multisig across distance without exposing participants.
Keylay is a coordination layer for remote multisig setup and signing. It is built to reduce trust in the coordination layer itself.
Designed for adversarial environments. Useful anywhere multisig participants are not in the same room.
- No custody of funds
- Supports air-gapped workflows
- No account required
- Open source · Publicly auditable
problem
wallet security improves with multisig; coordination still leaks trust and metadata
session
a short code connects participants without accounts or persistent identity
workflow
QR and file exchange support air-gapped signers and offline devices
transport
encrypted relay works today; Nostr is planned as the primary transport
The problem
Multisig removes a single-key point of failure. But coordination remains the weak point.
Multisig protects funds against a single compromised key. But coordination remains the weak point. Remote participants are often pushed toward ad hoc messaging, centralized services, or in-person exchange.
Those workarounds introduce trust assumptions, leak metadata, and tempt users to break air gaps. In ordinary settings that is friction. In adversarial settings it is a real security failure.
Keylay treats the coordination layer as a potential adversary, not just a convenience layer. No accounts, no database or stored server-side state, no persistent identity, and a planned move to Nostr as the primary transport all follow from that assumption: the path between participants may be observed, recorded, or controlled, and the tool should not require trusting it.
What Keylay changes
- Remote participants can coordinate without surrendering wallet isolation
- The coordination layer is treated as a security issue, not just a convenience issue
- The workflow remains browser-based and compatible with offline device use
How it works
A coordination layer, not a custody layer.
Keylay helps remote participants exchange the information needed for setup and signing while keeping sensitive operations on their own devices.
The current implementation routes browser-encrypted messages through a WebSocket relay. Planned future versions use Nostr relays as the primary transport, with WebSocket retained as fallback.
Participant A
Wallet / signer device
QR or file exchange
Keylay
Session code
Current: browser-encrypted WebSocket relay
Planned: Nostr primary
No custody of funds
Participant B
Wallet / signer device
QR or file exchange
1
Create a session
The initiator creates a session and shares a short code with remote participants.
2
Exchange coordination data
Participants exchange descriptors, PSBTs, and related files through the encrypted relay — as QR codes for air-gapped devices, or as direct file transfers.
3
Keep signing local
Signer devices operate locally. Private keys do not leave the devices that hold them.
4
Complete the workflow
Participants coordinate across distance without needing shared physical presence, and with less trust placed in the infrastructure between them.
Use cases
Built for hard cases. Useful for ordinary ones too.
High-risk environments
- Distributed custody under surveillance risk
- Cross-border coordination where trust is limited
- Journalists, activists, NGOs, and diaspora fund organizers
- Participants who cannot safely rely on centralized coordination tools
Even when funds are secured by multisig, the setup and signing process can still reveal who is involved, how they coordinate, and what infrastructure they depend on. Moving toward Nostr as the primary transport reduces exposure to any one relay operator; it does not by itself hide who is talking to whom.
General use
- Families or teams sharing multisig custody
- Business partners in different locations
- Remote cosigners who want cleaner air-gapped workflows
- Bitcoin users who want less trust in the coordination layer
Alpha
Keylay is usable today for real remote coordination workflows across desktop and mobile browsers. The current implementation is already concrete enough to evaluate, while the next steps are clear and bounded.
Current
- Encrypted sessions — X25519 key exchange with AES-256-GCM; the relay never sees plaintext
- Authenticated handshake — session codes double as authentication; HMAC-signed public keys prevent relay key substitution mid-handshake
- Supported payloads — PSBTs, BSMS files, JSON, and arbitrary binary or text files
- Air-gapped exchange — BBQr and UR (BC-UR) animated sequences, both encode and decode, so a PSBT or wallet descriptor can be shown to or read from an air-gapped signer in either format; received UR data decodes to real files (PSBT, transaction, or a coordinator-importable descriptor)
- Browser-native use — modern browsers only; no install, no accounts, no database or stored server-side state (the relay keeps session state in memory only)
- Mobile support — tested on Android and iOS
- Protocol v2 (since v0.9.0) — both participants must run v0.9 or later; a v0.8 client and a v0.9 client cannot connect to each other. If you self-host the app, update your copy — the current release hash is on the verify page
Planned
- Near-term — client security fixes from the October 2026 external report (findings E5–E9, listed on the security page) and a fix for the self-hosting Content-Security-Policy (CSP — the browser rule list that says which servers the page may connect to) problem; comparison-code pairing (a short code both people compare to confirm they reached each other — challenge/response pairing); more wallet guides (Sparrow + Coldcard Q available)
- Next — Nostr transport, with WebSocket kept as a fallback (removes dependence on a single relay operator; relays still see connection metadata); sessions with more than two participants (a declared signer count with numbered slots for cosigner data, so the descriptor can be assembled in the browser without a separate session per signer)
- Longer-term — resumable/asynchronous sessions (participants online at different times); PWA support (progressive web app — installable mobile use without an app store); a memory-hard KDF (key-derivation function that makes guessing session codes more expensive; blocked on browser support); CSP hash-pinning (the page allows only scripts that match published fingerprints); an independent third-party security audit
Presented at Blockchain Commons' Gordian Developers meeting (August 2026) and TABConf 8 (October 2026).