Solv is a Bitcoin reserve layer for DeFi

Solv is a system that turns Bitcoin held in reserve into blockchain tokens for lending, trading, and other automated finance. Its core asset, SolvBTC, represents one fully backed unit of Bitcoin reserve and moves through defined minting, custody, bridging, and redemption rules. FROST threshold signing distributes control of native BTC, while proof of reserves shows backing. The trade-off is reliance on operators, governance, contracts, bridge routes, and the custody models of accepted wrapped Bitcoin.

Choosing SolvBTC for Bitcoin liquidity across chains

A reserve-backed SolvBTC balance fits when the goal is entering DeFi across several chains without first selling the underlying Bitcoin exposure on an exchange.

That fit depends on four linked questions: what reserve asset enters, where SolvBTC will be used, how the position exits, and which intermediaries remain. Native BTC enters a Bitcoin custody pipeline. WBTC, BTCB, FBTC, cbBTC, BTC.b, or tBTC instead enters through an accepted on-chain reserve route. The minted token then works as collateral, settlement inventory, or liquidity on supported networks. Those choices determine whether multi-chain convenience compensates for the added operational layers. The comparison changes again if the destination application accepts only one representation or offers materially deeper liquidity for another.

The 1:1 reserve relationship is an accounting promise between SolvBTC supply and accepted backing, not a guarantee that every exchange pool stays exactly at parity each block. Secondary-market price follows pool liquidity and available arbitrage. Direct redemption follows protocol schedules and eligibility. A holder seeking composability should weigh both exit routes before treating the token as interchangeable with self-controlled native BTC.

SolvBTC is most useful when chain reach, standardized liquidity, and contract integration matter more than direct control of Bitcoin keys.

Where does the custody risk actually sit?

The custody risk in SolvBTC spans native BTC signing, wrapped reserve issuers, Safe Vault permissions, cross-chain bridges, and redemption operations rather than one contract alone.

The documented reserve model separates backing into 2 categories. Native BTC and BTCB sit in the core reserve category, while WBTC, FBTC, cbBTC, BTC.b, and tBTC sit in the innovative category. Solv applies minting caps and cross-chain rate limits to innovative reserves, and governance controls those parameters. Proof of reserves tests aggregate coverage, but the backing mix determines which external custody and bridge assumptions support that coverage. A reported 1:1 total therefore says how much backing exists, while classification shows what kind of backing carries the claim. For a worked version, see Solv walkthrough.

FROST removes whole-key storage from any single signing node because each participant holds a secret share. The effective model still turns on the signer roster, actual threshold, node availability, Auditor policy, and operational approval process. Wrapped reserve assets add their own issuer rules before Solv's contracts or Bitcoin signing layer enters the flow.

Custody exposure falls when native BTC dominates backing, reserve categories remain visible, and redemption capacity stays aligned with outstanding SolvBTC.

Redemption rules set the real exit path

An ordinary SolvBTC exit follows a standard burn-and-claim workflow, while a single-transaction whitelisted swap serves approved protocol integrations for atomic settlement only.

A standard request burns the submitted SolvBTC and creates 1 Redemption SFT, a state-bearing receipt that tracks processing and claim eligibility. Reserve assets move from the Safe Vault after allocation, and the holder then claims them. Whitelisted contracts follow a different path: an approved address burns SolvBTC and receives a reserve asset atomically.

The published user schedule groups requests from Sunday through Saturday, a 7-day window, and processes that batch on the next Monday. A holiday moves processing to the following business day. The published standard redemption fee is 0%, while minting fees vary by deposited wrapped asset because reserve conversion creates different costs. Network gas and bridge execution remain separate charges. Exit speed changes when approved integrations use the atomic path or deep secondary liquidity supplies an earlier market sale.

What do you need before minting SolvBTC?

Minting SolvBTC requires an accepted Bitcoin asset, a compatible wallet, destination-chain gas, and exact agreement between the selected network and token contract.

