# SolvBTC Mainnet Architecture

### Overview

SolvBTC is a Bitcoin-based custody and asset mapping protocol. Users deposit BTC into protocol-managed Bitcoin addresses and receive SolvBTC on Ethereum and other EVM-compatible chains at a 1:1 ratio. SolvBTC provides the foundational custody and issuance layer for BTC-based liquidity, DeFi participation, and related integrations.

The protocol continuously monitors Bitcoin deposits, processes minting and redemption requests, and manages Bitcoin transactions through a distributed threshold signing network based on FROST (Flexible Round-Optimized Schnorr Threshold). Around the FROST Network, SolvBTC incorporates a Vault Pool, onchain smart contracts, an Indexer, and Auditors to support the complete lifecycle of BTC custody and asset issuance.

***

### Architecture and Core Components

<figure><img src="/files/xI6cfgSqBTi6og2nKiaX" alt=""><figcaption></figcaption></figure>

<p align="center"><sub>SolvBTC Architecture for Bitcoin Mainnet</sub> </p>

<p align="center"></p>

SolvBTC consists of the following core components:

* FROST Network
* Vault Pool
* Onchain Smart Contracts
* Indexer
* Auditors

These components work together to observe onchain events, assemble protocol state transitions, and execute Bitcoin and EVM transactions throughout the asset lifecycle.

***

### FROST Network

The FROST Network is based on the FROST (Flexible Round-Optimized Schnorr Threshold) signing protocol, as specified in IETF RFC 9591. As an internationally standardized threshold Schnorr scheme designed for the Taproot era, FROST provides a formally specified and interoperable foundation for distributed Bitcoin signing.

Within the SolvBTC protocol, the FROST Network manages all Bitcoin signing keys and enables multiple independent nodes to collaboratively produce valid Bitcoin signatures through threshold Schnorr signing.

In the SolvBTC architecture, the FROST-based signing setup is designed to support custody separation at the address level, allowing active Vault addresses and cold storage addresses to be managed under a consistent signing security model. This enables assets to be distributed across different custody layers without changing the underlying trust assumptions.

#### Signing Key Management

When a Bitcoin transaction requires authorization, FROST nodes collaborate using their signing secret shares to produce a valid threshold Schnorr signature.

* Each FROST node holds an independent signing secret share
* Signing secret shares are generated via a distributed key generation process
* No single node can independently produce a valid transaction signature
* Multiple nodes cooperate to complete threshold Schnorr signatures

This mechanism enables ongoing transaction signing under distributed key management without centralized private key storage.

#### Address Generation and Management

As new deposits are accepted by the protocol, the FROST Network generates and manages Bitcoin deposit addresses.

* Bitcoin deposit addresses are generated and managed by the FROST Network
* Signing secret shares associated with each address are held independently by network nodes
* Address generation and subsequent signing operations follow a unified management process

#### Transaction Signing Execution

When BTC needs to be transferred from a Vault address, the FROST Network executes the signing process. Transaction signing depends on the availability of a sufficient subset of FROST nodes.

* The network constructs the corresponding Bitcoin transaction
* Nodes generate signature results based on the transaction content
* Signature results are aggregated into a complete transaction signature
* The signed transaction is broadcast to the Bitcoin network

***

### Vault Pool

The Vault Pool is a collection of Bitcoin addresses managed by the FROST Network and used to receive and store user-deposited BTC.

#### Vault Address Allocation

When a user initiates a deposit, the system allocates an address from the Vault Pool.

* Address selection considers current balance, capacity limits, and distribution strategy
* The selected address is returned to the user to complete the BTC transfer

#### Vault Capacity and Rotation

As BTC accumulates in a Vault address and approaches its capacity limit, the system updates address usage and allocation.

* Each Vault address has an asset capacity limit (e.g., 1000 BTC)
* Addresses nearing capacity are no longer used for new deposits
* New Vault addresses may be generated and added to the pool, or a portion of assets may be transferred to designated cold storage addresses under the same threshold signing configuration
* Addresses no longer receiving deposits remain available for fund management and subsequent transfers

The Vault Pool design supports transfers between active Vault addresses and designated cold storage addresses under the same threshold signing configuration. These addresses share identical signing authorities and security assumptions, ensuring that asset movements do not alter the protocol’s security model.

***

### Onchain Smart Contracts

SolvBTC deploys smart contracts on Ethereum and other EVM-compatible chains to manage SolvBTC minting and burning.

#### Mint Contract

When the Indexer detects and validates a confirmed deposit, it submits a Mint request to the contract.

* Mint requests include the Bitcoin transaction reference and the target EVM address
* The contract processes the request and updates the SolvBTC supply
* Minted SolvBTC is assigned to the user’s address

Different deposit amounts may follow different processing paths.

#### Burn Contract

When a user initiates redemption by burning SolvBTC, the Burn contract processes the request.

* The user calls the Burn function and specifies a Bitcoin receiving address
* The contract burns the corresponding amount of SolvBTC
* A Burn event is emitted with redemption parameters
* Subsequent BTC transfer processing continues offchain

#### Governance and Contract Control

The SolvBTC protocol applies governance mechanisms to control critical onchain contract operations. Governance is scoped according to the **nature and impact of the operation**, rather than enforced through a single uniform model.

* **Execution-level operations**, such as minting and burning, are primarily constrained by onchain contract logic and predefined execution rules. Certain execution paths additionally rely on approval workflows described in the Auditors section.
* **Protocol-level operations**, including contract upgrades and parameter changes, are governed through broader and more deliberate governance processes. These actions are infrequent and may involve expanded participation, time-delayed execution, or community-based decision mechanisms.

For details on governance mechanisms such as multisig control and timelock configurations, see the Smart Contract Governance page under Security.

***

### Indexer

The Indexer is an offchain service that continuously monitors blockchain activity relevant to the SolvBTC protocol.

#### Bitcoin Network Monitoring

* Scans the Bitcoin blockchain
* Detects transactions sent to Vault Pool addresses
* Tracks confirmation counts and records final confirmation states

#### EVM Chain Monitoring

* Monitors Mint and Burn contract events
* Extracts transaction hashes, amounts, and user addresses

#### Data Processing and Request Assembly

* Validates transaction formats and parameter completeness
* Assembles standardized Mint and Burn requests
* Submits standardized requests into the approval workflow
* Coordinates request readiness for subsequent execution

***

### Auditors

Auditors review and approve critical protocol operations. Auditors may consist of multiple independent entities operating under shared approval policies.

#### Approval Workflow

* Receive Mint and Burn requests submitted by the Indexer
* Verify the onchain transaction information included in each request
* Complete approval according to current policy
* Generate executable instructions upon approval

#### Coordination with Signing Execution

* Approved requests are forwarded to the FROST Network
* The FROST Network performs the corresponding threshold signing operation
* Bitcoin transactions are broadcast after signature completion

\
Auditors operate under predefined protocol policies and do not modify onchain contract logic or governance configurations.


---

# 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.solv.finance/solvbtc-mainnet-architecture.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.
