TIP-624: Allow claimed vote reward sent to appointed address

[TokenGoodies]

tip: 624
title: Allow claimed vote reward sent to appointed address 
author: TokenGoodies
discussions-to: <https://github.com/tronprotocol/tips/issues/624>
status: Draft
type: Standards Track 
category : Core
created: 2023-11-07

Simple Summary

This TIP aims to extract vote rewards to any address that is specified.

Abstract

At present, the extraction of vote rewards is achieved by calling the/wallet/withdrawbalance interface to extract the rewards to the owner account. This TIP will add a new transaction type that supports extracting the rewards to any specified address.

Motivation

When an account initiates a vote rewards claim transaction, the rewards are claimed and deposited into the account. There are several advantages and security benefits to depositing the claimed rewards into any account and not just the owner account. One of the primary motivations for suggesting this feature is based on the feedback from TRON users on various workings of TRON. With the proliferation of questionable wallet apps and suspect contracts that compromise user accounts, there is a genuine concern among users for the security of their accounts. Wallet apps that have built up a great reputation can turn rogue - by design or by way of a hackable exploit - and empty out user accounts of even the most careful users.

TRON's multi-signature mechanism mostly eliminates this concern by letting the users configure access to allow select operations in their accounts from other accounts. Claiming vote rewards, however, is the only day-to-day operation done by TRON users and the multi-signature permission mechanism doesn't give as much flexibility as it does to other operations. Currently, if a user wants to utilize the claimed rewards, they'll need to log in to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to log in frequently by making it possible to still claim their rewards from an account that is given multi-signature access for this new operation which reduces the risk of an account compromise.

With the rise of TRX value in recent months, and the favorable view institutions and a few governments are adopting towards crypto, there is a general willingness in the community to sit on their holdings for the long run. Providing a way for users to access their vote rewards without putting their account security on the line every time they log in would improve user confidence and will have an overall useful impact on TRON altogether.

Specifications

Add wallet/withdrawbalanceto API, the user can call this API to extract vote rewards to any address.

Params:

1. owner_address - address of transaction initiator, data type is string

2. receiver_address - recipient address of vote rewards, is owner_ address by default if leave blank, data type is string

3. visible - Whether the address is in base58 format, data type is bool

Returns: unsigned transaction, data type is JSON string

Example:

curl -X POST https://127.0.0.1:8092/wallet/withdrawbalanceto -d \
'{
  "owner_address":"TUoHaVjx7n5xz8LwPRDckgFrDWhMhuSuJM",     
  "receiver_address":"TZ4UXDV5ZhNW7fb2AMSbgfAEZ7hWsnYS2g",     
  "visible":true
}'

[laurenceja]

This proposal will indeed increase the flexibility of withdrawing rewards.

But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

[TokenGoodies]

This proposal will indeed increase the flexibility of withdrawing rewards.

But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

[laurenceja]

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Got it. That is reasonable, if an account B has the withdraw reward permission of account A, when the account B withdraws reward of account A, the TRX should can be into account B or any other specified account. A universal withdrawal reward API (withdrawrewardsto) will be more flexible.

[lurais]

As I can see , this tip will eliminate the need for users to login to their accounts frequently, so why not give an option to withdraw the rewards automatically without any user logins?

[TokenGoodies]

As I can see , this tip will eliminate the need for users to login to their accounts frequently, so why not give an option to withdraw the rewards automatically without any user logins?

Hi! In order for an account to do any state-changing transaction on a blockchain, it has to authenticate itself by signing the transaction with its private key.

If you are proposing voter rewards be sent to voting accounts automatically at the end of each voting period, that is a separate issue. This proposal suggests allowing voter rewards to be sent to any address by introducing a new operation type.

[CarlChaoCarl]

If it is secure enough, this design aims to provide users with a more convenient way to claim rewards.

[TokenGoodies]

If it is secure enough, this design aims to provide users with a more convenient way to claim rewards.

Hi @CarlChaoCarl! In our opinion, this proposal increases security and facilitates account safe-guarding by making redundant the need to login to the voting account to access the claimed TRX.

