> For the complete documentation index, see [llms.txt](https://docs.stroom.network/stroom/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stroom.network/stroom/phase-1-native-staking/stroom-bridge.md).

# 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

| Component                         | Role                                                                                                                  |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **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).