# 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 issue lies in the inability of xcvToken, Bifrost liquid staking tokens "vTokens", to create trading pairs with Native Moonbeam and Moonriver DEXs due to the `sufficient` parameter being set to false. This prevents any address from receiving xcvToken without having the native token GLMR, causing the contract for creating trading pairs to fail.

- Significance: This problem hinders the integration of xcvToken with Native Moonbeam and Moonriver DEXs, limiting its functionality and potential use cases.

- Proposed Solution: The proposed solution is to change the `sufficient` value of the registered xcvKSM, xcvMOVR, and xcvBNC from 'false' to 'true'. This will allow any address to receive these tokens without needing the native token GLMR.

- Expected Outcomes: The expected outcome is the successful creation of trading pairs with Native Moonbeam and Moonriver DEXs, enhancing the functionality and usability of xcvToken. This will also eliminate the need for DEX pool contracts to have a payable function to accept GLMR.

#41 Root Origin: Fixing xcvKSM, xcvMOVR and xcvBNC Asset sufficient to “true”

No Active Proposals