How BTCVM works

BTCVM is a Bitcoin-compatible chain running on Metal Blockchain, joined to Bitcoin by a one-for-one BTC bridge. This page covers how BTC moves, what it costs, and what you're trusting.

The chain

BTCVM uses Bitcoin's transaction format, script language and consensus rules, with SegWit and Taproot active from its first block, and Bitcoin Core's standard relay policy, except that fees are a thousandth of Bitcoin's and there is no dust limit. It runs as its own Layer 1 on Metal Blockchain, whose Snowman consensus makes a transaction final as soon as it is in a block, usually in under a second (the home page shows the live median). There is no mining and no reorganisation to wait out, though during the alpha the chain has one validator, so finality rests on that one operator's node. There is no mining reward either: BTC exists on BTCVM only through the bridge's peg reserve.

A key has the same address on Bitcoin and on BTCVM, whatever the address type: 1…, 3…, bc1q… or bc1p…. The wallets use native SegWit (bc1q…) addresses. The two balances are separate: coins on one network move to the other only through the bridge.

The bridge

Deposits: Bitcoin to BTCVM

Every wallet gets its own Bitcoin deposit address, a bc1q… address. Its script names your BTCVM address and is spendable only by the peg signers, so the bridge knows who to credit and nobody else can move the coins. Your wallet derives this address itself from the signers' public keys and refuses to show one that doesn't match. Once Bitcoin has confirmed it enough for its size (…), the same amount, less the bridge fee, is released to you on BTCVM from the peg reserve.

The web wallet can make the deposit for you from your Bitcoin balance. You can also send to your deposit address from any Bitcoin wallet or exchange.

Withdrawals: BTCVM to Bitcoin

A withdrawal sends BTC back to the peg reserve with a note naming a Bitcoin address. Once it's final on BTCVM, the signers pay that address from the BTC locked on Bitcoin, less the Bitcoin network fee at Bitcoin's current fee rate. Payouts are replaceable (BIP125): if one is still unconfirmed after 30 minutes and fees have risen, the bridge replaces it with one paying the current rate. The replacement spends the same coins, so the withdrawal can only be paid once.

Proof of reserves

Every BTC on BTCVM is backed by BTC locked on Bitcoin. The explorer lists every locked output, each linked to a public Bitcoin explorer, next to the amount circulating on BTCVM. The bridge refuses to move anything unless the locked BTC covers what circulates plus what's pending.

Fees, limits and timings

Live from the bridge:

Confirmations before a deposit is credited: …. A Bitcoin block comes about every 10 minutes, at random.
Bridge fee on each deposit: … BTC
Bitcoin network fee on each withdrawal: about … BTC today, at … sat/vB; it follows Bitcoin's fee rate
Smallest deposit: … BTC
Largest deposit (alpha): … BTC; larger ones are held for a refund
Most BTC on BTCVM in total (alpha): … BTC
Smallest withdrawal: … BTC
Signers: …
Peg address on Bitcoin: …

Sending on BTCVM costs 1 satoshi, whatever the amount, and is final within seconds. You can send as little as 1 satoshi. A Bitcoin block comes about every 10 minutes, at random, and a slow one can take much longer.

The site measures that speed live. For every payment sent through this site, the bridge times how long it takes from receiving the payment to accepting the block that holds it. On BTCVM, an accepted block is final. It checks four times a second, so a figure can be up to a quarter of a second slow, never fast. The home page shows the median of the last 50 payments, and /api/status reports the median, the 90th percentile and the latest (finality).

Where fees go

In short: fees on BTCVM go to its validators, and the withdrawal fee goes to Bitcoin's miners. The bridge keeps nothing.

