Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

automatic reward restaking #43

Closed
SurfingNerd opened this issue Oct 25, 2020 · 3 comments
Closed

automatic reward restaking #43

SurfingNerd opened this issue Oct 25, 2020 · 3 comments
Assignees

Comments

@SurfingNerd
Copy link
Collaborator

SurfingNerd commented Oct 25, 2020

The reward payout functions seems to be very complicated, and there are a lot of voices to simplify that.

    /// @dev The reward amount to be distributed in native coins among participants (the validator and their
    /// delegators) of the specified pool (mining address) for the specified staking epoch.
    mapping(uint256 => mapping(address => uint256)) public epochPoolNativeReward;

It would simplify a lot connected to claiming the reward like

epochsToClaimRewardFrom
_epochsPoolGotRewardFor
claimReward
...

The Restaking Reward solution is so obvious, why has it not been the solution first hand ?
Rumors tell that this was changed by POA Network after a first audit round ?
Or has it been the case that "send rewards to target address" has been the first solution ?!

Note that automatic reward restaking should be able to bypass the hard limit of 50k staked on one node: #80

TODO:
Implement testing: DMDcoin/honey-badger-testing#95

@SurfingNerd SurfingNerd mentioned this issue May 21, 2021
6 tasks
@SurfingNerd SurfingNerd changed the title redesigning reward payout automatic reward restaking May 30, 2021
@cryptonit
Copy link

prefered is restaking
staked amount is increased
each time u part if a reward distribution
once every 12 hours if the validat u stake on top is part if active set

the max total stake of validator of 50000 dmd will be ignored at automatic reward restake it can grow above 50k

@SurfingNerd
Copy link
Collaborator Author

Thesis to be confirmed or refuted for implementation:
For the block reward system call it is problematic to do transfers to contracts or regular accounts, because it would be a value transfer without a transaction.
Currently it is a block reward call as value transfer that includes a internal change of the reward contracts state.
This scenario might be a well supported standard scenario in EVM chains, while transfers, that are neigher the block reward transaction nor a regular (inner) transaction are not supported.

@cryptonit
Copy link

i agree a value cant leave the contract without a real transaction
this means a claim into user address must be a transaction

we should keep the way it works now but utilize bigger blockgaslimits to avoid multiple claims needed

@SurfingNerd SurfingNerd added the concept concept or idea with no planned timeframe, might get developed or dropped label Dec 22, 2021
@SurfingNerd SurfingNerd removed the concept concept or idea with no planned timeframe, might get developed or dropped label Mar 6, 2024
@SurfingNerd SurfingNerd assigned ghost Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

3 participants