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.

Cancel Referenda #24

accidental submission with an incorrect image. Apologies.

please cancel this one - public proposal #25

Based on the stability of the network we propose to increase the vault collateral ceiling to 7500 KSM

Increase System Collateral Ceiling to 7500 KSM

Based on the stability of the network we propose to increase the collateral ceiling to 7500 KSM

Increase collateral ceiling to 7500 KSM

We noticed a mistake with the proposal in that it calls "setSecureCollateralThreshold" instead of "setSystemCollateralCeiling".

Cancel Proposal #23

When the Kintsugi runtime was first uploaded to the Kusama crowdloan module we mistakenly assumed 6s block times which incorrectly calculated some genesis storage values. This proposal corrects this oversight to reduce the expiry period of issue, redeem and replace requests to one day (at the expected 12s block times) instead of two.

Update Issue, Redeem and Replace Periods

This release upgrades Kintsugi from 1.9.0 to 1.10.0

# Major changes

- Allow BTC transaction to have an number of outputs

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.10.0

# Code changes

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

Release 1.10.0: Allow Any Output for Bitcoin Transactions

See: https://github.com/interlay/interbtc/pull/546

Increase redeem transaction size

# Summary

This proposal activates KINT Vault rewards as of block 632805 - that is, around 4pm GMT (depending on block times).

# Proposal

The Interlay team has informed the community in a discussion post that the Vault rewards can be activated. See: https://kintsugi.subsquare.io/post/3

The next step is hence to activate Vault rewards via an on-chain governance proposal.

# Requesting TC Fast-track

Since everything is ready and the community has been waiting for Vault rewards to be activated, a fast-track by the Technical Committee is requested. This way, Vault rewards can go live on March 24. Without TC, this would be delayed by another 2 weeks (up to 7 days before the proposal becomes a referendum, and another week of voting and enactment).