Proposal: enable Stake 2.0

[lxcmyf]

Simple Summary

In order to improve the utilization of network resources and enhance the stability of the TRON network staking system, it is recommended to open the new staking model: Stack 2.0. For more information about the Stake 2.0 mechanism, please refer to TIP-467.

Motivation

Under the current stake mechanism, stake and delegate operations are bound together, and staking and resource management are very complicated. If you want to change the resource delegating recipient, you must unstake first, then make another staking and specify a new recipient. In addition, the unstake operation must wait for 3 days after staking, which means that the obtained resources cannot be delegated to others within 3 days. If the user has already voted before unstaking, the unstake operation will also cause the vote to be automatically canceled.

Therefore, we need to use a new stake mechanism to solve these problems, separate low-frequency stake operations from high-frequency resource delegate operations, and re-delegate resources without unstaking assets, reducing the complexity of staking and resource management. At the same time, the TVM virtual machine supports all instructions related to Stake 2.0, bringing richer application scenarios to the TRON smart contract ecosystem.

Specification

Propose to modify the No.59 and No.70 TRON Network Parameters so that open Stake 2.0,

• ALLOW_TVM_VOTE(No.59) = 1 Set the No. 59 network parameter to 1, and enable the virtual machine contract voting function. Since TVM supports voting by precompiled contract and instruction in Stake 2.0, this parameter needs to set to 1, making Stake 2.0 fully functional.

• UNFREEZE_DELAY_DAYS(No.70) = 14 If this parameter is larger than 0, it means Stake 2.0 is opened. This parameter indicates the length of the waiting period that unstaked TRX could be withdrawn after unstaking. In this case, the community decide to set it to 14, which means the waiting period is 14 days in Stake 2.0.

How to initiate the voting request

Implement Stake 2.0:

• createProposal 59 1 70 14

  Timeline

  The estimated timeline,

• Creation time of the voting request: 4th April 2023
• The effective time of voting request: 7th April 2023

Analysis

Here is the TRX staking rate on TRON,

From the above figure, we can see that the overall staking rate of the network is about 48%. In the future, based on Stake 2.0, more application layer protocols like TRC-484 can be implemented, bringing more application scenarios to the TRON smart contract ecosystem. Furthermore, it promotes the improvement of the network staking rate.

Compatibility

After Stake 2.0 is opened, staking can only be done through Stake2.0 API. The resources already staked and obtained under Stake 1.0 and the votes on the chain are still valid and will not change, and the assets can be redeemed using the unstake method of Stake 1.0. After the proposal takes effect, the Stake 1.0 staking API will return the error message "freeze v2 is open, old freeze is closed".

[Moneyversac]

You know 95% of the tron community is against this and yet you guys just force it. We know you don't care about the tron Community but at least for your own good give a clear deadline for the last few remaining devs on tron so they can update their contracts and projects accordingly before this goes live.

[ustx]

From a dev and user point of view, it's not possible to enable the new stake mechanism, the infrastructure is not ready. It's been on Nile only for 3 days, Tronscan implementation is not ready. This is a major change to the network resource management, I sincerely hope enough testnet time is given before going live on mainnet.

[Dendorion]

Give it atleast a reasonable amount of time to test stake 2.0 . Like USTX commented it is not ready developers should also be granted sufficient time to test the changes and implement them into their own systems . This is a big change into the network which should be thoroughly tested before deployment into mainnet so no need to rush it . Users are still trying to adjust towards the insane increased on chain fees with the last few proposals . Rushing this will only result in pushing more users and projects away.

[JamesEisenberg]

I completely agree with what has been said here before.

This is a major change that affects a large number of existing projects and smart contracts, Most of the community members are against the change, Relevant tests infrastructures are not yet ready, for example, Tronscan does not display the relevant information and the various wallets including Tronlink are not adapted to work with Stake 2.0 Documentation of the expected changes is poor and there are a lot of things that are not clear, such as the matter of granting multisig permissions and more... I ask you not to rush this major change, to give the developers and the owners of the various projects and smart contract in the community time to adapt and to give enough time to test things in a fully functional test environment.

[SRTron442]

your

A handful always complain to obstruct greater good. Dev activity record high level. Improvise your skill set. Tron upgrade can't be slown.

