Proposal https://kintsugi.subsquare.io/democracy/proposal/116 seeks to force to move funds. There's no motivation given for this proposal.

We hence assume that this is a malicious proposal and seek to cancel it.

Cancel proposal #116 - missing description and motivation to move funds

Follow up on https://kintsugi.subsquare.io/democracy/referendum/6

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 (Part 2)

# TL;DR

- Problem: The liquidity in the lending market is too low so that it does not allow for efficient borrowing or lending
- It is proposed to create initial liquidity for lending by incentivizing the supply of USDT and KSM for 1 month with a total of 3,000 KINT (1,500 for each market)
- It is expected to raise around $80,000 liquidity for each of the markets with an expected APY of 15%

# Problem

The lending market on Kintsugi currently faces the typical ‘chicken-egg’ problem in that there is no sufficient liquidity to borrow USDT or KSM at size without increasing the utilization to level where the interest rates become too high (above 90% utilization the interest rates increases very fast). 

Simultaneously, while there is low borrowing activities, the yield for supplying USDT or KSM is comparably low so that lender find more profitable opportunities on other lending protocols.

# Solution

To overcome this issue, it is suggested to bootstrap initial liquidity in the lending market by incentivizing the supply of USDT and KSM for one month. By then, there should be enough liquidity to allow for efficient borrowing of these tokens such that the interest rates can adjust by market forces.

Therefore, this proposal seeks to incentivize the supply of USDT and KSM markets with a total of 3,000 KINT for one month. 

Comparable rates for USDT and KSM on other protocols are

| Protocol | USDT | KSM |   
|---------|--------|-----|
| Parallel Heiko | 11% | 5% | 
| Moonwell | 13% | 11% | 


# Expected result

Assuming a conservatively high APY of 15% for USDT and KSM to attract sufficient liquidity, distributing the rewards equally between the two markets for one month would result in a target liquidity of $80,000 for both market.

Incentives for Kintsugi Lending

Proponent/Paid to: a3bDuQajgZhVs7Z9bJxfxBNyqBqmQCZr37okVrU7NCfzABJo8
Date: 11th April 2023
Requested KINT: 1,278.0051
Short description: Ongoing costs for Quarter 1 (January, February and March) of 2023, 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.

## Service Details 

Interlay is currently leveraging SubQuery’s enterprise-level managed service to provide reliable hosting for their SubQuery projects. This critical service provides production data to applications built by the Interlay team and the 99.9% uptime reliability ensures a seamless experience for the core team and their ecosystem. 

Over the period of 2023-01-01 to 2023-03-31, SubQuery supported Interlay’s SubQuery projects running in a shared database for a total of 4,320.0 compute hours. Each project deployment requires an indexing service, a compute service, and database access run in a production environment and monitored constantly to ensure availability.


## Costings

This proposal includes combined running costs for our infrastructure for Interlay from 1st January 2023 until 31st March 2023. The total combined running cost is USD $934.32. 

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

SubQuery Managed Service Solution (Q1 2023)

## Background
While the core implementation of the lending protocol on Kintsugi has proven sound and works smoothly, we recently identified a UX bug at the parachain level where the "collateral toggle" does not work correctly.

