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

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)

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)

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

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

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

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.