[shitmypants92]

Fk it. Launch Stake 2.0 and see how it works out. If we always wait until everyone is ready we will never move foward.

[Moneyversac]

Fk it. Launch Stake 2.0 and see how it works out. If we always wait until everyone is ready we will never move foward.

If they at least would give a deadline that would certainly help the devs to adapt. Otherwise I see chaos coming.

[shitmypants92]

The tron ​​blockchain is being developed by the tron ​​team at their own pace and with their own ideas for improvement. The community has always played a subordinate role in its history in case you didnt notice after almost 6 years.

So far this rarely resulted in chaos but rather turned tron into one of the most robust and trustworthy blockchains you could use right now.

We do not know what TRONs goal is currently, so we should not interfere in their actions too much. Maybe stake 2.0 is is urgently needed. Maybe they just want to steal away the energy market from us. Who tf knows.

[SRTron442]

Enough time has been given to test stake 2.0 Are you a developer or a blabbermouth? You came to github to waste time where folks working 20/24 a day. You ask for grants & taken it from the Foundation & now for vested interests you shamelessly malign tron. What chaos explain DicSuc?

[Moneyversac]

Enough time has been given to test stake 2.0 Are you a developer or a blabbermouth? You came to github to waste time where folks working 20/24 a day. You ask for grants & taken it from the Foundation & now for vested interests you shamelessly malign tron. What chaos explain DicSuc?

It's a fact that the Nile testnet went live around the 14th of February and the compiler didn't work until about the 17th or 18th of february. Not sure 48h is enough time for devs to get their stuff up to date and test it. When implementing big changes to a system it always needs a deadline so people know what they can expect. If they forget to change their stuff it's on them afterwards of course but sitting in the dark just makes people nervous and causes riots for nothing. This can be avoided by clear communication. For example: "nile update is live, please test and update accordingly, changes will be implementred by first of march" You won't be able to satisfy everyone but at least you give a clear statement and people are able to work towards it.

[lxcmyf]

#467 comment-1361611356, comment-1355605023 The relevant functions of Stake 2.0 are expected to be officially launched in the middle and late March. The nile test network has been released. TronScan have also completed the adaptation to Stake 2.0. The relevant sdk of TronWeb has also been developed. The compiler has now worked normally. Welcome to test the relevant functions on the nile test network.

[Jamestepfoward]

I have tested the V2 API on nile by wallet-cli, it works well, and it is pretty easy, try it and come back to leave a comment, unfounded discussion is meaningless. Now I believe this proposal is with no harm.

And just one suggestion @lxcmyf , I am not sure how to query some status of V2, such as the expire time of unfreezing transactions. I did not find it in the TIP, hope that you can add explanation or document for it.

[Moneyversac]

The relevant functions of Stake 2.0 are expected to be officially launched in the middle and late March. The nile test network has been released. TronScan have also completed the adaptation to Stake 2.0. The relevant sdk of TronWeb has also been developed. The compiler has now worked normally. Welcome to test the relevant functions on the nile test network.

Thank you for that Information. It's highly appreciated.

[lxcmyf]

I have tested the V2 API on nile by wallet-cli, it works well, and it is pretty easy, try it and come back to leave a comment, unfounded discussion is meaningless. Now I believe this proposal is with no harm.

And just one suggestion @lxcmyf , I am not sure how to query some status of V2, such as the expire time of unfreezing transactions. I did not find it in the TIP, hope that you can add explanation or document for it.

Ok, the document will be updated later. Thank you for your use and attention.

[ustx]

The relevant functions of Stake 2.0 are expected to be officially launched in the middle and late March. The nile test network has been released. TronScan have also completed the adaptation to Stake 2.0. The relevant sdk of TronWeb has also been developed. The compiler has now worked normally. Welcome to test the relevant functions on the nile test network.

Thanks for the info. I'd like to notify a bug on Tronscan implementation, that is not showing the resources delegate to others or by others.

[lxcmyf]

@ustx Can you provide the address of your wallet? So that I can repeat this problem on the test network. I want to confirm whether it is an information display error or other problems.

[JamesEisenberg]

