**Raise USDT ceiling for bridge**

With the USDT ceiling being reached on Kintsugi, it is suggested to increase the ceiling **by** $200,000 **to** $300,000 USDT to facilitate enough capacity for the growth of the Kintsugi bridge. 

To put this into perspective, the current ceilings in USD (prices as of 24/03/2023) are:

| Token | Current Price | Cap Native | USD Cap | % Pre-Proposal | % Post-Proposal
| -------- | -------- | -------- | --------| --------| -------- 
| KSM  | $33.61  | 60,000  | $2,016,600 | 84.8% | 78.2% 
| LKSM  | $4.40  | 55,000  | $242,000 | 10.2% | 9.4% 
| USDT  | $1.00  | 100,000  | $100,000 | 4.2% | 11.6%
| KINT  | $0.75  | 26,200  | $ 19,650 | 0.8% | 0.8%

A dedicated analysis for the asset is not required, since liquidators will receive USDT when redeeming kBTC and thus do not have any price exposure to a token that may be falling in price, which the liquidator might want to swap for a stable coin. Hence, no slippage estimation needs to be taken into account that could limit the increase in the ceiling to a lower amount. However, due to the recent depeg event of USDC and the uncertainty of centralized stable coin issues to be able to maintain the peg, it is advisable to limit the bridges exposure to USDT.


Raise USDT ceiling for bridge

Proponent/Paid to: a3bDuQajgZhVs7Z9bJxfxBNyqBqmQCZr37okVrU7NCfzABJo8
Date: 7 December 2022
Requested KINT: 912.840 
Short description: Ongoing costs for Quarter 3 (covering August to September) of 2022, for the running of a high performance and reliable data indexing managed service for Interlay.

# Original Motivation
Almost every blockchain has a need to process and query data, however everyone knows that a core weakness of blockchain data is that the processing and query performance is extremely inefficient. SubQuery is an open source platform that solves that.

Additionally, managing infrastructure can also be extremely challenging and many teams don't have the expertise or resource that is needed to deploy indexers to cloud providers and then run them at high availability so that they can be relied on for production use cases. SubQuery provides a hosted service with 99.9% reliability to remove this burden from teams,  so they can stay focused on building their dApps. 

# Costings
This proposal includes combined running costs for our infrastructure for Interlay from 1st August 2022 until 30th September 2022. The total combined running cost is USD $752.18.

