The Brale integration and dUSD stablecoin are live on Kusama Asset Hub.

A pair of proposals have been approved, #471 recouped integration costs and #474 received KSM to KSM Collective on Krievo to add liquidity to the new KSM:dUSD pair.

Brale are committed to adding an initial $300k of liquidity to the dUSD side of the pair.

KSM Collective has received $300k of KSM to add to the other side of the pair.

However… Asset Conversion Pallet which is based on Uniswap v2 only allows a single account to add liquidity which presents a challenge.

We are returning to OpenGov to communicate the issue, to solicit feedback and to get signal ahead of next steps.

This WFC is primarily to get specific feedback from Parity’s System chain’s team who are responsible for maintaining Asset Hub’s runtime about the feasibility of updating ACP.

There are (currently) three options:

1. Amend Asset Conversion Pallet to enable synchronous management of asset pairs by two separate accounts rather than a single entity. This would enable Brale to add dUSD and KSM Collective to add KSM. LP fees would be split evenly to each contributing party.
2. Wait for smart contracts on Kusama AH (Q1 2025) and abstract the required logic into a specific contract, enabling the same outcome as 1.
3. Send the KSM from KSM Collective to Brale who add the liquidity as a single account owner. An agreement would be arranged for 50% of the LP fees to be sent back to KSM Collective. For regulatory and compliance reasons Brale will not be able to move dUSD to KSM Collective.

Additional context

Kusama is not currently serviced by a DEX with single sided liquidity so we feel 1 would not compete with an incumbent offering.

1. addresses the issue at source and potentially enables more innovation to come to Kusama AH but is predicated on pushing a change in the runtime via The Fellowship.

2. is optimised for simplicity and permissionless innovation, but will require work from Virto’s team on the contracts - we also need to wait for contracts to be live.

3. Is best for speed - however it adds some off-chain bureaucracy and reduces the function of KSM Collective as a direct agent in the network.

In the absence of clear direction we will likely opt for speed and go with option 3 - with an understanding that the structure approved by OpenGov is changing.

This will allow us to get the pair up and working, we can then address the lower level issues after.

Alternatives

We may be missing an obvious alternative, feel free to comment with your thoughts.