Terra Classic Community DEX

Very happy to support this. Just what the chain needs. Agreed with some of the above points. But this is a no brainier to pass. I feel this will attract more investors. Great work.

1 Like

Hi @ek826 , Our understanding is that this proposal spawn directly from the community rather than through collaboration with TGF. And I believe I speak for the community - we are thrilled and welcome initiatives such as these.

However, the concepts and risks in this proposal are not easily comprehensible to the average LUNC investor. Hence would TGF be able to conduct a review on behalf of the community and make an independent recommendation, please? It will help most of the voting members.

4 Likes

Thank you @johny for the comprehensive and detailed answer to my questions above. I found it particularly useful to watch your past AMAs and videos.

@Discovery this is a great suggestion and one that the TGF also discussed in our meeting last week. Due to the complexity of this proposal, we sought out reviewers (a total of 5 thus far) 3 of which are completely external to LUNC, and all with DEX experience. While it has been difficult getting any kind of response, we will share any review that comes back before the voting period ends.

12 Likes

But TS is broken. How will this affect your DEX?

Thank you, @ek826 for thinking a step ahead to help the community.

Thanks Ed. This is important. I think majority of the community is not finance savvy hence find it hard to fully understand the proposal.

Overall I personally think itā€™s a well thoughout proposal even tho I donā€™t know whether this is technically safe to add this module to the chain.

Other concerns include:

  1. Doesnā€™t it affect APR of stakers? Seems yes
  2. Does it affect the virginity of the L1 as it may compete with L2 DEXes? I guess so. It could discourage related projects.
  3. The initial grant of 125k USD seems expensive from a man-day effort/cost perspective, not ridiculous tho.
3 Likes

Will this be compatible with the LUNC v2.0.3 L1 coding that TR is working on ?

Voted no on this.

Thereā€™s no reason for the oracle pool to take on this risk when the free market is already solving the liquidity problem.

LPing in most case is EV-, concentrated liquidity or not.

Thereā€™s a lot of risks that needs constant monitoring, for ever. I really donā€™t see the point of the L1 taking this on.

7 Likes

Thanks TCB.

Can I just confirm your intention was no with veto?

1 Like

This proposal must include ustc burns.

Voted NO on this oneā€¦

Ignoring for a moment all the risks inherent to this project (IL, Oracle pool, whale manipulations, hacking, etc.), the main reason Iā€™m against this is because I feel we need to dedicate community funding (limited as it is) to core L1 work. Iā€™d rather throw this money at a handful of contractors who could help Terra Rebels progress through their roadmap, than gamble it all on a ā€œluxury featureā€ like a dex.

Also, Iā€™m not a fan of the way the proposal-writers have advertised and sold their project as a fixed fiat-denominated expenditure of about $125kā€¦ but then despite that said proposal-writer(s) demand to be paid out in LUNC? The problem with this is that LUNC could easily appreciate in value within the next however many months, and the community would end up paying a lot more for this project than the advertised $125,000 itā€™s being billed at. Why not simply budget in fiat (USD, EUR, etc.), and then have payouts in LUNC according to those values at whatever time the milestones are hit? When asked about this directly, the main proposal-writer refused to elaborate. :man_shrugging:

Tying payouts to fiat values would also protect the dev team in case of LUNCā€™s depreciation (since theyā€™d be guaranteed payment, just with more tokens to make up the difference). But pegging payouts to crypto instead of fixed fiat amounts means that both the community and this project are at the mercy of the wider market and its movementsā€¦ not to mention the community would end up grossly overpaying for this project in case LUNC appreciates significantly with time.

So, all in all a NO from me.

Shalom! :pray:

4 Likes

You knows the premise of the dex is because we use a 3rd party dex rn that is making hundreds of thousands of dollars if not millions when actioning swaps. if we have a dex owned by the chain then that money can go back into the ecosystem. Please @johny is ready to give every answer of your concern. Please change your vote. Because at this time we need utility on lunc. Donā€™t discourage people who are trying.

Hi @johny

This is a well thought-out proposal and thank you for the detail presentation. I like the Core idea of treasury management to generate real yeild at the protocol level. My question are

1 is there any requirement at any stage of the project for a multi-sig wallet admin?. Since fund will be deposited in pairs liquidity pools.

2 What is the difference between this strategy of managing concentrated liquidity compared to the old VISOR Finance?

I voted YES to the 1 STEP, 11049 | Community pool spend proposal.
Now can somebody tell me why so many people have voted ā€œNo with vetoā€?
Usually the ā€œNo with vetoā€ is used for the scammer, to let them lose the LUNC.