The expected behaviour is that when the collateral toggle is enabled for a certain currency, the user's qToken balance becomes locked. Any incoming qTokens that the user receives, either by depositing underlying currency such as DOT and receiving qDOT, or by receiving qDOT from another user through a direct transfer, is automatically locked so it counts as collateral. This auto-locking of incoming qTokens is configured in the orml-tokens pallet. 
- The Kintsugi-Testnet, where we ran the trading competition, had a [correct configuration](https://github.com/interlay/interbtc/blob/5ffe24501f504f1a75728bc813331f3cbe62e2a6/parachain/runtime/testnet-kintsugi/src/lib.rs#L662) of the orml-tokens pallet and everything worked correctly. 
- The Kintsugi mainnet, on the other hand, had [no configuration](https://github.com/interlay/interbtc/blob/5ffe24501f504f1a75728bc813331f3cbe62e2a6/parachain/runtime/kintsugi/src/lib.rs#L693) for qToken actions, which resulted in incoming tokens not being auto-locked. This can cause several issues, such as max redeems failing, or new deposits not increasing the borrow capacity.

## Fix
Since the bug is that users may have both locked and free qTokens due to the auto-locking not happening, the [fix](https://github.com/interlay/interbtc/blob/33aaa3e1b6e2a61270ecc12f070fba241b096f55/crates/loans/src/migration.rs#L71) is to lock all the free qTokens for these users. In addition, the auto-locking actions are added to the Kintsugi runtime.

There are currently six accounts in an inconsistent state, all of which will have their free qToken balance locked once the fix executes. See the list below, where `lendToken` is the on-chain representation of qTokens.

```
a3c7Y5PBGnRRqmdoLpMo57JEJvpMcf6UmeaVgcARtFaj83XLU { lendToken: 3 } {"free":308696658247,"reserved":10058464217,"frozen":0} a3f7VPekrRf6Fve5JZXSnVqfkk5sa11UK3vU4WmXcGZxFmbMq { lendToken: 1 } {"free":99999579,"reserved":199999159,"frozen":0} a3aW5opjuroJDexG2edqXao5YqopHitoDxeuN98jvXDd3KRLp { lendToken: 3 } {"free":3058194,"reserved":3597544,"frozen":0} a3enkTvngppdDCLHkCSWmVQeFJ4NY35CStucvwHaRzhp56Tn8 { lendToken: 1 } {"free":599997308,"reserved":249999394,"frozen":0} a3aQPXJV6GGboBc3PPFbjM7cMEXLEw6X5DukgSFEhf8ucNNkN { lendToken: 1 } {"free":1249994288,"reserved":1124994859,"frozen":0} a3dkY3yWweLMkUjbSSNC2NawWegH3NZkWpYjsnBr2srQsp9LZ { lendToken: 2 } {"free":299970489359256,"reserved":100000000000000,"frozen":0}
```

Fix: Migrate inconsistent qToken account balances

Following the XCM issue resolved in https://kintsugi.subsquare.io/democracy/referendum/105, this proposals seeks to correct the balance of users that lost KSM when transferring them from Kusama/Statemine to Kintsugi.

## Background

When users transferred KSM from Kusama/Statemine to Kintsugi, KSM was allocated to the Kintsugi sovereign account on Kusama. However, the KSM that should have been allocated to the users on Kintsugi, were not created.

## Fix

Create KSM for users that were affected on Kintsugi in two steps:

1. setBalance of a temporary account. The account is arbitrary, it is ASCII encoding of 'temporaryAccount': a3cqmerph3fSEf6JuocyJGwonsgdBejZA6uBuz5bkLSeAARB1.
2. forceTransfer KSM to the affected users.

Transfer user 1: 0.910270119553 + 0.913770119553 + 1.500070119553 + 0.010161648 + 0.010161648 = 3344433654659 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
Transfer user 2: 5.000161648 to 0x8ec89c17095e305b89ce3d9525aca6e43d4dc4f2c877dc3e11d5ce9f3ce7b441

## Reported Transactions

The transfers follow the following report of transactions by users that have been verified to (1) were in fact KSM transfers to Kintsugi and (2) failed due to the XCM bug.

- https://kusama.subscan.io/xcm_message/kusama-676119b1259061b4d579a297f7620a99cba40fa6
  - 0.910270119553 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
- https://kusama.subscan.io/xcm_message/kusama-a79f0e7d5f31e4dfc6a4cc604bbe39e97839e299
  - 0.913770119553 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
- https://kusama.subscan.io/xcm_message/kusama-4233b2d9e8aa5b6f013c7d6809c0ebe3437245bf
  - 1.500070119553 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
- https://kusama.subscan.io/extrinsic/17343403-2
  - 0.010161648 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
- https://kusama.subscan.io/extrinsic/17343331-2
  - 0.010161648 to 0xaa296cd0eaff31991f2e041907268723c76253d5ba6f09518a8eb9e23711a817
- https://kusama.subscan.io/extrinsic/17337306-2
  - 5.000161648 to 0x8ec89c17095e305b89ce3d9525aca6e43d4dc4f2c877dc3e11d5ce9f3ce7b441

## Extrinsic

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

## Request to table the proposal

As this proposal fixes a bug, we request TC to table this proposal to a regular referendum.

Fix: Return lost KSM due to an XCM issue

We have identified an issue affecting transfers from the Kusama and Statemine chains. This issue results from runtime upgrade 0.9.38 enacted on the Kusama and Statemine chains. It is is causing transfers from (but not to) Kusama and Statemine to fail.

The problem arose due to Kusama/Statemine migrating to XCM v3. While XCM v3 is supported on our chain, there was an initial issue when the Kusama channels were opened due to a misconfiguration. To fix this misconfiguration a governance proposal is required.

**Request to fast-track**

Since this issue affects all KSM transfers to Kintsugi, we request fast-track by the TC.

**Technical Details**

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

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

Fix Kusama XCM channel

Untitled - public proposal #100

**Raise USDT ceiling for bridge**

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

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

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

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


Raise USDT ceiling for bridge

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

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

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

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

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

SubQuery Managed Service Solution (Q3, 2022)

Proposal 107 was done incorrectly and this proposal cancels 107.

Cancel proposal 107

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

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

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

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

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

For more details, please see the following:

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

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

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

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

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


Upgrade to runtime 1.23.2: Kintsugi lending runtime configuration

This runtime upgrade adds two security updates:

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

For more details, please see the following:

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

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

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

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

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

Upgrade to runtime 1.23.1: Security updates

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

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

**Request to fast-track by TC**

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

Fix: Increase LKSM/KBTC SystemCollateralCeiling to 55,000

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

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

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


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


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

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

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

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

(USD conversion rates as of 15 March 2023)

DeFi hub activation on Kintsugi

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

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

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

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



Increase LKSM/KBTC SystemCollateralCeiling to 55,000

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

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

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

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

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

SubQuery Managed Service Solution (Q4, 2022)

# This proposal:

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

For more details, please see the following:

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

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

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


Upgrade to runtime 1.22.0: Governance Improvements

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

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

Remove potentially malicious proposal #94

This proposal:

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

Updates Kintsugi to the latest runtime (breaking).

For more details, please see the following:

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

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

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

Upgrade to runtime 1.21.10: Capacity-based vault revenue distribution

## Summary

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

## Tabling

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

## Why second try?

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


Register SKSM as a foreign asset (second try)

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

A runtime upgrade should fix this.

Prevent submission of proposals without a preimage

## Proposal

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

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

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


## Resources:

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

Activation of USDT as a Vault collateral on Kintsugi

## Summary

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

## Tabling

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


Register SKSM as a foreign asset

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

**TC Table**

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

**Extrinsic**

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

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

## Summary

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

## Tabling

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


Register VKSM as a foreign asset

## Summary

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

## Tabling

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


Register MOVR as a foreign asset

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

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

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


Patch vault version to 1.18.1

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

This runtime upgrade adds the following:

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

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

For more details, please see the following:

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

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

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

# Request for tabling

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

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

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

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

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

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

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

LKSM threshold reduction

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

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


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

## TC

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

Regular Key Rotation - Rotating Oracle and TC Keys

Hi, this is Jah from Solarbeam,

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


HRMP channel request cancellation

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

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

## Releases

For more details, please see the following:

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

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

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

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

## Proposal

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



Upgrade to runtime v1.20.0

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

## Tl;dr.

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

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

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



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

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

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

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

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

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

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

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

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

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

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

- KINT emission by ~78%

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

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

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

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

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

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

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

Adjustment to Vault Reward Schedule on Kintsugi

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

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

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

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

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

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

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


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


Follow Up to Proposal #75 - threshold reduction

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

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

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

Enable LKSM as collateral for Kintsugi Vaults

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

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

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

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

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

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

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


Register USDT as a foreign asset on Kintsugi

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

* * * * *

## Original Motivation

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

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

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

## Service Details and Enhancements

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

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

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

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

## Enhancements

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

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

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

OnFinality - High Performance Public Infrastructure (Q3, 2022)

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

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

For more details, please see the following:

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

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

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

Upgrade to runtime v1.19.1

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

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

For more details, please see the following:

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

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

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



DEPRECATED: Upgrade to runtime v1.19.1

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

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

For more details, please see the following:

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

## Collators

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

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


Upgrade to runtime v1.19.0

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

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

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

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

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

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

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

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

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