[yanghang8612]

I don't think the addition of the WITHDRAWBALANCETO opcode is necessary. Smart contracts are programmable compared to system contracts. This means that developers can implement what you call /wallet/withdrawbalanceto using the syntactic features that are currently available. Here is the sample code:

function withdrawTo(address payable receiver) external {
    require(msg.sender == owner, "Unauthorized.");
    uint allowance = withdrawreward();
    receiver.transfer(allowance);
}

[TokenGoodies]

I don't think the addition of the WITHDRAWBALANCETO opcode is necessary. Smart contracts are programmable compared to system contracts. This means that developers can implement what you call /wallet/withdrawbalanceto using the syntactic features that are currently available. Here is the sample code:

function withdrawTo(address payable receiver) external {
    require(msg.sender == owner, "Unauthorized.");
    uint allowance = withdrawreward();
    receiver.transfer(allowance);
}

Hi @yanghang8612! If we understood you correctly, the voting account needs to call this contract method to transfer the claimed trx to a different address. In this case, the user still needs to login to their voting account first to call this method, which is what our proposal aims to obviate. Please let us know if we interpreted your comment incorrectly.

[yanghang8612]

A user login is not required because the voting account referred to here is the contract account, not the account that initiated the method call. For instructions, the account that is operated on when the instruction is executed is actually the contract account. For example, when a voting instruction is executed, it is actually the contract account that casts the vote for the super representative. Since the contract is deployed on the chain, there is no way for it to initiate the voting operation on its own, so it needs an external account to initiate a voting transaction and interact with the contract so that the contract account can complete the voting operation.

[TokenGoodies]

A user login is not required because the voting account referred to here is the contract account, not the account that initiated the method call. For instructions, the account that is operated on when the instruction is executed is actually the contract account. For example, when a voting instruction is executed, it is actually the contract account that casts the vote for the super representative. Since the contract is deployed on the chain, there is no way for it to initiate the voting operation on its own, so it needs an external account to initiate a voting transaction and interact with the contract so that the contract account can complete the voting operation.

Got it. Thanks for the clarification. So, this is only when the voted TRX is on a contract, correct? Our proposal is mainly aimed at helping user owned external accounts claiming their TRX rewards to a different account.

[Jones098]

Great idea

[yuekun0707]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.

Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

[TokenGoodies]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.
Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

Hi @yuekun0707! Giving TRX transfer permission to account B is a big security risk if account B were to be compromised. The point of this proposal is to minimize account A compromise risk by doing the withdrawto operation from account B. In this case, even if B were to be compromised, it would have minimal impact on the security of account A.

[yuekun0707]

This proposal will indeed increase the flexibility of withdrawing rewards.
But I have a question, and sorry for not getting the point below.

Currently, if a user wants to utilize the claimed rewards, they'll need to login to their account to access the claimed TRX. Allowing the claimed TRX to be deposited to any account will eliminate the need for users to login to their accounts frequently which reduces the risk of an account compromise.

Withdrawing reward to self account or withdrawing reward to other address both needs to be signed by the account's privatekey. After the user withdraws the reward, then he/she can send the TRX to other address directly. So why does the user need to login to their account to access the claimed TRX? and why this proposal can eliminate the need for users to login to their accounts frequently?

Hi! Thank you for your question. We apologize, we should've been clearer in our description. We'll update it.
Currently, when rewards are claimed, they go to the owner account automatically. This is the case whether the claim rewards operation is done directly from the main account (A) or from an account (B) that has claim rewards permissions in the main account. This new operation (withdrawrewardsto) will make it possible for a user to claim rewards and send the trx to another address without the user logging into account A, as long as account A gives permission to account B to make this operation. With this new operation, the user just needs to login to account B and make this transaction in account A and send the trx to any account.

Hi @TokenGoodies, I'm not sure whether I understand your case right, will this work for your situation: account A also give the transfer permission to B, then after B claimed A's rewards, B make a transaction to transfer the rewards to another account. Maybe the permission authorization here is not rational.

