**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

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)

Untitled - public proposal #66

Untitled - public proposal #65

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

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

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

## Summary
We would like to register $aUSD 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
As previously mentioned and discussed, we are looking towards proposing $aUSD as the next asset that can be used as vault collateral. The first step towards this is registering $aUSD as an asset on the chain. 
This is not equivalent to qualifying it as a vault collateral asset, it merely enables us to recognise it on chain. Among other things, it will also enable Karura to plan or consider updating their cross transfer UI and flow to include $aUSD transfers from Karura to Kintsugi and back. 
Request For TC Fast-Track

We would like to register the asset fairly quickly in order to have as much time as possible for tests and for Karura to plan the update of their UI as mentioned above. Therefore, we request that this proposal be fast tracked. 
 
## 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 aUSD as a foreign asset

A while back there was a bug in the parachain that caused vaults to miss out on rewards. A fix for this has already been released, but in order to reimburse the affected vaults, we need all vaults to first withdraw their rewards. This proposal makes all vaults call `fee.withdrawRewards`. Once this is done, we can do a storage migration in a future proposal to reimburse the affected vaults.


Force one-time reward withdrawal

 
 
## 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.


Remove Vault Theft Reporting

Breaking release to allow Vaults on Kintsugi to set individual secure thresholds. Other notable changes include a new liquidation recovery mechanism and client versioning process.

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

**Request for fast-track by the TC.**

Upgrade to runtime v1.17.0