I've made several USDT transfers on the Nile test network, but no matter what I do the energy level does not decreases. I was trying to test a situation where I undelegate an energy resource when some of it's energy is in use (recovery) - but I'm not able to test it because the energy does not seem to decrease.

Bandwidth is OK, the issue is only related for energy.

Maybe the problem is on Tronscan display ...

[Murphytron]

I've made several USDT transfers on the Nile test network, but no matter what I do the energy level does not decreases. I was trying to test a situation where I undelegate an energy resource when some of it's energy is in use (recovery) - but I'm not able to test it because the energy does not seem to decrease.

Bandwidth is OK, the issue is only related for energy.

Maybe the problem is on Tronscan display ...

Hi, as we discussed in TG group, this is due to the TRC 20 token contract set the consume energy ratio to 0, and it has enough energy balance for transactions, which means the energy of transaction is all payed by the contract owner's address, and the energy in your address would not be consumed. I think by transferring a TRC 20 token that consumes caller's energy, the features can be tested normally on tronscan.

[bractbright]

If I initiated two unstaking transactions, can I query the two records? Another problem, TRX in unstaking does not display on tronscan, looks like my funds are missing. It is recommended to add a field to display the unsaking, for example,

TRX Staked /Unstaking/ Balance： 2,090 TRX /3,000 TRX / 10,000 TRX

[Jamestepfoward]

If I initiated two unstaking transactions, can I query the two records?

Yes, the ongoing unstaking transactions can be queried by wallet/getaccount, and the list of unfrozenV2 shows the records. I can show you an example here:

"unfrozenV2": [ { "type": "ENERGY", "unfreeze_amount": 1000000, "unfreeze_expire_time": 1678355292000 }, { "unfreeze_amount": 99000000, "unfreeze_expire_time": 1678355310000 } ],

[joker-gdb]

If I initiated two unstaking transactions, can I query the two records? Another problem, TRX in unstaking does not display on tronscan, looks like my funds are missing. It is recommended to add a field to display the unsaking, for example,

TRX Staked /Unstaking/ Balance： 2,090 TRX /3,000 TRX / 10,000 TRX

If you login to tronscan, in the personal account page->Resource->Stake 2.0->My stake, you can see the ongoing unstaking TRX, but it's a bit hidden, will be more friendly if displayed on the main public account page.

[bractbright]

If I initiated two unstaking transactions, can I query the two records?

Yes, the ongoing unstaking transactions can be queried by wallet/getaccount, and the list of unfrozenV2 shows the records. I can show you an example here:

"unfrozenV2": [ { "type": "ENERGY", "unfreeze_amount": 1000000, "unfreeze_expire_time": 1678355292000 }, { "unfreeze_amount": 99000000, "unfreeze_expire_time": 1678355310000 } ],

Thanks, very useful! The unfreeze_expire_time seems to be determined by unstaking lock time, I saw it was N, what will the number be? the Nile is 3 days, will the main-net also be 3 days?

[Jamestepfoward]

If I initiated two unstaking transactions, can I query the two records?

Yes, the ongoing unstaking transactions can be queried by wallet/getaccount, and the list of unfrozenV2 shows the records. I can show you an example here: "unfrozenV2": [ { "type": "ENERGY", "unfreeze_amount": 1000000, "unfreeze_expire_time": 1678355292000 }, { "unfreeze_amount": 99000000, "unfreeze_expire_time": 1678355310000 } ],

Thanks, very useful! The unfreeze_expire_time seems to be determined by unstaking lock time, I saw it was N, what will the number be? the Nile is 3 days, will the main-net also be 3 days?

I have no idea what value it will be on the mainnet. I have learned the Ethereum will allow unstaking after Shanghai upgrade, and they have introduced Churn Limit Quotient to restrict amount of unstaking ETH, the reason they do it is to prevent large amount of ETH unstaked in short time to destroy the security of Ethereum, and also to prevent slashing attacks from happening. So regarding this, I guess the parameter N on TRON will be set much longer. I suggest someone could give detailed comparison and analysis about unstaking mechanism between different blockchains, so that the value of N could be determined accordingly.

[lxcmyf]

I have investigated the unstaking delay days of some public chains. Here are some cases:

Cosmos	PolkaDot	BSC	Solana
21 day	28 day	7 day	10 day

Among them, Solana's unstaking delay days is not constant and need to be calculated according to the actual situation.

