Kintsugi — The First 60 Days of Decentralized Bitcoin

Published in

Interlay

8 min readMay 26, 2022

“A Tale of market crashes and a resilient BTC bridging protocol”

Kintsugi is the Japanese craft of fixing broken pottery with precious metals, such as gold, silver, or platinum. When we announced our canary network for Interlay, we knew that launching the very first permissionless BTC bridge would be a daring undertaking, unusual and striking, like the Kintsugi art form Bringing something entirely new to the world is a challenging task which also requires us to meld the existing pieces of our predecessors together to create something entirely new. In this post, we want to highlight the successes but also bring attention to the golden repairs that make up the short history of the Kintsugi network.

TL;DR

Kintsugi is Market Resistant: Kintsugi’s network withstood extreme market conditions throughout the launch that included a 40% shrinking of the TVL locked in DeFi as well as the “big KSM unlocking”. No Vaults were liquidated due to price volatility.
kBTC Demand and Use-Cases: kBTC demand is very high with a volume of 39 BTC (about $1.18mm) going though the bridge. This allowed Vaults to collect fees of about 0.09 BTC in total. kBTC can be used for example on a wBTC/kkBTC stablepool in Solarbeam and in a aUSD/kBTC pool on Karura. More integrations are coming.
Lessons learned and asking for community proposal: Three major road blocks led to three golden repairs, strengthening the protocol. We are asking two Vaults to open a treasury proposal for the missing feature to replace Bitcoin transaction with higher fees when the network is congested.

Vaults at the Frontier

After only 60 days of Kintsugi, we have 55 Vaults registered on the network. For the user, this offers quite the diversity of where they can lock their BTC. This makes Kintsugi the network with the highest number of individual custodians right now.

Vaults are currently locking a total of 24 125 KSM collateral (about $2mm).
Even though KSM was unlocked during a market crash, the network remained stable and not a single Vault was liquidated due to price swings.

Not only is this a testament to the strength and security of Kintsugi, but it’s also thanks to the KSM collateral analysis we conducted prior to launch.

Golden Fixes

The true nature of Kintsugi is to see obstacles as an opportunity to strengthen what we are creating together, making the breaking points stronger than ever before. We encountered three main issues when operating Vaults that we will learn from as we move forward.

Running more than one Vault client

What happened: Unfortunately, we had two cases where the operator of a Vault client let the client run twice. When two Vault clients receive the same redeem request, they will both execute the request. This results in two separate BTC transactions that each fulfill the request. Having two BTC transactions for the same request results in having less BTC locked in the Vaults than kBTC issued and is thus flagged as theft.

Who was affected: In total, two Vaults were affected with a total of 163 KSM being slashed.

Steps taken: To make it clear that only one Vault client runs at the same time, the docs have been updated to summarize best practices for Vault operators: https://docs.interlay.io/#/vault/installation?id=dos-and-donts

Bitcoin Network Congestion and Lacking Replace-by-Fee Support

What happened: Due to the market turbulances in the week of May 9, the Bitcoin network encountered a higher number of transactions. As a result the Bitcoin network fees increased from about 2 sat/vb to 19 sat/vb.

Two Vaults each received a request by users to redeem kBTC for BTC right before the Bitcoin network fees started to rise. Vaults have 24 hours to fulfill such a request. If a user has not received their BTC after 24 hours they can chose to retry to redeem with another Vault or be reimbursed. Reimbursement means that the user burns the kBTC and receives KSM at a beneficial rate.

Both Vaults sent BTC to the users with, at the time, adequate BTC transaction fees and within the 24 hours. However, due to the rise in fees, the Bitcoin transactions just shortly after were estimated to only be included in more than 24 hours. There were over 7000 BTC transactions in the mempool at that time.

To mitigate the issue with long inclusion times, an emergency referendum was made to extend the redeem period from 24 hours to 48 hours: https://kintsugi.subsquare.io/democracy/referendum/32

However, still two Vaults were affected since their BTC transactions were only included after the redeem period had passed and the users making the request had already cancelled the initial request. This flagged both Vaults for theft.

Who was affected: In total, two Vaults were affected. One Vault was slashed for around 960 KSM but had 0.427 BTC left in the Bitcoin wallet. The other Vault was slashed for around 221 KSM with only having 0.0028 BTC left in the wallet.

Steps taken: This issues was the most critical we had faced and several steps were/are being taken:

