From 99f6036a5c873949bef551f7ecaa358c9a9025cb Mon Sep 17 00:00:00 2001 From: Josh Hannan Date: Thu, 4 Dec 2025 10:15:54 -0600 Subject: [PATCH 1/4] add flip for automatic restaking --- .../20251205-enable-automatic-restaking.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 governance/20251205-enable-automatic-restaking.md diff --git a/governance/20251205-enable-automatic-restaking.md b/governance/20251205-enable-automatic-restaking.md new file mode 100644 index 00000000..fc074f54 --- /dev/null +++ b/governance/20251205-enable-automatic-restaking.md @@ -0,0 +1,40 @@ +--- +status: Proposed +flip: GOV-30 +authors: Joshua Hannan (joshua.hannan@flowfoundation.org) +editors: +--- + +# FLIP GOV-30: Enable Automatic Restaking of Staking Rewards + +## Abstract + +Enable core contract feature to automatically restake rewarded tokens for nodes and delegators each epoch instead of requiring stakers to do it manually. + +## Background + +Rewards to node operators and delegators are paid at the end of every epoch to each staker's reward bucket. Currently, these rewards will sit there until the user manually does something with them, either withdrawing or restaking them. This can be cumbersome to most stakers who simply want to continue staking their tokens every week. Many users over the years have asked for functionality to automatically restake their rewards for them. + +Flow originally decided to not include this feature out of an abundance of caution about crypto regulations. Given recent developments in the past five years related to crypto regulations, and especially considering that most other Proof-of-Stake blockchains support this feature with no negative repercussions, the Flow foundation is proposing enabling this feature following community discussion and voting. + +## Proposal + +When tokens are moved between buckets at the end of every epoch, for any given staker, transfer all their rewarded tokens to their staked bucket and update all the relevant staking metadata for that user. + +Because rewards are paid every epoch after tokens are moved between buckets, this means that staking rewards that are paid to users will still stay in their rewards bucket after they are paid every week. This will allow users who want to withdraw rewards every week instead of restaking them to still be able to do without having to wait for the 1-2 week unstaking period. We believe that this will be the least disruptive to any existing stakers who maybe doing something different than restaking every week. + +In addition to being a convenience for users, this will also ensure that there isn't unstaked FLOW just sitting in rewards buckets and will increase the total amount of FLOW staked overall, further securing the network. + +As part of the discussion of this FLIP, we will be sharing it with all the node operators in the network and posting in relevant social channels for other Flow users to see. We will get feedback from all affected parties to ensure that nobody is negatively affected by this change. + +If the FLIP is approved, we propose a staged rollout for automatic restaking on Flow testnet and mainnet as follows: + +| Date | Action | Status | +|-|-|-| +| Thursday, December 4th, 2025 | Publish FLIP and begin community discussion | :hourglass_flowing_sand: Pending | +| Wednesday, January 21st, 2026 | Assuming No pushback from community, mark FLIP as approved | :hourglass_flowing_sand: Pending | +| Wednesday, January 28th, 2026 | Enable automatic restaking on testnet | :hourglass_flowing_sand: Pending | +| Wednesday, February 4th, 2026 | Enable automatic restaking on mainnet |:hourglass_flowing_sand: Pending| + +## Resources +- From eab4465c8c1bae1991751347d5ffff9ff284a001 Mon Sep 17 00:00:00 2001 From: Josh Hannan Date: Thu, 4 Dec 2025 15:09:21 -0600 Subject: [PATCH 2/4] make automatic restaking more clear and add other options considered --- .../20251205-enable-automatic-restaking.md | 42 ++++++++++++++++--- 1 file changed, 36 insertions(+), 6 deletions(-) diff --git a/governance/20251205-enable-automatic-restaking.md b/governance/20251205-enable-automatic-restaking.md index fc074f54..f9d69153 100644 --- a/governance/20251205-enable-automatic-restaking.md +++ b/governance/20251205-enable-automatic-restaking.md @@ -1,11 +1,11 @@ --- status: Proposed -flip: GOV-30 +flip: GOV-353 authors: Joshua Hannan (joshua.hannan@flowfoundation.org) editors: --- -# FLIP GOV-30: Enable Automatic Restaking of Staking Rewards +# FLIP GOV-353: Enable Automatic Restaking of Staking Rewards ## Abstract @@ -13,17 +13,47 @@ Enable core contract feature to automatically restake rewarded tokens for nodes ## Background -Rewards to node operators and delegators are paid at the end of every epoch to each staker's reward bucket. Currently, these rewards will sit there until the user manually does something with them, either withdrawing or restaking them. This can be cumbersome to most stakers who simply want to continue staking their tokens every week. Many users over the years have asked for functionality to automatically restake their rewards for them. +[Flow Epochs and Staking Documentation](https://developers.flow.com/protocol/staking) + +Rewards to node operators and delegators are paid at the end of every epoch, which is once a week at the moment. Currently, these rewards will sit there until the user manually does something with them, either withdrawing or restaking them. This can be cumbersome to most stakers who simply want to continue staking their tokens every week and compound their rewards. Many users over the years have asked for functionality to automatically restake their rewards for them. Flow originally decided to not include this feature out of an abundance of caution about crypto regulations. Given recent developments in the past five years related to crypto regulations, and especially considering that most other Proof-of-Stake blockchains support this feature with no negative repercussions, the Flow foundation is proposing enabling this feature following community discussion and voting. ## Proposal -When tokens are moved between buckets at the end of every epoch, for any given staker, transfer all their rewarded tokens to their staked bucket and update all the relevant staking metadata for that user. +The Flow staking protocol maintains five buckets of tokens for each staker, listed near the end of [this document](https://developers.flow.com/protocol/staking/epoch-terminology): + +* Tokens Committed +* Tokens Staked +* Tokens Unstaking +* Tokens Unstaked +* Tokens Rewarded + +At the end of every epoch, committed tokens moved to staked, any unstaking requests move from staked to unstaking, and unstaking moves to unstaked. Rewards are paid after all these movements happen and are deposited into a staker's Rewards bucket. + +With this change, during this automatic token movement between buckets at the end of every epoch, for any given staker, the protocol will transfer all the tokens in their rewards bucket to their staked bucket. + +Because rewards are paid every epoch after tokens are moved between buckets, this means that each staking rewards payment will still stay in the rewards bucket for one week after they have been paid. This means: + +* Reward tokens that the staker's / delegator's does not withdraw from their rewards bucket into their account within one week will automatically be staked. Once the tokens are staked, they are subject to the standard 1-2 week unbonding period. + +* Users can withdraw (a portion of or all of) the rewards immediately within one week after the tokens have been rewarded. This moves the tokens out of the rewards bucket. Only the tokens remaining in the rewards bucket will be automatically restaked at the next epoch switchover. + +We believe that this will be the least disruptive to any existing stakers who may be doing something different than restaking every week. + +In addition to being a convenience for users, this will also ensure that there isn't rewarded FLOW just sitting in rewards buckets doing nothing and will increase the total amount of FLOW staked overall, further securing the network. + +## Other Options + +### Opt-in automatic restaking + +One option considered was making this feature opt-in, but this was decided against because the changes required for it would be cumbersome because of Cadence's upgrade restrictions with fairly small benefit. Also, because users still have a week to withdraw their rewards, they still have the opportunity to "opt-out" every week by withdrawing their rewards if they want. + +### Scheduled Transactions for Restaking -Because rewards are paid every epoch after tokens are moved between buckets, this means that staking rewards that are paid to users will still stay in their rewards bucket after they are paid every week. This will allow users who want to withdraw rewards every week instead of restaking them to still be able to do without having to wait for the 1-2 week unstaking period. We believe that this will be the least disruptive to any existing stakers who maybe doing something different than restaking every week. +Another option was to introduce [a scheduled transaction handler](https://github.com/onflow/flow-core-contracts/pull/564) that allows users to schedule transactions for themselves to restake their rewards. This also allows users to opt-in, but is unnecessarily complex for something that really should just be a built-in network feature. -In addition to being a convenience for users, this will also ensure that there isn't unstaked FLOW just sitting in rewards buckets and will increase the total amount of FLOW staked overall, further securing the network. +## Next Steps As part of the discussion of this FLIP, we will be sharing it with all the node operators in the network and posting in relevant social channels for other Flow users to see. We will get feedback from all affected parties to ensure that nobody is negatively affected by this change. From 7ce1b687e4075dfc1a07cd38f83db009eded82f2 Mon Sep 17 00:00:00 2001 From: Josh Hannan Date: Mon, 8 Dec 2025 14:34:15 -0600 Subject: [PATCH 3/4] add section about opt-out version --- governance/20251205-enable-automatic-restaking.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/governance/20251205-enable-automatic-restaking.md b/governance/20251205-enable-automatic-restaking.md index f9d69153..8497eb22 100644 --- a/governance/20251205-enable-automatic-restaking.md +++ b/governance/20251205-enable-automatic-restaking.md @@ -45,10 +45,12 @@ In addition to being a convenience for users, this will also ensure that there i ## Other Options -### Opt-in automatic restaking +### Opt-in/Opt-out automatic restaking One option considered was making this feature opt-in, but this was decided against because the changes required for it would be cumbersome because of Cadence's upgrade restrictions with fairly small benefit. Also, because users still have a week to withdraw their rewards, they still have the opportunity to "opt-out" every week by withdrawing their rewards if they want. +Another option could be to make this automatic by default, but allow users to opt-out by indicating that they don't want their rewards to be automatically restaked every week. This would still have most of the benefits described above, but would allow some users that maybe have unique tax considerations to have control over their rewards. It is also being considered as an option. + ### Scheduled Transactions for Restaking Another option was to introduce [a scheduled transaction handler](https://github.com/onflow/flow-core-contracts/pull/564) that allows users to schedule transactions for themselves to restake their rewards. This also allows users to opt-in, but is unnecessarily complex for something that really should just be a built-in network feature. From 48c5c3fc7a60d7a535f9e2e9a79d4a52ff1ae983 Mon Sep 17 00:00:00 2001 From: Josh Hannan Date: Mon, 8 Dec 2025 14:45:45 -0600 Subject: [PATCH 4/4] rework section for optin and optout --- governance/20251205-enable-automatic-restaking.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/governance/20251205-enable-automatic-restaking.md b/governance/20251205-enable-automatic-restaking.md index 8497eb22..206e8497 100644 --- a/governance/20251205-enable-automatic-restaking.md +++ b/governance/20251205-enable-automatic-restaking.md @@ -47,9 +47,19 @@ In addition to being a convenience for users, this will also ensure that there i ### Opt-in/Opt-out automatic restaking -One option considered was making this feature opt-in, but this was decided against because the changes required for it would be cumbersome because of Cadence's upgrade restrictions with fairly small benefit. Also, because users still have a week to withdraw their rewards, they still have the opportunity to "opt-out" every week by withdrawing their rewards if they want. +One option considered was making this feature opt-in, so users could choose whether they want this. -Another option could be to make this automatic by default, but allow users to opt-out by indicating that they don't want their rewards to be automatically restaked every week. This would still have most of the benefits described above, but would allow some users that maybe have unique tax considerations to have control over their rewards. It is also being considered as an option. +Another option could be to make this automatic by default, but allow users to opt-out. + +Both of these options would still have most of the benefits described above, but would allow some users that maybe have unique tax considerations to have control over what is done with their rewards. It is also being considered as an option. + +One potential problem with allowing users to choose is that Cadence's upgrade restrictions make including this quite cumbersome. We would have to create a separate record from the existing staking records that are accessed separately from the other records, which, with the large number of existing stakers, could significantly affect the performance and cost of existing epoch operations. We would like to avoid this for the protocol and users if possible. + +Additionally, users still have a week to withdraw their rewards, they still have the opportunity to "opt-out" every week by withdrawing their rewards if they want. + +### Longer Period between Restakes + +If one week feels like it is not enough time to give users to decide whether or not to restake or withdraw, it is possible to extend this to any arbitrary number of weeks between restaking. If a month or more is preferable, this could be included and would not affect performance and cost like making the feature opt-in or opt-out would. ### Scheduled Transactions for Restaking