# 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).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.stroom.network/stroom/phase-1-native-staking/stroom-bridge.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.