Replace-by-Fee: By default, all Vault clients running version 1.11.0 or higher use replace-by-fee (RBF). This allows Vault operators to bump fees of their Bitcoin transactions should they get close to the redeem deadline: https://github.com/interlay/interbtc-clients/pull/293
Cap Slashed Collateral: By default, the slashed amount of thefts is now capped at the liquidation threshold of the collateral. For KSM, that is 150% at the moment. Prior to this change, thefts would slash all collateral held by the Vault.
Double Check Bitcoin Configuration: We are asking all Vault providers to check that they do not use the `fallbackfee` argument when running their Bitcoin nodes as that might default to a too low default fee when the Bitcoin network is congested.

Next steps:

Request for Community Proposals: We encourage the affected Vault operators to open a treasury proposal to reclaim their lost funds worth in KINT.

Using An Unsupported Bitcoin Version

What happened: A Vault operator used the Bitcoin Core 23 pre-release version (at the time) to register the Vault. We use an on-chain key derivation scheme to ensure that Vaults use unique addresses for each issue request. That means each user gets a unique deposit address each time. However, due to changes in Bitcoin Core 23, the Vault client failed to import the private key to the generated public address. Hence, the BTC locked with this Vault became inaccessible.

Who was affected: One Vault was affected with 16 KSM and 0.04 BTC being locked.

Steps taken: The installation instructions now contain a warning to use Bitcoin Core 22. The Vault client will also check the Bitcoin Core version on start-up and refuse to use release 23.

KBTC in Kintsugi and Beyond

We currently have about 24 BTC locked (about $700k) in the Kintsugi bridge. Users made 875 successful requests to issue kBTC and 173 successful requests to redeem BTC again. In total, we had 38 BTC moved through the bridge (about $1.1mm).

The demand for kBTC is very high as most days the bridge has almost no capacity to mint new kBTC. Since all kBTC needs to be backed by collateral (currently only KSM), the network prefers stability, especially in turbulent times, over aggressive growth. However, it is our goal to significantly increase the capacity over time using multiple collateral assets and generating long-term incentives for Vaults to deposit their capital as an economic safeguard for kBTC.

kBTC can be used natively cross-chain using XCM. Integrations with other parachains and projects include the stable pool on Solarbeam as well as the aUSD pool on Karura. More use cases are coming. Let us know any use cases and platforms you want to see integrated next in our Discord.

The Next 60 Days

Kintsugi’s security model withstood the market turbulances of the past weeks.

Such testing conditions make us confident that both kBTC and iBTC will lay the foundation for the first decentralized BTC representations for DeFi.

We are just getting started though. In the next 60 days, we have a fully packed program. Here are a few teasers:

Integrations: We are opening more XCM channels to other parachains including Parallel Heiko and others.
Multi-collateral Vaults: There are two proposals open to add KINT and xcUSDC as collateral options to Vaults. This will allow Vaults to diversify to prevent from economic risks.
Vault operators and LP: split the vault to replay transactions only and allow users to provide capital into a Vault without the need to run a client on a server

What About iBTC?

Kintsugi is the frontier in bridging. With the learnings of Kintsugi, we will launch the Interlay network within the next weeks. The sequence of events will follow this high-level sequence:

Transfer and wallet available from Day 1: Users will be able to transfer INTR and other tokens via the Dapp from the first day of the token drop.
Staking and staking rewards: A governance proposal will be created by the community to enable staking rewards. With staking rewards enabled, governance participation will be incentivized.
Activation of the iBTC bridge: Once users have staked INTR to vote with vINTR, a governance proposal by the community will activate Vault block rewards. This kicks off the launch of the iBTC bridge using DOT as collateral.

Check out the full roadmap and the current status here: https://interlay.notion.site/2fc1c75ed57a465c941f25312d629908?v=785e5fc077284625b4150ceb83df209f

About Interlay
We envision a future where blockchains seamlessly connect and interact: anyone can use any digital asset on any blockchain, trustless and without limitations. We work with Bitcoin, Ethereum, Polkadot, Cosmos, and others to expand interoperability, capital efficiency, and openness.

Our flagship product is interBTC — Bitcoin on any blockchain. A 1:1 Bitcoin-backed asset, fully collateralized, interoperable, and censorship-resistant, realizing the true free nature of BTC and decentralized finance.

Follow our Twitter, Telegram, and Discord to keep up to date with daily updates from the team.