BTCVM
Mac app
BTCVM technical roadmap
BTCVM is a Bitcoin-compatible chain running as a Layer 1 on Metal Blockchain, joined to Bitcoin by a one-for-one BTC bridge. This page covers what is built today, how it works, what it doesn't do yet, and the order in which we'll close those gaps.
Where it stands. The chain, the bridge and the web wallet are built for Bitcoin: Bitcoin's rules with SegWit and Taproot from the first block, SegWit deposit addresses, payouts at Bitcoin's live fee rate that can be replaced if they're slow, all tested against btcd's script engine. The software for independent signers, and the ceremony that brings them in, are built too. BTCVM launched as an L1 on Metal mainnet on 25 September 2026, and this site is served by it. The bridge runs on separate signers, and the first mainnet round trip completed on 26 September 2026: deposits credited on BTCVM, and a withdrawal paid back to Bitcoin.
Done: the first round trip
A small amount goes each way on mainnet: a deposit from Bitcoin, credited on BTCVM, then a withdrawal paid back to Bitcoin. Each step has a transaction on each chain, visible in the explorer, and proof of reserves matches throughout: BTC locked on Bitcoin equal to BTC circulating on BTCVM plus deposits waiting to be credited.
- Deposits: done. On 26 September 2026 two deposits from the web wallet were credited on BTCVM, each two minutes after its second Bitcoin confirmation, signed by separate signers. Proof of reserves matched: 0.00033828 BTC locked, 0.00033828 BTC on BTCVM.
- Withdrawal: done. A withdrawal of 10,000 sats was paid on Bitcoin seconds after it was final on BTCVM, signed by separate signers, and confirmed in block 968,622 (6ea8e5ad…).
What is built
| Component | What it does | State |
|---|---|---|
| BTCVM L1 | Bitcoin's transaction, script and consensus rules, with SegWit and Taproot active from the first block, and Bitcoin Core's relay policy, except that fees are a thousandth of Bitcoin's (a payment costs 1 satoshi) and there's no dust limit (you can send 1 satoshi), with Snowman consensus: a transaction is final once it is in a block, in seconds. No mining reward. | Built |
| Peg reserve | BTC is created only in the chain's reserve blocks, which consensus enforces. That supply is locked to the peg signers and released only against BTC locked on Bitcoin. | Built |
| Bridge | Watches both chains. It credits deposits after enough Bitcoin confirmations for the amount (2 up to 0.001 BTC, 3 up to 0.005 BTC, 6 above), and pays out withdrawals once they are final on BTCVM, at Bitcoin's current fee rate. A payout still unconfirmed after 30 minutes is replaced with one paying the current rate, spending the same coins. It stops moving funds if the solvency check fails. Tested against btcd's script engine. | Built |
| Web wallet | One key, one native SegWit (bc1q…) address on both networks: Bitcoin and BTCVM balances side by side, and a one-click move between them. Keys stay in the browser, optionally encrypted to a passkey, and every payment is shown for review, read from the transaction itself, before it's signed there. The page checks the deposit address and every coin it spends itself, rather than trusting the server. It installs as an app on Mac, iPhone and Android. | Built |
| Explorer | Shows bridge activity with the transaction on each chain, proof of reserves output by output, and BTCVM blocks, transactions and addresses. | Built |
| Monitoring | Checks the peg, overdue transfers, both nodes and the validator's fee balance every minute, and sends Telegram alerts. | Built |
| Separate signers | A signer service for each key holder, and btcvm signer-setup, the ceremony that brings new signers in. The tests run the ceremony, then a deposit and a withdrawal signed by separate signers. The bridge runs on them: a coordinator with no keys and three signers, each its own service, user and Bitcoin wallet, on one server for now. Independent operators follow. | Running |
| macOS wallet | A native Mac app for both networks: review every payment before it's signed, Touch ID for each signature, the key kept encrypted to the Mac's Secure Enclave, signed automatic updates, and importing keys from a Bitcoin Core wallet.dat, swept into the app's own address. Built and tested against Bitcoin Core; being tried out before its first release. | Testing |
| Bitcoin node | The bridge's own Bitcoin Core node, which the bridge and the wallet's Bitcoin balances read. It runs pruned: it checks every block but keeps only recent ones, about 100 GB. Synced with Bitcoin on 26 September 2026. | Running |
BTCVM's VM ID on Metal Blockchain, from the name btcvm:
- VM ID
- kMtihm7W3KssmcJb9mzwZfC6gkiPrJhWaa5KMLHdEB9R8Q4pp
How BTC moves
Every BTC on BTCVM is backed by BTC locked on Bitcoin, and anyone can check both sides. The bridge enforces one invariant: locked on Bitcoin ≥ circulating on BTCVM + pending. If that ever fails, it stops.
Deposit: Bitcoin to BTCVM
- The wallet gives each user a personal Bitcoin deposit address, a P2WSH (bc1q…) address that any wallet can send to. Its script commits to the user's BTCVM address, followed by a 2-of-3 multisig of the peg signers. The browser derives the address itself and refuses to show one that doesn't match.
- After enough Bitcoin confirmations for the deposit's size (6 by default, about an hour; smaller deposits may need fewer), the signers release the same amount from the peg reserve to the user's BTCVM address, less the bridge fee. The release is tagged with the deposit it pays for, so a deposit can't be credited twice.
- Deposits over the beta cap, or arriving while the total is at its limit, are held and can be refunded on Bitcoin.
Withdrawal: BTCVM to Bitcoin
- The user sends BTC back to the peg reserve with a tag naming a Bitcoin address.
- Once that transaction is final on BTCVM, which takes seconds, the signers pay the Bitcoin address from the locked BTC, less the Bitcoin network fee at Bitcoin Core's current two-block estimate, kept within the signers' policy range. The payout usually confirms in about 10 minutes.
- 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 only one of them can confirm.
Who holds the keys
The peg is a 2-of-3 multisig: any two of the three signer keys together can move funds. Those keys control both sides of the bridge.
On Bitcoin
The locked BTC: the peg address and every personal deposit address. These are the real coins users sent in.
On BTCVM
The reserve created by consensus in the chain's first block. Releasing it is how a deposit is credited, so it decides how much bridged BTC exists.
Two key holders acting together could take the locked BTC, or credit BTC with nothing behind it. The defence is independence: separate people, on separate machines, each checking the chains through their own nodes.
In the separate-signer design, the bridge process holds no keys. It proposes each transaction, and every signer checks it against its own view of both chains:
- The action is really owed: a confirmed deposit not yet credited, a final withdrawal not yet paid, or a refund its operator approved.
- The transaction is exactly the one the signer would build itself, down to every amount and address.
- The signer has not already signed another transaction that could pay the same thing twice.
- It stays within that signer's own daily limit.
A compromised bridge server can then delay transfers but can't move locked BTC.
Signing is automatic. Each signer is a service that applies these rules by itself, so deposits and withdrawals go through in the time it takes to reach the required confirmations, with no one approving them by hand. People act only to approve refunds and to change the rules, which means a new signer set that every operator joins.
Bringing signers in: the setup ceremony
btcvm signer-setup takes each operator through setup. Only public information changes hands: no private key, password or token is ever sent to anyone. It runs interactively for a person, or with flags for automated operators. Without a terminal, the join step requires the fingerprint the operators confirmed, so no script can approve a signer set on its own.
| Step | Who | What happens |
|---|---|---|
init | Each operator | Makes a key on their own machine, or imports one at a hidden prompt, and produces a public signer card signed with that key. |
coordinator | Bridge operator | Makes the key that signs every request to the signers. |
assemble | Bridge operator | Checks the cards and builds the signer set: the keys, how many must sign, the networks, the fees and caps. Prints a short fingerprint. |
join | Each operator | Shows the set; operators confirm the fingerprint with each other on a call; writes a ready-to-install service. |
check | Anyone | Checks the key, both nodes, sync, and that the service refuses unsigned requests. |
Each operator runs a full Bitcoin Core node, a BTCVM node and the signer service. The tests run the whole ceremony, then a deposit and a withdrawal signed by separate signers.
How far the trust can be spread
Releasing locked BTC will always need a threshold of signers: Bitcoin's script can check signatures and time locks, but not what happened on another chain. So the bridge can be decentralised, with many independent signers, but not made trustless on the Bitcoin side until Bitcoin itself changes. What can change is how many parties must collude, who they are, and what it costs them.
| Stage | What you trust | State |
|---|---|---|
| One operator | The beta: three separate signers, but all on one server run by one operator. The caps limit what's at risk. | Today |
| Independent signers | That fewer than the threshold of known, separate key holders collude: 2 of 3, then 3 of 5. | Staged |
| Metal validators as signers | That no two-thirds of the chain's own validators collude: the same assumption that secures BTCVM itself. | Planned |
| Bonded signers | As above, but signing anything the rules don't allow forfeits collateral worth more than the signer could take. | Planned |
| Deposits on proofs | No one, for deposits: validators check the Bitcoin deposit themselves. Signers only guard withdrawals. | Planned |
What an operator runs. Metal validators already run metalgo, so a signer adds a pruned Bitcoin Core node (about 100 GB), BTCVM on their node, and the light signer service. The plan is to package all of it as one install, plus the ceremony.
Two limits. A Bitcoin multisig script holds at most 20 keys, so a larger signer set needs threshold signatures, where many signers produce one ordinary signature together. And every change to the signer set moves the locked BTC to a new multisig address, which is what key rotation does.
Safety built in today
- Consensus-enforced supply. Blocks that create reserve BTC in the wrong amount, to the wrong address or at the wrong height are invalid, so no other code path can create BTC.
- Solvency check before every action. The bridge audits both chains and moves nothing unless locked BTC covers circulating BTC plus pending transfers.
- Beta caps. A cap on each deposit and on the total circulating on BTCVM, so the most that can be at risk is known in advance.
- A wallet that checks the server. The browser verifies deposit addresses and the value of every coin it spends against the raw transactions, caps fees, and computes transaction IDs itself. A strict content security policy limits what the page can load.
- Refunds and alerts. Held deposits can be returned on Bitcoin. Health checks alert on insolvency, overdue transfers, stalled nodes and a low validator balance.
- No secrets in the source. Every commit and push is scanned for private keys, tokens and passwords, both locally and in CI, and GitHub push protection is on. Keys live only on the machines that use them.
- Tests. Consensus, VM, bridge and wallet tests, including one that runs the browser's signing code and checks its transactions against the Go script engine.
Known limits
These are the gaps between today's beta and a bridge that can hold significant value. Every phase below closes one or more of them.
| Limit | Why it matters | Closed in |
|---|---|---|
| Signer keys aren't yet held by independent operators | Until they are, the 2-of-3 multisig doesn't protect against a single operator. The software and setup ceremony to fix this are built; switching over needs independent operators. | Phase 3 |
| One validator | The chain stops if that node stops, and consensus is only as trustworthy as one operator. | Phase 3 |
| The signers credit deposits | Two signers acting together could credit BTC on BTCVM that isn't backed on Bitcoin. | Phase 5 |
| No external audit | The bridge and consensus changes have only been reviewed internally. | Phase 4 |
| A single Bitcoin node | The bridge sees Bitcoin through one node it runs itself. | Phase 4 |
| Beta caps | Deliberate for now; they're raised only once the items above are done. | Phase 7 |
Roadmap
Each phase ends at a check anyone can verify, and the next phase starts only once it passes.
-
Build for Bitcoin
Done- BTCVM on Metal Blockchain's current release, with Bitcoin's chain parameters and rules, SegWit and Taproot active from the first block, Bitcoin Core's policy with 1-satoshi fees and no dust limit, and the consensus-enforced peg reserve.
- Bridge with personal SegWit deposit addresses, payouts at Bitcoin's live fee rate, replaceable payouts, a solvency audit, caps, refunds and a health monitor, tested against btcd's script engine.
- Web wallet with native SegWit addresses, explorer and proof of reserves.
-
Prove the round trip
Done- DoneLaunch the L1 on Metal mainnet, and serve this site from it.
- DoneThe bridge's Bitcoin node, pruned Bitcoin Core, synced with Bitcoin.
- DoneThe first mainnet deposits, credited on BTCVM (above).
- DoneThe wallet's one-click move from its Bitcoin balance, reviewed and signed in the browser.
- DoneThe first withdrawal, paid back to Bitcoin.
- DoneHTTPS, and daily encrypted backups of the keys, bridge state and the deposit registry, with copies off the server, and a restore checked against the live keys.
Done when each direction has transaction IDs on both chains, visible in the explorer, and proof of reserves matches.
-
Remove single points of failure
Partly built- BuiltSigner service. A bridge process that holds no keys, and a signer service per key holder that checks every transaction against its own nodes before signing, with a signing log and a daily limit.
- BuiltSetup ceremony (
btcvm signer-setup): cards, a signer set with a fingerprint, service files and health checks. The existing keys can be imported, so the peg address and the funds stay where they are. - DoneMove the bridge onto them. Each key in its own signer service and a coordinator that holds none, with the peg address unchanged.
- NextIndependent operators. At least two people or organisations besides us, each running their own Bitcoin and BTCVM nodes and a signer, brought in through the ceremony. Then grow from 2-of-3 to 3-of-5.
- NextMetal validators as signers. A one-command install of the signer, a Bitcoin node and BTCVM for Metal validators, who already run the infrastructure. Grow to 5 to 7 validator signers with a two-thirds threshold, so the bridge is secured by the same operators as the chain.
- BuiltKey rotation. A new signer set names the one it replaces; the old signers, retired, move the locked BTC and the reserve to it, and later deposits to old addresses are moved and credited too. Next: rotate the live peg onto keys made by independent operators, retiring the beta's keys.
- NextHardware-backed storage for signer keys.
- NextAt least three validators run by different operators, with a validator manager, so validators can be added and replaced without relaunching the chain.
Done when no single machine or operator can move locked BTC or halt the chain.
-
Audit and harden
Planned- An outside security review of the consensus changes, bridge and wallet signing before larger amounts, then fix what it finds.
- Have signers cross-check Bitcoin through more than one node.
- More transfers from separate wallets, including a deposit over the beta limit, held, and its refund.
- BuiltAn emergency pause that stops all signing, and a written runbook for incidents, refunds and restoring from the daily encrypted backups. Next: rehearse it once, and a public bug bounty.
- Bonded signers. Each signer locks collateral that is forfeited if they sign anything the rules don't allow. Theft stays possible in principle, but it becomes costly.
- Delays on large withdrawals. Withdrawals above a set size wait a few hours before they're paid, giving the monitor and the other signers time to pause the bridge if anything looks wrong.
Done when the audit report is published with every finding closed or explained.
-
Deposits without signers
Planned- A BTCVM upgrade in which the validators follow Bitcoin's block headers themselves, and the reserve releases a deposit's BTC only with proof that the deposit is buried enough blocks deep in Bitcoin's chain.
- No signer is involved in crediting a deposit, and nobody, the signers included, can create BTCVM BTC that isn't backed by BTC locked on Bitcoin.
- Signers remain for withdrawals only. Bitcoin's script can check signatures and time locks but not another chain, so releasing locked BTC needs signers on every BTC bridge until Bitcoin itself changes.
Done when the upgrade has been audited, activated by the validators, and deposits are credited on proofs alone.
-
Native passkey accounts
Planned- A BTCVM upgrade that accepts passkey signatures (WebAuthn, P-256) alongside Bitcoin's own, as Ethereum is doing with RIP-7212. Touch ID, Face ID, 1Password, and any FIDO security key (even older U2F-only keys) can then sign BTCVM transactions directly.
- No seed phrase and no private key held in the browser: the passkey is the account, backed up and synced by the user's password manager or kept on a hardware key.
- Recovery built in: an account can name a second passkey or a time-delayed recovery key.
- Today's wallet already uses passkeys to encrypt the key. That works only where the passkey supports the PRF extension, such as 1Password. Native accounts remove that limit.
- Scope: BTCVM only. BTC on Bitcoin itself still needs a Bitcoin key, since Bitcoin's rules are not ours to change.
Done when the upgrade has been audited, activated by the validators at a set block height, and a passkey-only wallet has made a round trip through the bridge.
-
Open up
Planned- Raise the caps in steps, with the proof of reserves at each step.
- Threshold signatures. Beyond 20 signers, a Bitcoin multisig no longer fits, so every Metal validator could sign only through threshold signatures: many signers producing one ordinary signature. It's substantial cryptography, taken on once the signer set needs to grow past a multisig.
- Atomic swaps. BTCVM runs Bitcoin's own script language, so BTC on Bitcoin can be swapped for BTC on BTCVM with hash-locked payments: both sides complete, or both are refunded. It needs no bridge and no signers, only someone on the other side of the swap, such as a market maker, which makes for fast, trustless exits alongside the bridge.
- Support for wallets and developer tools beyond the web wallet: standard RPC endpoints and a documented API.
- Public infrastructure: open RPC nodes and a hosted explorer with an uptime history.
Done when the caps are lifted without new trust assumptions.
Verify it yourself
- Use the bridge and explorer at metalbtc.com. Proof of reserves lists every locked Bitcoin output, and each links to a public Bitcoin explorer.
- Read or build the source at github.com/MetalBlockchain/btc-vm, which has the VM plugin, bridge, wallet and deployment scripts.
This roadmap describes engineering work and its order; it isn't a schedule.