So why people are against this?

3 Likes

Hi @Thorchain.BULL that was a harsh one :sweat_smile:. I see where you coming from though and youā€™re right we should be careful. The risk of an IL at 100% or 50% etc. is in $ value, not in token.
Basically what Iā€™m trying to say is that in our case, the worst case is to end up with a lot of USTC tokens or a lot of LUNC tokens. Even if theyā€™re worth 0, itā€™s fine, the Oracle already has a position in tokens anyway and weā€™ll still have tokens to distribute. We believe thatā€™s one of the few case where LPing wouldnā€™t actually be EV-

May I kindly request that you move to abstain by the time we provide you with data and if youā€™re not happy with the data you see then switch back to No With Veto ? I mean people are getting excited the prop creates the much need emulation and hopefully the unity we need to move fwd.

Does it seem reasonable ?

Thanks !

2 Likes

You guys want to borrow a sizable portion of the oracle pool & take on risks in a space where 95% of market participants lost historically.

Youā€™re telling me it doesnā€™t matter if an arbitrageur extracts value from the poolā€™s assets because thatā€™s what the yield is paid in?

The arbitrageurs are still taking value away from the pool. If an arbitrageur extracts then itā€™s less tokens to pay yield in to stakers. At the end of the day they denominate their positions in USD.

Weā€™re not even talking about the other risks (smart contracts, trust etc).

Iā€™m going to be really blunt : any validator voting yes for this isnā€™t doing a proper risk assessment. There is no way this is +EV

6 Likes

Iā€™m generally not supportive of this.

  1. there are already 2 dexes on classic, one is 100% open source (astro).
    Iā€™m not sure why you are going through the development cost/risk of building another AMM, especially since you could just clone theirs, and potentially use their battle tested stuff. (and it would give you a much faster lead time)

  2. you could even just build a dApp that uses OSMO, Injective, or Kujiā€™s trading chains to do the work via IBCā€¦ this would be beneficial to everyone, as it would add TVL to existing TVL, which would mean better trades. (astroport is also building something called slAMM which does something similar to this)

  3. using the community funds is a novel idea. Iā€™m not opposed to it, but it does have risks as @Thorchain.BULL mentioned.

  4. how does this effort self-fund? How do we ensure that the dex will be maintained in a years time if it isnā€™t generating $ for you?

I also have little no faith in your timelines 4 man months to write a cosmos module? have you written a AMM before? or a cosmos module? (I mean it usually takes 2-3 months to schedule an auditā€¦ so Iā€™m not sure what you based your estimates on)

it took the astro team at least 6 months, and mars is currently 6 months out, and are just in BETA nowā€¦

I could go on, but you get my pointā€¦ itā€™s a no from me.

6 Likes

And Iā€™ll say to ā€œface the musicā€. This is exactly why I created Governance chaos topic. This case has only just begun to be discussed. It was far to early to put it into vote. How much it has passed? A week? We should first discuss it properly, find out all the pros and cons, and only then decide. For such difficult case scenario Iā€™ll say minimum one month of discussion.

2 Likes

What Iā€™m saying is that if they take something they give something. Either way weā€™re happy to have what theyā€™ll give eg. LUNC or USTC

Thatā€™s the risk youā€™re talking about eg. I have 1000$ I convert to tokens and then one token goes to 0 and then I convert back and I end up with 0$
If I would have kept my tokens instead of LPing I would have lost ā€œonlyā€ 50%.

Now in our case, itā€™s different we already have the tokens, and what matters is to have tokens to distribute as rewards. So IL for us means I start with 1000 LUNC and 10 USTC and I end up with 0 LUNC and 1000 USTC for example.

  1. I still have 1000 USTC to distribute
  2. We currently have 20M$ USTC and if it goes to 0 we lose 20M$ anyway

Also, we donā€™t have to start with a sizable portion of the Oracle Pool we can start with 1M$ (1.5% of the Oracle Pool) for example. Currently SHIB/ETH on Uniswap v3 has 1M$ liquidity and generate 500$ to 2k$ day. If Binance cuts the burn, we could at least work with that to keep covering DEV costs.

I do understand your concern, and again youā€™re right we ought to be careful, all Iā€™m asking is give us few days so we can discuss a bit more before No Vetoing the prop.

2 Likes

The whole point here is to allow the protocol to LP so the protocol can actually earn money and be self sustainable right. Weā€™re reusing the existing AMM hence itā€™s faster.
The timeline does not include auditing.

1 Like