[ustx]

I have no idea what value it will be on the mainnet. I have learned the Ethereum will allow unstaking after Shanghai upgrade, and they have introduced Churn Limit Quotient to restrict amount of unstaking ETH, the reason they do it is to prevent large amount of ETH unstaked in short time to destroy the security of Ethereum, and also to prevent slashing attacks from happening. So regarding this, I guess the parameter N on TRON will be set much longer. I suggest someone could give detailed comparison and analysis about unstaking mechanism between different blockchains, so that the value of N could be determined accordingly.

I don't think we need a large "N" parameter to safeguard the network. Currently N is equal to 3 days, but practically is equal to zero, since after the 3 days have passed the user can unstake without any delay. So in the event of a high volatility event, right now a huge amount of TRX could be unstaked instantaneously. This situation has never put Tron at risk so far, so I would advise the decision makers to avoid pushing the N value above the current value of 3 days.

[lxcmyf]

I have no idea what value it will be on the mainnet. I have learned the Ethereum will allow unstaking after Shanghai upgrade, and they have introduced Churn Limit Quotient to restrict amount of unstaking ETH, the reason they do it is to prevent large amount of ETH unstaked in short time to destroy the security of Ethereum, and also to prevent slashing attacks from happening. So regarding this, I guess the parameter N on TRON will be set much longer. I suggest someone could give detailed comparison and analysis about unstaking mechanism between different blockchains, so that the value of N could be determined accordingly.

I don't think we need a large "N" parameter to safeguard the network. Currently N is equal to 3 days, but practically is equal to zero, since after the 3 days have passed the user can unstake without any delay. So in the event of a high volatility event, right now a huge amount of TRX could be unstaked instantaneously. This situation has never put Tron at risk so far, so I would advise the decision makers to avoid pushing the N value above the current value of 3 days.

Well, we need to draw different opinions for setting this parameter at this stage. As I have shown in the above survey, I believe that this parameter will become more meaningful after integrating the opinions of all people and the questions they put forward.

[Jamestepfoward]

First I would thank you @lxcmyf for posting the comparison, and we can see most of other chains have much longer lock-up time. Then I want to add some words to my opinion that making the N longer is not only kind of security concern, but also from beneficial consideration. Because by staking TRX, the circulation supply of total TRX will decrease, meaning that there will be less TRX for trading. And it will have positive influence on the price of TRX. And even I think tron should give extra reward to users who stake TRX exceed specific time period. As users on other chains can get on well with so long lock-up time, I think it is not difficult for tron users to feel comfortable with a longer time of unstaking regarding to the steady TRX price.

[LauraYH]

The longer the unstaking lock-up period, the greater the effect on the price stability of coins, and coin holders will benefit from it.

[ExOCeo]

After the 3-day lock period, an unstaking instruction has to be initiated to practically get the trons back. For those who do not script unstaking right after the lock period automatically, there is usually a delay in action, which makes the mechanism a dualistic system. But to prevent extreme market, even with a second action 'withdraw', 3 for 'N' is too risky to apply, 5 to 9 days would be good enough.

[lxcmyf]

After the 3-day lock period, an unstaking instruction has to be initiated to practically get the trons back. For those who do not script unstaking right after the lock period automatically, there is usually a delay in action, which makes the mechanism a dualistic system. But to prevent extreme market, even with a second action 'withdraw', 3 for 'N' is too risky to apply, 5 to 9 days would be good enough.

I guess you are talking about the mechanism of Stake 1.0, but we are now discussing the relevant parameters of Stake 2.0. The lock-up time mechanism for Stake 1.0 and Stake 2.0 is different: Unstaking of Stake 1.0 can only be done three days later after staking, unstaking in Stake 2.0 can be done anytime after staking, only there will be a delay of N days before the unstaking TRX can be withdrawn.

#467 comment-1356246774 In Stake 1.0, if you stake TRX and delegate the resources to other addresses, unstaking cannot specify an amount, you can only specify the resource type and the recipient address, then unstake all correlated TRX. This is optimized in Stake 2.0, you can specify the type of resource and the amount to unstake.

