I’m seeking conceptual and technical feedback on a draft BIP for Stateless PSBT Coordination, designed to solve the communication gap in multisig setups without relying on trusted, stateful servers.
Currently, coordinating a multisig transaction across hardware and software wallets requires either manual file passing (USB/SD) or relying on a centralized coordinator server that logs IP addresses, xpubs, and transaction metadata.
The Proposed Standard: I’ve drafted a BIP (bip-stateless-psbt-coordination) that proposes a “Blind Relay” model. It leverages an ephemeral, end-to-end encrypted WebSocket architecture.
Zero-Knowledge: The relay server never sees the PSBT, the xpubs, or the signatures.
Stateless: The room and all associated data cease to exist the moment the room is closed or after 24hours.
Split-Key OpSec: The room URL and decryption key (#key fragment) are transported out-of-band by the users.
Implementation (Signing Room): To prove the viability of this BIP, I’ve built an open-source reference implementation called Signing Room. I just released v1.8.0, which enforces human-layer OpSec by actively separating the transport of the room link and the decryption key in the UI.
Feedback Request: I would love the community’s eyes on:
I have just realised v2.0.0 of signing room which has alot of great improvements and also has a drop in web component so anyone can integrate with one Html Tag.
This release decouples the core cryptographic and coordination logic from our main Angular client. It is a framework-agnostic TypeScript SDK designed to programmatically orchestrate ephemeral, end-to-end encrypted PSBT coordination ceremonies.
Because the SDK is unified with our standard web UI, all programmatic room creations, joins, and signature uploads sync dynamically in real-time. This opens up the possibility for headless multisig automation, such as AI agent signing ceremonies combined with a human-in-the-loop coordinator who retains finalization privileges.
Key areas covered in the walkthrough:
The architectural components and how the fit together for signing room
A quick progress update on Signing Room and the stateless PSBT coordination BIP draft.
Last week I tagged v3.4.0 of the coordinator and v1.2.0 of the SDK. The primary focus of this release is introducing Role-Based Access Control (RBAC) without introducing accounts, database state, or leaking participant identities to the relay.
Previously, the protocol operated on a binary access model (Coordinator vs. Guest), where any connected peer could download, sign, and broadcast updates to the PSBT. In institutional, legal, or high-security multisig workflows, separation of duties is critical. Transactions often require off-chain witnesses, compliance officers, or observers who need real-time verification of outputs and signatures without having the capability to submit signatures or manipulate the state machine.
To maintain zero-knowledge relay architecture:
The room initiator generates role-scoped capability tokens derived from the root session entropy inside the browser. Key material resides strictly in the URL fragment (#) and is never transmitted over HTTP.
Capability tokens encapsulate signed policy scopes (e.g., can_propose, can_sign, witness_only). The relay enforces these permissions ephemerally in RAM: if an unauthenticated socket or an observer without signing privileges attempts to dispatch a signature payload, the relay rejects the frame.
Joining clients decode their role privileges locally from their fragment token, enabling the interface to adapt deterministically (restricting signing prompts for auditors while providing verification tooling).
Sean Carlin ·