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 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 or trusted infrastructure.
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 dependence on any one relay operator and better fits environments where surveillance resistance matters.
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 animated sequences (full encode/decode) and UR/QR sequences (decode only; encode to Keystone/Passport not yet supported)
- Browser-native use — modern browsers only; no install, no accounts, no server-side state
- Mobile support — tested on Android and iOS
Planned
- Nostr transport — Nostr relays become the primary channel; WebSocket remains as fallback. Unlike a centralized relay, Nostr cannot be taken down, surveilled at the infrastructure level, or controlled by a single operator.
- Wallet guides — step-by-step setup and signing flows for major wallet and coordinator combinations
- Persistent sessions — named, resumable sessions for reconnecting collaborators
- PWA support — installable mobile use without an app store
- Multi-party sessions — sessions with a declared signer count and slot-based key collection; each participant submits their cosigner data to a numbered slot, enabling in-browser descriptor assembly once all slots are filled and eliminating the need for separate per-signer sessions during wallet setup