Hi @yuekun0707! Giving TRX transfer permission to account B is a big security risk if account B were to be compromised. The point of this proposal is to minimize account A compromise risk by doing the withdrawto operation from account B. In this case, even if B were to be compromised, it would have minimal impact on the security of account A.

Yes, I agree with your point, transfer permission should be processed very carefully. Thus I think add a new System Contract to support this situation is reasonable.

[lxcmyf]

@TokenGoodies
Can toAddress be specified arbitrarily? Or is it necessary to be granted access permissions for multiple signatures?

[TokenGoodies]

@TokenGoodies Can toAddress be specified arbitrarily? Or is it necessary to be granted access permissions for multiple signatures?

Hi @lxcmyf. The toAddress can be any user account address. If the owner account makes this transaction, there is no need for multi signature. The owner can however give multi signature access to this operation to other accounts so they can make this transaction and send the voter rewards to any address. We only mentioned multi signature in the description because we wanted to explain how the voter rewards can safely be transfered out of owner's account without using owner's private key. For the implementation of this new operation, the explanation on multi signature can be ignored since all current and future TRON operations can be accessed by other accounts through multi signature mechanism anyway.

[lxcmyf]

@TokenGoodies Can toAddress be specified arbitrarily? Or is it necessary to be granted access permissions for multiple signatures?

Hi @lxcmyf. The toAddress can be any user account address. If the owner account makes this transaction, there is no need for multi signature. The owner can however give multi signature access to this operation to other accounts so they can make this transaction and send the voter rewards to any address. We only mentioned multi signature in the description because we wanted to explain how the voter rewards can safely be transfered out of owner's account without using owner's private key. For the implementation of this new operation, the explanation on multi signature can be ignored since all current and future TRON operations can be accessed by other accounts through multi signature mechanism anyway.

@TokenGoodies
Okay, I understand now.

[lxcmyf]

@TokenGoodies
This tip has been standardized, please stay tuned.

[TokenGoodies]

@TokenGoodies This tip has been standardized, please stay tuned.

Thank you!

[lxcmyf]

@TokenGoodies
Firstly, I would like to appreciate your interest in this feature, which allows the owner user to withdraw their voting rewards to any specified receiver_address. However, there are a few points that I believe are worth considering to ensure the security and trustworthiness of this transaction.

One concern is that the receiver_address is manually input, which raises the possibility of human error. While we can certainly validate the format of the address to ensure it meets the required standards, we cannot verify whether the address is trusted by the owner. In scenarios like payment deductions, for example, users typically select a recipient from a pre-approved or trusted list of bank accounts.

Therefore, it would be ideal if the owner could have a list of trusted addresses that they can choose from when withdrawing their rewards. This way, there is less risk of funds being sent to an unintended or untrusted address.

I would like to know your thoughts on this matter. Do you agree that implementing a trusted address list for the owner would enhance the security and trustworthiness of the withdrawbalanceto feature? If so, do you have any specific requirements or suggestions on how this list should be managed and maintained?

I look forward to your feedback and ideas on this matter. Thank you for considering my concerns and for your valuable input.

[TokenGoodies]

@TokenGoodies Firstly, I would like to appreciate your interest in this feature, which allows the owner user to withdraw their voting rewards to any specified receiver_address. However, there are a few points that I believe are worth considering to ensure the security and trustworthiness of this transaction.

One concern is that the receiver_address is manually input, which raises the possibility of human error. While we can certainly validate the format of the address to ensure it meets the required standards, we cannot verify whether the address is trusted by the owner. In scenarios like payment deductions, for example, users typically select a recipient from a pre-approved or trusted list of bank accounts.

Therefore, it would be ideal if the owner could have a list of trusted addresses that they can choose from when withdrawing their rewards. This way, there is less risk of funds being sent to an unintended or untrusted address.

I would like to know your thoughts on this matter. Do you agree that implementing a trusted address list for the owner would enhance the security and trustworthiness of the withdrawbalanceto feature? If so, do you have any specific requirements or suggestions on how this list should be managed and maintained?

I look forward to your feedback and ideas on this matter. Thank you for considering my concerns and for your valuable input.