In Stake 1.0, once you make an unstaking, all the votes you have made would be revoked, and you have to make the votes again with the TRON Power left in your account to avoid the loss of voting reward. This is also optimized in Stake 2.0, partial unstaking would not revoke all votes, it releases the spare voting rights first, and if the spare voting rights are insufficient, then it would revoke a certain amount of votes as needed.

In Stake 1.0, to cancel a certain type of resource delegating for a certain address, you can only cancel all of them at once, and you cannot cancel by specifying an amount. This is also optimized in Stake 2.0, we can only cancel part of it as needed, which improves the flexibility of resource management.

[blockpulsedev]

@lxcmyf can you please details the energy recovery model ?

For example, account A has 100M energy.

At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M.

At what time A will recover the full 100M energy ? At T+36hours ?

[lxcmyf]

@lxcmyf can you please details the energy recovery model ?

For example, account A has 100M energy.

At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M.

At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

[blockpulsedev]

@lxcmyf can you please details the energy recovery model ? For example, account A has 100M energy. At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M. At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

Thanks. Meaning the protocol keep a history of all the energy consume time less than 24 hours and calculate an average recovery amount ?

Does it also apply to delegated energy, when undelegated, what will be the reference energy consume time used for recovery calculation ?

[lxcmyf]

@lxcmyf can you please details the energy recovery model ? For example, account A has 100M energy. At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M. At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

Thanks. Meaning the protocol keep a history of all the energy consume time less than 24 hours and calculate an average recovery amount ?

Does it also apply to delegated energy, when undelegated, what will be the reference energy consume time used for recovery calculation ?

Yes, it also applies to resource delegating: Assume that at time T, A delegated 100 energy to B, and B used all of it. At time T+12, A undelegated 100 energy to B, and A had used 50 energy at that time. Then, for A, the final recovery time is T + 12 + (50 12 + 50 24) / (50 + 50) = T + 12 + 18 = T + 30

[Moneyversac]

@lxcmyf can you please details the energy recovery model ? For example, account A has 100M energy. At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M. At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

Thanks. Meaning the protocol keep a history of all the energy consume time less than 24 hours and calculate an average recovery amount ? Does it also apply to delegated energy, when undelegated, what will be the reference energy consume time used for recovery calculation ?

Yes, it also applies to resource delegating: Assume that at time T, A delegated 100 energy to B, and B used all of it. At time T+12, A undelegated 100 energy to B, and B had used 50 energy at that time. Then, for A, the final recovery time is T + 12 + (50 12 + 50 24) / (50 + 50) = T + 12 + 18 = T + 30

Thanks for all the replies you have given so far, it's highly appreciated.

After the 3-day lock period, an unstaking instruction has to be initiated to practically get the trons back. For those who do not script unstaking right after the lock period automatically, there is usually a delay in action, which makes the mechanism a dualistic system. But to prevent extreme market, even with a second action 'withdraw', 3 for 'N' is too risky to apply, 5 to 9 days would be good enough.

I guess you are talking about the mechanism of Stake 1.0, but we are now discussing the relevant parameters of Stake 2.0. The lock-up time mechanism for Stake 1.0 and Stake 2.0 is different: Unstaking of Stake 1.0 can only be done three days later after staking, unstaking in Stake 2.0 can be done anytime after staking, only there will be a delay of N days before the unstaking TRX can be withdrawn.

Thanks for all your replies so far, it's highly appreciated ans helps clearing things up.

I have a question about the "N" timer. I understood that other than on stake 1.0 there will be no unstaking timer until you press unstake on 2.0, correct?

After we press unstake and the "N" timer starts, will we lose our energy/voting power during the unstaking event too?

So let's say timer "N" is at 14d as example. That would mean no energy/voting power for 14 days? Or will that only be removed after you collect your TRX as soon as the timer is at 0?

I personally think there should be a option to choose from "N" = 3 days minimum with minimum voting rewards to a max of 4 years stake for example. Just like sun staking.

Anyhow I think 3 days is enough but I wouldn't mind 7 days either for example.

[Bellgin]

I think the N for the waiting period should be longer, maybe like Polkadot, 28 days. The longer the waiting period is, the more decisive and careful the decision of staking will be, especially for those big whales, making the market more predictable and less volatile.

[Jackmrshen]

