[Proposal: 25] Emergency Fixing xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true” (Seeking for whitelisted fast track)


This proposal is specific to fixing an xcToken contract issue with a previously passed governance vote. And replacing proposal #21 in General Admin Track for accelerating and proposal #23 in Whitelisted Track with adding xcvDOT as XCM fee asset by supporting with Purestake team.

*We are seeking assistance from the technical committee to whitelist the pre-image so that the whitelist track can be used to accelerate this proposal.

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: Moonbeam Transaction Hash (Txhash) Details | Moonbeam

V2: Moonbeam Transaction Hash (Txhash) Details | Moonbeam

V3: Moonbeam Transaction Hash (Txhash) Details | Moonbeam

On Solarbeam:

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.

Links to: https://moonbeam.polkassembly.network/referenda/25


This topic was derived from two previous proposals with the same objective:

  1. Proposal #21 in the General Admin Track.
  2. Proposal #23 in the Whitelist Track.

Here is an explanation in case there is any confusion as to why we posted the same proposals twice:

  1. For Proposal #21 in the General Admin Track, due to the lengthy governance process in this track and the urgent nature of the issue mentioned above, we discussed with the Purestake team to seek acceleration in the Whitelist Track.
  2. For Proposal #23 in the Whitelist Track, we received support from the PureStake team to add xcvDOT as an XCM fee asset. Therefore, we included the corresponding changes in this Proposal #25.

Said this to the other one as well. This is a must do;

  • Will only be one unlock, ever
  • 100M DOT needs places to live
  • Liquidity is lifeblood for DeFi and if even a small % comes to Moonbeam it’s a big win
  • There has been significant coordination between multiple teams to hit this date, delaying this or missing this window due to an XCM parameter mistake should not happen.

To be clear, the pre-image associated with this proposal is:


This is a whitelist.dispatchWhitelistedCallWithPreimage that contains the operations as described above.

The callhash to be whitelisted is thus:


I have confirmed that this is the pre-image/referendum that was tested in chopsticks.


A proposal to whitelist the call has been created for the Technical Committee’s consideration.

Technical Committee members are individually deliberating the matter and have been asked to put in their vote of either Aye or Nay within the next 24 hours. That should still provide lots of time to pass the referendum if a majority of Tech Committee members vote in favor.

A reply will be posted following the close of the vote tomorrow indicating whether the call was whitelisted or not.

1 Like

Hi @tyrone1868 !

Thanks for posting a detailed breakdown and the reason for urgency. Do you know how this was missed in testing? Maybe I am just misunderstanding the issue statement, but wouldn’t sending test Tx’s to validate caught this much earlier?

1 Like

Copying my comments over from the prior referendum 23:

Chiming in here to voice my support and mention that this was tested via Chopsticks, not just the execution of the proposal itself but the whitelisting of the proposal, voting by a simulated technical committee, and finally the execution of the whitelisted proposal. This successfully changed the asset status to isSufficient = true as expected. There were no issues with the test.


Hi everyone,

The OpenGov tech committee has decided to whitelist this proposal to fast track it - a majority of the TC was in support and voted accordingly.


Just wanted to let everyone know that at this point, proposal 25 has been enacted.


@tyrone1868 Hi–Even though the OpenGOV TC group approved of this fast track request. I would still like to know how this was not caught in testing and required a fast track proposal request.

Hey @blackk_magiik ,
Thanks for asking this, I think it did lack of asset testing with contract on EVM when registering. Our focus was concentrated on XCM testing at that time. Hence, we found this issue just right approach to DOT unlock, but it was did lack of testing.

1 Like

Hey @tyrone1868 thanks for the honest answer!