@lxcmyf, thank you for raising this concern; we appreciate your suggestions to improve this TIP. While security is always an important issue and one that this TIP is partly trying to address, we are not sure if maintaining a whitelist of approved recipients is the way to go for this operation. To us, this operation is no different than a regular TRX transfer from one account to another, except the TRX transferred is the unclaimed voter rewards TRX instead of available TRX in this case.

Our philosophy is that blockchains should support transactions in their raw form and allow the wallet/dapp creators and centralized exchanges to implement additional security measures, like whitelists of recipients, if they want to. Since, currently, TRX from an account can be transferred to any account, and this new operation is essentially similar to a TRX transfer, we do not see a need to involve the complexity of maintaining a trusted address list for this operation. Thanks!

[lxcmyf]

@TokenGoodies
Thank you for your efforts and suggestions.

[lxcmyf]

@TokenGoodies
Given the addition of a receiver address, according to the verification rules of previous transactions, it is usually not allowed to be empty, which means that when the receiver address is empty, verification will be performed.

[TokenGoodies]

@TokenGoodies Given the addition of a receiver address, according to the verification rules of previous transactions, it is usually not allowed to be empty, which means that when the receiver address is empty, verification will be performed.

@lxcmyf, this is fine. You can update the spec of this TIP to make the receiver address a mandatory field instead of optional, if that is what you are suggesting.
Thanks!

[lxcmyf]

@TokenGoodies Given the addition of a receiver address, according to the verification rules of previous transactions, it is usually not allowed to be empty, which means that when the receiver address is empty, verification will be performed.

@lxcmyf, this is fine. You can update the spec of this TIP to make the receiver address a mandatory field instead of optional, if that is what you are suggesting. Thanks!

@TokenGoodies
Thank you for your participation and contribution!
In addition, when the owner address and receiver address are the same, verification will also be performed and it is not allowed for the two addresses to be the same.

[TokenGoodies]

@TokenGoodies Given the addition of a receiver address, according to the verification rules of previous transactions, it is usually not allowed to be empty, which means that when the receiver address is empty, verification will be performed.

@lxcmyf, this is fine. You can update the spec of this TIP to make the receiver address a mandatory field instead of optional, if that is what you are suggesting. Thanks!

@TokenGoodies Thank you for your participation and contribution! In addition, when the owner address and receiver address are the same, verification will also be performed and it is not allowed for the two addresses to be the same.

Yes, this verification makes sense when the receiver address is the same as the owner address. Thank you for thinking through all the edge cases.

[TokenGoodies]

@TokenGoodies Given the addition of a receiver address, according to the verification rules of previous transactions, it is usually not allowed to be empty, which means that when the receiver address is empty, verification will be performed.

@lxcmyf, this is fine. You can update the spec of this TIP to make the receiver address a mandatory field instead of optional, if that is what you are suggesting. Thanks!

@TokenGoodies Thank you for your participation and contribution! In addition, when the owner address and receiver address are the same, verification will also be performed and it is not allowed for the two addresses to be the same.

Thank you, @lxcmyf !

Seeing as how it's been 4 months since this TIP was created, we'd like to do a quick refresher on what this TIP is about in the form of a few bullet points.

• Our insights on TRON holders' behavior and understanding how they interact with their accounts and what's important to them stem from our conversations with multitudes of new TRON users that have contacted us over the years

• The main issue this TIP aims to address is eliminate the need for users to login to their accounts to withdraw rewards, thus reducing the number of times they need to use their private key which decreases the danger of an account compromise