I have a question about the "N" timer. I understood that other than on stake 1.0 there will be no unstaking timer until you press unstake on 2.0, correct?

Yes, according to the model description, there will be no lock-up time after staking in Stake 2.0, we can unfreeze the TRX any time after freezing if only the correlated resource is not delegated to others. I think you are right.

After we press unstake and the "N" timer starts, will we lose our energy/voting power during the unstaking event too?

So let's say timer "N" is at 14d as example. That would mean no energy/voting power for 14 days? Or will that only be removed after you collect your TRX as soon as the timer is at 0?

I'm afraid so, the resource will be released immediately after we unstake or unfreeze the TRX, and we will get no voting power or resource during N days.

I personally think there should be a option to choose from "N" = 3 days minimum with minimum voting rewards to a max of 4 years stake for example. Just like sun staking.

Anyhow I think 3 days is enough but I wouldn't mind 7 days either for example.

I don't think to make the N value optional for users is necessary bro, because we will lose resource during these N days, no one will expect this N to be too long. But there will also be some issue if it is set too short, that's why most public chain set it a constant value.

[Dendorion]

Aside from the technical aspects i think it is important to find some balance when setting "N" personally think between 3 to 5 days would be ideal and also give an edge above other chains. Longer values will cause less people to stake as the voting income is a mere 3 to 5% . Not calculating energy income as that comes and goes with demand. Making chart gains outweigh passive gains with unlock timer.

As for preventing whales to sell they will simply keep part of their TRX unfrozen in case of any price jumps as again these gains outweigh passive income . Most volumes for TRX we can find on CEX unless people choose to freeze the mayority is not participating in freezing neither are bots or tron it's own MM Wintermule. Longer "N"periods will not change this in my view.

[blockpulsedev]

@lxcmyf can you please details the energy recovery model ? For example, account A has 100M energy. At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M. At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

Thanks. Meaning the protocol keep a history of all the energy consume time less than 24 hours and calculate an average recovery amount ? Does it also apply to delegated energy, when undelegated, what will be the reference energy consume time used for recovery calculation ?

Yes, it also applies to resource delegating: Assume that at time T, A delegated 100 energy to B, and B used all of it. At time T+12, A undelegated 100 energy to B, and B had used 50 energy at that time. Then, for A, the final recovery time is T + 12 + (50 12 + 50 24) / (50 + 50) = T + 12 + 18 = T + 30

At T + 12, A get back 50 from B and remains 50 to be recovered. Why the formula is not T + 12 + (50 * 12) / 50 = T + 24 ? With you formula, it means at T + 12, A needs to recover 50 in 12h and 50 in 24h, or a total of 100 at 18 hours.

[lxcmyf]

@lxcmyf can you please details the energy recovery model ? For example, account A has 100M energy. At time T: A use 100M energy At time T+12hours: A has recovered 50M energy At time T+12hours: A use 1M energy. So the remaining energy at this time is 49M. At what time A will recover the full 100M energy ? At T+36hours ?

Stake 2.0 optimizes the usage consolidation calculation. If some energy has been used, the energy used again when its usage is not fully recovered will not wait for 24 hours to recover, but will be combined with the energy used, as shown in your example: Final recovery time = T + 12 + (50 12 + 1 24) / (50 + 1) = T + 12 + 12.2 = T + 24.2

Thanks. Meaning the protocol keep a history of all the energy consume time less than 24 hours and calculate an average recovery amount ? Does it also apply to delegated energy, when undelegated, what will be the reference energy consume time used for recovery calculation ?

Yes, it also applies to resource delegating: Assume that at time T, A delegated 100 energy to B, and B used all of it. At time T+12, A undelegated 100 energy to B, and B had used 50 energy at that time. Then, for A, the final recovery time is T + 12 + (50 12 + 50 24) / (50 + 50) = T + 12 + 18 = T + 30

At T + 12, A get back 50 from B and remains 50 to be recovered. Why the formula is not T + 12 + (50 * 12) / 50 = T + 24 ? With you formula, it means at T + 12, A needs to recover 50 in 12h and 50 in 24h, or a total of 100 at 18 hours.

At time T+12, A undelegated 100 energy to B, and A had used 50 energy at that time. I have corrected who used energy at T + 12.

[txoh1603]

