Solv is a Bitcoin finance protocol for SolvBTC positions around Monday redemption

Solv is a Bitcoin finance protocol whose position workflow covers minting SolvBTC, reading the resulting balance, adjusting the liquid amount, and closing through scheduled redemption. A standard exit burns the chosen amount and places a Redemption SFT in the requesting wallet as the pending claim record. Requests submitted from Sunday through Saturday enter the following Monday batch, or the next business day when Monday is a holiday. Claiming reserve assets completes the position lifecycle after processing.

Bottom line: It is a Bitcoin finance protocol for minting SolvBTC, checking balances, adjusting holdings, and redeeming via a burn request that issues an SFT for Monday processing.

Standard redemption versus Whitelisted Swap

Standard Redemption Contracts serve ordinary SolvBTC holders, while Solv's Whitelisted Swap serves approved protocol addresses through atomic settlement. Both routes convert SolvBTC into backing assets, yet they expose different access rules, timing, and records.

The public route separates the request from settlement. After accepting a request, the system performs four principal actions: it burns SolvBTC, generates a Redemption SFT, allocates reserve assets from the Safe Vault, and lets the holder claim. Completion requires at least two user-signed transactions, covering the request and final claim; an approval can add another signature. Whitelisted Swap validates an approved caller, burns the specified tokens, and delivers the Reserve Asset atomically. Its documented six-step sequence has no deferred SFT state. The protocol-level alternative completes inside one transaction.

The burn boundary changes the asset you hold

The SolvBTC burn boundary removes the requested ERC-20 balance before the corresponding reserve assets become claimable. The accepted request issues one Redemption SFT whose token ID identifies that specific exit.

Burning commits the selected amount to the redemption workflow. The wallet therefore holds two different objects after a partial request: liquid SolvBTC for the untouched balance and an ERC-3525-based record for the amount awaiting processing. The Redemption SFT carries status and claim eligibility, and Solv describes it as a non-transferable processing credential rather than a freely tradable position.

Once processing begins, the SFT carries the claim rights that previously belonged to the burned tokens.

A position has three separate balances

A SolvBTC position contains three balance categories: liquid tokens, pending redemption value, and funded reserve assets ready for a claim. Reading only the ERC-20 line misses the other two.

Entry starts with one subscription action through a supported pool. Published storage pools pair Ethereum with FBTC, cbBTC, and WBTC; BNB Chain with BTCB; Arbitrum with WBTC; Avalanche with BTC.b; and Base with cbBTC. The router accepts the pool currency and returns SolvBTC to the connected address. Solv maintains a 1:1 reserve relationship between each SolvBTC unit and one unit of Bitcoin reserve, although the selected input asset and minting terms determine the exact subscription transaction.

Liquid SolvBTC

The liquid balance comes from the SolvBTC ERC-20 contract on the selected chain. An EVM address occupies 20 bytes and appears as 40 hexadecimal characters after its prefix. The request transaction hash supplies a separate 32-byte record, normally displayed as 64 hexadecimal characters.

Pending Redemption SFT

The pending amount sits under a distinct Redemption SFT token ID. Some wallets emphasize ERC-20 balances and omit detailed ERC-3525 metadata, so the Solv position view or a compatible chain explorer gives the clearer record. The value attached to that ID should match the accepted redemption amount.

Claimable reserve assets

The claimable balance appears after reserve allocation reaches the redemption contract. This state differs from both the remaining SolvBTC balance and the pending SFT value. A withdrawable amount signals that the final claim transaction has become available.

Can you change a pending SolvBTC redemption?

A pending SolvBTC redemption changes through cancellation and resubmission because the existing SFT does not expose an amount editor. The replacement request receives a new Redemption SFT token ID.

At contract level, cancellation identifies the record with two fields: a 32-byte pool ID and a 256-bit redemption token ID. The router takes back that SFT, revokes the associated market request, reconstructs the share value, and returns corresponding SolvBTC to its owner. Contract state, rather than a published hourly cutoff, decides whether revocation succeeds. A successful cancellation uses one transaction. Submitting the revised amount requires a second transaction, burns the new amount, and creates another token ID for the next applicable batch.

Partial exits preserve the liquid remainder

A partial SolvBTC redemption burns only the requested amount, leaving the remainder available for transfer or a later request. Adding to the position creates the opposite movement by increasing the liquid ERC-20 balance.

Each accepted redemption fixes its own SFT value. Later SolvBTC receipts do not enlarge that record, and later transfers do not reduce it. This separation makes routine adjustment arithmetic straightforward: start with the liquid balance, subtract each newly accepted burn, and track every issued SFT independently until claim or cancellation.

