Solv reserves back SolvBTC with Bitcoin and supported wrapped Bitcoin assets

Reserve deposits support issuance and create a matching claim

SolvBTC is a reserve-backed token whose minting and redemption rules connect circulating units with underlying Bitcoin value. A supported deposit supplies backing, while issuance creates the corresponding token claim. Native Bitcoin deposits require confirmation before the approval and minting stages. The receiving wallet holds newly issued SolvBTC only after approved mint execution.

The backing relationship continues after issuance, even when a holder transfers the token or supplies it to another application. Moving a reserve token does not itself move the underlying native Bitcoin to the recipient. SolvBTC can exist on multiple chains under a unified reserve model. That makes the scope of a supply total important: a balance on one chain describes that deployment, while a protocol-wide comparison needs the corresponding combined claims.

Native Bitcoin and wrapped reserves introduce different dependencies

The reserve framework separates core assets from innovative assets, which carry additional controls. Reserve categories describe policy, while allocation describes the assets actually held.

Open full-size image

Core assets still have distinct custody arrangements

Native BTC and BTCB belong to the framework's core category. Native Bitcoin remains an asset on Bitcoin mainnet, whereas BTCB is a wrapped Bitcoin representation. Sharing a reserve category does not give them identical custody mechanics. For any wrapped holding, the reserve depends on the wrapper's relationship with its underlying Bitcoin as well as Solv's control of the wrapped tokens.

Innovative assets have admission controls

The framework lists WBTC, FBTC, cbBTC, BTC.b, and tBTC as innovative reserves. It applies minting caps and cross-chain rate limits to this category. Those controls constrain exposure or movement; they do not replace the wrapper's backing and redemption arrangements. Eligibility permits use under the applicable rules, while allocation information identifies the assets actually supporting issued tokens.

Compare Bitcoin-equivalent backing with the same supply scope

Reserve coverage is a relationship between backing value and outstanding token claims, measured on a consistent basis. SolvBTC's stated reserve model assigns one Bitcoin-equivalent unit of backing to each token. A dollar-denominated total and a token count cannot establish that relationship without a conversion basis. The comparison needs compatible units, matching reporting times, and a clear definition of the claims included.

Wrapped reserves require attention to valuation as well as quantity. A wrapper's intended Bitcoin relationship and its traded value can diverge during stressed conditions. Where a report values wrappers at intended parity, realizable value still depends on their market and redemption conditions. Reserve information should make its valuation basis understandable. Outstanding redemptions also matter when the supply definition excludes already-burned tokens whose payouts remain incomplete.

Bitcoin price exposure continues despite matched backing

A fully backed Bitcoin-denominated holding still changes in value when Bitcoin's price changes against another currency. Falling dollar value can occur without a reduction in the Bitcoin units backing each SolvBTC. Conversely, a higher dollar reserve total can reflect Bitcoin appreciation rather than additional backing. Market value and coverage answer different questions. The traded price of SolvBTC may also differ from its stated reserve relationship when market liquidity or redemption expectations change. Available market liquidity and the executed sale price determine the proceeds from a particular sale.

Custody controls govern who can release reserve assets

Reserve security includes control over asset movement, alongside the presence of assets in custody. Solv's Bitcoin-mainnet architecture and its on-chain liquidity architecture handle different execution environments. Their safeguards need to be understood within the custody system holding the relevant backing.

Threshold signing protects Bitcoin transaction authorization

SolvBTC's FROST custody design requires multiple signing participants to authorize a Bitcoin transaction. Participants hold separate signing shares, and the design avoids reconstructing the private key on a single participant. Signing also needs enough participants to remain available. Solv's migration design allows legacy storage and the FROST system to coexist during transition. The architecture alone therefore cannot establish that every reserve balance already uses the final custody arrangement.

Vault permissions restrict on-chain asset movement

Solv Guard adds permission restrictions to Safe smart-contract wallets. Its configuration identifies permitted target contracts and operations, with additional access checks where configured. Governance can change authorizations and upgrade relevant controls. These permissions limit what an operator may execute; they do not establish reserve quantity or remove governance dependence. For a wrapped reserve holding, both the vault's permissions and the wrapper's underlying custody remain relevant.

Available backing and available withdrawal liquidity differ

Redemption liquidity concerns the assets an eligible exit path can actually deliver under its conditions. After a standard on-chain redemption request is accepted, the contract burns submitted SolvBTC and creates a redemption record. The system allocates corresponding reserve assets before the holder claims them. A Redemption SFT, or semi-fungible token, represents the request's state and claim eligibility.

The separate whitelisted swap design supports conversion within one on-chain transaction for authorized callers, subject to its configured controls. This restricted path does not establish an instant exit available to every holder. The selected redemption path determines caller eligibility, the payout asset, and processing conditions separately from the aggregate backing figure.

Reserve reporting and contract audits establish different facts

Reporting describes backing within its stated scope

Solv's transparency presentation distinguishes SolvBTC circulation, backing, proof-of-reserves information, and audit material. Reserve observations concern assets and their valuation at the reporting time. On-chain oracle reporting can make reserve information available to applications, but an oracle still depends on its data and methodology.

A reserve balance alone cannot establish the absence of other claims over those assets. Ownership, restrictions, and outstanding obligations affect what the reported backing can support.

Contract audits examine particular code and controls

Solv's audit collection covers different components, including token contracts, routers, and vault controls. A contract audit concerns the code and version within its review scope. Reserve balances and individual payouts require separate observations. Neither substitutes for understanding the custody arrangement and exit conditions governing the holding.

Token backing differs from protocol-owned reserve fundraising

The Bitcoin Reserve Offering design concerns institutional fundraising for a protocol-owned Bitcoin reserve, with SOLV conversion terms. A fundraising target or announced allocation does not establish an observed SolvBTC reserve balance. Likewise, liquid staking through xSolvBTC adds a distinct strategy and withdrawal relationship, even where Bitcoin backing remains relevant. Deciding whether reserve information supports a SolvBTC holding starts with identifying the reserve assets and obligations it covers.