Summary
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.
