**This proposal had included the extra corresponding changes in proposal #25.* https://forum.moonbeam.network/t/proposal-25-emergency-fixing-xcvdot-xcvglmr-xcfil-and-xcvfil-asset-sufficient-to-true-seeking-for-whitelisted-fast-track/1338/2

# Summary

This proposal is specific to fixing an issue with a [previously passed governance vote](https://forum.moonbeam.network/t/proposal-2-register-bifrost-liquid-staking-tokens-lsts-xcvdot-xcvglmr-xcfil-and-xcvfil-on-moonbeam/920).  Given the length of governance and enactment process as well of that of the much anticipated DOT unlock in the broader ecosystem, we would be missing a key opportunity to which we have worked towards internally and with the Purestake team and Moonbeam ecosystem partners to which we simply cannot miss out on. More specifically, we have planned a series of DEX incentive campaigns,  have obtained a GLMR incentives grant and are part of the Ignite campaign in order to drive DOT liquidity to the Moonbeam ecosystem and build use-cases on native Moonbeam protocols with our liquid staking assets.

This proposal aims to fix by changing the `sufficient` value of the registered **xcvDOT, xcvGLMR, xcFIL, and xcvFIL** 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 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 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 xcvDOT, xcvGLMR, xcFIL, and xcvFIL without GLMR.

Emergency Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true” (This had been replaced for whitelisted in proposal #25)

**This proposal is replacing by proposal [#25](https://forum.moonbeam.network/t/proposal-25-emergency-fixing-xcvdot-xcvglmr-xcfil-and-xcvfil-asset-sufficient-to-true-seeking-for-whitelisted-fast-track/1338) for seeking Whitelisted accelerating.*

# Summary

This proposal is specific to fixing an issue with a [previously passed governance vote](https://forum.moonbeam.network/t/proposal-2-register-bifrost-liquid-staking-tokens-lsts-xcvdot-xcvglmr-xcfil-and-xcvfil-on-moonbeam/920).  Given the length of governance and enactment process as well of that of the much anticipated DOT unlock in the broader ecosystem, we would be missing a key opportunity to which we have worked towards internally and with the Purestake team and Moonbeam ecosystem partners to which we simply cannot miss out on. More specifically, we have planned a series of DEX incentive campaigns,  have obtained a GLMR incentives grant and are part of the Ignite campaign in order to drive DOT liquidity to the Moonbeam ecosystem and build use-cases on native Moonbeam protocols with our liquid staking assets.

This proposal aims to fix by changing the `sufficient` value of the registered **xcvDOT, xcvGLMR, xcFIL, and xcvFIL** 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 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 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 xcvDOT, xcvGLMR, xcFIL, and xcvFIL without GLMR.

[Proposal: 23] Emergency Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true” (This had been replaced for whitelisted in proposal #25)

# Summary

This proposal is specific to fixing an issue with a [previously passed governance vote](https://forum.moonbeam.network/t/proposal-2-register-bifrost-liquid-staking-tokens-lsts-xcvdot-xcvglmr-xcfil-and-xcvfil-on-moonbeam/920).  Given the length of governance and enactment process as well of that of the much anticipated DOT unlock in the broader ecosystem, we would be missing a key opportunity to which we have worked towards internally and with the Purestake team and Moonbeam ecosystem partners to which we simply cannot miss out on. More specifically, we have planned a series of DEX incentive campaigns,  have obtained a GLMR incentives grant and are part of the Ignite campaign in order to drive DOT liquidity to the Moonbeam ecosystem and build use-cases on native Moonbeam protocols with our liquid staking assets.

This proposal aims to fix by changing the `sufficient` value of the registered **xcvDOT, xcvGLMR, xcFIL, and xcvFIL** 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 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 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 xcvDOT, xcvGLMR, xcFIL, and xcvFIL without GLMR.

Emergency Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true”

[Proposal: 32] Emergency Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true”

[Proposal: 32] Emergency Fixing xcvKSM, xcvMOVR and xcvBNC Asset sufficient to “true”

- This proposal is about fixing a problem with some tokens on Moonbeam.
- The problem is that these tokens cannot be traded on certain DEXs because of a setting called "sufficient."
- The proposal wants to change the "sufficient" setting from false to true.
- This will allow anyone to receive these tokens without needing another token called GLMR.
- The proposal wants to make sure these tokens can be used by everyone.

#23 Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true” (This had been replaced for whitelisted in proposal #25)