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

Governance
,
1

Summary

This proposal aims to amend the previous asset registration proposal 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.) 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 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.

1 Like
2

Links to: https://moonriver.polkassembly.network/referenda/32

1 Like
3

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

4

CertHum certainly supports this correction.

5

For xcvTokens on Moonbeam have the same issue, which had been posted to Whitelist track for emergency fixing: Moonbeam Dapps

6

hey Tyrone, please ensure that you provide a more detailed explanation of the current #32 proposal and consider renaming it if necessary. when you submit multiple proposals on the same topic, it can create confusion. It appears that you’ve sent a link to the Moonbeam proposal

2 Likes
7

Since GeneralAdmin origin was not enough for assets_forceAssetStatus, This proposal had been reinitiated in Root Track, Proposal #41.

1 Like
8

I changed the the topic name to “MR32/MR41” because this proposal specifically relates to two distinct MRs: MR32 and MR41. this renaming helps clarify the topics being discussed

here’s Tyrone’s response for reference: [Proposal: MR32] Fixing xcvKSM, xcvMOVR and xcvBNC Asset sufficient to “true” - #7 by tyrone1868

2 Likes
9

Thanks for help turrizt. Kevin and Aaron recommended me to post a forum dicussion for the MR41, so I would create a new one though.

1 Like
10

Tyrone, with all due respect, your approach has been causing confusion. when it was essential to introduce a new proposal on the forum, it would be greatly appreciated if you could create a dedicated proposal post promptly. instead of sharing fragmented information and then disappearing, consider posting a comprehensive proposal from the start. this way, the forum can serve as a place where community members clearly understand what they are voting for and can easily navigate through the discussions. Thank you :slight_smile:

1 Like
11

Kindfully advice, thank you.

1 Like