[Full proposal can be found here](https://docs.google.com/document/d/1Bv6UsREPsC4_X_pMpThT4uFe7iGvA3sXT5dRCx-AR5E/edit?usp=sharing)

SubQuery Managed Service Solution (Q3, 2022)

Proposal 107 was done incorrectly and this proposal cancels 107.

Cancel proposal 107

This runtime upgrade includes the security upgrades from https://kintsugi.subsquare.io/democracy/referendum/99 and a fix in the kintsugi runtime that solves the issue of not being able to supply to a money market.

Moreover, the proposal fixes an incorrect storage initialization from runtime upgrade https://kintsugi.subsquare.io/democracy/referendum/96

The exchange rate for the lending markets need to be initialized with the default min exchange rate. However, the migrations for the min exchange rate ran after the migrations to add the markets. Hence, the markets were incorrectly initiated with exchange rates of 0.

All markets set to 20,000,000,000,000,000  (0x000082dfe40d47000000000000000000)

Storage keys:
- KSM: 0x4c82a580ac33cceba8ed9766387f22b70bb8c5c17613de2e4a943eba04ed0085b07346ecf84ec5fc071ffd603686a75b000a
- KBTC: 0x4c82a580ac33cceba8ed9766387f22b70bb8c5c17613de2e4a943eba04ed008590ba0e583e411ba5f3e2184860729bd3000b
- USDT: 0x4c82a580ac33cceba8ed9766387f22b70bb8c5c17613de2e4a943eba04ed0085d2924cfa3fa750ea617b77e20b37199c0103000000

For more details, please see the following:

https://github.com/interlay/interbtc/releases/tag/1.23.2
https://github.com/interlay/interbtc/compare/1.23.1...1.23.2

**The clients do not need to upgrade for this release**

The latest compatible clients release for this version is v1.20.0:

https://github.com/interlay/interbtc-clients/releases/tag/1.20.0

**Request to fast-track**
Due to the security nature of this proposal, we request TC fast-track.


Upgrade to runtime 1.23.2: Kintsugi lending runtime configuration

This runtime upgrade adds two security updates:

1. Disallow xcm messages containing transact as a result of the SR Labs audit
2. Allow vaults to withdraw to 0 collateral or to above the minimum collateral to prevent an incentive attack in the vault capacity model

For more details, please see the following:

https://github.com/interlay/interbtc/releases/tag/1.23.1
https://github.com/interlay/interbtc/compare/1.23.0...1.23.1

**The clients do not need to upgraded for this release**

The latest compatible clients release for this version is v1.20.0:

https://github.com/interlay/interbtc-clients/releases/tag/1.20.0

**Request to fast-track**
Due to the security nature of this proposal, we request TC fast-track.

Upgrade to runtime 1.23.1: Security updates

Proposal https://kintsugi.subsquare.io/democracy/referendum/97 was tabled and approved.

However, the proposal did not enact:
- At block 2629833: the LKSM ceiling increase proposal was made: https://kintsugi.subsquare.io/democracy/proposal/104
- At block 2634181: the governance upgrade proposal was applied (https://kintsugi.subscan.io/extrinsic/2634181-1?event=2634181-7). This upgrade deleted all existing preimages and resulted in any in-flight (the LKSM proposal above) to fail.

**Request to fast-track by TC**

As the original proposal already passed, we request to fast-track this proposal by the TC.

Fix: Increase LKSM/KBTC SystemCollateralCeiling to 55,000

This proposal suggests to update the runtime to implement the new AMM and lending market pallets and to pay 118,000 KINT as liquidity mining incentives from treasury. This is in dependence on the previously published discussion post of the [Kintsugi DeFi Hub launch]([https://kintsugi.subsquare.io/post/15](https://kintsugi.subsquare.io/post/15)). Please refer to the discussion post for further details on the derivation of the results that are to be enacted with this proposal.

Apart from the runtime upgrade the implements the AMM and lending market pallets and the incentives, this proposal will set up the following lending markets, using the suggested parameters:

| Market          | Max LTV | Liquidation LTV | Cap          | Cap in USD* |
|-----------------|---------|-----------------|--------------|-------------|
| Market #1: kBTC | 63%     | 67%             | 20 kBTC      | 520,000     |
| Market #2: KSM  | 54%     | 61%             | 30,000 KSM   | 1,069,000   |
| Market #3: USDT | 65%     | 69%             | 800,000 USDT | 800,000     |


| Market          | Base Rate | Jump Rate | Full Rate  | Optimal Utilization |
|-----------------|-----------|-----------|------------|---------------------|
| Market #1: kBTC | 0.0%      | 5.0%      | 50.0%      | 90.0%               |
| Market #2: KSM  | 0.0%      | 15.0%     | 40.0%      | 90.0%               |
| Market #3: USDT | 0.0%      | 15.0%     | 40.0%      | 90.0%               |


Furthermore, the enactment of this proposal will create the following pools in the AMM pallet and payout the aforementioned liquidity rewards over a three month period:

| Pool               | Tareget TVL (in USD) | APR at Target TVL | KINT rewards | KINT rewards (in USD) |
|--------------------|----------------------|-------------------|--------------|-----------------------|
| Pool #1: kBTC/KSM  | 500,000              | 25%               | 45,000       | 31,500                |
| Pool #2: kBTC/USDT | 400,000              | 28%               | 40,000       | 28,000                |
| Pool #3: KSM/KINT  | 150,000              | 65%               | 35,000       | 24,500                |

Specifically, with an average block time of 12 seconds, the rewards will be paid out over 662, 400 blocks (5 * 60 * 24 * 92 ~ 3 month), such that the block rewards will be:

- kBTC/KSM: 0.067934783 KINT
- kBTC/USDT: 0.060386473 KINT
- KMS/KINT: 0.052838164 KINT

(USD conversion rates as of 15 March 2023)

DeFi hub activation on Kintsugi

Currently the Collateral Ceiling for LKSM/KBTC is 38,000 LKSM and the ceiling is reached. 

This proposal increases the Collateral Ceiling for LKSM/KBTC to 55,000 LKSM. This is the recommendation from the Interlay Team. 

**Reason this the ceiling should be increased:**

- Give vault owners flexibility to increase their collateral when vault falls below threshold. As it is now the vault owners would hit a ceiling. 
- Increase Liquid KSM / Liquid staking tokens exposure to Kintsugi vaults



Increase LKSM/KBTC SystemCollateralCeiling to 55,000

Proponent/Paid to: a3bDuQajgZhVs7Z9bJxfxBNyqBqmQCZr37okVrU7NCfzABJo8
Date: 7 February 2023
Requested KINT: 1,303.5031 
Short description: Ongoing costs for Quarter 4 (covering October to December) of 2022, for the running of a high performance and reliable data indexing managed service for Interlay.

# Original Motivation
Almost every blockchain has a need to process and query data, however everyone knows that a core weakness of blockchain data is that the processing and query performance is extremely inefficient. SubQuery is an open source platform that solves that.

Additionally, managing infrastructure can also be extremely challenging and many teams don't have the expertise or resource that is needed to deploy indexers to cloud providers and then run them at high availability so that they can be relied on for production use cases. SubQuery provides a hosted service with 99.9% reliability to remove this burden from teams,  so they can stay focused on building their dApps. 

# Costings
This proposal includes combined running costs for our infrastructure for Interlay from 1st October 2022 until 31st December 2022. The total combined running cost is USD $1,040.58.

[Full proposal can be found here](https://docs.google.com/document/d/1eFPXgN5yQw6ZXVQ77hwifafFv7ilskiAyGFTopr23Ow/edit?usp=sharing)

SubQuery Managed Service Solution (Q4, 2022)

# This proposal:

- Changes the default voting threshold from negative to positive turnout bias. That means with low voter participation, we need overwhelming yay votes for a referendum to pass. With the negative turnout bias, we need to potentially motivate a lot of people to vote down a malicious referendum. With positive turnout bias, it’s sufficient to have less voters at a low quorum to reject a referendum. ([GitHub issue](https://github.com/interlay/interbtc/issues/942)) 
- Requires preimage submission before proposals can be made. This prevents proposals/referenda being voted on without actually knowing what the proposal is encoding. ([GitHub issue](https://github.com/interlay/interbtc/issues/951))

For more details, please see the following:

https://github.com/interlay/interbtc/releases/tag/1.22.0
https://github.com/interlay/interbtc/compare/1.21.10...1.22.0

The latest compatible clients release for this version is v1.20.0:

https://github.com/interlay/interbtc-clients/releases/tag/1.20.0


Upgrade to runtime 1.22.0: Governance Improvements

Proposal 94 https://kintsugi.subsquare.io/democracy/proposal/94 does not contain a preimage. As referendum #90 https://kintsugi.subsquare.io/democracy/referendum/90 confirmed, we should not allow proposals to be made without a preimage, this proposal seeks to remove proposal #94.

This is a workaround for now as a runtime upgrade will have to made to disallow making proposals without a preimage in the first place.

Remove potentially malicious proposal #94

This proposal:

1. Adds the capacity-based vault revenue distribution as outlined in https://interlay.subsquare.io/post/13
2. Updates the Polkadot dependencies to v0.9.37

Updates Kintsugi to the latest runtime (breaking).

For more details, please see the following:

https://github.com/interlay/interbtc/releases/tag/1.21.10
https://github.com/interlay/interbtc/compare/1.20.1...1.21.10

The latest compatible clients release for this version is v1.19.7:

https://github.com/interlay/interbtc-clients/releases/tag/1.19.7

Upgrade to runtime 1.21.10: Capacity-based vault revenue distribution

## Summary

We would like to register sKSM on Kintsugi as a first step towards the Kintsugi DeFi Hub launch.

## Tabling

We request that TC upgrade this proposal directly to a referendum.

## Why second try?

The first proposal failed since nobody voted: https://kintsugi.subsquare.io/democracy/proposal/91


Register SKSM as a foreign asset (second try)

The Kintsugi chain allows the submission of proposals without noting the preimage. This is outdated and should not be done as https://kintsugi.subsquare.io/democracy/proposal/94 has been added without the preimage.

A runtime upgrade should fix this.

Prevent submission of proposals without a preimage

## Proposal

Following the discussion post on Interlay [(https://interlay.subsquare.io/post/14)](https://interlay.subsquare.io/post/14), and the numerous requests by Vault operators, I propose the activation of USDT as a vault collateral on Kintsugi.

The configuration proposed (taking account analysis by the Interlay team) for USDT is as follows:

* Initial collateral ceiling: 100.000,00 USD equivalent
* Secure collateral threshold: 165%
* Premium redeem threshold: 155%
* Liquidation threshold: 140%
* Minimum collateral threshold: 150 USDT


## Resources:

* USDT Asset Registered: [https://kintsugi.subsquare.io/democracy/referendum/68](https://kintsugi.subsquare.io/democracy/referendum/68)
*   Statemint XCM Channel: [https://kintsugi.subsquare.io/democracy/referendum/60](https://kintsugi.subsquare.io/democracy/referendum/60)
*  Governance guides: [https://docs.interlay.io/#/guides/governance](https://docs.interlay.io/#/guides/governance) (incl. how to make a proposal)
* Python code used for analysis of new assets proposed as vault collateral: [https://github.com/interlay/collateralization-analysis](https://github.com/interlay/collateralization-analysis)

Activation of USDT as a Vault collateral on Kintsugi

## Summary

We would like to register sKSM on Kintsugi as a first step towards the Kintsugi DeFi Hub launch.

## Tabling

We request that TC upgrade this proposal directly to a referendum.


Register SKSM as a foreign asset

This proposal opens the XCM channel to Basilisk. This will allow assets to be transferred in between Kintsugi and Basilisk and open a path towards more use cases for kBTC and more collateral assets for kBTC.

**TC Table**

Since we want to proceed as quickly as possible with opening the channel to move the discussion to actual use cases for both communities, we request that this proposal be tabled.

**Extrinsic**

https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fapi-kusama.interlay.io%2Fparachain#/extrinsics/decode/0x0202085b000101000214000400000000070084e7755f1300000000070084e7755f0006000700e40b5402383c002a080000e803000000900100140d01000400010100485e490259e75f0e1c433e39ea5b88bdb0be6bf4e04ec5ee9b1223120a92ce755b000101000214000400000000070084e7755f1300000000070084e7755f0006000700e40b5402183c012a080000140d01000400010100485e490259e75f0e1c433e39ea5b88bdb0be6bf4e04ec5ee9b1223120a92ce75

Open XCM channel with Basilisk - Part 1/1 (Accept & request HRMP)

## Summary

We would like to register vKSM on Kintsugi as a first step towards the Kintsugi DeFi Hub launch.

## Tabling

We request that TC upgrade this proposal directly to a referendum.


Register VKSM as a foreign asset

## Summary

We would like to register MOVR on Kintsugi as a first step towards the Kintsugi DeFi Hub launch.

## Tabling

We request that TC upgrade this proposal directly to a referendum.


Register MOVR as a foreign asset

Updates the vault client to the latest release for the vault runner.

Vault client 1.18.0 contains a bug that prevents the client from properly shutting down: `ERROR service: Waiting for 1 tasks to shut down...`

Release notes: https://github.com/interlay/interbtc-clients/releases/tag/1.18.1


Patch vault version to 1.18.1

Release notes: https://github.com/interlay/interbtc-clients/releases/tag/1.18.1

This runtime upgrade adds the following:

1. Tables proposals to referenda always on Monday morning at 9:00 UTC to get around the block time variance issue and make referenda execution predictable
2. Tables two proposals to referenda to account for the fact that treasury and regular proposals are happening in parallel

Updates Kintsugi to the latest runtime (**non-breaking**).

For more details, please see the following:

https://github.com/interlay/interbtc/releases/tag/1.20.1
https://github.com/interlay/interbtc/compare/1.20.0-hotfix+sub...1.20.1

The latest compatible clients release for this version is `v1.18.1`:

https://github.com/interlay/interbtc-clients/releases/tag/1.18.1

# Request for tabling

To not block other ongoing proposals, we request to table this proposal to a referendum for voting.

Upgrade to runtime v1.20.1: Fix governance schedule to table on Monday morning and table two proposals

This proposal accounts for the threshold adjustment mentioned in the original discussion post here: https://interlay.subsquare.io/post/12
The KSM thresholds were reduced in https://kintsugi.subsquare.io/democracy/referendum/71. However, the corresponding thresholds for LKSM collateral were not yet reduced to the values recommended by the Interlay team, and in particular the models from team member `InternalError` posted here:
Repo: https://github.com/interlay/collateralization-analysis
Results: https://github.com/interlay/collateralization-analysis/blob/master/analysis.log

This proposal is to change the secure threshold levels as follows:
Current values LKSM <> KBTC
liquidation: 150%
premium-redeem: 200%
secure (min. when minting): 260%

Proposed new values LKSM <> KBTC
liquidation: 145%
premium-redeem: 165%
secure (min. when minting): 180%

This change reduces the capital requirements of Vaults by ~30%.

For more information on the meaning of individual thresholds, see Vault collateral thresholds.

LKSM threshold reduction

This proposal rotates the oracle and TC keys. This is a regular operation to ensure that keys are regularly changed.

New oracle: `5G3aLPc3xAyvbmH8ov5peRMSZ3mQkEKw9XGorfTkEs1dupQe`
New TC: `5F9RAS5mjNojn9ERWJPwtds2mARhGnbPsaxYXD6K72HBayV5`


## Extrinsic
https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fapi-kusama.interlay.io%2Fparachain#/extrinsics/decode/0x02020c3e01b0145df1c59b0abc15e8dca23f8d2ac569b4f537ed6f97604271d6f396aba65620496e7465726c61794802b0a2918e8abe126f7a6e73eb2369634702ed01b4b33aceaf69f4489a3495793e884cbb382de0a33753615d03727177d4abc91fedd67aa99df93ba892ad4cb11f3e0244c1692c0dcbacc9331cd24a640fe7302cbe7ae05b10003c2484c91de2f7d14e

## TC

Request for TC fast-track to make start of new oracle predictable.

Regular Key Rotation - Rotating Oracle and TC Keys

Hi, this is Jah from Solarbeam,

This proposal is intended to send 7000 KINT tokens from Kintsugi treasury to the designated address, so they can be used for a new kBTC/ETH pool on Solarbeam (Moonriver).

kBTC is the market leader for bringing Bitcoin to the Kusama ecosystem, in order to grow its market position, kBTC needs to gain accessibility to wider Kusama users and provide more profitable use cases. 

We suggest launching a kBTC/ETH pool on Solarbeam, and incentivizing the kBTC/ETH pool with KINT and SOLAR tokens.

**Proposal**
With a money market (lending & borrowing) launching on Kintsugi, it is important to enable use cases for kBTC, as well as to increase the overall liquidity of kBTC in the wider Kusama ecosystem. 

A kBTC/ETH pool can facilitate the growth of kBTC liquidity, and increase exposure of kBTC and KINT to Solarbeam users.

On the demand side, taking into account the demand in the larger context of Defi, BTC/ETH is one of the most popular pairs on Ethereum, which could potentially translate to similar demand in the Kusama ecosystem. 

On the supply side, ETH is one of the most liquid assets on Solarbeam, which can provide sufficient liquidity to facilitate the liquidation environment for the kBTC vaults. 

The goal with this proposal is to incentivise the kBTC/ETH pool for 3 months. We propose the transfer of 7000 KINT tokens from the Interlay Treasury to our (Solarbeam) designated wallet address mentioned below in order to be used as incentives for the kBTC/ETH pool. 

4000 KINT will be distributed to the pool for farming rewards in the first month, 1500 KINT for the second month and 1500 KINT for the third month. To better support this effort and achieve considerable TVL, we will match the rewards with 400 SOLAR per day for the same 3 month period.

Once the funds are received to the address below, they will be added as incentives to the kBTC/ETH pool.
Solarbeam Designated Address: 0x1375D820e32Eec62cDd75c3e95b1E71A830B2149


Use Treasury Funds to Incentivise kBTC/ETH pool on Solarbeam (Moonriver)

# Summary
Hi, this is Tyrone from Bifrost, this proposal is in regard to using treasury to incentivise a kBTC/KSM pool on the Bifrost chain on Zenlink.

This proposal will send 3000 KINT tokens from treasury to Bifrost’s designated address to be used for the kBTC/KSM pool on Zenlink (Bifrost).

We suggest launching a KSM pair with kBTC on Bifrost for two reasons:
1. To increase kBTC exposure on Bifrost and Zenlink, specifically, introducing kBTC to the Bifrost community.
2. To facilitate profitable liquidation for kBTC vaults. Bifrost, with deep liquidity for KSM, and great volume in vKSM (which can be easily converted to KSM), could provide a great environment for this purpose.

# Proposal
The launch of Kintsugi 2.0 will introduce more opportunities for cross chain activities, a kBTC/KSM pool on Zenlink (Bifrost) is one gateway to introduce more use cases and liquidity to both Kintsugi and Bifrost, opening doors to future collaboration between the parachains. 

Besides the transaction of both native tokens, kBTC will be crossed to Zenlink DEX. Bifrost, Zenlink and Kintsugi will create a three-party incentivized KSM-kBTC pool, which may benefit more utilities for BTC spreading around Kusama ecosystems. Creating KSM-kBTC pool will in addition provide more liquidity options for KSM-vKSM pair users, kBTC and be indirectly swapped with vKSM between two pairs. 

We would like to propose a kBTC/KSM liquidity pool on Zenlink (Bifrost), with incentives running for 2 months: the first month triple incentives from Bifrost, Kintsugi and Zenlink, and second month continue with incentives from Kintsugi and Bifrost. By providing these incentives, we can help attract the necessary liquidity and ensure that the pool is able to operate effectively.

We propose the transfer of 3000 KINT tokens from the Kintsugi Treasury to our (Bifrost) designated wallet address mentioned below in order to be used as incentives for the kBTC/KSM pool. To better support this effort and achieve considerable TVL, we (Bifrost) would provide 6000 BNC in incentive in the course of 2 months, Zenlink will provide 15,000 ZLK in the first month. The incentives are scheduled to start on December 19th 2022.

Once the funds are received to the address below, they will be added as incentives to the kBTC/KSM pool.
**Bifrost Designated Farming Charge Address**:
dmTEFZ77m7WtJmd7PY6pMh111uTtW9jpwfwasTGsWKUGp5M
![](https://i.imgur.com/0GL4APs.png)
The kBTC/KSM Farming pool (id:12) is ready to be charged, charging will be exectued by Bifrost team.
*Considering the fluctuation of the average block producing time on chain, creating a Farming Pool in advance may cause the time deviation between announcement time and actual farming started.

Use Treasury Funds To Incentivise kBTC/KSM pool on Zenlink (Bifrost)

**Summary**
Statemine had to resubmit their channel open requests and is doing so using other `Transact` calls. Before their motion/referendum passes - https://kusama.polkassembly.io/motion/581 - we need to cancel the initial request. 

**Request to upgrade to referendum**
As this cancellation needs to happen before the motion on polkassembly is enacted, we request that this proposal be tabled to a referendum. 

**Polkassembly new proposal:** https://kusama.polkassembly.io/motion/581


HRMP channel request cancellation

Updates Kintsugi to the latest runtime (**breaking**). This contains, but is not limited to, the following changes:

- Updates core dependencies to polkadot-v0.9.31
- Updates to the new weight handling system

## Releases

For more details, please see the following:

- https://github.com/interlay/interbtc/releases/tag/1.20.0
- https://github.com/paritytech/polkadot/releases/tag/v0.9.31

The latest compatible clients release for this version is v1.18.0:

- https://github.com/interlay/interbtc-clients/releases/tag/1.18.0

Request to fast-track the referendum to execute on 1 December 2022 10am UTC.

## Proposal

- https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fapi-kusama.interlay.io%2Fparachain#/extrinsics/decode/0x0202085502aea2be02e2d56b6910f263e47bfa43ac0655ba96574b74d53949d82ab94218404500147661756c749d0168747470733a2f2f6769746875622e636f6d2f696e7465726c61792f696e7465726274632d636c69656e74732f72656c65617365732f646f776e6c6f61642f312e31382e302f7661756c742d70617261636861696e2d6d657461646174612d6b696e747375676938a6b61f1186d0ff091533ff49e9975580e411e48e9ce68b2e40ff50b6f76bd8
- Code hash: `0xaea2be02e2d56b6910f263e47bfa43ac0655ba96574b74d53949d82ab9421840`



Upgrade to runtime v1.20.0

**The relevant discussion:** [https://interlay.subsquare.io/post/12](https://interlay.subsquare.io/post/12)

## Tl;dr.

- KINT Vault block rewards are currently too high, considering market conditions and in comparison to competitors / projects with similar risk profile.

- This proposal suggests to adjust Vault block rewards to a more sustainable level, updating the KSM collateral requirements to competitive and more capital-efficient rates, and introducing regular review cycles to assess ROI for protocol and Vault operators.

- The saved funding will remain with the network treasury, to be used as governance decides, e.g.. to bootstrap kBTC growth as market conditions improve and help build liquidity in the native AMM and lending protocols set to launch on Kintsugi and Interlay in early 2023 (more details in upcoming Interlay 2.0 whitepaper - [read 2.0 roadmap announcement](https://medium.com/interlay/interlay-2-0-roadmap-c6387d9d1abb)).



## Goal
The goal of this proposal is to adjust Vault block reward rates to be more sustainable while keeping incentives for operators high enough - and more reliable.

## Solution
**1) Reduce collateral thresholds.**
The latest collateral risk models [1] suggest the following collateral thresholds for KSM (on Kintsugi):

liquidation: 130%
premium-redeem: 145%
secure (min. when minting): 160%

This change **reduces the capital requirements of Vaults by ~40%**.

For more information on the meaning of individual thresholds, see [2]

**2) Adjust Vault block rewards to competition.**
The proposal is to adjust the Vault rewards such that:

**APR on Kintsugi is ~30%** assuming the amount of collateral locked at the time of this proposal. This proposal updates the block reward from 0.456621004566 KINT to 0.102803978513969 KINT.

**3) Regular Review & Adjustment of Vault Economics.**
Rather than having a static model, we propose that Vault economics be reviewed on a regular basis, allowing to react and adjust for external/macroeconomic events.

The community, including Vault operators, can make recommendations/requests to adjust the Vault rewards schedule via the Governance portal (guides provided).

The process to adjust rewards will be greatly simplified over the next months with upcoming improvements to governance (more details are in [the Interlay 2.0 whitepaper](https://medium.com/interlay/interlay-2-0-roadmap-c6387d9d1abb)).

## Expected Result
The optimization of collateral thresholds combined with the adjusted reward schedule is expected to reduce emissions as follows:

- KINT emission by ~78%

## Why should community vote in favor of this proposal?
This proposal makes a big step to improving the economic stability and outlook of Kintsugi.

The current emission schedule was conceived during a growing crypto market, in anticipation of reaching significant kBTC targets by EOY 2022. However, due to recent macro-economic events in crypto (Luna, 3AC, Celsius and now FTX), as well as the two hacks (Nomad impacting Moonbeam and aUSD on Acala) affecting Polkadot, the growth of DeFi on Dotsama has not been as fast as hoped. As a result, kBTC and iBTC utilization rates are low, with most BTC sitting on Kintsugi/Interlay.

The high initial emission was also a measure to reward early technical risk and to cover the high collateral requirements imposed at launch (260% over-collateralization for KSM/DOT Vaults). The technical risk of the bridge can be considered significantly reduced by now. The bridge has been operating successfully since March 2022 on Kintsugi and since August 2022 on Interlay, withstanding the recent market turbulences. The removal of the aggressive BTC theft reporting [4] has also greatly reduced the risk of wrongfully slashing Vaults. The proposed reduction of collateral thresholds to competitive rates also constitutes a big step towards Vault capital efficiency.

### References
[1] Interlay Vault collateral risk modelling framework. [https://github.com/interlay/collateralization-analysis](https://github.com/interlay/collateralization-analysis)

[2] Vault collateral thresholds. [https://docs.interlay.io/#/vault/overview?id=collateral](https://docs.interlay.io/#/vault/overview?id=collateral)

[3] APR comparison to similar projects. [https://api.ipfsbrowser.com/ipfs/get.php?hash=QmPhP8utFLhharELDeN6Njbc2234DGxnc4A73wxf2JHwPJ](https://api.ipfsbrowser.com/ipfs/get.php?hash=QmPhP8utFLhharELDeN6Njbc2234DGxnc4A73wxf2JHwPJ)

[4] Kintsugi proposal discussing removing theft-reporting. [https://kintsugi.subsquare.io/democracy/referendum/52](https://kintsugi.subsquare.io/democracy/referendum/52)

Adjustment to Vault Reward Schedule on Kintsugi

This proposal accounts for the threshold adjustment mentioned in the original discussion post here: [https://interlay.subsquare.io/post/12](https://interlay.subsquare.io/post/12)

The initial proposal includes the reduction of token emissions but not the threshold reductions: [https://kintsugi.subsquare.io/democracy/proposal/75](https://kintsugi.subsquare.io/democracy/proposal/75)

### This proposal is to change the secure threshold levels as follows:

**Current values KSM <> KBTC**
liquidation: 150%
premium-redeem: 200%
secure (min. when minting): 260%

**Proposed new values KSM <> KBTC**
liquidation: 130%
premium-redeem: 145%
secure (min. when minting): 160%

This change **reduces the capital requirements of Vaults by ~40%**.

For more information on the meaning of individual thresholds, see [Vault collateral thresholds](https://docs.interlay.io/#/vault/overview?id=collateral).


**Request for the TC:**
Please upgrade this proposal to referendum manually, as this should have gone together with [the token reduction proposal](https://kintsugi.subsquare.io/democracy/proposal/75).


Follow Up to Proposal #75 - threshold reduction

I would like to propose that we use LKSM as collateral. LKSM can be redeemed for KSM at any time, so it is as valuable. However, for vault operators it also earns some APY, since they get LKSM in return for staking KSM.

**Thresholds for LKSM**
liquidation threshold: 150%
premium threshold: 200%
secure threshold: 260%
minimum collateral: 20 LKSM
ceiling: 38.000 LKSM

I request that this be upgraded already to referendum to speed up the process.

Enable LKSM as collateral for Kintsugi Vaults

This proposal is for accepting the Bifrost to Kintsugi part of the XCM channel and finalising the XCM connection.

Request for upgrade to referendum:
We would like to move quickly with opening the channel in order to enable and facilitate future use cases for kBTC between Kintsugi and Bifrost. Therefore, we request that this proposal is upgraded to a normal referendum.

Open XCM Channel with Bifrost - Part 2/2 - HRMP Accept

**Summary**
We would like to register $USDt on Kintsugi as a first step towards considering it as a Vault collateral and to facilitate other ongoing developments.

**Proposal**
Enabling this kind of asset on Kintsugi will allow users to adopt less risky positions with potentially tighter collateral thresholds which should eventually increase the system-wide minting capacity.

We request that TC upgrade this proposal directly to a referendum.

**Resources**
- Kintsugi > Statemine: https://kintsugi.subsquare.io/democracy/referendum/60
- Statemine > Kintsugi: https://kusama.polkassembly.io/post/1807


Register USDT as a foreign asset on Kintsugi

Proponent: a3byawr54JPxf1RpvnbLZPkZN2Q9Ry7gg5CXiqcvEtgPWvQM8
Date: 7th October, 2022
Requested KINT: 4,559.17
Short description: Ongoing costs for the running of high performance, scalable, and reliable public infrastructure for Interlay's Kintsugi Network.

* * * * *

## Original Motivation

Setting up blockchain infrastructure is difficult, time consuming, and expensive:
-   It requires a level of server development expertise that many do not have
-   It's costly to run a full node nearly continuously, especially when your dApp's traffic is low and inconsistent. 
-   Running production level infrastructure is especially tricky. You need to autoscale quickly to handle bursty traffic, and you want to provide services in different regions around the world to provide low latency services - all of this is incredibly costly, but comes with significant economies of scale for a provider.
-   DevOps requires constant attention - time that would be better spent elsewhere building.

A shared node API service helps mitigate these barriers of entry to trying accessing a new protocol by reducing all these costs to near zero. We manage all the nodes for our users and distribute them across the world (with intelligent routing) to achieve global scalability from day 1, we monitor each node and ensure that they meet certain service levels, and we have the expertise and scale to handle production workloads and high peak traffic.

In summary, we try to reduce the pain of getting started on  Kintsugi Network and minimise the costs of accessing secure nodes while traffic from your dApp is low. When you grow, you can continue to use our shared API service, or we also [provide access to one click deploy dedicated Kintsugi nodes](https://onfinality.io/dedicated_nodes)  to any cloud of your choosing.

## Service Details and Enhancements

During the last quarter, we've focused on three key areas for the development of OnFinality - cost optimization, network expansion, and providing more value from our Ultimate API service.

The bear market has made many of our customers more price sensitive, and as such we've been working with them to optimise our services to provide more for less. We've reduced prices for our larger customers between 30 and 40%, and created products designed to target and onboard new chains with entry level pricing. We've also been working on new rate limiting capabilities to progressively restrict abusers of our public APIs to upgrade to paid API plans.

In the past quarter we have succeeded in our goal of onboarding two new networks, with the addition of Avalanche and Juno to our API service. This was a large amount of upfront work, extending OnFinality to allow chains outside of Polkadot/Substrate, but now that it has been done we should be able to move faster and onboard new chains each week. We hope that this means that we will be able to invite as many new ecosystem participants into Polkadot as possible with this expansion. 

Finally, providing move value from our Ultimate API service has always been a priority, and in this space we've added new API specific paid plans at competitive prices to our competition. We have also delivered the ability for our customers to better understand and learn about their users, with API Insights that tell you where your users are, what they are requesting, what methods are failing (to find bugs in your dApp), and where optimisations can occur.

## Enhancements

Additionally, we are proud to have delivered some key service enhancements that benefit the ecosystem in the last quarter. This includes:
-   [API Insights](https://blog.onfinality.io/onfinality-introduces-api-insights-so-you-can-analyse-and-learn-about-your-applications-faster/) so you can analyse and learn about your API applications faster and find bugs with your dApp
-   [Cost optimisations](https://blog.onfinality.io/go-further-with-more-affordable-pricing/) to reduce pricing for our customers by up to 40%
-   [New API plans](https://blog.onfinality.io/get-ahead-with-onfinalitys-new-api-endpoints/) for our high usage customers and a way to allocate resource to [move towards a more sustainable funding model](https://polkadot.polkassembly.io/post/1270)
-   [Support for Alibaba Cloud](https://blog.onfinality.io/onfinality-collaborates-with-alibaba-cloud-to-provide-a-premium-experience-to-web3-builders/) to provide more decentralised cloud hosting options for our customers
-   [Updates to our website](https://blog.onfinality.io/onfinality-announces-a-new-ui-to-help-web3-developers-build-smarter/) to include a new Network marketplace so [you can see what networks are supported](https://onfinality.io/marketplace)
-   Support for new layer 1s - [Avalanche](https://blog.onfinality.io/onfinality-launches-beta-api-support-for-avalanche/) and [Juno](https://blog.onfinality.io/onfinality-launches-api-support-for-jun-c3-b8-network/) (in Cosmos)
-   A variety of improvements to our health metric collection tools and automated recovery scripts to ensure our 99.9% SLA is exceeded.
-   Scale improvements to our team, processes, and systems to allow us to provide this same service to any  substrate team

You can always see live data on our API service on our public [status page](https://status.onfinality.io/) and [analytics page](https://analytics.onfinality.io).

[Full proposal can be found here](https://docs.google.com/document/d/1lJ_FzSnq32KkrIcePATqf-Yuflkny3vwQvdmTNAlBxs/edit?usp=sharing)

OnFinality - High Performance Public Infrastructure (Q3, 2022)

Updates Kintsugi to the latest runtime (**non-breaking**). This contains, but is not limited to, the following changes:

- Updates core dependencies to `polkadot-v0.9.29`
- Reduces voting and enactment periods

For more details, please see the following:

- https://github.com/interlay/interbtc/releases/tag/1.19.1
- https://github.com/paritytech/polkadot/releases/tag/v0.9.29

The latest compatible clients release for this version is `v1.17.4`:

- https://github.com/interlay/interbtc-clients/releases/tag/1.17.4

Upgrade to runtime v1.19.1

Updates Kintsugi to the latest runtime (**non-breaking**). This contains, but is not limited to, the following changes:

- Updates core dependencies to `polkadot-v0.9.29`
- Reduces voting and enactment periods

For more details, please see the following:

- https://github.com/interlay/interbtc/releases/tag/1.19.1
- https://github.com/paritytech/polkadot/releases/tag/v0.9.29

The latest compatible clients release for this version is `v1.17.4`:

- https://github.com/interlay/interbtc-clients/releases/tag/1.17.4



DEPRECATED: Upgrade to runtime v1.19.1

Breaking release to update Kintsugi to the latest runtime. This contains, but is not limited to, the following changes:

- Vaults can now self-redeem (burn kBTC for unlocking collateral) without sending BTC
- Removed the refund protocol since theft reporting was already eliminated
- Issue requests can now be executed after expiry if the Vault has sufficient collateral
- Allows issue requests to be cancelled prematurely by the user (may slash griefing collateral)
- Collators can now lock vKINT to register as an authority
- Adds generic registry to store client release info (for auto-updater)
- Includes all relevant changes to support polkadot-v0.9.26

For more details, please see the following:

- https://github.com/interlay/interbtc/releases/tag/1.19.0
- https://github.com/interlay/interbtc-clients/releases/tag/1.17.0
- https://github.com/paritytech/polkadot/releases/tag/v0.9.26

## Collators

After deliberation, it was agreed with the community that we trial public collator registration. Initially nine slots will be made available requiring a deposit of >1000 vKINT to be locked. If the balance falls too low or the collator fails to produce blocks they will be kicked.

See: https://voting.opensquare.io/space/kintsugi/proposal/QmQY4e1hjfVpioisSchaXYPr7iJddp7xaSkn74kEd8zNhc


Upgrade to runtime v1.19.0

This referendum opens the XCM channel to Bifrost. This will allow Kintsugi assets to be transferred to Bifrost and used there.

This is the first part of two referenda to open bi-directional communication with Bifrost. The second referendum will accept the open channel to Kintsugi.

Note: Bifrost needs to pass a referendum as well to accept this open channel.

Request to upgrade to 7 day referendum:
As we want to move quickly on opening new xcm channels in order to make room for discussions on use cases for kBTC, we would like to upgrade this proposal already to a 7 day referendum.

Open XCM channel with Bifrost - Part 1/2 (HRMP INIT)

This referendum opens the XCM channel to Basilisk. This will allow Kintsugi assets to be transferred to Basilisk and used there.

This is the first part of two referenda to open bi-directional communication with Basilisk. The second referendum will accept the open channel to Kintsugi.

Note: Basilisk needs to pass a referendum as well to accept this open channel.

Request to upgrade to 7 day referendum:
As we want to move quickly on opening new xcm channels in order to make room for discussions on use cases for kBTC, we would like to upgrade this proposal already to a 7 day referendum.

Open XCM channel with Basilisk - Part 1/2 (HRMP INIT)

This proposal is for accepting the Astar Shiden to Kintsugi part of the XCM channel and finalising the XCM connection.

Request for upgrade to referendum:
We would like to move quickly with opening the channel in order to enable and facilitate future use cases for kBTC between Kintsugi and Astar Shiden. Therefore, we request that this proposal is upgraded to a 7 day referendum.

Open XCM Channel with Astar Shiden - Part 2/2 - HRMP Accept

**Proposal**
This proposal opens the XCM channel to Statemine. This will allow assets to be transferred in between Statemine and Kintsugi and open a path towards more assets that can be used as collateral types for vaults in the future.

This is the first part of two referenda to open bi-directional communication with Statemine. The second proposal will accept the open channel to Kintsugi.

Note: Statemine will need to pass a referendum as well to accept this open channel.

**Request for upgrade to referendum**
Since we want to proceed as quickly as possible with opening the channel so we can move the discussion to actual use cases for both communities, we request that this proposal be upgraded to a referendum.

Request To Open XCM channel with Statemine - Part 1/2 (HRMP INIT)

This referendum opens the XCM channel to Astar Shiden. This will allow Kintsugi assets to be transferred to Astar Shiden and used there.

This is the first part of two referenda to open bi-directional communication with Astar Shiden. The second referendum will accept the open channel to Kintsugi.

Note: Astar Shiden needs to pass a referendum as well to accept this open channel.

Request to upgrade to 7 day referendum:
As we want to move quickly on opening new xcm channels in order to make room for discussions on use cases for kBTC, we would like to upgrade this proposal already to a 7 day referendum. 

Open XCM channel with Astar Shiden - Part 1/2 (HRMP INIT)

**Summary**
We would like to register $LKSM as an asset on Kintsugi as a first step towards considering it as a vault collateral and to facilitate other developments on Karura and Kintsugi side.

**Proposal**
Several parachains have already developed or enabled a way for users to stake their KSM or DOT while still being liquid. This has been done via liquid tokens, one of them being LKSM. 
Enabling this kind of asset will mean more capacity for vaults using their LKSM as collateral but also that vaults can compound the earnings they are already getting by staking KSM. 

We would like to register the asset fairly quickly in order to have as much time as possible for tests. Therefore, we request that this proposal be upgraded directly to a referendum.

**Resources**
Kintsugi Governance 101: https://docs.interlay.io/#/kintsugi/governance
Governance guides: https://docs.interlay.io/#/guides/governance (incl. how to make a proposal)

Register LKSM as a foreign asset on Kintsugi

Proponent: a3exf9eKEVPGXSyFA9T8wBFsAFY5YecUDR8N133juhnt2HkPa (web3alert.io) 
Date: 12.08.2022
Requested KINT: 4428 EUR / 2.8 = 1581 KINT (based on 7day avg rate by Coingecko)
Short description: Web3alert.io maintenance costs for Kintsugi at the rate of 600 EUR/month (+ VAT) for the period 1 August 2022 to 1 February 2023.

![Kintsugi](https://miro.medium.com/max/1400/1*CwnkMbmZwoOfiA-2uOI5XA.png)

https://web3alert.io is a service that listens for events on Kintsugi and sends notifications about them to messengers. At the moment, Web3alert supports Telegram, Discord and Slack.

[Medium story about the Kintsugi integration on Web3alert](https://medium.com/@web3alert/web3alert-integrates-with-kintsugi-af3e9423fe52)

[See the full proposal here](https://docs.google.com/document/d/1M2YEVzi9RoOcT8LOzEBn03IKgDI9izbQTCKH8ZxjBXo/edit?usp=sharing)

Treasury spend for Maintenance of web3alert.io Kintsugi integration for 6 months

SubSquare is a governance platform for substrate based blockchains, and we have integrated kintsugi since 01.2022. We are keep doing the maintenance and common features development work. We propose a treasury spend to support the work.

## Work scope

1. The routine maintenance work to keep the deployment well running.
2. Common features developed
    - UI improvement including header customization, democracy referenda metadata improvement, etc.
    - DID login without email/username signup.
    - Post features enhancement like supporting banner and polls.
    - UI improvements & bug fixes. 
3. Future common features
    - Support more user call interfaces.
    - UI improvements and UX enhancements.
    - User profile page.

## Budget

We request $800 per month for these 6 months maintenance, common features development and server fee. Note that we maintain separate packages for kintsugi, so the request is a bit more than that of other para chain deployments.

| Item        | detail            | Cost   |
|-------------|-------------------|--------|
| Monthly fee | 05.2022 - 10.2022 | $4,800 |
| In KINT      | 3.22/KINT        | 1490 |

Subsquare kintsugi maintenance from 05.2022 to 10.2022

Due to a bug in the v6 `VaultRegistry` migration all Vaults now have an incorrect number of `issued_tokens` which puts many below the liquidation threshold. Fortunately, the `stake` stored in `VaultRewards` is still correct which prevents liquidation since that number is smaller than the value trying to be liquidated.

This fix manually forces the `VaultRegistry` to the correct state which was determined by querying the storage prior to runtime upgrade and applying the expected migration function. More details to follow in our post-mortem.

Request for TC fast-track to minimize system downtime.

Correct state after failed v6 migration

 
 
## Summary
 
After careful consideration, we propose to formally remove Vault theft reporting through governance.
 
Main motivation:
 
 
 
* No impact on the ecnomic security of the bridge. 
* Reduced attack surface (Bitcoin transaction parsing functionality is complex and difficult to maintain / test against Bitcoin Core code). Two critical bugs were already detected ([https://medium.com/interlay/kintsugi-released-urgent-security-patches-aebf969ee087](https://medium.com/interlay/kintsugi-released-urgent-security-patches-aebf969ee087))
* Significantly improved Vault flexibility (enables cold/hot storage, easy exit, leveraged positions, …)
 
On Kintsugi, theft reporting is currently deactivated to fix the two critical bugs. However, this emergency fix did not yet go through formal governance. This proposal suggests a patch to remove theft reporting properly.
 
## Proposal: Remove Theft Reporting
 
This proposal removed the theft reporting functionality completely from the Kintsugi parachain
 
Code changes: [https://github.com/interlay/interbtc/releases/tag/1.18.0](https://github.com/interlay/interbtc/releases/tag/1.18.0)
 
**Why was Theft Reporting implemented in the first place?**
 
Theft reporting was first introduced to enforce a 1:1 peg between BTC and iBTC. The goal was to reduce potential attack surfaces by restricting how Vaults could move the BTC: only when instricuted by the parachain. This came at the cost of flexibility and - as we observed in practice - ended up achieving the opposite of what was intended. 
 
### Analysis: No Impact on Economic Security
 
The following applies before and after removing of theft reporting: 
 
_Each minted kBTC is backed by collateral, e.g KSM. The system collateralization rates are set higher than the value of BTC locked (over-collateralization) to ensure Vaults never have incentive fail user redeem requests. In case of a failed redeem or if a Vault’s collateralization rate drops below a pre-defined threshold (still above 100%), the system executes a liquidation: Vault collateral is confiscated and used to reimburse users (Vault gets to keep the BTC)._
 
The following changes (without impact on security):
 
Using thresholds of the current KSM/kBTC Vauklts on Kintsugi
 
 
<table>
  <tr>
   <td>With theft reporting
   </td>
   <td>Without theft reporting
   </td>
  </tr>
  <tr>
   <td>Issue: 
<ul>
 
<li>1 BTC deposited in Vault
 
<li>260% worth Vault KSM collateral locked
 
<li>1 kBTC minted 
</li>
</ul>
   </td>
   <td>Unchanged
   </td>
  </tr>
  <tr>
   <td>kBTC exists:
<ul>
 
<li>User can move 1 kBTC
 
<li>1 BTC “locked” in Vault 
 
<li>260% worth of Vault KSM collateral locked with parachain
 
<p>
Total capital locked = 1 BTC (100%) + 260% collateral = 360% 
</li>
</ul>
   </td>
   <td>kBTC exists:
<ul>
 
<li>User can move 1 kBTC
 
<li><strong>Vault can freely move 1 BTC</strong> 
 
<li>260% worth of Vault KSM collateral locked with parachain
 
<p>
Total capital locked = 260% collateral
</li>
</ul>
   </td>
  </tr>
  <tr>
   <td>Redeem (success):
<ul>
 
<li>User returns 1 kBTC
 
<li>Vault sends 1 BTC to user
 
<li>260% worth of Vault KSM collateral is unlocked
</li>
</ul>
   </td>
   <td>Unchanged
   </td>
  </tr>
  <tr>
   <td>Redeem (fail):
<ul>
 
<li>User returns 1 kBTC
 
<li>Vault fails to send 1 BTC to user
 
<li>150% worth of Vault KSM collateral is confiscated and paid to user. 
 
<li>Vault keeps BTC and is removed from active Vault list
 
<p>
Note: user can also retry with another Vault. In this case, only a small % of the Vault collateral is slashed and the Vault remains operational.
</li>
</ul>
   </td>
   <td>Unchanged
   </td>
  </tr>
  <tr>
   <td>Liquidation due to under-collateralization:
<ul>
 
<li>Vault drops below 150% collateralization rate
 
<li>150% worth of Vault KSM collateral is confiscated 
 
<li>Anyone can burn 1 kBTC to receive the 150% worth of KSM collateral 
 
<li>Vault keeps BTC and is removed from active Vault list
</li>
</ul>
   </td>
   <td>Unchanged
   </td>
  </tr>
</table>
 
 
As you can see, the only difference is that the Vault can freely move BTC while kBTC exists. 
 
As such,  **economic security remains unaffected:** The decision for a Vault to keep BTC or return it back to the user is still wholly ensured by the collateral at the time of redemption.
 
### Improved Implementation Security
 
Theft reporting requires parsing BTC addresses from BTC transactions. This is very difficult to implement on-chain as no existing Bitcoin libraries can be used (not compatible with parachain wasm). 
 
This led to two critical bugs identified  (see critical bugs: https://medium.com/interlay/kintsugi-released-urgent-security-patches-aebf969ee087 ) and future compatibility issues with Taproot (see technical issues here: https://github.com/interlay/interbtc/issues/606).
 
Removing theft reporting significantly reduces code complexity and helps avoid aforementioned issues in the future. 
 
### Removing Theft Reporting: Enabled, New Product Features
 
As a positive side-effect, removing theft reporting enables a bunch of new  product features, improving the user experience for Vault operators:
 
1. **BTC cold storage** At any given time, it’s unlikely that 100% of the BTC will be redeemed at once. By being able to move BTC freely, Vaults can secure BTC to a cold storage location and only keep part of the BTC in a hot wallet. Each Vault must assess the risk / benefit of keeping BTC in cold storage, e.g. in case of bank runs. 
 
2. **Extra yield from BTC:** As Vaults are free to move BTC, they can also use this BTC to earn yield on other platforms (mostly centralized as of now, however). The defaul implementation of the Vault client will keep the BTC in the wallet. Any actions outside the Kintsugi network are at the sole risk and discretion of the Vault operators. 
 
3. **Cost-efficient system exit**: A new, more capital efficient way for Vaults to exit the system is made available. Vaults can use the BTC to acquire kBTC over multiple steps, e.g. sell BTC for USDC on a CEX, buy kBTC with USDC on a DEX, use kBTC to self-redeem and close Vault. 
 
4. **Levaraged positions / synthetic minting**: The same 1 BTC can now be used to issue multiple kBTC, as long as the collateral backing is in place. This enabled Vaults to take up leveraged positions: mint more kBTC than they have BTC to earn more rewards (locking up the necessary collateral), at the risk of being liquidated if they cannot source the necessary BTC to fullfill redeem requests. 
 
5. **Simplified Vault Operation:** We had incidents on Kintsugi where Vault operators were flagged for theft without malicious intent. Rather, due to Bitcoin congestion or operational issues, Vault operators got liquidated. Removing theft reporting will prevent such cases from happening in the future.
 
—-----------------------------------------------------------
 
As always, we appreciate your time reviewing this proposal and welcome comments and feedback.
