The interBTC bridge is fully decentralized: anyone can run a Vault.
As many as want to participate.
One honest and online Vault is enough to allow users to move BTC to Polkadot. A user can even be their own Vault. The more Vaults, however, the better.
Definitely! Please only use one unique key per client to avoid race conditions on signing. Additionally, if a Vault is started using the same key name as another that was already running it will load the same Bitcoin wallet and may attempt to transfer "locked" funds. If this happens the Vault may not have enough funds to back locked KBTC/IBTC.
Yes! Vaults earn fees in KBTC/IBTC and KINT/INTR.
Vaults should remain online to check for issue and, most importantly, redeem requests.
Currently, Vaults have 24 hours to execute a redeem request.
As such, a Vault must come online at least once every 24 hours.
We recommend Vaults remain online to avoid failing redeem requests in times of high network load on Bitcoin.
Vaults must lock up collateral equivalent to the locked BTC value based on the network thresholds.
The Vault will be slashed a punishment fee and the user can (i) chose to retry with another Vault or (ii) claim the Vault's collateral.
If a Vault fails to fulfill a redeem request on time, it incurs a punishment fee (paid to the redeeming user) and can be liquidated, at the choice of the redeeming user. Vaults can freely move around BTC (e.g. between hot and cold storage) they have received, as long as they execute redeem requests on time.
An earlier version of the protocol had a "theft reporting" feature which prevented Vaults from moving BTC, unless there was a redeem/replace request. Theft reporting was removed here in accordance with this post-mortem since it does not add to the economic security of the bridge and with the purpose of improving Vault flexibility. The proposals to enact this change were successfully executed on Kintsugi and Interlay.
The Vault must re-balance its collateral. If it fails to do so, the interBTC bridge has a multi-stage collateral scheme in place. See here for more details.
Vaults utilise the local Bitcoin Core full-node for key management.
Each Vault must submit a Bitcoin public key (the "master" key) when registering with the interBTC bridge. When the Vault (re)starts it will check that this key is still held by the Bitcoin wallet.
!> Never transfer funds manually from the Bitcoin wallet.
Each time a user requests to issue new interBTC, the interBTC bridge uses the master key of the selected Vault to derive Bitcoin addresses (controlled by this Vault) via an on on-chain key derivation scheme. This address is used by the user for the BTC deposit.
While unlikely, if all Relayers go offline the interBTC bridge will pause operation.
The Vault does not have sufficient BTC to process outstanding requests, this is likely due to the overpayment of Bitcoin fees relative to what was allocated by the parachain - when the Vault spends from more UTXOs it will cost more. You MUST transfer additional BTC to cover fees as specified here. We plan to assign treasury funds to reimburse Vault operators as well as improve the on-chain estimations.
On startup, the Vault will check that your Bitcoin full node still has access to the key it registered with. If this is not the case, something may have happened to your wallet file.
Sometimes it is not possible for Bitcoin to estimate the transaction fees for redeem requests.
To avoid this happening, set a sensible default on startup such as -fallbackfee=0.0002.
The secp256k1 elliptic-curve dependency used for generating Vault addresses requires a newer version of Clang. Please download the latest available version for your distribution or check the minimum supported version in the build instructions.