Stake 2.0 - A new TRON stake model #467
Comments
ethan1844
added
enhancement
|
GOOD |
|
Great thought. |
|
It sounds like not such a bad idea, however the implementation is not clear at all. In tron currently, there is a huge market for selling energy. In that sense, the current model provides stability and security to these buyers who are expecting to receive the energy for at least 3 days with the current model. The redelgation of resources would be a wonderful idea if/when implemented, as it would reduce bandwidth costs of having to vote, unfreeze and refreeze, which could just be written over with a simple method of changing the address the resources are delegated to. On the other hand, as a developer, I can see this having a slight number of issues with choosing the best lath for implementation. One such main issue that immediately comes to mind is the amount which you're redelgating. What if someone wants to redelegate a larger amount than that frozen for one account? Would you allow them to input a larger for TRX staked and use another frozen amount from another account (from lowest to highest unfreeze time that has passed)? To make this question more clear, let's stake an example. For example addr x had 3000 TRX staked, addr y (with a larger unfreeze time than x which has also passed) has 3000 TRX staked. You redelegate 4000 TRX. In terms of efficiency, would it be better to use 3000 from addr x and 1000 from addr y? Or to limit the usage to 3000 and redelagting from just addr x and then redelgating 1000 from addr y? Even in this case, does the remaining 2000 for addr y have a new unfreeze time or not? There are plenty of ways to implement this. Although I would love to hear more about specifically how redelgation would help in times of market fluctuations to keep TRX stable? And what implications (as mentioned by you) does it have on the stake model currently? |
|
I agree with this proposal, which is conducive to the efficient use of tron's resources, but I still have the following questions
|
|
@CryptoRhinoGH |
|
I suggest we need a function to stake our Tron for a customized unstake period, like 1 week or 2 months or 2 years with minimum 3 days mandatory unstake period, this will further improve longer period tron staking in the tron network and it also helps the tron energy and bandwidth renting market |
|
I think the problem is not the unstake period, but how to make full use of the mortgage resources to make them better used |
Chain itself should not implement this, it is generally implemented through smart contracts, but requires EVM/TVM to support staking-related instructions. |
|
@caohuiboss
|
|
To clear my idea again, The issue is about the unstake period because if we implement a customised unstake period then this gives energy/bandwidth buyers a guarantee, this will be highly positive for the energy/bandwidth renting market and also improve long period unstakeble tron on the network, we can publicly shill this information on Twitter or social media |
|
Great news! IMO this TIP is a great opportunity to enhance the stake/resources system! Would love to see this implementation |
|
This proposal will lead to stop the deflation of tron if the majority of srs start to sell energy at cheap |
|
This feels like a way for very large wallets to be able to sell energy into the market without having to worry about missing voting rewards or potentially shifting SR rankings. The energy market is a solid part of the Tron community now, and lets not forget that a bit of energy scarcity is a good thing, it drives users to buy TRX to the point where they then can freeze to offset their cost. I'm not convinced that this is a good idea. It feels like it would take a system that is running relatively well and introduce a good bit of uncertainty. I predict the first thing that happens if you can redelegate energy without restaking is that all the large wallets that are frozen to bandwidth will then freeze for energy. This will reduce network energy for everyone else. Then those large wallets will sit on that energy, without missing any voter rewards, they can then sell it at the leisure, those controlling the energy market and driving more money into the very top wallets. Currently the energy market is serviced by mid range holders and even small holders who fill energy orders. I see this going away and many of those smaller and mid range holders who have been accruing TRX to continue to rent it would then likely return to selling daily rewards. In short I see this potentially creating an energy cartel of the topmost whales at the expense of the smaller more open energy market that exists today. |
|
Good idea but I think we can face problems with redelegating resources from the account when it already used resources Problem: how the first account should repair resources, they will be in minus after re-delegating by the owner? Solution: allow redelegation of resources from the first account to the second only when the first account repairs all used delegated resources |
|
This proposal is short on clear details. But if I understand it right, it is proposing the following main things
First of all, it proposes too many changes. Second, it says several times that the current resource utilization is in-efficient and this proposal will improve it but I just don't see how. How would being able to delegate resources whenever you want be beneficial to anyone other than those with big TRX bags. This sounds like it is only helpful to those that want to delegate their energy for a fees without having to wait for 3 days. So, in this case, they'd be able to delegate energy for 1 day instead of 3 days. This would help big whales corner the resource renting market and hurt smaller holders Another TIP that is disguised as something that benefits the whole TRON community when it actually only benefits those with large TRX accounts to sell their energy resources. There is already too many TRX in circulation which is one of the factors affecting the price. Like someone above said, this will burn fewer TRX everyday as people would just rent energy instead of burning TRX for their transactions. This will be very bad for the price of TRX as there will be more and more TRX everyday. For me, this proposal is a big NO because it doesn't solve any current problems, but creates a few new problems, the most glaringly obvious one being that it stops TRX from being deflationary. |
|
@otakuinny It is motivation, not a solution bro, no need to show how at this step. |
|
@otakuinny Also, you mentioned that it is not conducive to deflation. I think the final result will not tend to inflation. Leasing resources also needs to pledge TRX to support this behavior, which will not lead to reduced use of TRX. |
|
This TIP will spawn a huge energy market. About 1 year ago, I also considered putting some of my TRX into the energy market to gain income, but then I gave up. Now the energy market is too small, it is difficult for my TRX to go out at one time. Because if someone needs to rent, I need to unfreeze and then freeze and delegrate the energy to him, but I can't get income by freezing my remaining TRX. Once I freeze to get voting income, I will not be able to rent for the next 3 days. I think TVM should add staking-related instructions, so that a liquidity mining pool can be realized through smart contracts. The income of this pool comes from voting and lease . This is a major progress, because some decentralized energy markets will be created, these energy markets are not just a place to trade energy, but a decentralized liquidity mining pool. |
|
@joker-gdb |
|
Sounds good, unstaking and getting the funds immediately, it seems to be invisible on other chains, such as EOS, DOT, COSMOS, maybe you guys can learn from these implementations. |
@Jakevsky, this TIPs section is not for half-baked ideas with no real details. If you have half an idea, you need to fully think through on how exactly it is supposed to work and then post your proposal. Take a look at all the other proposals. They all explain exactly what they want to happen and how. This proposal basically says, there needs to be a better resources model but doesn't explain anything else. As for your question about large TRX accounts, the commissions they can earn by renting out their TRX will more than make up for any changes in the TRX prices that are caused by the Inflation this proposal creates so they don't care cos they still make money. |
@lxcmyf, my main concern is not about the unstaking but with the disruption in the energy market this creates as this is only beneficial for large TRX holders and hurts small holders. The accounts that are staking and not doing anything with the resources they are receiving are already locking their TRX up. In your new scheme, those trx will still be locked except now they can delegate resources without unstaking and within the mandatory 3 day period. So, the only thing that changes is that whales are gonna make more money at the expense of small trx bag holders. And, it will definitely lead to inflation as more people will just rent energy and not burn any TRX for transactions. I just have a simple question for everybody. Who does this proposal benefit? Think about the answer and you'll realize this is not good for the TRON community in general. |
What you said proves this proposal is no good. This only benefits those that can use their TRX to sell resources all at the expense of those that can't and it also leads to massive Inflation of TRX supply which will negatively affect the price. The current resources model works just fine. If anything the only thing that can make it better is if the user can freeze their TRX for more than 3 days. |
We've both been around since the beginning and I know both have a clear idea how these TIPS and chain changes get pushed through and also who typically benefits. But even if we look past the obvious point that this is for the benefit of whales and potentially TronDAO itself, you also keyed on a very important point. These are big changes, and complicated changes, this is not just raising the energy price or setting a longer timeout on the TVM. This is tinkering with the very delicate balance that is resources, something thats been relatively successful for years now. It is like you said, half baked at best and way to complicated and large a thing to just brashly change. On top of this, we are rapidly approaching the time when USDD was supposed to have its burn mechanism cut into javatron, something that is also a big change and very delicate. I see very little reason to risk changing the resource system that has worked so well for so long and I think it points to big players once again steam rolling changes on the chain for their own benefit. |
|
Again people need to think about how this would play out. TronDAO and other very large players have billions of TRX frozen for bandwidth because those TRX are voting for their SRs. The reason those large wallets don't sell energy is because they can't risk SR positions and staking rewards by leaving TRX unfrozen waiting for energy orders. They can't practically sell the energy from their billions of TRX, so they don't currently sell. Now if they can freeze one time and then redelegate as they wish, heres what will happen: The large large wallets will freeze for energy and just like when binance accidentally froze for energy a while back, the amount of available energy for everyone else will dramatically decrease. So the first result will be a sudden loss of energy for most small and middle users. This of course creates scarcity and will force those people to now look to buy energy, where previously they may have accrued enough TRX to freeze and cover their usage. So now they go looking for energy and the massive wallets will become the main sellers because they can undercut the market due to huge supply. So basically it will both hurt small users while benefitting many huge wallets that already collect staking rewards and do little else in terms of contributing. I fail to see the upside to this proposal and this is without considering the details of implementation, which if flawed, could cause havoc on the chain. |
If there is a problem, it should be fixed the right way. This fix will cause further problems. I didn't say only small number of users use excess energy. It could be the that almost all the users who receive energy use more energy than they paid for inadvertently. This hasn't been an issue because the total amount of energy used on any given day never came even close to the total energy limit of 90 billion. So, the total energy consumed including the excess Energy used by receivers was always under this limit so this was never an issue. But, when you start debiting it from the owner it will have noticeable repercussions, as there'll be thousands of energy receivers complaining why they didn't receive the full energy they paid for. Changing this will have severe adverse affects on the resource rental market. There are some good features in stake 2.0 but this is not one of them. If this is change is implemented, that will be it for me on TRON. And, trust me, you'll notice the decrease in on chain activity if my dapps are migrated to BSC. |
I try to understand your question. You mean that A delegates energy to B and then delegates it to C after recycling it from B, because only a part of it is recycled, so C cannot use all the energy that A delegates to itself? If this is the case, this will not happen. A can only delegates unused resources to C. As long as the energy that A delegates to C can be used completely. |
In the current system, C gets 2000 energy even when B uses excess energy. This is how it should work. This system should not change. @lxcmyf, please let us know what is the part that is confusing you? |
|
@lxcmyf, if you are saying, in the above example, A cannot delegate 100 trx to C if those 100 trx have no energy left, then, this is still a problem This causes A to lose a whole day's worth of revenue, while B gets to use energy he didn't pay for. How does this make resource rental market better when resource owners are shafted?? Basically, this will reduce the revenue of resource owners by 25%, which will be devastating. How would you feel if Tron foundation cuts your pay by 25% for absolutely no reason at all? |
|
This proposal has the law of unintended consequences written all over it. It changes so many things it is impossible to predict how many ways these changes affect the whole eco-system negatively. For example, if staking and resource delegation are not separated, then everybody will just stake for energy in the hopes to sell(delegate) energy. But majority of them won't sell energy because there aren't as many buyers as there are sellers. But since they all staked for energy, it'll bring the energy per trx frozen rate significantly down, just like bandwidth. When this rate is down, even renting energy won't save a lot of trx. This will cause a situation where all transactions will cost trx to be burned since freezing doesn't give enough energy. When this happens, no one will make any transactions and that will be the end of tron. This is a very real possibility. This can be prevented by simply decoupling staking and resource delegation. Staking should only give voting rights and resource delegation should be used to assign actual resources. Not sure why tron foundation is refusing to make this simple, yet highly needed, change 🤔. |
I understand your concern. You are worried that B uses the energy at the last moment of the lock period, which makes it impossible for A to use the recovered energy immediately. But this is not a problem. The implementation of the contract is very flexible. The contract provides many query interfaces, so that the contract developer can charge according to the energy usage of the delegated object when recovering the energy. The typical implementation is: first, charge according to the duration of B's lease, and then make an additional charge according to B's current energy usage as an offset to A. In addition, centralized energy leasing can charge users an extra day's money first, and then return it according to their usage. |
You understand the problem and yet say it is not a problem.
I don't think you understand how smart contracts work. If B uses additional energy than he paid for, a contract DOES NOT have the ability to transfer trx from account B's account for excess energy usage. So, I'm not sure what contract flexibility you are talking about,
This suggestion is ridiculous. It creates so much un-necessary overhead and maintenance and can easily lead to owner and receiver disputes when owner charges more for receiver's excess usage and receiver says he did not use any. I don't think you are thinking about any of these situations very seriously. You sound like you are just saying whatever comes to your mind. If you don't make any changes to the model and keep it as it is now, then none of the above issues will be a problem in the new model. Why are you offering half-assed solutions to a complex problem when there is a simple solution available. |
B did not use 2000 excess energy, before A undelegate the resource, B has the right to use all the energy, this is the rule of system design. I think this change is reasonable, "stealing energy" exists in Stake 1.0, in the above example, after A undelegate the resource, A immediately gets 2000 energy, the 2000 energy bypasses the recovery mechanism, Stake 2.0 fix the issue. Different people have different understandings of whether 2000 energy should take time to restore, the energy owner hopes that he can get 2000 energy directly, pre-charges is a solution for the energy owner. |
Nope, pre-charging and sending the trx back to the receiver is a stupid idea. Like i said before, it creates unnecessary disputes, and also creates unnecessary transactions. It is one of the stupidest ideas I have ever heard. You keep talking about B having a right to use energy. I don't give a #$@% about B's rights. All I care about is owner losing 25% of the revenue if the resource doesn't recover fully immediately. |
Stack1.0 has the problem of energy reuse in a short period of time. The Stack2.0 protocol prevents this phenomenon from continuing. The design of the agreement needs to take into account the interests of the lender and renter, and there is no bias towards either party. In addition, both centralized and decentralized resource market products can adopt diversified strategies, which can not only prevent owners from bearing losses through withholding fees, but also allow owners to bear the cost of exceeding the lending time, so as to attract more users to use their own products, and also allow users to directly pay the cost of using beyond the lending time. This will be at the discretion of the project party. |
Who said this is a problem? You haven't given one reason why this is a problem.
How is losing 25% of the revenue in interest of the owner? The bias may not be intentional but it is accidental. Never attribute to malice that which can be adequately explained by stupidity.
So, one of your suggestions is for owners to just take the loss? Also, the owners know how to "attract more users"; they don't need suggestions from someone who doesn't even know how smart contracts work and yet somehow mysteriously works at the tron foundation. SMH 😆
Right. Because this totally works! After the rental period, if the receiver uses more energy, the owner can simply somehow ask the receiver to pay more and the receiver will just pay it. Your lack of understanding of the resource rental market is mind boggling. Charging for an additional day and refunding after the rental period doesn't work because the receiver will always insist that they haven't used any excess energy cos they don't understand the concept of energy replenishment. I think you have already made several changes to the model while the conversation on this proposal is still ongoing, and is the reason why you won't listen to any of the community suggestions. I am done trying to convince you why these changes are bad. So long; I wish I could say it was fun but it wasn't. I think I lost a few brain cells for having engaged with idiots. Now that I know what kind of people work at the tron foundation, it's future became very clear to me. Thank you for giving me a peek into your clown world. |
|
From the perspective of system design, the energy used is instantly restored, bypassing the recovery mechanism, which is a system design problem, this will cause "energy stealing". the resouce owner get 25% profit for a long time, if Stake 2.0 fixes this problem, the owner thinks that he has lost 25% profit, I think the idea is terrible. Of course, if the energy owner thinks that the resource receiver should not overuse the resource, pre-charging is also fair for them. Stake 2.0 provides enough APIs to query the status of resources, and Tronscan also provides the daily energy usage data of every account, these data is open and transparent for everyone, and there is no obstacle to pre-charging, and it will not cause controversy. |
Assuming that only A stakes and obtains the resources of the entire network and delegates all the resources to B, B can use all the resources of the entire network. After B's using, A immediately releases the delegate and then delegates all the resources to C, and C can use them again. Then in a short period of time, both B and C use all the resources of the entire network at the same time. |
@lxcmyf why the Solidity implementation of the delegateresource function does not implement the 3 days lock period, while the API does? |
Also, the resourceType has a new supported value called tron power. Does this mean when contracts freeze trx they can only receive either tron resources (0 or 1) or voting power (2)? What about user accounts? This is very in-consistent and confusing. Any comment on why freezing and resource delegation can't be de-coupled? If freezing automatically gives resources, it will create serious wastage of resources. Freezing should only give voting power, and resources should only be assigned when delegate resource operation is called. This is a simple common sense solution. |
|
Close this issue as it is implemented by GreatVoyage-v4.7.0.1. |
The TVM instruction does not support locking. If you want to lock it, you may use smart contracts to do so. |
Before #51 proposal is opened, staking TRX may obtain both TRON power and one type of resource you specified. Once #51 proposal is opened, staking TRX would only obtain either TRON power or one type of the resources you specified. |
Since #51 is not opened yet what happens when I pass the value 2 to the resourceType parameter of the delegateResource method? |
Whether #51 is opened or not, delegateResource cannot be filled with 2 because TRON_POWER cannot be delegated and such transactions cannot pass validation. But after #51 is opened, the freezing transaction can be filled with 2 and thus get only tron power. |
|
hi all, when stake 2.0 going live? |
Hi, we are still discussing about the parameter N. It is estimated to be open on mainnet by the end of March. Come to join the discussion in #TIP-519 |
|
A few months back, I lost my bitcoin and it was a devastating blow to my financial health, I thought I was going to die after losing everything. I have always thought it was impossible to recover your assets or stolen crypto but I stumbled upon a post about a cryptocurrency and assets recovery agent named Chloe William's who works with Cyber Security Service, this lady is well known for her professional services and credible recovery services. I contacted Chloe, and with her help, I was able to recover my stolen crypto. |
and others
Simple Summary
This TIP aims to establish a more flexible stake model, called Stake 2.0, Stake 2.0 can improve the utilization of network resources, and at the same time enhance the stability of the TRON stake system.
Motivation
At present, by staking TRX on the TRON network, you can obtain voting rights called TRON Power, as well as bandwidth or energy as resources. The users need to choose whether to obtain whether energy or bandwidth during the stake operation. The obtained resources can also be delegated to other addresses only if they are specified when staking. Once the staking is completed, it is not allowed to unstake within 3 days. Then, the users can perform the unstake operation and immediately obtain the staked TRX.
The delegating of resources under the current stake mechanism is hardly flexible, resulting in low resource utilization and complicated user operations. The stake and delegating operation are bound together at present. If you want to alter your resource delegating object, you need to perform unstaking first, then make another staking and designate a new delegating object. Additionally, the unstake operation must wait for 3 days after staking, which means that the resources obtained cannot be re-delegated to others within 3 days. If the user has already voted before unstaking, the unstake operation will also result in the automatic cancellation of the vote. Hence, all these rules greatly reduce the efficiency of resource allocation and incur extremely complicated user operations to stake and delegate at will.
Since the TVM does not support stake, vote, or delegate commands, the developers are not able to implement related operations in a smart contract, which limits the applications involved staking and delegating, like tokenization and decentralized resource exchange. In addition, the principal will arrive immediately after the stake is released, when the TRX market fluctuates violently, a large number of staking or unstaking operations will be triggered, which will also have a certain impact on the overall stake model.
Therefore, we need a new stake mechanism to solve these problems, separate low-frequency staking operations and high-frequency resource delegating operations, support resource re-delegating without unstaking, and improve resource utilization. Add stake, delegate, vote, and related commands should be added in the TVM, meanwhile, the new mechanism should implement the delayed arrival of unstaking TRX, improve the stability of the stake model under extreme market conditions, and help network participants to form more stable expectations for the total circulation of the entire network.
Specifications
Based on the description above, a newly designed staking model is shown as below, seven new APIs should be added to the java-tron client:
/wallet/freezebalancev2/wallet/unfreezebalancev2/wallet/delegateresource/wallet/undelegateresource/wallet/withdrawexpireunfreeze/wallet/getavailableunfreezecount/wallet/getcanwithdrawunfreezeamount/wallet/getcandelegatedmaxsize/wallet/getdelegatedresourcev2/wallet/getdelegatedresourceaccountindexv2and six new opcodes should be added to TVM:
FREEZEBALANCEV2,UNFREEZEBALANCEV2,DELEGATERESOURCE,UNDELEGATERESOURCE,CANCELALLUNFREEZEV2,WITHDRAWEXPIREUNFREEZEMechanism
The mechanism of Stake 2.0 is shown as follows:
/wallet/freezebalancev2to stake TRX and obtain resources, specifing the type of resource. The corresponding resource goes to the owner address that has staked TRX./wallet/delegateresourceto delegate resources to multiple recipients respectively. The delegating time locker is an optional, if selected, the delegated resources cannot be undelegated within 3 days, if not selected, there will not be lock-up period. When the owner repeat the delegating operation with time lock of same amount to the same receiver address, the lock-up period will be reset to 3 days./wallet/undelegateresourceto cancel the resource delegating for a recipient, supporting partial cancellation by amount./wallet/unfreezebalancev2to unstake TRX, partial unstaking is supported, but only for the available part, TRX related to the delegated resources are considered locked and not available, therefore, cannot be unstaked.Ndays, then call/wallet/withdrawexpireunfreezeto get back TRX，Nis a TRON network parameter.Specification in undelegateresource
If the recipient has consumed a part of the resource, after undelegating, this part of resources will still be not available status in the owner account, and needs some time to recover. The owner can only delegate the available resources to others.
Example：
/wallet/undelegateresourceto undelegate all the energy left. Now, A has a balance of 600 units of energy in the account, 400 units are in recovering.Specification in unstake
TRX partial unstaking is supported, but a maximum of 32 partial unstaking operations is allowed simultaneously, in other words, there should be no more than 32 delay arrivals of the unstaking assets in progress at the same time.
Example,
There could be at most 32 unstaking operations in processing at the same time in the new model.
Unstaking will first reclaim the idle TRON Power, then the TRON Power that has been used. For the reclaiming of TRON Power that has been used, if vote for multiple SRs, it will revoke votes in proportion.
Example：
Suppose that a user stakes 2000 TRX and gets 2000 TRON Power, 1,000 TRON Power is idle and 1,000 TRON Power votes for 5 SRs. Each SR gets 200 votes. Now the user unstake 1500 TRX, which means 1500 TRON Power needs to be reclaimed, in this case, the 1000 idle TRON Power will be reclaimed first, then revoke 100 votes from each SR.
Revoked votes from SR(A) = (Total revoked votes from all SRs/ Total previous votes to all SRs) * Total previous votes to SR(A)
Specification of HTTP APIs
/wallet/freezebalancev2
Description: stake TRX to obtain TRON Power (voting rights) and bandwidth or energy.
Params:
owner_address- Address of transaction initiator, data type is stringfrozen_balance- Amount of TRX to be staked, unit is sun, data type is uint256resource- Resource type, "BANDWIDTH" or "ENERGY", data type is stringvisible- Whether the address is in Base58 format, data type is boolReturns - unsigned transaction, data type is json string
Example:
/wallet/unfreezebalancev2
Description: Unstake TRX to release bandwidth and energy and at the same time TRON Power will be reduced and all corresponding votes will be canceled.
Params:
owner_address- Address of transaction initiator, data type is stringunfreeze_balance- Amount of TRX to be unstaked, unit is sun, data type is uint256resource- Resource type, "BANDWIDTH" or "ENERGY", data type is stringvisible- Whether the address is in base58 format, data type is boolReturns - unsigned transaction, data type is json string
Example:
/wallet/delegateresource
Description: delegate resource
Params:
owner_address- Address of transaction initiator, data type is stringreceiver_address- Receiver address of resource to be delegated tobalance- Amount of TRX staked for resource to be delegated, unit is sun, data type is unit256resource- Resource type, "BANDWIDTH" or "ENERGY", data type is stringlock- Whether it is locked, if it is set totrue, the delegated resources cannot be undelegated within 3 days.When the lock time is not over, if the owner delegates the same resources using the lock to the same address, the lock time will be reset to 3 daysvisible- Whether the address is in base58 format, data type is boolReturns - unsigned transaction, data type is json string
Example:
/wallet/undelegateresource
Description: undelegate API
Params:
owner_address- Address of transaction initiator, data type is stringreceiver_address- Receiver address of resource to be delegated tobalance- Amount of TRX staked for resource to be undelegated, unit is sun, data type is unit256resource- Resource type, "BANDWIDTH" or "ENERGY", data type is stringvisible- Whether the address is in base58 format, data type is boolReturns - unsigned transaction, data type is json string
Example:
/wallet/withdrawexpireunfreeze
Description: withdraw unfrozen balance API
Params:
owner_address- Address of transaction initiator, data type is stringvisible- Whether the address is in base58 format, data type is boolReturns - unsigned transaction, data type is json string
Example:
/wallet/getavailableunfreezecount
Description: remaining times of available unstaking API
Params:
owner_address- account address, data type is string.visible- whether the address is in base58 format, data type is boolReturns - Remaining times of available unstaking, data type is number.
Example:
/wallet/getcanwithdrawunfreezeamount
Description: query the withdrawable balance at the specified
timestampParams:
owner_address- account address, data type is string.timestamp- query cutoff timestamp, in millisecond.visible- Whether the address is in Base58 format, data type is boolReturns - withdrawable balance，unit is sun.
Example:
/wallet/getcandelegatedmaxsize
Description: query the amount of delegatable resources of the specified resource Type for target address, unit is sun.
Params:
owner_address- account address, data type is string.type- resource type，data type is number, 0 is bandwidth, 1 is energyvisible- whether the address is in base58 format, data type is boolReturns - the amount of delegatable resource, unit is sun.
Note: The interface indicates the return of the maximum amount of delegated resources for normal transactions, but there are some special transactions in actual situations, such as multi-signature, memo and other transactions that will deduct a part of the resource usage. At this time, the maximum value of specific resources that can be used may be smaller than the recommended value returned through this interface.
Example:
/wallet/getdelegatedresourcev2
Description: query the amount of resources detail delegated by
fromAddresstotoAddressParams:
fromAddress- resource from address, data type is string.toAddress- resource to address, data type is string.visible- whether the address is in base58 format, data type is boolReturns - Resource delegation information
Example:
/wallet/getdelegatedresourceaccountindexv2
Description: query the resource delegation index by an account
Params:
value- account ddress, data type is string.visible- whether the address is in base58 format, data type is boolReturns - Resource delegation index
Example:
Specification of TVM instructions
0xda:FREEZEBALANCEV2The
FREEZEBALANCEV2takes 2 operands pop up from stack:amount: amount to freeze in SUN.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.If operation succeed, push 1 to stack, otherwise push 0 to stack.
0xdb:UNFREEZEBALANCEV2The
UNFREEZEBALANCEV2takes 2 operands pop up from stack.amount: amount to unfreeze in SUN.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.If operation succeed, push 1 to stack, otherwise push 0 to stack.
0xdc:CANCELALLUNFREEZEV2The
CANCELALLUNFREEZEV2takes no operand pop up from stack.If operation succeed, push 1 to stack, otherwise push 0 to stack.
0xdd:WITHDRAWEXPIREUNFREEZEThe
WITHDRAWEXPIREUNFREEZEtakes no operand pop up from stack.If operation succeed, push the actual withdrawal amount to stack, otherwise push 0 to stack.
0xde:DELEGATERESOURCEThe
DELEGATERESOURCEtakes 3 operands pop up from stack:amount: resource amount to delegate in SUN.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.receiver: account address to receive the resource.If operation succeed, push 1 to stack, otherwise push 0 to stack.
0xdf:UNDELEGATERESOURCEThe
UNDELEGATERESOURCEtakes 3 operands pop up from stack:amount: resource amount to undelegate in SUN.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.receiver: account address to return the resource.If operation succeed, push 1 to stack, otherwise push 0 to stack.
Specification of precompile contracts
0x100000b:GetChainParameterThe
GetChainParametertakes 1 parameters:index: index of the parameter to be queried.Query the specific chain parameters, and push the query result to stack. The solidity syntax is shown below.
chain.totalNetLimitchain.totalNetWeightchain.totalEnergyCurrentLimitchain.totalEnergyWeightchain.unfreezeDelayDays0x100000c:AvailableUnfreezeV2SizeThe
AvailableUnfreezeV2Sizetakes 1 parameters:target: target account address.Query the size of the available unfreeze queue for
targetaddress, and push the query result to stack.0x100000d:UnfreezableBalanceV2The
UnfreezableBalanceV2takes 2 parameters:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the unfreezable balance of a specified
resourceTypefortargetaddress, and push the query result to stack.0x100000e:ExpireUnfreezeBalanceV2The
ExpireUnfreezeBalanceV2takes 2 parameters:target: target account address.timestamp: query cutoff timestamp.Query the withdrawal balance at the specified
timestampfortargetaddress, and push the query result to stack.0x100000f:DelegatableResourceThe
DelegatableResourcetakes 2 parameters:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the amount of delegatable resources(unit: SUN) of the specified
resourceTypefortargetaddress, and push the query result to stack.0x1000010:ResourceV2The
ResourceV2takes 3 parameters:target: target account address.from: from account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the amount of resources(unit: SUN) of a specific
resourceTypedelegated byfromaddress totargetaddress0x1000011:CheckUnDelegateResourceThe
CheckUnDelegateResourcetakes 3 parameters:target: target account address.amount: resource amount to undelegate in SUN.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Check whether the contract can recycle the specified
amountof resources of a specificresourceTypethat have been delegated totargetaddress, and push the amount of clean resource(unit: SUN), the amount of dirty resource(unit: SUN) and the restore time to stack.0x1000012:ResourceUsageThe
ResourceUsagetakes 2 parametes:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the usage of a specific
resourceTypeof resources fortargetaddress, and push the amount of usage(unit: SUN) and the restore time to stack.0x1000013:TotalResourceThe
TotalResourcetakes 2 parameters:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the total amount of available resources(unit: SUN) of a specific
resourceTypefortargetaddress, and push the query reslut to stack.0x1000014:TotalDelegatedResourceThe
TotalDelegatedResourcetakes 2 parameters:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the amount of delegated resources of a specific
resourceTypefortargetaddress, and push the query reslut to stack.0x1000015:TotalAcquiredResourceThe
TotalAcquiredResourcetakes 2 parameters:target: target account address.resourceType: 0 as bandwidth, 1 as energy, 2 as tron power.Query the amount of acquired resources(unit: SUN) of a specific
resourceTypefortaregetaddress, and push the query reslut to stack.Solidity example
Here is an example showing how to call the above TVM instructions in solidity：
Backward Compatibility
After the proposal of the new mechanism is opened, it will not affect the previously frozen TRX. For those TRX frozen through the old mechanism, it can be redeemed using the old unstake interface. If needed, the only way to stake in the future is through the new mechanism.
The text was updated successfully, but these errors were encountered: