[Proposal: 23] REPLACED BY PROPOSAL 25

Governance
,
1

*This proposal is replaced by proposal #25 for seeking Whitelisted accelerating.

Summary

This proposal is specific to fixing an issue with a previously passed governance vote. 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.

1 Like
2

Links to: Change xcvDOT, xcvGLMR, xcFIL, and xcvFIL Asset sufficient to “true” | Polkassembly

3

Small original mistake that prevents us from using the listed assets correctly.
We would need to change the parameters ASAP :heart:

4

Absolutely support this correction.

5

This proposal had been posted to Whitelist Track for Emeregency fixing: https://moonbeam.polkassembly.network/referenda/23

7

hey Tyrone, please ensure that you provide a more detailed explanation of the #21 proposal and consider renaming it if necessary. when you submit multiple proposals on the same topic, it can create confusion

1 Like
8

This topic was derived from two 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 Proposal #25.
2 Likes
9

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.

2 Likes
10

Here’s a screenshot showing the successful state of isSufficient = true

1600Ă—796 184 KB

1 Like
11

This DOT unlock is a once-in-a-lifetime event and if Moonbeam doesn’t have options for liquid staking / farms etc then it’ll be a huge miss for the ecosystem. Getting as much DOT locked on Moonbeam should be the #1 priority so this is of strategic importance for the community. This should get approved

12

Having liquid staking on Moonbeam is massive with this DOT unlock coming. Would be an absolute shame to not fast-track this because of an error in creation. This is a must do IMO

13

All - please note that this proposal is no longer valid and is replaced by proposal 25:

The testing reported by @kevin was done on proposal 25.

All commentary should move to proposal 25, sorry for the confusion.

4 Likes