Fee	When you pay it	How much	Who gets it
Network fee	Any payment on BTCVM	1 satoshi	The validator that built the block
Bridge fee	Each deposit	… BTC	The validator that built the block (it's the fee of the transaction that credits you)
Withdrawal fee	Each withdrawal	about … BTC today	Bitcoin's miners (it pays for the payout on Bitcoin)

With several validators, each sets its own fee address. Metal takes turns choosing which validator proposes each block, weighted by stake, and that validator collects the fees in it. So fees spread across validators roughly in proportion to their stake. BTCVM only makes a block when there are payments, so a validator's share also depends on traffic. The alpha has one validator; support for more isn't deployed yet.

How BTCVM compares

	Bitcoin	BTCVM	Lightning
Smallest payment	294–546 satoshis (the dust limit)	1 satoshi	1 satoshi (thousandths inside channels)
Fee for a payment	Hundreds of satoshis at 1–5 sat/vB, far more when blocks are full	1 satoshi, whatever the amount	Often 0–1 satoshi plus about 0.01–0.1% of the amount, more through some wallets
Final after	About 10 minutes per block; an hour for 6 confirmations	Seconds; final under Snowman consensus (the alpha has one validator)	Seconds, if a route is found
Setup	None	None: ordinary Bitcoin addresses, and the receiver can be offline	Channels and liquidity; the receiver must be online
Who holds the BTC	You	You on BTCVM; the BTC behind it is locked on Bitcoin under the peg signers (2 of 3)	You, in channels

Lightning fees depend on the route and the wallet; the figures are typical.

No fee is destroyed or leaves the peg. Fees paid on BTCVM stay there as ordinary BTC, backed by BTC locked on Bitcoin like any other. The bridge's signers aren't paid from fees yet.

Trust and limits

Alpha, with real BTC. The bridge is new and hasn't had an external audit. During the alpha, one operator holds all of the bridge's signing keys, so you are trusting that operator. Caps and daily limits are enforced by the signer software; they don't limit what someone holding the keys could take. The chain has one validator. A pause that other signers can trigger, support for more validators, and the hardening work on the roadmap aren't deployed yet. Keep amounts small. See the alpha terms.

Custody. The BTC locked on Bitcoin and the reserve on BTCVM are held by a 2-of-3 multisig of peg signers. Any two of them could move it. During the alpha, one operator holds all of the bridge's signing keys, so you are trusting that operator: the multisig doesn't yet protect against them, or against someone who takes their keys. Moving the keys to independent operators is planned, as the next step on the roadmap; the software and setup ceremony for it are built.
What the signers check. Each signer checks every transaction against the chains and signs only what is owed, exactly as it would build it. While one operator holds every key, these checks guard against mistakes and a faulty coordinator, not against that operator; with independent operators, each will check through its own nodes.
Caps. During the alpha, each deposit and the total on BTCVM are capped, which limits how much the bridge credits. Caps and daily limits are enforced by the signer software; they don't limit what someone holding the keys could take: anyone holding two of the three signer keys could move every coin at the peg and deposit addresses, including deposits held over the cap. Keep amounts small.
Pause. The bridge can be paused in an emergency: nothing is signed or paid, and the site shows why. Deposits and withdrawals made while paused are processed after it resumes. Only the operator can pause it today; a pause that other signers can trigger remotely isn't deployed yet, and a pause doesn't stop someone who has stolen the keys.
Refunds. A deposit that can't be credited, for example one over the alpha limit, is held on Bitcoin and can be refunded. Refunds are approved by the operator; to request one, use the contact details in the terms, with the deposit's transaction ID and the Bitcoin address to refund to.
Backups. The bridge's keys and settings are backed up daily, encrypted to a key held off the server, and a backup can be restored and checked against the live keys.

Wallets

In the browser. The bridge page is a wallet: your key is made in the browser and never leaves it. Protect it with a passkey, for example one saved in 1Password, and opening the wallet takes the passkey. Passkey protection needs a passkey provider that supports the PRF extension; older security keys don't. Every coin a payment spends is checked against the raw transaction that created it, so the server can't inflate a fee. Before anything is signed, the wallet shows what the payment does (who's paid, the change back to you, a withdrawal's Bitcoin address, and the fee), read from the transaction itself, and signs only once you confirm.

On a Mac. The Mac app (alpha, version 0.1.2, signed and notarized by Apple) keeps the key encrypted to the Mac's Secure Enclave, asks for Touch ID for every payment, and imports from a Bitcoin Core wallet.dat, whose keys are read on the Mac and never sent anywhere.

The web wallet is open source, in the BTCVM repository (cmd/btcvm/web).

Whichever you use, back up your key. It's your wallet on both networks, and without it the BTC can't be recovered.

For developers

The bridge serves a JSON API at this site, used by both wallets:

GET  /api/info                 network, fees, limits and signers
GET  /api/status               both chains' heights, sync, the peg audit
GET  /api/reserves             every locked output on Bitcoin
GET  /api/activity             recent deposits and withdrawals
GET  /api/address/{address}    BTCVM balance, outputs and history
GET  /api/tx/{txid}            a BTCVM transaction, described
GET  /api/block/{height|hash}  a BTCVM block
GET  /api/deposits/{address}   deposits for a BTCVM address
GET  /api/pegout/{txid}        a withdrawal's status
POST /api/deposit-address      {"address": …}: your deposit address
POST /api/tx                   {"hex": …}: broadcast on BTCVM
GET  /api/health               checks, for uptime monitors
POST /api/btc/watch            {"address": …}: follow a Bitcoin address
GET  /api/btc/address/{address} its Bitcoin balance, coins and history
POST /api/btc/import           {"address": …, "txid": …}: add an older payment
GET  /api/btc/rawtx/{txid}     a Bitcoin transaction's bytes
POST /api/btc/tx               {"hex": …}: broadcast on Bitcoin
POST /api/btc/scan             {"addresses": […]}: find coins (a job)
GET  /api/btc/scan/{id}        that job's progress and coins found

The source, including the chain, the bridge, the web wallet and the deployment scripts, is on GitHub.

Security

Please report vulnerabilities privately through GitHub's security advisories, not in a public issue.