feat: Staking reward generation through inflation #757
Conversation
valeriyr
added
the
sc-platform
valeriyr
force-pushed
the
l1sc/issue-153-staking-reward-through-inflation
branch
from
426c484 to
9f2b264
Compare
valeriyr
force-pushed
the
l1sc/issue-153-staking-reward-through-inflation
branch
from
0486b8d to
55cd94c
Compare
…king-reward-through-inflation
…king-reward-through-inflation
…nd_reinvestment removed)
…king-reward-through-inflation
…_rewards removing, 100% refund
| // Stake Subsidy parameters | ||
| pub stake_subsidy_start_epoch: u64, | ||
| pub stake_subsidy_initial_distribution_amount: u64, | ||
| pub stake_subsidy_period_length: u64, | ||
| pub stake_subsidy_decrease_rate: u16, | ||
|
|
||
| // Validator committee parameters |
There was a problem hiding this comment.
Could it be an easier option instead of removing the stake_subsidy related stuff, just to configure it not to generate rewards?
There was a problem hiding this comment.
I don't think we intend to reuse the stake subsidy fund at any point in the future. So I think removing it is the best option, otherwise it becomes technical debt immediately. Or am I missing your point?
There was a problem hiding this comment.
I think you are right, we do not need it.
Removing this entity affects a lot of code and seems like it can be disabled, so I thought that it was better to remove it later as a separate task when we have inflation tests ready.
We also need to clean GenesisCeremonyParameters from the subsidy stuff.
There was a problem hiding this comment.
Yeah, by now I already removed a lot of subsidy related stuff, but not all. If the current state works without removing more, we can remove the rest later - I already mentioned this in the PR description as a later task for which we should create issues.
| pub stake_subsidy_fund_nanos: u64, | ||
| pub funds_to_burn: u64, |
There was a problem hiding this comment.
Theoretically, we can get rid of this variable if we mint all token allocations on the Move layer.
The flow could be:
- "Burn" all migrated IOTA tokens that need to be allocated to validators/addresses.
- Initialize the IOTA TreasuryCap supply with something like this: TOTAL_SUPPLY - TOKEN_ALLOCATIONS.
- Mint allocations in the
genesis::createfunction.
In the case of clean/vanilla genesis just mint tokens without initial supply.
| @@ -79,7 +73,8 @@ module iota_system::genesis { | |||
| /// all the information we need in the system. | |||
| fun create( | |||
| iota_system_state_id: UID, | |||
| mut iota_supply: Balance<IOTA>, | |||
| iota_treasury_cap: TreasuryCap<IOTA>, | |||
| iota_supply: Balance<IOTA>, | |||
There was a problem hiding this comment.
This balance also could be removed if we just mint the required tokens.
Description of change
Changed
Outstanding TODOs Post-PR
AuthorityState.SystemEpochInfoEventfor informational purposes.Builder::validate_output(in genesis-builder) for newly introduced fields.IndexedEpochInfostill has stake subsidy related fields.GenesisCeremonyParameters.Outstanding PR tasks
// unless already in place. Check distribution is correct
v0hasvalidator_target_reward: 0set by default.Open Questions
v0analogously in addition tolatest?Links to any relevant issues
fixes #153
Type of change
Choose a type of change, and delete any options that are not relevant.
How the change has been tested
TODO