• A few observations on what's been discussed in the Core Devs Community Call meeting on Feb 2nd...

  • This TIP was suggested as a way to improve account security of daily TRON users based on studying their usage patterns. It is not made with any one person's own needs in mind.

  • We don't see this as a pseudo-requirement as this feature, rather than being a constraint, actually expands the flexibility of accessing rewards

  • There seems to be a question about being able to withdraw part of the rewards. While this could be useful, this is outside the scope of this TIP. Since the current withdraw operation only allows withdrawing rewards in full, this new operation should also follow the same model. If anyone wants to start a conversation about withdrawing partial rewards, a separate TIP can be created for that discussion.

  • There also appears to be some talk of automatic reward extraction and limiting the addresses the rewards can be extracted to. We are a little bewildered by the introduction of these topics in this TIP's discussion. Right now, an account owner can do a regular TRX transfer from their account to any account without any restrictions. This new operation is in most regards exactly like a regular TRX transfer. The only difference is that the TRX being transferred is the unclaimed voter rewards instead of the available TRX in the owner's account. As such, we are puzzled how there can be a security consideration with this TIP or why unrelated things like automatic reward extraction or whitelisting receiver addresses are being discussed.

[lxcmyf]

@TokenGoodies
Okay, thank you for your feedback. The purpose of this meeting tronprotocol/pm#75 is to plan the attributes to be done next, not to discuss whether to do or not to do something.

[GuipaiQigong111]

@TokenGoodies
Can I understand it as an extended transaction type for extracting rewards? Will this type of transaction be used frequently in the future? Let me think, let me try to understand his scenario implementation:
Assuming that account B wants to withdraw the reward from account A to their own address, but it is currently not possible to do so, they can only withdraw the reward from account A and transfer it to account B. After this function is implemented, account A does not need to log in to the account and is granted multiple signature permissions in advance. After account B logs in, they can initiate the reward extraction by clicking the button, and the reward from account A will be directly withdrawn to account B.
Do I understand correctly?

[TokenGoodies]

@TokenGoodies Can I understand it as an extended transaction type for extracting rewards? Will this type of transaction be used frequently in the future? Let me think, let me try to understand his scenario implementation: Assuming that account B wants to withdraw the reward from account A to their own address, but it is currently not possible to do so, they can only withdraw the reward from account A and transfer it to account B. After this function is implemented, account A does not need to log in to the account and is granted multiple signature permissions in advance. After account B logs in, they can initiate the reward extraction by clicking the button, and the reward from account A will be directly withdrawn to account B. Do I understand correctly?

Hi @GuipaiQigong111! Yes, your understanding is correct. With this new operation type, passive TRON users can extract rewards without needing to login to their voting account and not worry about their accounts getting compromised on account of logging in frequently.

[GuipaiQigong111]

@TokenGoodies It seems that what I was thinking is right. Thank you.

[barbatos2011]

Our insights on TRON holders' behavior and understanding how they interact with their accounts and what's important to them stem from our conversations with multitudes of new TRON users that have contacted us over the years

Hi, @TokenGoodies! This proposal is quite useful, I'd like to know how you got these feedbacks from the holders? Do you have a platform or other ways? I think this is very beneficial for the ecological of TRON if we can get more feedbacks in the future.

[TokenGoodies]

Our insights on TRON holders' behavior and understanding how they interact with their accounts and what's important to them stem from our conversations with multitudes of new TRON users that have contacted us over the years

Hi, @TokenGoodies! This proposal is quite useful, I'd like to know how you got these feedbacks from the holders? Do you have a platform or other ways? I think this is very beneficial for the ecological of TRON if we can get more feedbacks in the future.

Thank you, @barbatos2011!
We receive messages from TRON users on Telegram daily with questions on staking, voting rewards etc. This proposal is the result of our conversations with these users over the years, after understanding the kind of transactions they make the most on a regular basis and understanding what's important to them in a general sense.

[barbatos2011]

Our insights on TRON holders' behavior and understanding how they interact with their accounts and what's important to them stem from our conversations with multitudes of new TRON users that have contacted us over the years

Hi, @TokenGoodies! This proposal is quite useful, I'd like to know how you got these feedbacks from the holders? Do you have a platform or other ways? I think this is very beneficial for the ecological of TRON if we can get more feedbacks in the future.

Thank you, @barbatos2011! We receive messages from TRON users on Telegram daily with questions on staking, voting rewards etc. This proposal is the result of our conversations with these users over the years, after understanding the kind of transactions they make the most on a regular basis and understanding what's important to them in a general sense.

Thank you very much for this information and look forward to your more proposals in the future.

[yanghang8612]

