Bedrock is a Multi-Asset Liquid Restaking Protocol Supporting uniBTC Deposits and Claims

The network mismatch that breaks a clean deposit

The deciding condition is route support: choose a network and deposit asset the uniBTC interface lists together before approving any contract.

The common mistake is to treat a visible uniBTC token deployment as proof the same chain accepts deposits and processes claims. Those capabilities are separate. Ethereum mainnet uses chain ID 1 and the familiar WBTC contract, while Rootstock uses chain ID 30 and exposes RBTC in the Bedrock route. A wallet must show the intended chain, input ticker and exact protocol contract before signing. MetaMask can switch networks, yet a token balance shown on one network says nothing about route capacity on another. The interface's active asset selector is the operational boundary for that transaction.

Checking chain ID 1 before an Ethereum WBTC deposit keeps the approval, mint and later balance record in one ledger.

Preparing the wallet and wrapped BTC amount

A clean uniBTC entry begins with the correct wallet account, selected chain, listed wrapped BTC and enough native gas for both transactions.

Connect and select

Connect the account intended to hold the position, then choose the network before choosing the asset. On Ethereum, ETH pays gas while WBTC supplies the deposit value. The displayed Pay token, Receive token and exchange ratio should all describe the same route before any signature leaves the wallet.

Approve the vault

Wrapped BTC follows ERC-20 allowance rules. The first transaction authorizes the Bedrock vault to transfer a specified amount from the wallet; it does not mint uniBTC. Setting the allowance equal to the intended deposit keeps the permission bounded. If an existing allowance already covers the amount, this step disappears and only the mint transaction remains. A lower allowance needs a separate approval before the vault can call transferFrom.

Mint and record

After approval settles, enter the amount and review the quoted uniBTC output. The documented WBTC route represents deposits at a 1:1 token ratio and the vault accepts wrapped assets using 8 or 18 decimals. There is no published protocol deposit floor, although 0.005 WBTC is the documented economic threshold intended to keep transaction costs proportionate. The deposit itself produces one mint transaction. For an 18-decimal input, any remainder below the 10^10 conversion base does not mint an additional uniBTC unit.

Save the mint transaction hash with the selected chain and wallet account; those three facts locate the new position without relying on a frontend cache.

How should the uniBTC balance be read?

The uniBTC balance should be read as eight-decimal ERC-20 units held by the connected address, separate from any pending redemption record.

Wallet balance

uniBTC uses 8 decimal places, so its smallest displayable unit is 0.00000001 uniBTC. MetaMask can import the token so the wallet displays it, but importing adds only metadata. The authoritative quantity comes from the token contract's balanceOf result on the selected chain. WBTC also uses 8 decimals, which keeps its base-unit conversion direct on the original Ethereum deposit path. The same eight-place convention applies when the router records amounts.

Position status

A wallet balance describes liquid uniBTC still held at that address. A submitted unstake is recorded separately by the delayed-redeem router, so the interface distinguishes available, pending, claimable and completed amounts. Once uniBTC moves into a pending request, it no longer belongs in the freely transferable wallet balance.

Transaction record

An EVM transaction hash occupies 32 bytes and appears as 64 hexadecimal characters after the prefix. Etherscan, the Rootstock explorer or another chain-specific explorer can show whether approval, mint, unstake and claim transactions succeeded. A token balance alone does not identify which action created it. Matching the wallet address, chain ID and transaction hash reconstructs the position state cleanly.

Adding to or reducing the position

A routine uniBTC adjustment is another mint or a partial unstake, and the contract treats each action as a new transaction.

Adding wrapped BTC repeats the allowance check and mint call; it does not alter the earlier transaction. Reducing the position starts a new redemption record for only the chosen amount, leaving the remaining uniBTC transferable. The documented unstake floor is 0.0001 uniBTC, equal to 10,000 of uniBTC's 0.00000001 base units. A first reduction with no router allowance therefore needs two wallet transactions: one approval and one request. With sufficient allowance, the request needs one. Using Max commits the entire available balance, so a partial adjustment requires a typed amount below that balance and below the displayed capacity.

Submitting the unstake request

A valid uniBTC exit starts with a supported output asset, an amount at or above the interface minimum and available redemption capacity.

Choose the output

The Unstake view asks for the network, amount and wrapped BTC output. Bedrock displays the expected return, lock period and available cap before confirmation. The amount must be at least 0.0001 uniBTC and below the capacity shown for that route. Capacity is a live constraint, so the interface value at submission controls whether the request proceeds.

Approve the request contract

The withdrawal router needs an ERC-20 allowance for the uniBTC being committed. Approval changes allowance only; the tokens remain in the wallet until the request transaction executes. Review the spender and amount as separate fields. Reusing an adequate allowance removes one signature, while increasing the requested amount beyond it restores the approval step.

Create the pending record

The request transaction transfers uniBTC into the delayed-redeem router and appends a record under the connected address. That record contains the amount, creation timestamp and selected output token. It is pending immediately after confirmation, even if the wallet's uniBTC balance has already fallen. The later claim belongs to the same address and does not follow a subsequent uniBTC transfer. Sending uniBTC elsewhere after request creation therefore does not move the queued record or its eventual output.

Record the request transaction rather than the approval transaction, because its timestamp starts the wait and its address owns the claim.

When does a pending request become claimable?

A pending uniBTC request becomes claimable when its recorded creation time plus the configured redemption delay has passed on-chain.

The published uniBTC user flow describes an 8-day unlock, while the deployed router exposes a configurable delay instead of hard-coding eight days. The delayed-redeem router accepts a configured delay from 0 seconds through 30 days, whose upper bound equals 2,592,000 seconds. The request's displayed timestamp and status therefore decide the actionable claim time. One protocol day equals 86,400 seconds for the router's capacity accounting, and its configurable daily-cap ceiling is 1,000 uniBTC. That ceiling is not the available capacity shown to a user; the active cap, outstanding debt and elapsed day buckets determine the remaining amount.

Claimable and completed are different states. The interface marks a mature record claimable, but wrapped BTC reaches the wallet only after a separate claim transaction succeeds. The router processes eligible records from the oldest uncompleted entry forward and groups amounts by output token during the claim. The completed counter then advances and the corresponding uniBTC is burned as the wrapped asset transfers to the requesting address.

The contracts beneath the interface

The uniBTC lifecycle is split across a vault, the ERC-20 token contract and a delayed-redeem router with distinct state changes.

Seven fixed parameters explain most balance and claim arithmetic. Values such as route capacity, gas price and the configured delay still come from the transaction screen or on-chain state, while the parameters below define precision and hard bounds. The table covers EVM deployments.

On deposit, the vault uses transferFrom to move an allowed asset and then calls the uniBTC mint function. Eight-decimal inputs map directly; 18-decimal inputs are divided by 10^10, aligning them to uniBTC's 8-decimal precision. Chainlink Proof of Reserve data participates in the vault's reserve check, and a failed configured reserve condition stops minting. The implementation builds on OpenZeppelin contracts while the position represents Bedrock's Bitcoin restaking route involving Babylon.

On exit, the router holds the requested uniBTC, stores a 32-bit creation timestamp and later asks the vault to transfer the chosen 8- or 18-decimal wrapped asset. It then burns the matching uniBTC amount. Those separate calls explain why approval, request and claim appear as distinct records, and why the same connected address must return to finish the lifecycle.