With the new stake model, there will be many dApps and protocols implementing TRC-484. New scenarios, pools, mining, and other possibilities would come up after 2.0 is opened. Staking TRX to mint 484 tokens should be rewarded then, and 484 tokens could be traded in the dex, as they could be swapped directly to TRX. The arbitrageurs will prompt liquidity in both ways.

[Jackmrshen]

Aside from the technical aspects i think it is important to find some balance when setting "N" personally think between 3 to 5 days would be ideal and also give an edge above other chains. Longer values will cause less people to stake as the voting income is a mere 3 to 5% . Not calculating energy income as that comes and goes with demand. Making chart gains outweigh passive gains with unlock timer.

As for preventing whales to sell they will simply keep part of their TRX unfrozen in case of any price jumps as again these gains outweigh passive income . Most volumes for TRX we can find on CEX unless people choose to freeze the mayority is not participating in freezing neither are bots or tron it's own MM Wintermule. Longer "N"periods will not change this in my view.

Yeah, from your point of view, you are actually saying that we need whales to stake as much as possible, but for our individuals we do not want to lose the liquidity, so we need to find a balance between encouraging whales to stake more and keeping the flexibility of retail investors. I also noticed the TRC-484 that @txoh1603 mentioned. I was not so clear with the purpose at that time, but now I realize that it would be a perfect way to solve this problem. I think it is talking about tokenizing the staked TRX. Imagine that if we can have another token like TRX-484, and the new token can also be listed on DEX, then we can choose whether to make profit by staking or simply sell it at any time. Then the parameter N is no longer a limitation for retail investors, it would be set longer to benefit all of the users, because it will not influence the liquidity.

[xylophonesir]

Aside from the technical aspects i think it is important to find some balance when setting "N" personally think between 3 to 5 days would be ideal and also give an edge above other chains. Longer values will cause less people to stake as the voting income is a mere 3 to 5% . Not calculating energy income as that comes and goes with demand. Making chart gains outweigh passive gains with unlock timer. As for preventing whales to sell they will simply keep part of their TRX unfrozen in case of any price jumps as again these gains outweigh passive income . Most volumes for TRX we can find on CEX unless people choose to freeze the mayority is not participating in freezing neither are bots or tron it's own MM Wintermule. Longer "N"periods will not change this in my view.

Yeah, from your point of view, you are actually saying that we need whales to stake as much as possible, but for our individuals we do not want to lose the liquidity, so we need to find a balance between encouraging whales to stake more and keeping the flexibility of retail investors. I also noticed the TRC-484 that @txoh1603 mentioned. I was not so clear with the purpose at that time, but now I realize that it would be a perfect way to solve this problem. I think it is talking about tokenizing the staked TRX. Imagine that if we can have another token like TRX-484, and the new token can also be listed on DEX, then we can choose whether to make profit by staking or simply sell it at any time. Then the parameter N is no longer a limitation for retail investors, it would be set longer to benefit all of the users, because it will not influence the liquidity.

You mean staking TRX to 484 contract to get sTRX， swap sTRX for TRX in sunswap dex to to avoid unstaking lock-up period？

[Jackmrshen]

Aside from the technical aspects i think it is important to find some balance when setting "N" personally think between 3 to 5 days would be ideal and also give an edge above other chains. Longer values will cause less people to stake as the voting income is a mere 3 to 5% . Not calculating energy income as that comes and goes with demand. Making chart gains outweigh passive gains with unlock timer. As for preventing whales to sell they will simply keep part of their TRX unfrozen in case of any price jumps as again these gains outweigh passive income . Most volumes for TRX we can find on CEX unless people choose to freeze the mayority is not participating in freezing neither are bots or tron it's own MM Wintermule. Longer "N"periods will not change this in my view.

Yeah, from your point of view, you are actually saying that we need whales to stake as much as possible, but for our individuals we do not want to lose the liquidity, so we need to find a balance between encouraging whales to stake more and keeping the flexibility of retail investors. I also noticed the TRC-484 that @txoh1603 mentioned. I was not so clear with the purpose at that time, but now I realize that it would be a perfect way to solve this problem. I think it is talking about tokenizing the staked TRX. Imagine that if we can have another token like TRX-484, and the new token can also be listed on DEX, then we can choose whether to make profit by staking or simply sell it at any time. Then the parameter N is no longer a limitation for retail investors, it would be set longer to benefit all of the users, because it will not influence the liquidity.

