Bedrock

Bedrock availability is route-specific for uniBTC bridging

Bedrock availability is route-specific: the Bedrock bridge moves uniBTC between supported EVM networks through Chainlink Cross-Chain Interoperability Protocol (CCIP), provided the selected direction has remaining capacity. The published roster covers Ethereum Mainnet, Arbitrum One, BNB Smart Chain, Mode, OP Mainnet, Mantle, Corn, Berachain, B² Network, and BOB. An externally owned account (EOA), sufficient uniBTC allowance, source-chain gas, and a quote below the displayed route cap are required before submission.

The short version: It is the supported-network scope for uniBTC bridging, using Chainlink CCIP to move the Bitcoin-backed token across chains for EOA wallets within route-specific caps.

Sending uniBTC through the five-stage CCIP workflow

The Bedrock uniBTC bridge follows five stages from wallet connection to destination-chain confirmation status.

Start on Bedrock's uniBTC screen with the EOA already set to the network holding the balance. Select Bridge, choose the source and destination, enter the amount, and read the displayed cap and fee. The first transaction grants the bridge contract enough ERC-20 allowance; the next sends the CCIP message. A sufficient prior allowance removes the approval step, leaving one source-chain signature. Bedrock then exposes the message ID, source transaction, amount, route, and settlement status, so the same record connects the two chains. The route selector shows only configured choices for that session.

Approval changes spending permission; it does not itself move uniBTC. The send transaction creates the cross-chain instruction and consumes the approved amount.

Before signing, match the amount, direction, estimated delivery window, CCIP fee, and available cap. That review determines whether the configured route remains executable.

Fees appear before the transfer starts

Bedrock displays the route quote before confirmation, combining source execution costs with the CCIP delivery fee.

Chainlink CCIP collects a single fee on the source chain. Its formula has two parts: blockchain fee and network fee. The blockchain component estimates destination execution plus L2 data availability where applicable. The network component pays the CCIP oracle infrastructure and changes with the token-pool mechanism, route class, and fee asset. Bedrock shows the combined quote before the send signature, so no destination gas payment is requested during that bridge submission. More context is available in Using Bedrock.

The defined CCIP schedule gives useful anchors. Lock-and-unlock transfers carry a 0.045% network fee when LINK pays, or 0.05% with another supported fee asset. Static-mechanism lanes from Ethereum to a non-Ethereum chain use 0.45 USD in LINK or 0.50 USD otherwise; the reverse direction uses 1.35 USD or 1.50 USD. A non-Ethereum-to-non-Ethereum lane uses 0.225 USD or 0.25 USD. These are network components, not complete Bedrock quotes, because destination gas and data-availability inputs remain in the blockchain component.

Read the quote after selecting both chains. Changing either endpoint changes the lane, destination execution estimate, and potentially the token-handling tier.

The ten-network roster behind Bedrock availability

The published Bedrock bridge roster contains 10 EVM networks, each identified by a fixed decimal chain ID.

The roster names Ethereum Mainnet (chain ID 1), Arbitrum One (42161), BNB Smart Chain (56), Mode (34443), OP Mainnet (10), Mantle (5000), Corn (21000000), Berachain (80094), B² Network (223), and BOB (60808).

The roster describes network eligibility, not a full-mesh promise. Ten networks create 90 mathematically possible one-way pairs before route configuration, capacity, and lane status are considered. Bedrock availability therefore belongs to the selected direction, not merely to two names appearing in a list. Ethereum-to-Arbitrum and Arbitrum-to-Ethereum are separate lanes, with separate quotes and capacity checks. The connected interface resolves that distinction by restricting each destination menu after the source is chosen.

Use the decimal ID to confirm the wallet network, then use the route selector to confirm that uniBTC movement exists in the intended direction.

Route caps define executable availability

A route cap is the remaining uniBTC capacity assigned to one source-and-destination direction at submission.

For anyone starting out, Bedrock applies the cap to each directional lane and displays the usable balance in real time. The interface rejects an entered amount above that value before it creates a CCIP message. Capacity changes as bridge traffic consumes or restores the allocation, so a static number in an article would not describe the next transaction. The operative test has one comparison: entered uniBTC must be less than or equal to the displayed route capacity. Reopening the form refreshes the decision input before approval or sending.

One chain pair produces two cap checks because A-to-B and B-to-A are different directions. Available capacity in one direction does not establish capacity in the reverse direction.

Split transfers still face the cap at every submission and add another source transaction and fee quote. The next decision is whether the displayed lane can carry the intended amount now.

Why is my listed network pair unavailable?

Five checks explain an unavailable Bedrock route: direction, capacity, wallet type, token deployment, and transaction funding.

• The destination is not enabled from the selected source.
• The entered uniBTC amount exceeds the displayed route cap.
• The connected address is a contract account rather than an EOA.
• The wallet is on another chain or shows a different token deployment.
• The source account lacks allowance or the network's native gas asset.

Resolve the checks in that order because each one controls the next interface state. Select the source chain first, then inspect the destination menu rather than assuming the reverse route exists. Compare the amount with the live cap, confirm that the connected address is an EOA, and match the chain ID to the network holding uniBTC. Finally, leave enough native gas for approval when needed and for the send transaction. A route becomes actionable only after all five conditions pass together.

If the destination disappears after changing the source, the interface has identified a lane limitation. Choose an enabled direction or wait for that exact route's capacity or status to change.

EOA wallet support and gas requirements

Where it matters, Bedrock limits this uniBTC bridge to EOAs and charges transactions on the selected source network. An EOA uses one private key rather than contract code to authorize a transaction. MetaMask can connect that account type, while a Safe smart account is a contract account and falls outside the supported wallet scope. The account needs ETH on Ethereum Mainnet, Arbitrum One, Mode, OP Mainnet, and BOB; BNB on BNB Smart Chain; MNT on Mantle; BTCN on Corn; BERA on Berachain; and BTC on B² Network. Destination gas is also needed for any later transaction involving the received uniBTC.

CCIP messages, finality, and transfer history

Each accepted Bedrock transfer produces one CCIP message ID that follows the route through destination settlement.

On EVM routes, the message ID is a 32-byte value, displayed as 64 hexadecimal characters after the prefix. It links the source transaction with CCIP processing and the destination result without replacing either chain's transaction hash. Bedrock shows the ID, amount, source, destination, and status, while the Chainlink CCIP Explorer follows the same message across the lane. This record separates a submitted source transaction from a completed destination delivery.

Importantly, Bedrock presents 5–20 minutes as the estimated range, but actual completion follows source finality, CCIP processing, destination execution, and lane conditions. Track a pending transfer by its message ID before submitting another, because a second send creates a second independent message and fee.

The user fit for route-based uniBTC access

This availability model suits uniBTC holders who need direct, traceable movement among Bedrock-supported EVM deployments.

It works cleanly when the holder controls an EOA, already owns uniBTC on an enabled source, and intends to use the same asset on a listed destination. Bedrock availability is less about finding any chain with a uniBTC contract and more about finding a funded directional lane. The route selector, cap, fee quote, and CCIP message record provide the four inputs that decide whether to proceed.

A destination outside the roster requires a separate asset or bridging path, which changes contracts and operating assumptions. Within the roster, choose the chain where uniBTC has the intended downstream use, then confirm that the selected direction, capacity, and native gas balance support the transfer.

7 August 2026 Updated