Worked example. In this hypothetical example, the changing inputs are a 2.400 SolvBTC starting balance, a 0.900 SolvBTC request submitted on Tuesday, and no intervening transfers. Acceptance burns 0.900 and leaves 1.500 SolvBTC liquid because 2.400 minus 0.900 equals 1.500. The wallet also receives one Redemption SFT representing the requested 0.900. Tuesday points to the following Monday, a six-calendar-day scheduled interval. After the final claim, the liquid side remains 1.500 SolvBTC.

Monday processing sets the position clock

SolvBTC standard redemption uses one weekly processing batch, so request timing determines the wait before reserve allocation. Network confirmation and batch processing run on separate clocks.

Once the basics are settled, Solv accepts SolvBTC redemption requests from Sunday through Saturday and processes the batch on the following Monday. That schedule creates a fixed one-to-seven-calendar-day interval before holiday adjustments. A Sunday request points to the next day, whereas a Monday request points to the following Monday. When Monday is a holiday, processing shifts to the next business day. These figures describe the scheduled batch date, not the moment when a wallet transaction confirms or the moment when the funded SFT becomes claimable.

A complete timeline therefore has three timestamps: request confirmation, scheduled Monday processing, and claim-ready status after reserve allocation.

The Redemption SFT moves through three stages

The Redemption SFT bridges three practical stages: an accepted request, allocated reserve assets, and a completed claim. Its token ID keeps one request distinguishable from another.

Request creation

The router receives the selected SolvBTC amount and requests redemption from the applicable pool. Acceptance burns that amount and transfers a newly created Redemption SFT to the requesting EVM address. The liquid token balance falls immediately.

Reserve allocation

The Fund Manager moves matching assets from the Safe Vault into the redemption path under the rules enforced by the Solv Vault Guardian. During this interval, the SFT functions as the wallet's claim record. It does not behave like an available SolvBTC balance.

Final claim

Once allocation completes, the holder submits the claim transaction. The contract transfers the relevant Reserve Asset to the designated wallet and burns the Redemption SFT. Standard completion therefore contains two essential user actions: create the request and claim the funded record.

What happens after the Monday batch runs?

From a timing perspective, SolvBTC Monday processing funds eligible Redemption SFTs, and each holder then completes a separate claim transaction. Monday processing alone does not place the output automatically in the wallet.

The Fund Manager first allocates the matching Reserve Asset from the Safe Vault to the redemption contract. The position view can then expose a withdrawable amount for the relevant token ID. Claiming transfers that asset and retires the SFT, leaving no pending record for the completed amount. A confirmed request, a processed batch, and a funded claim are therefore three different statuses. The final asset movement appears under the claim transaction rather than under the earlier burn transaction.

Network choice follows the whole lifecycle

The SolvBTC chain anchors the redemption contract, gas payment, SFT record, and claim transaction for that position. Moving the liquid token first creates a different chain context.

EVM chain identity

Ethereum uses chain ID 1, BNB Chain uses 56, Arbitrum uses 42161, Base uses 8453, and Avalanche C-Chain uses 43114. SolvBTC deployments also exist on networks such as Solana and Stellar, while cross-chain integrations use mechanisms from Chainlink, LayerZero, and Axelar. Identical-looking wallet addresses on EVM networks do not share balances because each chain maintains separate contract state. Gas also follows the selected network: ETH funds Ethereum, Base, and Arbitrum transactions, BNB funds BNB Chain, and AVAX funds Avalanche.

Native BTC destination

Native Bitcoin redemption follows a different endpoint from an EVM Reserve Asset claim. The Bitcoin-mainnet architecture records a receiving Bitcoin address, detects the EVM burn event, assembles a request, and uses the FROST Network to authorize the Bitcoin transaction. Bitcoin represents one BTC with eight decimal places, making one BTC equal to 100,000,000 satoshis. The output shown before signing determines whether the lifecycle ends with native BTC or an on-chain asset such as WBTC, BTCB, BTC.b, cbBTC, or FBTC.

The SFT lineage explains the two-asset view

The Redemption SFT reflects Solv's earlier Staking Abstraction Layer architecture, which separated liquid shares from payable claims. SolvBTC now applies that pattern to a Bitcoin-reserve redemption record.

ERC-3525 gives an SFT three coordinate types: a token ID, a slot, and a value. In this workflow, the token ID distinguishes the request, the slot groups records under compatible product terms, and the value records the redemption quantity. The liquid side remains an ERC-20 token, which explains why a wallet can show zero redeemed SolvBTC while retaining a valuable SFT.

The documented Standard Redemption Contract structure retains this SAL lineage and is marked for future redesign. Interface labels may therefore evolve, but the position logic remains readable through five events: request, burn, record creation, reserve allocation, and claim.

Solv questions, answered