Hi @Anna thanks for reaching out.
- Shorter Cycles: While shorter cycles enable more frequent payments, they also introduce higher transaction costs (approximately three times higher, as cycles decrease from 2.8 days to 1). Additionally, this change increases the operational workload for DevOps teams, because bakers will have to pay rewards every day.
I understand that at the scale of a baker with 60K delegators, potentially increasing 2.8 times the payouts generates a bit of extra work, and it might have a larger operational impact than on smaller bakers. As for the fees, do you have an estimate of their impact? Our intuition is that the increase in net costs should not be significant for large bakers (nor smaller ones), but we are willing to revisit our hypotheses if that’s not the case.
We believe that shortening the cycles should further boost the conversion of delegators to stakers, eventually reducing the number of necessary delegator payouts. That said, as others have suggested in the discussion, there is no protocol-mandated obligation to distribute delegation rewards every cycle, and some bakers already pool delegation payouts and or include them in their own blocks to avoid fees. There is also the option to adjust delegation fees accordingly.
In terms of operational impact, we look forward to continuing discussions on how we can streamline delegator payouts both from Octez/protocol side, as well as from improving existing tooling.
- DAL Rewards Activation: To activate DAL rewards, 66% of all bakers must implement DAL?
In the current model, the DAL requires 66% of the baking power to attest published slots. If we don’t reach that participation threshold, there is no activity, and hence the DAL incentive does not activate.
And if the proposal passes, there is a significant risk of delays, as many bakers may wait for others to adopt DAL first, avoiding infrastructure costs before rewards activation. Do we understand this correctly? Please provide more details regarding the activation.
This is indeed why we are engaging with bakers early, and we want to make sure bakers start adopting and deploying DAL infrastructure on mainnet before the potential activation of the protocol “R”. We currently have a working DAL on Ghostnet, with a large supermajority of the stake backing it. This was achieved thanks to a close cooperation of core teams and many community bakers. We will continue launching such initiatives to make sure bakers are ready to deploy the DAL on mainnet – as a matter of fact, some bakers already deploy DAL nodes on mainnet today.
Reduced Unstaking Period: While a shorter unstaking period encourages users to stake directly rather than delegate—especially given the economic adjustments in previous proposals—it could also make staking too liquid.
I don’t think there is a risk of making staking too liquid, as all the other periods that depend on cycle length are also reduced accordingly: the untasking wait remains longer than the wall-clock time required to adjust baking rights and, crucially, slashing windows. Moreover, the issuance mechanism keeps their cycle-determined parameters, so it is equipped to react to shorter unstaking periods.
We believe that a minimal locking period of at least 4 days is then more than sufficient, and it would also attract more stakers, as the current locking period of ~10 days might be a deterrent in periods of market volatility.