Look. Forget giving money to devs, burn tax and all that. Just burn 50% of the total supply and re-peg it then leave the rest to market forces. Someone needs to make a firm decision because all these constant proposals, bickering and infighting isn’t doing #LUNC any good.
That’s exactly what I was thinking we need the tax to burn at least 50 percent and then the rest between community pool and we need to start to refill oracle pool. I would also like to see a liquid staking feature that you could bypass the lockup feature by paying say. 5 percent tax half to be burned other half to fill the oracle pool
Agree with this except for the change of the 50% reminting parameter. The community wants burns and that pushes the price. Just look at the price action since 11111 passed. The dollar value of the LUNC in the community pool will greatly increase if you keep reminting lower - thus changing the parameter to 50% is counter productive. Keep it to 10%
Voted YES!
Hi @ek826 ,
Thank you for the well outlined proposal. I did have a few questions, and concerns, and would request your feedback on them. I did not have time to finish research before responding, since the discussion opened just before Christmas (and my time has been fairly limited) - so please feel free to correct anything I may not have correct in my representation of the technology.
It looks like the majority of the aspects you have proposed are update, dependency upgrade, or security related. There are a few though that appear to deal with changes to the protocol and I would like to ask if you are intending them to be implicit in this proposal, or if there will be separate proposal discussions and proposals for them (although with this proposal providing some of the funding for research required to present to the community):
- Propose governance for no canonical github repo.
- Propose governance for Mev-Tendermint (for PoS the “Maximal Extractable Value”) pluggin for Tendermint/Ignite.
- Links for my own reference (and passing along if helpful to others as well)
- I would have grave concerns if the pluggin(s) selected leave the transactions encrypted on the blockchain itself, rather than just as protection of the mempool from those looking to take advantage of it, or those who would block transactions in consensus. These concerns about encryption on the blockchain for transactions, rather than just the mempool, have to do with how that type of privacy can attract, and hide, criminal behavior that hides real world horrific crimes. I realize not everyone will have the same concerns that I would have if it did leave them encrypted on the blockchain itself in a way that only 2/3’s of the validators could decrypt. It does appear though so far from the pluggins I have investigated that are part of the MEV solution, they focus on the mempool. Please correct me though if that is wrong, I was still in the middle of researching.
Also the following appear they may be changes to the protocol as well:
- Transition to iavl fast node via iavl 0.19.4.
- I was not finished on my research for the immutable AVL+ tree for persistent data, as to whether it was a change to protocol, or just an update to the Golang package?
- Initial concern in link below (without finished research - although this may be the reason for the proposal to 0.19.4):
- I was not finished on my research for the immutable AVL+ tree for persistent data, as to whether it was a change to protocol, or just an update to the Golang package?
- Implement upgrade handlers to utilize software upgrade governance proposals.
- Adjust ante handler to send 50% of “burn tax” to community pool & 50% to treasury burn wallet.
- I was concerned about this one as well, but I saw you answered above that it would be a separate proposal for the 50% ante handler.
I was wondering if you have budgeted for independent security reviews (or to retain a service for the 3 months). Mainly since each of these developers are working together on a team, rather than community contributors, and therefore are not necessarily independent of each other (or if at this time you will use those on this team of developers who have not worked on a particular phase/story or task to review for code and security of those who have)?
I am also concerned with the “community oversight committee”. It would appear that if the role is specifically to provide a few community members to be part of the process regarding oversight of monthly distributions, and the admin to be a liaison to the community, then that would not be as much of a concern in my mind. However, if they are meant to somehow speak on behalf of the community in a way that bypasses governance, or to function as a tribunal, senate, etc. then that would be a concern for me. So part of that is a question seeking further information (if there is any further information or clarification beyond what I gathered and mentioned above), the other part is to share my potential concern.
I have been very concerned that what originally was “we will implement solutions that come from governance” has been turned around to pretty much mean “we will get governance to sign off on our solutions”. The first quoted statement is community driven, and the second is developer driven. While I appreciate that you, personally, have been willing to work across the board with everyone, the way solutions have tended to come forward in the past months have been more developer driven in my mind.
I think it is more than ok for a developer to help the customer (the Terra v1 governance community in this case) explore options to their requirements, to suggest goals for their consideration for a project, phase/story, or task, to help them see what is possible, to help them see where shifting a solution, or a completely different solution, may better meet their goals and the spirit of their requirements. But, it is another thing when the developer leads that process, and the customer feels they have no other option, or not much of one anyways, than to accept the solutions (in an “as good as it gets” moment).
I am concerned with some of the statements of the Notional linked github article, and as I have mentioned, I am not sure the L1 development portion of the TR road map was really community driven (in other words brought to the community for research, agreement of a prototype, in 1 or 2 proposals, and then a final proposal for the actual solution - or at least 1 proposal for all of it earlier on). I will say though that I do think that you, and to some degree others on this proposed team, have sought out community feedback (and for that I am thankful).
Here are a few of the concerning statements with the linked Notional github article:
- “so I propose that the working title for the chain be “dawn”, due to the optimistic nature of that word, and my own personal history with it, eg: GitHub - dawn-network/dawn: global hosting, financial automation, server-less web components. It’s always darkest before the dawn, anyhow… We’re changing our name, because Do’s daughter is named Luna, and we’re respecting his massive initial contributions to the chain.”
- This does not seem too community driven as a statement. Do Kwon himself gave the name to this chain and kept Terra in the name at the creation of v2 (as to the “classic” part, others begged him not to use that name in proposal 1623). In addition, it is the Terra v1 governance community that apparently own the intellectual property to the name Terra, Luna, and UST, as is outlined in the Terra Community Trust, which was retained in the Terra v1 documentation (and does not exist in the Terra v2 documentation).
Probably the most concerning statement I have read is this statement (which should give everyone pause in my estimation):
- “Dawn will be a chain focused on its own sovereignty, a place to run experiments – even dangerous ones.”
I can appreciate however, that Notional has stated “We’ll only make moves that have the consent of the community through governance.” However, I have heard statements like this along the way, and they have not always meant community driven, but developer driven (in the way I mentioned above)(and of course the developer driven analysis was depending on the person and/or the situation at that time). Thankfully it has not always been the case along the way (however, that statement is not meant to dismiss the severity of the situation, which has been months in the making, at least in my mind, or of the statement).
These are my questions and concerns. Thank you too for putting the time, energy (physical, and emotional), work, testing, research, and service in to helping people and this community.
I hope you are doing well today ![]()
Why is this here? Proposal 11111 has just been passed.
Where is the V2.0.3 parity upgrade that @Zaradar spoke about while he was with TR.
Agree and also thanks for all efforts!
#Brasil communities will also support for sure, vote proposal and idea!
We will share it here strongly!
Keep the good work guys, let’s go!
@betosampaiolab
It’s a yes from me. I think ek826 is and has been working to benefit the whole LUNC community.
It seems to me we have a lot of newbies trying undermine the good work done by others, I’m never going to vote for a proposal from some stooge that has just joined and has two minute read time.
Thank you ek826
I’m in favour of the whole thing. Great layout of details.
In terms of money, for top tier devs these are fair prices. You can easily do a search online to see how much developers earn around the world to gauge an idea. So for me the proof will be in the pudding - when great features are added and junior developers start making waves.
Also, what’s the crack with cyber security especially as there have been a lot of attacks on bridges and channels etc.?
50% in community pool ![]()
Iam here, will vote YES
U people r jokers , they dont have the power to burn 50% supply ![]()
Ed and Zaradar are duo who broth TR down !Rebels from Terra rebels !
Question is why ?They could done the same inside of TR group didn’t they ?
Why we lost TR and probably whole work they did had in plan who was brilliant ?
Answer i see in money they found not enough for work inside group.
Now TR is down With lot of scam this duo coming with new proposal asking much more money
via proposal they put to vote !
Vote no with veto do not give anything to this duo or let them change proposal to be payed after delivering job to community !
Thank you for recommending my suggestion.
Even if my proposal is chosen by the Community, the work of the current L1 task force must be preceded to implement it.
The reason for this is that LUNC is currently unable to keep the tax in a different wallet except coin burn.
That’s why as a stopgap they do the incineration and then re-mint for the community pool.
This kind of work causes a lot of misunderstanding for people except programmers. And that misconception often leads to a decline in market confidence and reckless criticism of developers.
Developers also have feelings. Continued exposure to negative public criticism will inevitably reduce their passion and motivation.
So support the plan of a great DEV team. Everything needs priority.
If this work is successfully completed, any proposal will be a little easier to implement, as it will allow direct distribution of the Community’s tax.
Let me know if you’re also looking for a designer / advisor on design (UI / UX). I’ve got 16 years of experience designing web & mobile applications as well as leading and building product design teams from scratch.
Current holder of LUNC and would love to help out if you need it.
If one day you would need a tester, then you can ping me. Im testing backend apps for few years, it could be interesting to test blockchain
I only mean this half jokingly, Id be willing to take part in the oversight. I’ve been steadily involved in various aspects of the community since the capitulation. I have a decent technical understanding and have made my focus helping the community learn.
He didn’t deliver and when asked he got all upset and angry ![]()
Let’s hope he delivers with his L1 task force friends… he has 4
‘s little helpers to help him…
Now he can’t say he’s not getting paid…
![]()