According to TIP-271 Solidity example and TIP-467 Solidity example, users can write smart contracts with stake/vote/reward withdrawal functionality on TRON. I think if you adopt this way of writing contracts to host your TRX assets, you will be able to implement customized stake/vote/reward withdrawal.

[TokenGoodies]

According to TIP-271 Solidity example and TIP-467 Solidity example, users can write smart contracts with stake/vote/reward withdrawal functionality on TRON. I think if you adopt this way of writing contracts to host your TRX assets, you will be able to implement customized stake/vote/reward withdrawal.

Hi @yanghang8612! That only works if the TRX is on a smart contract. The majority of TRX in circulation is in individual user accounts. This proposal's aim is to reduce the risk of a user account compromise by natively providing a new operation type that the users can use to safely access their rewards without having to login to their main accounts.

[yanghang8612]

Hi @yanghang8612! That only works if the TRX is on a smart contract. The majority of TRX in circulation is in individual user accounts. This proposal's aim is to reduce the risk of a user account compromise by natively providing a new operation type that the users can use to safely access their rewards without having to login to their main accounts.

Yes, I understand your intent.

There is practically no difference between a smart contract account and a individual user account except for the way the account is controlled. Benefitting from the unique instruction set in TVM, a smart contract account can do most of the operations of a individual user account by deploying a specific bytecode, such as TRX transfers, TRC10 transfers, TRC20 transfers, staking/unstaking, delegating/claiming resources, voting, reward withdrawal and so on.

For existing individual users, they can transfer their assets to a smart contract account that is pre-deployed with a specific permission control, and then invoke the contract to perform the above operations. At the same time, users can customize different control permissions for different operations, which is more flexible compared with the native multi-signature permission control system on the chain.

More recently, the ERC-4337: Account Abstraction can be considered to be introduced into the TRON network to bring better access experience to users. The ERC-4337 is very much in line with the solution I mentioned above.

[TokenGoodies]

Hi @yanghang8612! That only works if the TRX is on a smart contract. The majority of TRX in circulation is in individual user accounts. This proposal's aim is to reduce the risk of a user account compromise by natively providing a new operation type that the users can use to safely access their rewards without having to login to their main accounts.

Yes, I understand your intent.

There is practically no difference between a smart contract account and a individual user account except for the way the account is controlled. Benefitting from the unique instruction set in TVM, a smart contract account can do most of the operations of a individual user account by deploying a specific bytecode, such as TRX transfers, TRC10 transfers, TRC20 transfers, staking/unstaking, delegating/claiming resources, voting, reward withdrawal and so on.

For existing individual users, they can transfer their assets to a smart contract account that is pre-deployed with a specific permission control, and then invoke the contract to perform the above operations. At the same time, users can customize different control permissions for different operations, which is more flexible compared with the native multi-signature permission control system on the chain.

More recently, the ERC-4337: Account Abstraction can be considered to be introduced into the TRON network to bring better access experience to users. The ERC-4337 is very much in line with the solution I mentioned above.

We are aware that this can be achieved through a contract, but if you look at the rationale we offered for making this proposal, you'll notice that the target audience are new/less-savvy TRON users who keep their TRX in their accounts and don't usually send it to a contract they know nothing about. Building contracts like these can in themselves be an attack vector where anyone can build a contract claiming to do this but which ends-up stealing user funds. Your mention of ERC-4337 which abstracts away the concept of an EOA is interesting, but most crypto users still believe in the maxim, "Not your keys, not your coins", and prefer to keep their assets in their accounts.

The current withdraw rewards operation should've been implemented in a way where the extracted rewards can be sent to any address from the beginning. TRON consistently attracts new users in huge numbers and one of the unfortunate negative side-effects of TRON's popularity is that it is a prime target for scammers who target new entrants to the chain. Providing this functionality natively on chain will make one of the most frequently made operations more secure.

[yanghang8612]

@TokenGoodies Thanks for the explanation.

I was just trying to provide an existing solution. Also, as you know, it takes a long process to propose a TIP that modifies the protocol on the TRON network to the point where it is implemented and activated on the mainnet.