*Since Proposal MR32 passed but executed failed with bad origin in General Admin Track, this proposal has been reinitiated in Root Track now.

# Summary

This proposal aims to amend the [previous asset registration proposal](https://forum.moonbeam.network/t/proposal-24-register-bifrost-liquid-staking-tokens-lsts-xcvksm-xcvmovr-xcvbnc-on-moonriver/921) by changing the `sufficient` value of the registered xcvKSM, xcvMOVR and xcvBNC from 'false' to 'true'.

# Issue Statement

Recently, we have discovered that xcvToken , Bifrost liquid staking tokens "vTokens", cannot create trading pairs when integrating with Native Moonbeam and Moonriver DEXs such as Stellaswap, Beamswap, and Solarbeam. ([*The issue had fixed on Moonbeam.](https://moonbeam.polkassembly.network/referenda/25)) The reason is that when xcvToken is registered, the `sufficient` parameter is set to false, which prevents any address from receiving xcvToken without having the native token GLMR. As a result, the contract for creating trading pairs fails.

Failed TXes for example:

On Beamswap V2: https://moonscan.io/tx/0xf2afc1c170bd70fc6bce7a3b6f8188eb3bc9c22ebf37e9dfaba47a8667329136

V2: https://moonscan.io/tx/0x97ca37b9b6bd13f1ce0347fc420500d0c4a47b26dfa2cbd80d3d8e81af3c01b5

V3: https://moonscan.io/tx/0x3de1e740eb3e8def53defcc21b6b9f5bf21682b768c097ca6744b3bf1ea6fdca

On Solarbeam:

https://moonriver.moonscan.io/tx/0x100a076e860487900e7b2e6f6bd47d66ba961a883f47376cc80f47aaf128b554

As the Moonbeam team reported: “If an asset is `sufficient` it means that it can be sent to an account that has no balance of a native token. If an asset is not sufficient, it can't be sent to an account that has no balance of the native token.”

Although sending GLMR or MOVR to a DEX pool contract in advance to avoid `sufficient` issue can be solution, but pool contract needs to have a payable function to accept GLMR, which unfortunately most DEXes pool contracts doesn't have.

So, we would need to change `sufficient` from `false` to `true` to ensure that any address can still receive xcvKSM, xcvMOVR and xcvBNC without MOVR.

Send a batch of dispatch calls and atomically execute them.
The whole transaction will rollback and fail if any of the calls failed.

May be called from any origin except `None`.

- `calls`: The calls to be dispatched from the same origin. The number of call must not
  exceed the constant: `batched_calls_limit` (available in constant metadata).

If origin is root then the calls are dispatched without checking origin filter. (This
includes bypassing `frame_system::Config::BaseCallFilter`).

## Complexity
- O(C) where C is the number of calls to be batched.

Problem Statement:
- The `sufficient` value of registered xcvKSM, xcvMOVR, and xcvBNC tokens is set to 'false', preventing trading pairs from being created on Moonbeam and Moonriver DEXs.

Significance:
- The current setting hinders the ability to trade xcvTokens on DEXs, causing failed transactions and limiting liquidity.

Proposed Solution:
- Change the `sufficient` value of xcvKSM, xcvMOVR, and xcvBNC tokens from 'false' to 'true' to allow any address to receive these tokens without requiring MOVR.

Expected Outcomes:
- Enable the creation of trading pairs for xcvTokens on Moonbeam and Moonriver DEXs, improving liquidity and facilitating seamless transactions.

#45 [Proposal: MR45] Root Origin: Fixing xcvKSM, xcvMOVR and xcvBNC Asset sufficient to “true” (Will be decision deposited by Moonbeam)

No Active Proposals