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.
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.
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.
But TS is broken. How will this affect your DEX?
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:
- Doesnāt it affect APR of stakers? Seems yes
- Does it affect the virginity of the L1 as it may compete with L2 DEXes? I guess so. It could discourage related projects.
- The initial grant of 125k USD seems expensive from a man-day effort/cost perspective, not ridiculous tho.
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.
Thanks TCB.
Can I just confirm your intention was no with veto?
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.
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!
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?
Hi @Thorchain.BULL that was a harsh one . 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 !
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
Iām generally not supportive of this.
-
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) -
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)
-
using the community funds is a novel idea. Iām not opposed to it, but it does have risks as @Thorchain.BULL mentioned.
-
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.
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.
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.
- I still have 1000 USTC to distribute
- 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.
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.