This is great work
1 Like
How do other coins enforce tax, some have taxes up to 10% on cex
Hi @almutasem_alhaj ,
In a nutshell: This proposal gives governance, which includes validators, a path for distribution of code that has been developed for proposal 3568 (for the 1.2% burn) and for 4095 (re-enable delegation and staking) - both of which passed governance votes. This proposal only deals with the distribution of the code, and the code itself, and a security proposal regarding code for 4095.
If the vote passes, it gives TerraForm Labs (TFL) 10 business days (so does not count weekends) to either come up with their own implementation of 3568 and 4095, or merge, build, and distribute the code proposed in this proposal. If they do not, then the proposal outlines the path to distribution of the proposed code using these instructions.
The code current gives until block height 9346889 for catch-up consensus (where both v0.5.20 and v0.5.21 [the code being voted on with this proposal] can coexist on the same network for validators). The date for this would be approximately September 12. After that date, staking and delegation would be active again, and the underlying code for 3568 (for the 1.2% burn) would be distributed. However, since the code for 3568 relies on keys within a parameter that is stored on the block chain, and a parameter proposal is the means that the system gives to change parameters on the block chain, another proposal (a parameter proposal) will need to happen to move the percentage from 0% (the current value of that parameter) to 1.2%. There are a few caveats in section 10.1 of āEmergency Management and Recovery of Luna Classicā to consider however re: the parameter proposal.
At blockheight 10225289, which is approximately November 12, new validators would be allowed to join the active validator set.
It is important to note that the approximate dates of September 12 (for staking and delegation) and November 12 (for new validators) are subject to change (as the proposal mentions).
The proposal itself gives a template to use for future update and upgrade changes to protocol and code based upon the protocol. This gives the Terra v1 governance community (which includes validators) the ability to establish the code is well tested and reviewed and gives a path for distribution.
This is important since as I have mentioned in a different setting a trusted source for code has governance as well as security and project management considerations:
At least for myself personally: for governance chains, code distribution is a decision, and decisions are made by governance. That governance includes validators (and right now, it probably mostly consists of validators, and those who had staked before). For chains that are not governance, the miners/validators own the network aspect, and they would make network decisions. The one situation that I can see for this chain that would allow for a validator alliance is where the chain is hard forked (which by the way, with this particular chain it sees hard forks as a threat and makes efforts to mitigate it appropriately), at that point there are now two chains with governance claims - at that point a validator alliance would be necessary to align with which governance side of the chain they will follow.
- āSince the Tendermint is designed to never fork at allā [hard fork]:
- Alliance agreements (recognizing that Terra v1 has its own additional governance aspects layered on in its documentation):
- A few other sources without overloading:
On the security side (again as a personal professional opinion): from my time in various aspects of IT, code distribution has security as well as project management aspects. For a large proof of work blockchain and network (such as Bitcoin, or currently Ethereum), where miners/validators are indefinite in number it can withstand malicious code (whether intentional or unintentional). This chain though has a small number of active validators, where it is more crucial (especially where it deals with peoples money) to have good testing, security, and review standards in place. This proposal would be voting on the distribution path for this particular code, the code itself, and an additional preventative security aspect (extending what was approved in 4095). I also have other concerns, but this proposal attempts to remain neutral for all parties, and at least provides a template for code distribution in case TFL does not consider community contributions as they have in the past, and includes governance (and therefore validators) in the process.
As the Cosmos documentation states (the Terra v1 ecosystem is built on top of Cosmos and Tendermint):
āā¦the protocol and software must also be obtained from a trusted sourceā
I hope that helps out a little bit, and that you have a great day today 
2 Likes
Link To Formal Proposal Text
To Vote:
-
Click here to vote on proposal 4159 - Distribution of code for 3568 (for the 1.2% burn) and 4095 (re-enable delegation and staking)
- To change TerraStation to Classic, see these instructions
Note: In looking back in TFLās repository for Terra Station we found that they made changes to the wallet without proposals. However, any changes that block or alter any aspect of governance should be made only with proposals (since documentation specifically states that TerraStation is how governance is to stake, to propose governance, and to vote). You can compare this with Terra v1 governance votes that have been passed
For this reason, any non-governance access changes, as mentioned above, regarding new functionality on TerraStation and the associated mobile applications to launch in tandem with v21 would be implicit with this proposal.
Note - Testing: Initial internal testing has passed for changes made to code re: āno validator should achieve more than 20% of the voting power for an indefinite period until community governance decides otherwiseā
Also too, just to clarify that the dates are approximate, and can be accelerated or extended based on circumstances (but they are the dates listed in the current code comments as approximate dates).
1 Like
Some people are saying we need %66 and why need that ? Now if %58. it wont pass ?
@Bond_Man Well this question needs more details, but it will clearly pass if voting is now over. For pass there must be 50 % votes for yes. But i think you mean we need 2/3 (66,666ā¦%) of validators power? I am right? If system works like we need 2/3 validators to make change it will pass in current situation and if system works like we need 66,6666ā¦% of voting power of validators to make change it will pass too because validators that abstained in voting are not for yes or no they just want to see if it passes or not so if it pass they will make change with others that voted for yes. Hope itĀ“s clear 
1 Like
Hi @Bond_Man ,
As @tolben pointed out, there are two things at play here: the Terra v1 governance proposal vote, and the realities of the blockchain consensus model (if some validators do not follow the proposal vote - intentionally or unintentionally).
First, there should not be a problem for distribution if this proposal passes. This proposal allows governance, including validators, the ability to vote on the path for code distribution for proposals 3568 and 4095 (both of which have already passed governance votes prior). Terra v1 governance, including validators, are able to express their honest will and what they believe is the best for the Terra v1 community, the network, and for validators their delegators during the vote, but then abide by the Terra v1 governance community proposal final decision once voting is closed. As long as the vote meets quorum (40% of all staked LUNA v1 votes), the Yes votes are greater than the sum of (No + No With Veto), and No With Veto does not go over 33.4%, then a proposal will pass (source). It is important to note that a person or validator can change their vote during open voting for a proposal.
Second, is the reality that Terra is designed on top of Tendermint and Cosmos. In order for this type of proof of stake blockchain to reach consensus, it needs more than 66% of staking power to agree to blockchain blocks being voted upon. There is a situation where if the network has a conflict, where more than 33% of the validators agree, but there is less than 66% agreement by staking power of all active validators, this can present an issue. There are mitigation efforts that help to overcome these issues, to uphold a governance proposal path of distribution, but of course the easiest is that validators follow the path this proposal outlines if this proposal should succeed.
I hope that helps out a little bit, and that you have an awesome day
3 Likes
Thanks for clear answer friend. I saw at some discord group they are discussing same topic. Like i saw there if we can get %66 paramchain code will implement directly as like that .but let me read also @aeuser999 answer.s
2 Likes
Thank you very much for response
1 Like
@Bond_Man I would like to be clear more then before. At this current situation we have 142 mil of 207 mil that we need for apply change. But let me note this informations.
Since the code is so similar and changes are applied after block height codes are able to coexist at same time until blockheight is reached. That means there is plenty of time to contact and warn unattracted validators in vote to upgrade code.
But since we already know big validators usually wait until last minute to make sure others validators just dont vote like them we can probably count them. I ment before in my comment before. I am pretty sure itĀ“s not a problem. But it is true what you heart.
2 Likes
What is the problem to implement new code after voting? First it was until August 12, then until September 12, now until November 12. Why pull the cat by the balls? )
4 Likes
Hi @Alexandr_Romanov ,
Historical Information:
The approximate dates are based off of aspects mentioned in proposal 4095 discussion, mainly that:
- Re-enable Staking/Delegations on Terra Classic exclusively to the current active validator set for a period of 60 days. The ability to create new validators will remain disabled until block height #8905758 (approximately, 22nd August, 2022)
- New validators can be created only after block height #8905758 (approximately, 22nd August, 2022)
Proposal 4095 specifically mentioned in its discussion that:
āThese have been peer-reviewed by Cosmos SDK contributors. Should the proposal go through, the PR will be merged to the Terra money repo.ā
But, TerraForm Labs did not merge the pull requests into the terra-money project for the Terra version of cosmos-sdk.
Discussion Information For This Proposal:
This proposal discussion (for proposal 4159) specifically stated as part of the discussion for distribution, for the code itself, and for an added preventative security measure extending what was proposed in 4095:
If this proposal should pass, @ek826 mentioned that the block height for the activation of 3568 and 4095 is 8,890,141, approximately August 12, 2022. This blockheight is subject to change if required by validator adoption or independent review.
The activation being referred to as seen in the code itself is for the DelegatePowerRevertHeight constant (dealing with node consensus catch-up), and the constant TaxPowerUpgradeHeight. The comments in the code for DelegatePowerRevertHeight specifically state:
āThis is approximate and will be adjusted if neededā
The code also used the timeline from 4095 for the constant StakingPowerRevertHeight (re-enables the creation of validators), which would be approximately 60 days beyond.
Formal Proposal Information:
As @ek826 mentioned in his comment on 7/25, which was prior to the formal proposal being submitted:
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.
The formal proposal 4159, the proposal associated with this discussion thread, specifically states (formatted version of the proposal text):
Minus any minor adjustments to blockheight to meet agreements stated in proposal 4095, or any minor adjustments required for due diligence review, rework, or testing on the part of an independent reviewer
The proposal itself gives the flexibility with regards to approximate timelines, and the approximate timelines stated in this comment above are consistent with what was proposed in the discussion, and in the formal proposal. The caveats listed there about approximate timelines being accelerated or extended would also be in line with this formal proposal.
It is important to realize that the proposed dates are meant to facilitate security, trust, any potential minor rework required around reviews, and further testing that may be required, and an update path that takes into account any and all technical realities for all parties involved to help facilitate a smooth update. The approximate nature of the dates has been stated openly from the beginning of the proposal discussion (and in the formal proposal itself) - as well as the caveat that the timeline could be accelerated or extended as required.
I hope that helps out, and that you have a great day today
9 Likes
Since it is highly unlikely TFL will respond let alone implement any of this. Do we have the resources to get the code validated and implimented?
Link To Formal Proposal Text
To Vote:
-
Click here to vote on proposal 4159 - Distribution of code for 3568 (for the 1.2% burn) and 4095 (re-enable delegation and staking)
- To change TerraStation to Classic, see these instructions
Note: In looking back in TFLās repository for Terra Station we found that they made changes to the wallet without proposals. However, any changes that block or alter any aspect of governance should be made only with proposals (since documentation specifically states that TerraStation is how governance is to stake, to propose governance, and to vote). You can compare this with Terra v1 governance votes that have been passed
For this reason, any non-governance access changes, as mentioned above, regarding new functionality on TerraStation and the associated mobile applications to launch in tandem with v21 would be implicit with this proposal.
Note - Testing: Initial internal testing has passed for changes made to code re: āno validator should achieve more than 20% of the voting power for an indefinite period until community governance decides otherwiseā
1 Like
I figured what the heck and voted for. Proposal contains multiple moves forward as I see, even if I disagree with some of the numbers (tax % among others). The figures can be adjusted in future proposals, I find getting the methods and framework up and running and the blockchain open to delegation huge necessary things, which will allow for further tweaking and more community input/participation.
1 Like
Hi @David_Wedlock ,
It would be the easiest if TerraForm Labs (TFL) would merge, build, and distribute (or distribute their own implementation). However, if this proposal (proposal 4159) should pass, and TFL does not either come up with their own implementation, or merge, build, and distribute the code associated with proposal 4159, then after 10 business days, validators can use the instructions associated with this proposal to update (starting Aug 17th 12am UTC time zone):
The instructions also have a link to support information, and I do believe that @ek826 plans to proactively communicate with validators. However, if a validator should have any issues with updating, and they are not able to gain the help they need through the instructions, then they can direct message either @ek826 or myself @aeuser999 in this system, and one of us will direct them the appropriate support they need.
To direct message in this system, click the profile circle in the upper right corner of browser window > click the mail icon > click the down arrow at bottom of list > click new message .
There is a window of time that both v0.5.21 and v0.5.20 can both exist on the network, essentially creating an update window of time.
I hope you have a wonderful day today
3 Likes
Hi thanks i agree it would be great if TFL just helped but Iām not going to hold my breath. Has the code been audited yet or does that still need to happen?
Happy to see some positive steps forward being taken.
1 Like
Thank you Terra Rebels
Hi @David_Wedlock ,
In regard to a security audit on the code, @ek826 may be able to answer that better (or give further information). I do know that one firm he has reached out to has declined to do the audit.
I hope that helps a little bit.
I hope you have a great day