User a3cDUVdQi8FqkiUBMjqS3RBWPghRWFXBwjRzKZvmB3MmHLDcP burned [0.0575407](https://kintsugi.subsquare.io/post/11#:~:text=I%20burned%200.0575407%20kBTC%20without%20getting%20KSM%20in%20return.%0Aturn%20them%20from%20the%20treasury%20in%20equivalent%20KINT) kBTC without getting KSM in return.
turn them from the treasury in equivalent 400 KINT = 0.0575407 kBTC

Burning kBTC for 0 KSM

**Proponent:** a3byawr54JPxf1RpvnbLZPkZN2Q9Ry7gg5CXiqcvEtgPWvQM8
**Date:** 7th July, 2022
**Requested KINT:** 3,383.31
**Short description:** Ongoing costs for the running of high performance, scalable, and reliable public infrastructure for Interlay’s Kintsugi Network.

OnFinality has been running API service resources for Interlay since the 1st of September 2021 - this proposal covers this period from the 1st/April 2022 to 31st/July 2022. Over this period we served a total of 547,285,279 responses through our API service and over 2.14 TB of data egress. Our highest day saw over 11.6 million responses in a single 24 hour period and at the end of the period the 7 day average is 4,223,836 responses. We also have a 90 day uptime of 99.96%

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

OnFinality - High Performance Public Infrastructure (Q2 2022)

**Summary**
We want to execute 2 proposals that failed due to invalid preimages but passed in referenda.

**Proposal**
We had 2 proposals from the community that moved to referenda and had passed via community votes (see details and links below). 
However, due to the indices having changed in the meantime, the preimages failed. 

This proposal is a fast track execution of the 2 proposals listed below:
1. Recovery of funds impacted by the unsupported Bitcoin version - https://kintsugi.subsquare.io/democracy/referendum/41
2. Raise the Griefing Collateral for Issue requests to 0.5% - https://kintsugi.subsquare.io/democracy/referendum/44

Request for fast track:
Also, I request that the proposal be fast tracked as the 2 mentioned proposals have already gone through referenda and both had passed. 

Execute Referenda #41 & #44

Deactivates Vault theft reporting due to an issue in the P2SH/P2PKH parsers.

Fixes a critical bug reported via the Immunefi bug bounty program.

Detailed post-mortem to follow.

Emergency Patch - P2SH/P2PKH Parsing

Replaced by https://kintsugi.subsquare.io/democracy/referendum/47

[Faulty Proposal] Emergency Patch - P2SH/P2PKH Parsing

Ensures that BTC transactions are unique in double payment reporting.

Fixes a critical bug reported via the Immunefi bug bounty program.

Detailed post-mortem to follow.

Emergency Patch - Theft Reporting

The "griefing collateral" (also called the "security deposit" on the issue page) requires a user to lock some KINT in order to create an issue request. Its purpose is to deter individuals from creating issue requests that they do not intend to fulfill. If a user creates an issue request and doesn't send the BTC within the time limit (currently 48+ hours, depending on block production rate) then the request expires and they lose the griefing collateral.

Currently the griefing collateral is calculated as 0.005% of the amount of kBTC being issued. For instance, a user who wants to issue $1,000 worth of kBTC must lock a meager $0.05 worth of KINT. The amount was initially set low in order to limit the hurdles involved in minting kBTC while launching the parachain and bootstrapping liquidity. However this seems to no longer be a concern, as kBTC has been in high demand for over 6 weeks and the bridge is regularly at or close to its maximum capacity.

Instead, what has transpired is that a small number of accounts tend to "reserve" kBTC whenever it is available, creating issue requests without the intent to send the BTC until later (either close to the deadline or not at all). **Of the last 100 issue requests, more than 20% of them expired.** This has the negative effect of tying up the available capacity in the bridge and preventing other, honest users from being able to issue kBTC, as well as affecting the distribution of vault rewards. When done maliciously this would be classified as a Denial of Service attack. In short, the griefing collateral is not high enough to fulfill its purpose.

After some discussion in the community Discord, my suggestion is to raise the griefing collateral to 0.5% (i.e., $5 of KINT when issuing $1,000 worth of kBTC). I believe this amount strikes a good balance, with increased financial costs for dishonest activity while not being prohibitive for honest users wishing to use the bridge (and will hopefully help with the capacity issue which prevents those users from bridging BTC at all). It's on the same order of magnitude as the issue fee (0.15%), but unlike the fee, the griefing collateral is returned to the issuer once their request has completed successfully.

Prior to the fee.setIssueGriefingCollateral extrinsic being available, this proposal was polled off-chain where it passed unanimously, here: https://voting.opensquare.io/space/kintsugi/proposal/QmVyuks8HLFbbmXHoEZRgaGrb3j5DoVQBakERbqPepjR3N

Raise the Griefing Collateral for Issue Requests to 0.5%

Breaking release to migrate Kintsugi from vanilla `Aura` to `Session` and `CollatorSelection`.

For more details, please see the following:

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

**Request for fast-track by the TC.**


Upgrade to runtime v1.16.0

Includes a fix for KINT reward distribution that failed to account for lost rewards when a Vault was slashed (after a premium redeem). This upgrade also introduces an KINT per kBTC limit which can be optionally set to prevent distributing too many rewards - there are no plans to enable this. The node release also includes the polkadot-v0.9.24 update which includes a libp2p fix for a potential DoS attack vector - this is a high-priority upgrade.

For more details, please see the following:

- https://github.com/interlay/interbtc/compare/1.14.1...1.15.0
- https://github.com/interlay/interbtc/releases/tag/1.15.0
- https://github.com/paritytech/polkadot/releases/tag/v0.9.24

**Request for fast-track by the TC.**


Upgrade to runtime v1.15.0


I am the owner of the vault impacted by the unsupported bitcoin version bug detailed in the Kintsugi post mortem here  https://medium.com/interlay/kintsugi-the-first-60-days-of-decentralized-bitcoin-87085c2bf717

As of today, 19 KSM and 0.02 BTC are locked and can't be recovered. I've submitted a treasury proposal to get some KINT as partial compensation

Recovering funds impacted by the unsupported Bitcoin version bug

**Summary**

We want to temporarily extend the redeem period to allow us to fix / implement a way to bump transaction fees.

In the meantime, we recommend all Vault operators manually enable Replace-By-Fee (RBF) on their bitcoin full-nodes by setting `walletrbf=1`.

**Proposal**

Increase the redeem period to approximately 7 days (assuming ~12s per block).

We currently have a Vault with redeem requests where the block inclusion fees are set too low. Unfortunately the RBF feature we enabled in the client doesn't seem to work. 

Considering the above, we want to extend the redeem times so that we have enough time to either find what's not working with RBF or find an alternative way for Vaults to "bump" the chances of their transaction being included on mainnet.

NOTE: this is a temporary change and will revert in approximately 8 days which should give Vault operators enough time to adjust their configurations.


Temporarily extend redeem period for 8 days

This includes the new `orml-asset-registry` pallet and upgrade to `polkadot-v0.9.20`.

- https://github.com/interlay/interbtc/releases/tag/1.14.1
- https://github.com/paritytech/polkadot/releases/tag/v0.9.20

Requesting fast-track on Monday 13th June 2022 ~ 9AM GMT.


Upgrade to runtime v1.14.1

#### As part of this proposal, I also suggest that we `Fast track` its enactment so that we can allow for new issuance, given that we have already had a lengthy time to discuss; and there has been no contention from the community.

----------------------------------

## Summary
This proposal enables the usage of `KINT` as collateral for Kintsugi vaults.

## Proposal
> ℹ️ The full discussion of this proposal can be found [in this post](https://kintsugi.subsquare.io/post/5)

```
Currently only KSM is accepted as collateral for vaults. One of the main goals for kBTC stability is to diversify the number of tokens that can be used as collateral. This has also been requested by current kBTC vault operators.

The next asset suggested as collateral is the KINT governance token. It is the quickest to enable and has also been one of the main requests from active vaults.
```

In order to enable `KINT` as collateral, to activate the new Vaults, parameters need to be changed on-chain as following:

- **Initial collateral ceiling:** `100,000 USD equivalent` (26,200 `KINT`)
- **Secure collateral threshold:** `900%`
- **Premium redeem threshold:** `650%`
- **Liquidation threshold:** `500%`
- **Minimum Collateral:** `55 KINT`

## Further Resources

- [kBTC Collateral Analysis For KSM](https://medium.com/interlay/kbtc-collateral-analysis-ksm-f481f66f8a5e)
- [Kintsugi Governance 101](https://docs.interlay.io/#/kintsugi/governance)
- [Governance guides](https://docs.interlay.io/#/guides/governance)
- [Kintsugi tokenomics](https://docs.interlay.io/#/kintsugi/tokenomics)
- [Python code used for analysis of new assets proposed as vault collateral](https://github.com/interlay/collateralization-analysis)



Enable A New Vault Type With KINT As Collateral

This proposal implements a restriction of voting power for two years for team and investors to ensure that Kintsugi decisions are fully decentralized.

### Background

Since both vested and unvested tokens can participate in voting, the Interlay team and investors introduce additional restrictions on their own voting power during the first 2 years after network launch. Specifically: while the community can use 100% of their vested and unvested KINT to vote, team and investors can only use a portion of their KINT (which is subject to lockup and vesting) to participate in governance - increasing linearly over 2 years.

### Voting Power Distribution

See https://docs.interlay.io/#/kintsugi/governance?id=voting-power-distribution


Limit voting power of Kintsugi team and investors

This includes some migrations and the upgrade to polkadot-v0.9.19.

- https://github.com/interlay/interbtc/releases/tag/1.13.0
- https://github.com/paritytech/polkadot/releases/tag/v0.9.19


Upgrade to runtime v1.13.0

This includes some migrations and the upgrade to polkadot-v0.9.19.

- https://github.com/interlay/interbtc/releases/tag/1.13.0
- https://github.com/paritytech/polkadot/releases/tag/v0.9.19

[Cancelled]: Upgrade to runtime v1.13.0

# Summary 

This proposal accept's Parallel Heiko's request for opening the XCM channel, and requests the opening of the channel in the reverse direction. Note that after execution of this proposal, Parallel will need to accept on their side before we have functioning bi-directional communication. 

We would recommend not using the new xcm channel until we have announced it to be fully functioning.

# Technical proposal details:

Relaychain::RequestOpenTransact Data: 0x3c0025080000e803000000900100
Relaychain::RequestOpenTransact Hash: 0x565565261966dcdc6a762e97f2698fccba30759b585d09f5775fac7d28b9b2f0
Relaychain::RequestOpenTransact url: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x3c0025080000e803000000900100

Relaychain::AcceptOpenTransact Data: 0x3c0125080000
Relaychain::AcceptOpenTransact Hash: 0xdb7cd9e58f1c034e08ca1aacf5dac638595b0746eb46a52a8df56725087d8af5
Relaychain::AcceptOpenTransact url: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fkusama-rpc.polkadot.io#/extrinsics/decode/0x3c0125080000

Batched Data: 0x02020826000101000214000400000000070084e7755f13000000000700a0db215d0006000700e40b5402383c0025080000e803000000900100140d01000400010100a2e1685f62b2a1a996a2a1ba10ac6836c2b72174cab1bd1c6907454e6365fb7026000101000214000400000000070084e7755f13000000000700a0db215d0006000700e40b5402183c0125080000140d01000400010100a2e1685f62b2a1a996a2a1ba10ac6836c2b72174cab1bd1c6907454e6365fb70
Batched Hash: 0x203e0b62605995d1ca8079fd2b081d645f7a863bdb1c241d68f2b984027a6cf6
Batched url: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fapi-kusama.interlay.io%2Fparachain#/extrinsics/decode/0x02020826000101000214000400000000070084e7755f13000000000700a0db215d0006000700e40b5402383c0025080000e803000000900100140d01000400010100a2e1685f62b2a1a996a2a1ba10ac6836c2b72174cab1bd1c6907454e6365fb7026000101000214000400000000070084e7755f13000000000700a0db215d0006000700e40b5402183c0125080000140d01000400010100a2e1685f62b2a1a996a2a1ba10ac6836c2b72174cab1bd1c6907454e6365fb70


Open XCM channel with Parallel Heiko

Authorizes the runtime upgrade to release [1.12.2](https://github.com/interlay/interbtc/releases/tag/1.12.2) which contains an important bug fix for liquidated Vaults which has left the parachain in an invalid state.

Upgrade to release 1.12.2

**Ongoing costs for the running of high performance, scalable, and reliable public infrastructure for Interlay’s Kintsugi Network.**

OnFinality has been running API service resources for Interlay since the 1st of September 2021 - this proposal covers this period from the 1st/September 2021 to 31st/March 2022. Over this period we served a total of 514,371,649 responses through our API service and over 3 TB of data egress. Our highest day saw over 14 million responses in a single 24 hour period and at the end of the period the 7 day average is 8,955,955 responses.

[You can read the full proposal here](https://docs.google.com/document/d/1QIAb5yD2q1aW4iMyPSufCL1SxtXuIL4I4FpP7hlpEOI/edit?usp=sharing)

OnFinality - High Performance Public Infrastructure (Q3, 2021 - Q1, 2022)

Many Bitcoin transactions are currently getting stuck due to low inclusion fees. Some have been open for 8+ hours and have estimated inclusion times of 24+ hours. Current inclusion estimates say that 19 sat/vB should be included in an hour. However anything below that (5 redeem requests at time of writing) might take a day or longer. It is not clear why Vaults are spending too little on fees but it is possible that the ongoing market volatility is playing a role.

In order to prevent honest Vaults from being slashed / banned we should **fast-track** this proposal to increase the timeouts from 24 to 48 hours (on the assumption of 12s block times - in reality this will be longer).

The team will continue to investigate future mitigations such as the replace-by-fee mechanism.



Increase Issue, Redeem and Replace Periods to 48h (@ 12s p/b)

This release upgrades Kintsugi from 1.10.0 to 1.12.1. We will fast-track this proposal soon so that it can be included before the end of the week.

# Major changes


- Upgraded to polkadot-v0.9.18
- Issue and replace no longer take a griefing collateral amount argument - the amount is now determined automatically
- Bitcoin public key is now shared among all vaults that are controlled by the same accountid, in preparation of multicollateral support
- Proposals can now be cancelled by their authors
- Replace requests can now be executed even after they have been cancelled, as long as the vault has sufficient collateral

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.12.1
- https://github.com/interlay/interbtc/releases/tag/1.12.0
- https://github.com/interlay/interbtc/releases/tag/1.11.0

# Code changes

https://github.com/interlay/interbtc/compare/1.10.0...1.12.1


Release 1.12.1

There is already a proposal to increase the KSM collateral ceiling to 60k KSM. 
https://kintsugi.subsquare.io/democracy/referendum/29

The proposer asked for a TC fast-track - the TC seems and all Vault operators who have voiced their opinion in the comments or in the Discord are in favor.

However, since the proposal already became a referendum, it can no longer be fast-tracked. This means it would take 10 days to activate which - given the current KSM price drop and dire need for Vault to be able to add more collateral - is not feasible.

I have hence created a new proposal that can be fast tracked. 

@TC: please fast track asap so us vault operators can add more KSM to avoid liquidation. 

For fast-track: Increase KSM Collateral Ceiling to 60k KSM

### Summary

I propose that we increase the KSM collateral ceiling for vaults from 15.000 KSM to 60.000 KSM

### Proposal

Since vaults have already locked up most of the current 15k KSM collateral, we should proceed to increase the ceiling for KSM to 60.000. This will allow vaults to increase their collateral and be able to accept more kBTC to be minted. I believe this is also beneficial to the Kintsugi ecosystem!

### Request for fast track:
Also, I request that the proposal be fast tracked in order to avoid the existing ceiling being reached and limiting vaults from adding more collateral. Ideally the fast track would allow for the ceiling to be raised before end of next week. 

Why do we need to raise the collateral ceilings?
The ceilings limit how much BTC a vault can host/store. We started on purpose with a low overall ceiling when launching Kintsugi to have time to fix any issues that might come up. However, it is not feasible for scaling the system and allowing users to issue kBTC to keep the ceilings so low.

Increase KSM Collateral Ceiling to 60.000 KSM - public proposal #31

The preimage is invalid and the referendum will fail anyway.

Cancel Referenda #27

Untitled - public proposal #18

Following up the latest discussions in the vault-lounge at Interlays Discord I'm proposing to double the current collateral cap to allow growth and broader usage.

CollateralCeiling Increasement to 15k KSM

This was an accidental submission from @whisperit, proposing to cancel the ongoing referendum.