@aeuser999
Following @ek826 comment above, would it be possible to amend the core proposal wording to include each section that is due to be changed with a small description and reference to the agora section discussed? It will help keep the new readers updated as to the latest changes.
i.e.
The section mentioned below, based on the new info provided by @ek826 would look from:
That no validator should achieve more than 25% of the voting power for the first 60 days
,into:
UPDATE: That no validator should achieve more than 20% of the voting power indefinitely unless superseded by a new proposal; as per the below confirmation
OLD: That no validator should achieve more than 25% of the voting power for the first 60 days
(I hope you get the idea. Btw, am not sure if @ek826 did actually agree to the indefinite part that @kl4mb1 mentioned or was lost in translation)
It does not allow me to edit the description since it is in slow mode. However, please know that each comment, at least based upon the merits, in the full discussion chain will be taken into account for the proposal that is submitted.
I hope that helps, and that you have a great day today
“Four out of the six validators confirmed their upgrades to v21. Both v20 and v21 were able to co-exist on the network simultaneously during this upgrade. We then reached the DelegatePowerRevertHeight at block 7684490” (From Section 9 of Emergency Management and Recovery of Luna Classic - ie. whitepaper).
I believe these 3 points are crucial.
While I have looked through the code, I am not a cosmos-module or audit expert.
Going forward we need to use the community fund to get independent audits going for every future code release.
It will help assure people that you’re not putting crap/hacks in there.
Thank you 100% agree.
I can update you with progress on this front.
I have verbally walked through the logic with a ex-TFL developer. He stated that it sounds ok in theory but would need to be tested. We have extensively tested the code on TestNet but we acknowledge that the real world is a different distribution.
Through the above contact, we have been given a direct correspondence to SCV-Security. Still awaiting a response. Using the community fund for security audit is an excellent suggestion. Thank you.
It appears that we will need a little longer than originally expected before submitting the formal proposal, to make sure that a few of the merits in this discussion, and an issue raised, can be adequately addressed before putting in the formal proposal (so the proposal is able to cover each aspect adequately - I would like to make sure everything is in correct order before it is submitted).
But, during this time, the discussion period will continue
I hope that helps out, and that you have a great day today
It has become clear after discussions with the other developers, community members, and validators that an independent audit of our code is necessary. We have inquired for audit quotes from scv-security, oak security, and halborn security. I am looking for others as well. This would be important to demonstrate our code is trustworthy to both validators and central exchanges that will run the v21 code. We are simultaneously building out new functionality on TerraStation and the associated mobile applications to launch in tandem with v21. Other changes to the proposal will be to reduce the maximum voting power down from 25% to 20%, and have this restriction in place until future governance decides otherwise. Due to these requests and changes, we will be amending the proposal into governance with a proposed block height that falls on or around September 12.
Since you guys are our best and only hope, I would like to thank you all for what you are doing. Much appreciated. But September 12 ? of this year ? or the next ?
@Domenico_Pietrovito Well, i think this will work. Because LUNC is just very popular. And we have to move not stay here. I don´t know what TFL´s are doing right now, but i think we will hear from them when the price will rise up. But until the problem is solved it´s will be overvalued coin so be careful.
Main goals 1) code smart contract for reserve assets and vote how reserve scheme will look like 2) use community pool funds for purchase reserve assets or re-enable peg, disable burn mechanism and use this not burned funds to purchase reserve assets (this will be much faster) or re-enable peg at current level and disable temporaly minting ability to USTC until price will reach 1 USD then re-enable peg fully.
