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

Activate KINT Vault Rewards

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

Reduce issue fees to 0.15%

Increase system collateral ceiling to 2500 KSM

Required for kBTC launch to ensure more Vaults can register, previous ceiling was 317 KSM.

Increase system collateral ceiling to 1326 KSM

This release upgrades Kintsugi from 1.8.1 to 1.9.0

# Major changes

- Simplify Vault reward supply distribution

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.9.0
- https://github.com/interlay/interbtc/releases/tag/1.8.2

# Code changes

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

Release 1.9.0: Simplify Vault Reward Supply Setting

### Summary

This proposal activates KINT staking rewards as of block 599997 - that is, around 15 March 12:00 UTC (depending on block times). *[Update: due to slower block times, rewards will likely activate around March 16th EOD UTC]*

### Proposal

The Interlay team has informed the community in a discussion post that the staking rewards can be activated. 

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

### Requesting TC Fast-track

Since everything is ready and the community has been waiting for staking to be activated, a fast-track by the Technical Committee is requested. This way, staking rewards can go live on March 15. 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). 


Activate KINT Staking Rewards 

This release upgrades the Kintsugi from 1.7.3 to 1.8.1

# Major changes

- Upgrade polkadot dependency to 0.9.17
- Fix difficulty check bug in btc-relay
- Fix stack overflow in democracy due to missing decode limit in do_enact_proposal
- Don't charge a tx fee for execute_redeem

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.8.1
- https://github.com/interlay/interbtc/releases/tag/1.8.0
- https://github.com/interlay/interbtc/releases/tag/1.7.4

# Code changes

https://github.com/interlay/interbtc/compare/1.7.3...1.8.1



Release 1.8.1: Upgrade Kintsugi to polkadot 0.9.17 and fix a difficulty check bug in the btc-relay

The stable parachain confirmations had been set to 600 parachain blocks. However, this was using 6-second block times that are standard in standalone mode. This proposal corrects the parachain confirmations to 300 blocks accounting for 12-second block times in the parachain mode.

The arguments are obtained as follows:
- storage key obtained by going to chain state -> btcRelay -> stableParachainConfirmations. It shows the encoded storage key.
- The value should be 300 (because 300 * 12 = 3600), which in hex is 0x12c. Encoded in 32 bit little endian this is 0x2c010000

Account for 12 second block times in stable parachain confirmations

This is part 2/2 to open the bi-directional channel with Karura. See [referendum #7](https://kintsugi.subsquare.io/democracy/referendum/7) for more details.

Open XCM channel with Karura - Part 2/2 (HRMP ACCEPT)

Before releasing kBTC, we remove all currently unused oracle accounts. Oracles should be added later via a governance process and then dedicated accounts should be added instead, or, better, dedicated pallets should be added.

Remove outdated oracle account

# Karura XCM

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

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

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

Note: The proposal was fast-tracked by the technical committee.

# Force XCM

The second part of this proposal enforces all XCM to use V2.

Open XCM channel with Karura - Part 1/2 (HRMP INIT) || Force XCM version to V2

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



This is part 2/2 to open the bi-directional channel with Mooonriver. See [referendum #4](https://kintsugi.subsquare.io/democracy/referendum/4) for more details.

Open XCM channel with Moonriver - Part 2/2 (HRMP ACCEPT)

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

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

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

Note: The proposal was fast-tracked by the technical committee.

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

This release upgrades the Kintsugi from 1.5.9 to 1.7.3.

# Major changes

- Upgrade polkadot dependency to 0.9.16
- Adds functionality for parachain to parachain communication

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.7.3
- https://github.com/interlay/interbtc/releases/tag/1.7.2
- https://github.com/interlay/interbtc/releases/tag/1.7.1
- https://github.com/interlay/interbtc/releases/tag/1.7.0
- https://github.com/interlay/interbtc/releases/tag/1.6.1
- https://github.com/interlay/interbtc/releases/tag/1.6.0
- https://github.com/interlay/interbtc/releases/tag/1.5.13
- https://github.com/interlay/interbtc/releases/tag/1.5.12
- https://github.com/interlay/interbtc/releases/tag/1.5.11
- https://github.com/interlay/interbtc/releases/tag/1.5.10
- https://github.com/interlay/interbtc/releases/tag/1.5.9

# Code changes

https://github.com/interlay/interbtc/compare/1.5.9...1.7.3


Release 1.7.3: Upgrade Kintsugi to polkadot 0.9.16 and integrate XCM modules for parachain to parachain communication

This referendum has not been executed due to a misconfiguration in the fast-track. Fast-track delay was set to 7,200 blocks. Since this change was needed ahead of time, a new referendum was brought forward instead.

NOT EXECUTED: Duplicate of referendum 3 to upgrade Kintsugi to release 1.7.3

This release upgrades Kintsugi from 1.5.6 to 1.5.9

# Major changes

- Introduce ss58 prefixes for interlay and kintsugi
- Add endowed accounts to chain spec for token distribution

# Release notes

- https://github.com/interlay/interbtc/releases/tag/1.5.9
- https://github.com/interlay/interbtc/releases/tag/1.5.8
- https://github.com/interlay/interbtc/releases/tag/1.5.7

# Code changes

https://github.com/interlay/interbtc/compare/1.5.6...1.5.9

Release 1.5.9: Upgrade Kintsugi to polkadot 0.9.13 and add several bugfixes

This referendum was not executed since `setCode` is not supported on parachains. Instead, the `authorize` and `enact` flow must be used.