#6 Removal of the Master and Child pool concept from cSwap (Discussion)

Hello everyone,

cSwap DEX has been launched on the Mainnet, and we have been improving and iterating with user inputs and taking feedback wherever necessary.

We have implemented a unique liquidity mining mechanism that involves a Master pool and a Child pool. While we believe that this mechanism has the potential to be effective, we have received feedback from most of our users that it is difficult to understand and maybe deterring them from providing liquidity.

We are looking for ideas on how to simplify the mechanism and make it more user-friendly. Also would request the community to suggest alternative liquidity mining mechanisms to replace the existing mechanism.

Hi,

The concept of master pool is not bad. An idea that can help users understand better is the following. Suppose a user provides liquidity in the CMDX / ATOM pool, then he gets a “boost power” which he can use on other child pools. Let’s say the boost power acts as a reward multiplier (*1.1 or 1.2 over an equivalent amount to the liquidity provided). It allows users to better understand the mechanism (because he must do an action to use his boost power). What do you think about it (I don’t know if it’s easy to implement as a mechanism).

1 Like

The idea is interesting, I would concentrate now on teaching people how it works. Maybe some marketing

Eliminating this mechanism will weaken cmdx even more by making it less fluid. People will choose pools without cmdx

Maybe it would be more easy to turn the concept upside down? Such that when a user decides to take part in a specific child LP, automatically a position is taken on the master pool if the user wants to do that?
And that can then be done by simply selected a tickbox or something, after which the rest is done automatically?

And the potential APR is also shown realtime, such that the user can check if she/he wants to take the risk?

I agree with everything others have said thus far. The mechanism itself has merit and this is a UX problem.

My experience and $0.02:

It took me a few to grok the reward semantics and you absolutely have to leave the dApp and read the docs to get there. Those could also use some love. Bonding / unbonding semantics weren’t explained. If I have $100 in child pool A and $100 in child pool B, does the master pool need $100 or $200 to achieve maximal returns? I know the answer is $200, but I read the docs in their entirety and still had questions, at which point I ended up in discord. I still don’t know if there are entry / exit fees, or how swap fees are paid out.

Once I understood, I needed a spreadsheet to know the real, aggregate APR as I experimented with different allocations. I imagine I’ll use that spreadsheet pretty regularly moving forward to rebalance, but truly optimal UX probably shouldn’t require doing this.

Once I’d made decisions, it was then cumbersome to swap to the exact amounts needed to attain equilibrium. I wasn’t able to trade for WMATIC. The other pairs had a lot of slippage and I quickly gave up on getting to exact equilibrium. Osmosis-style single-asset autoswaps would have made this so much easier.

My first epoch came and went and with no new CMDX in my wallet, I realized I’d missed something. I don’t think the minimum 24-hour bonding period was mentioned anywhere outside of discord IIRC. Then came the immediate realization that I can’t immediately compound the rewards back into the pools to receive the subsequent epoch’s rewards (IIUC depositing/farming immediately upon receipt is no different than doing so 23h59m later, and neither will result in increased rewards until the next epoch, ~48h later). Could we enable auto-compounding on-chain to maximize returns and minimize manual operations for users? Out of scope in this thread, I know, but I imagine TVL and more generally engagement is lost there.

IMHO, ideal UX…

  • probably doesn’t involve leaving the dApp at all
  • prominently displays the user’s current, calculated aggregate APR
  • allows users to automate the repetitive tasks (rebalancing, compounding, single-asset swaps to enter a pool, etc.)
  • is probably close to what @Leonoors_Cryptoman suggested, though I’d add…
    • create/update percentage-based allocation to child pools + master pool in one place via one transaction
    • show users what the resulting aggregate APR will be as they experiment with different portfolio strategies
    • optionally enable autocompounding
    • streamline rebalancing back to optimality both manually and automatically
3 Likes

@black.lodge Thank you for sharing your feedback and experiences with our dApp. We appreciate your insights and suggestions on how to improve the user experience. We understand that there are challenges with understanding the reward semantics and that the documentation could use some improvements. We will also look into how we can auto-compound the rewards.
We take your feedback seriously and will work on incorporating your suggestions.

1 Like

I think the childpool/masterpool concept was a good idea, but obviously im biased bc of the syndicate conflict of interest. The solidly model has been proven to work aka Ve(3,3) and can build upon the flywheel for the comdex ecosystem. My suggestion is to find a happy medium with the Velocking mechanism to trap liquidity with incentives and cliff off the emissions to incentivize votes. Also contracts for these must be immutable for it to work and can help Syndicate draw incentives from other Amms to direct them to cSwap. Im also open to discuss other ideas, but that mechanism iterated correctly has trapped stick liquidity, and will get very interesting with launch of cAsset.

Another possible idea is to intergrate a mechanism such as frax finance has with their deep mote, i’m not the biggest fan of every platform having their own token but if cSwap were to have a mechanism similar to VeCrv or Solidly we can coordinate and build off it properly. Bribes would also be easier to flow through to users directly syndicate can directly facilitate that.

1 Like

I also think that there needs to be a mechanism to trap liquidity through incentives without haltering token price