Hi @jgreen, I’ve read through the document and would like to understand a little more information on the potential of IL, profit, and general admin of Omnipool.
What is the current TVL in the Omnipool?
Where did the initial liquidity come from for the other parachain tokens in the Omnipool (HDX, CFG, ZTG, ASTR)?
What is the current status of this initial liquidity for each token (current IL or profit, and to what extent?)
It appears that part of IL is based on the performance of other tokens in the pool (correct me if that statement is wrong, but that is what I gathered from the IL doc), and so what is the decision making process for new tokens added to the Omnipool / what metrics are used?
Thanks @AlbertoV19, amazing and thorough job. I would like to add the xTokens wrapper should not be needed to send the funds back, please let us know if you were successful using the following flow: withdrawAsset, buyExecution, depositReserveAsset -> [xcm to moonbeam: withdrawAsset, buyExecution, DepositAsset]
It appears that part of IL is based on the performance of other tokens in the pool (correct me if that statement is wrong, but that is what I gathered from the IL doc), and so what is the decision making process for new tokens added to the Omnipool / what metrics are used?
Listing new tokens is typically suggested and temperature-checked by the community in a public discussion on the HydraDX subsquare forum and also forum of the listed project. Then if all seems legit, it is passed to HydraDX council, who rigorously asseses all aspects associated with the token. The project, team behind it, tokenomics, security etc. The council then opens a motion and passes it to public referendum for all HDX holders to vote on the listing.
Hey @jgreen so I tested it out as per your suggestion but the actual combination is (with polkadotXcm.send):
WithdrawAsset → Takes the 10 xcGLMR from Moonbeam’s Sovereign Account on HydraDX and puts them on holding
BuyExecution → Buy block space in HydraDX
InitiateReserveWithdraw → Burns the remaining xcGLMR on holding and initiates an XCM message to withdraw the remaining xcGLMR from HydraDX’s Sovereign Account on Moonbeam. This instructions prepend WithdrawAsset and ClearOrigin from the following two instructions:
BuyExecution → Buy block space in Moonbeam
DepositAsset → Deposit to Moonbeam Treasury Address on Moonbeam
As for my part. All testing showed that the flow is possible. There is still one element that depends on HydraDX governance which is the creation of the GLMR position in Omnipool and assigning that position to Moonbeam’s Sovereign Account on HydraDX.
HydraDX submitted the preimage hash 0xcb11c8c1ca7c31233cde02c2a09d5d109b9726a5f14a797977dc625417d44611 to Moonbeam.
Using Chopsticks, I, once again, tested to confirm the flow would work. First, I submitted a Root track proposal using that preimage hash (check that the preimage match):
Then, I fast-tracked the proposal using the Chopsticks OpenGov tool I presented in ParisDOT - This allows us to emulate the execution of a proposal as is.
As you can see, the proposal executed OK and a Xtokens call was sent to the following address 0x6d6f646c6f6d6e69706f6f6c0000000000000000000000000000000000000000 which is the same as provided in the original post (just decoded). The value sent was 500000 GLMR.
On HydraDX, with Chopsticks, we can see that the transfer arrived to the designated address:
Hi, everyone. I believe for proposals like this one and for future ones, we should initiate a signal vote using snapshot.org before proceeding to Moonbeam OpenGov. Additionally, setting some rules in advance could be beneficial.
Keeping up with these proposals is becoming more challenging, and there might be even more in the future. We acknowledge that the average user may not have the time to thoroughly review every proposal. It’s important to remember that managing assets requires ongoing oversight. Are the Moonbeam team members capable of providing this level of oversight, and if so, could we have their names and roles clarified?
However for me its a “Nay” as not brining tvl or transaction on Moonbeam directly.
hey Lord, I just want to leave some of my thoughts on this:
therefore, Moonbeam’s delegate voting feature is incredibly helpful! users can delegate their tokens to a delegate, who will then ensure a fair vote on each proposal. in addition, the delegate will inform his delegators of the decisions made. I think this is an amazing killer feature that addresses many issues!
After reviewing all of the available information on the proposal, and external sources of information, I would support this if it went to an on-chain vote for the following reasons:
Providing liquidity to an exchange is not an obscure or unheard of request. In this case the tokens are still in control of the treasury.
For Polkadot to thrive, it’s important that the different parachains work together. A thriving Polkadot ecosystem is likely to help all chains (a rising tide lifts all boats).
HydraDX is well known and has a track record for delivering – this isn’t an anon request.
While there is risk of IL, and other possibilities for loss of funds, this should be weighed against the potential gain from the continued success of Omnipool and benefit Moonbeam would receive as part of that success within Omnipool.
Also, this proposal should be weighed against the opportunity cost by the funds not being available to other proposals. It would seem to me that compared to other alternatives, this would be a bit of a diversification play against previous proposals and that is a positive.
The only thing that I think would be beneficial if it were approved, would be a reclamation of the funds over time, and based on performance.