You mean staking TRX to 484 contract to get sTRX， swap sTRX for TRX in sunswap dex to to avoid unstaking lock-up period？

Yes, definitely, if it can be achieved on TRON ecosystem users will stake without any hesitation.

[txoh1603]

I suggest setting the parameter value longer in consideration of security and increasing the staking rate. Why not set the parameter to 14 days? I think two weeks should be enough to deal with the black swan event in cryptocurrency history.

[okwapa210]

No concerns from me on it

[WindsofChange92]

@lxcmyf The "N" parameter discussion needs to be in its own entirely new TIP and voted on by the SRs. The "N" parameter in this proposal should stay the same (3 days) as it hasn't been specified.

My personal opinion is I am okay with the 3-day stake and nothing more. Anything more becomes very very very user-unfriendly.

Maybe it is a better idea for a user to specify their own "N" lock-up period.

[xylophonesir]

Aside from the technical aspects i think it is important to find some balance when setting "N" personally think between 3 to 5 days would be ideal and also give an edge above other chains. Longer values will cause less people to stake as the voting income is a mere 3 to 5% . Not calculating energy income as that comes and goes with demand. Making chart gains outweigh passive gains with unlock timer. As for preventing whales to sell they will simply keep part of their TRX unfrozen in case of any price jumps as again these gains outweigh passive income . Most volumes for TRX we can find on CEX unless people choose to freeze the mayority is not participating in freezing neither are bots or tron it's own MM Wintermule. Longer "N"periods will not change this in my view.

Yeah, from your point of view, you are actually saying that we need whales to stake as much as possible, but for our individuals we do not want to lose the liquidity, so we need to find a balance between encouraging whales to stake more and keeping the flexibility of retail investors. I also noticed the TRC-484 that @txoh1603 mentioned. I was not so clear with the purpose at that time, but now I realize that it would be a perfect way to solve this problem. I think it is talking about tokenizing the staked TRX. Imagine that if we can have another token like TRX-484, and the new token can also be listed on DEX, then we can choose whether to make profit by staking or simply sell it at any time. Then the parameter N is no longer a limitation for retail investors, it would be set longer to benefit all of the users, because it will not influence the liquidity.

You mean staking TRX to 484 contract to get sTRX， swap sTRX for TRX in sunswap dex to to avoid unstaking lock-up period？

Yes, definitely, if it can be achieved on TRON ecosystem users will stake without any hesitation.

This is valid for small stakes, the amount in DEX should not be enough to convert for big stakers, but I think the lock time is good for the stability of staking, the circulating supply of TRX in the market will not change too much due to large price fluctuations

[txoh1603]

In fact, I prefer the “N” to be 14 days or even larger now. 3 days are too short to deal with price fluctuations. Ethereum owns more than 500,000 validators and still, they make it very complex to unstake. It’s actually much easier for whales on TRON to reach a consensus than that on Ethereum. So if TRON set the “N” value too short, it could be very risky. As discussed by @xylophonesir and @Jackmrshen, by setting “N” longer, in fact, we can get security and convenience at the same time.

[joker-gdb]

@lxcmyf The "N" parameter discussion needs to be in its own entirely new TIP and voted on by the SRs. The "N" parameter in this proposal should stay the same (3 days) as it hasn't been specified.

My personal opinion is I am okay with the 3-day stake and nothing more. Anything more becomes very very very user-unfriendly. Also, big whales don't move their stakes around often. If they want to dump their TRX having a 14-day stake period won't affect that as they are more than likely to have staked TRX for more than a few months and can unstake at any time because they have passed the period many times over.

The only thing the "N" parameter will affect is the energy market. Maybe it is a better idea for a user to specify their own "N" lock-up period.

If they want to dump their TRX having a 14-day stake period won't affect that as they are more than likely to have staked TRX for more than a few months and can unstake at any time because they have passed the period many times over.

I think you may misunderstood, In stake 1.0, unstaking can only be done three days later after staking. In stake 2.0, unstaking can be done anytime, after staking, N days needs to be waited before withdrawing.