EVM wallets distinguish networks through fixed chain identifiers. Ethereum mainnet uses chain ID 1, BNB Chain uses 56, Arbitrum One uses 42161, Base uses 8453, and Avalanche C-Chain uses 43114. Each network has its own SolvBTC contract and gas asset, even when the ticker looks identical. An EVM address contains 20 bytes and is written as 40 hexadecimal characters after the prefix, so network selection remains a separate decision from address formatting.

• Use MetaMask or Rabby for compatible EVM routes.
• Use Phantom when the selected route ends on Solana.
• Hold the destination network's native asset for gas.
• Select a reserve asset accepted by that minting pool.
• Match the displayed contract to the chosen network.

On EVM deployments, SolvBTC uses 18 decimal places, while Bitcoin displays BTC at 8 decimal places and 1 BTC equals 100,000,000 satoshis. That encoding difference does not change the 1:1 reserve relationship; it changes how contracts represent balances and round small amounts. The preferred entry route changes if the intended DeFi application accepts another Bitcoin representation more directly.

Collateral, settlement, and yield are separate decisions

Collateral, settlement, and liquidity use SolvBTC as a common reserve balance, while yield exposure starts only after entering a separate vault or strategy. Related products such as xSolvBTC and BTC+ add their own accounting, net asset value rules, portfolio mandates, and redemption terms. Chainlink and RedStone price feeds support integrations where protocol accounting needs external values. Return expectations change when the base token enters one of those additional product layers.

WBTC, cbBTC, tBTC, and native BTC solve different problems

Among Bitcoin representations, SolvBTC prioritizes a unified multi-chain reserve, whereas WBTC and cbBTC emphasize issuer-backed liquidity, tBTC emphasizes distributed custody, and native BTC preserves base-layer control.

Native BTC uses Bitcoin's UTXO model and keeps settlement on its base layer, but it does not call EVM applications directly. WBTC follows a custodian-and-merchant structure, cbBTC is issued by Coinbase, and tBTC uses Threshold Network's distributed signing model. BTCB supplies a Bitcoin-linked asset on BNB Chain. SolvBTC differs by accepting several reserve forms behind one token and coordinating issuance across Ethereum, Solana, Stellar, and other supported networks.

The choice turns on custody preference, chain reach, collateral acceptance, market depth, and redemption mechanics. Native BTC fits direct base-layer control, while a wrapped asset fits when a specific protocol already supports its contracts and liquidity. SolvBTC gains relevance when one reserve model must span several execution environments.

FROST signing and the five-part issuance stack

For native Bitcoin deposits, SolvBTC combines a FROST Network, Vault Pool, on-chain contracts, Indexer, and Auditors to turn confirmed transactions into authorized mints.

Those 5 components divide responsibility. The Vault Pool holds protocol-managed Bitcoin addresses. The Indexer watches Bitcoin and EVM events. On-chain contracts mint or burn SolvBTC. Auditors approve policy-governed state changes, and the FROST Network signs Bitcoin transfers. The documented native mint path contains 5 steps from deposit through mint execution, while redemption uses another 5 from burn initiation through BTC broadcast. Separation makes events traceable while creating dependencies between observation, approval, and signing.

RFC 9591 specifies FROST as a 2-round threshold Schnorr protocol in which a threshold of participants produces 1 aggregate signature. Bitcoin's BIP 340 format uses 32-byte x-only public keys and 64-byte Schnorr signatures. Those constants explain the cryptography, not Solv's actual node count or signing threshold. The custody model becomes stronger when operational parameters, signer availability, and governance actions remain transparent.

Governance and reserve ownership remain separate

Governance decisions use SOLV for voting and staking incentives, while SolvBTC represents Bitcoin reserves; holding one token does not create a claim on the other.

Once the basics are settled, SOLV began with a genesis supply of 8,400,000,000 tokens. Its documented 9,660,000,000 maximum is dynamic because governance can authorize additional issuance for Bitcoin Reserve Offerings, so it is not a permanent hard cap. This distinction matters when evaluating supply exposure: SOLV tokenomics affect governance and incentives, while SolvBTC backing depends on reserve assets, custody, and redemption. SolvBTC makes the most sense when multi-chain composability and a defined reserve path outweigh a preference for direct native BTC control.

Quick answers about Solv