Stroom Bridge
General architecture of the Stroom bridge
The Stroom Bridge provides a secure and permissionless mechanism for bridging native Bitcoin to DeFi ecosystems through a federated validator architecture. It is specifically designed to address two key limitations of legacy BTC bridges:
Custodial centralization risks
Inefficiency of idle BTC capital
This document outlines the bridge’s technical architecture, operational flow, and the security mechanisms that underpin its design.
🧩 Key Components
Validators (K-of-N)
A group of professional validator entities that manage and sign bridge operations.
Validators' Joint Public Keys
Shared public key derived from validator private keys, used for deposit address derivation and strBTC minting auth.
Taproot Deposit Addresses
Unique BTC addresses per user, derived from a joint public key + a user's Ethereum address.
Federated Multisig Wallet
A multisig wallet on Bitcoin, managed by a validator federation.
FROST
A Schnorr-based threshold signature protocol enabling efficient joint threshold signing by validators.
🔐 Bridging Architecture Overview
The bridge is governed by a K-of-N multisig federation. A quorum of at least
K = ⅔N + 1 validators must approve each mint or redemption payout. The signing operations are performed using FROST to produce a valid Schnorr signature from the validators' private keys.
🧠 All signatures are verifiable on-chain either in a strBTC smart contract on Ethereum or in a Bitcoin Taproot script using the joint validator public key.
🔐 Taproot Address Generation
Each BTC deposit address is unique and generated like so:
Taproot Address = tweak(joint_pubkey, user_eth_address)Signature validation on withdrawal uses tweaked private keys, ensuring validators' access to the user-specific Taproot deposit address.
Ensures only the rightful Ethereum address owner can initiate mints/redemptions tied to a BTC deposit.
🔄 Cross-Chain Message Validation
Stroom utilizes cross-chain observation, rather than relays. Validators observe both:
BTC chain for deposits
Ethereum for burns
No off-chain consensus state is shared between validators, all critical information is stored either on the Bitcoin or Ethereum blockchain. Such a design increases fault isolation and reduces complexity.
✅ All redemptions are permissionless and processed within ~1–2 block confirmations (10–20 minutes).
Last updated