Feedback Request for 'R' Protocol Proposal

  • Cycle length is reduced to 1 day

I think this will help a fair bit, particularly with onboarding new users, who have always struggled to understand measurements given in cycles. This added a layer of complexity/confusion to new users. I think we have an issue with frontends needing to be updated when this goes live though.

For example, when adding info about staking/unstaking users don’t understand cycles so apps will have given info/instructions in terms of days (e.g. “~11 days to unstake”). Currently the constants RPC (…/chains/main/blocks/head/context/constants) does not have a constant to say that unstaking takes 4 cycles. So its never been possible to automate this display to end users.

Before pushing this change live, I would ask that we do a pass on the constants RPC and ensure that everything that needs to be there is in there. So that in the future any more changes like this could be automatic and not impact frontends

2 Likes

I have long said that it would be better to focus on an even number of hours or days for the cycle, even if it is approximate, but it is better for understanding time periods on the network. And once again I will repeat that 1 day for the cycle is too little and too early. Start with 2 days, see how it goes. Then you can reduce it to 1 day if everything is ok.

1 Like

Given that bakers have full discretion on when they pay delegators, does it not matter too much how long the cycles are?

Bakers can choose to pay daily, weekly, etc - all marketing/operational decisions for how they manage their payment schedules & configure the tools used to pay delegators.

If payment cycles are set to be longer than reward cycles and If the balances in baker’s reward holding/payment accounts are also delegated, that could even lead to an additional revenue stream due to bakers holding onto unpaid reward balances for longer.

5 Likes

Hello, dear Tezos community!

As one of the largest bakers, we are always eager to support initiatives that foster positive changes in Tezos, aligning with our goal of a promising future and continuous network improvement. Below are some of our thoughts and concerns regarding this proposal:

  1. 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.

  2. DAL Rewards Activation: To activate DAL rewards, 66% of all bakers must implement DAL? 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.

  3. 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.

We appreciate the opportunity to provide feedback and look forward to discussing these points further.

4 Likes

What it we don’t achieve the 66%? I just think about the initial plan to attract 50% stake for adaptive inflation but we keep hanging ~20%. What to do in a similar case for the DAL? Can rewarding DAL node operators with an adaptive incentive as well? One that goes down if we reach the 66%?

In the current model, if 66% of the baking power doesn’t attest available slots, the DAL does not work. It is not possible to adapt the rewards in this sense.

Or, I’m just thinking out loud here: Reward early adopters! Avoid raising inflation and reward them with shares of projects in the Tezos Ecosystem. Maybe with Uranium (even though I’m not a fan of it) or NFT’s with recognizable value.

@Tezosnodes

yes, it is certainly a good idea not to fine but to reward, for example, as in other networks. In AVAX, for deploying an additional node, the validator receives a premium or bonus and thus they reach the required number of nodes. This is better than fining

We could consider a different incentive for early adopters, and we will take this and other similar suggestions into account. However, these extra bootstrapping incentives imho should always be separated from the incentive mechanism.

5 Likes

I respect your point of view, but disagree on taking funds from liquidity baking. With the enhancements being made to tzBTC, specifically the increased ease in wrapping Bitcoin, there is a a good chance that participation in liquidity baking will increase. That liquidity is needed to incentivize participants.

We need to leave liquidity baking alone for maybe another year and see how the tzBTC enhancements play out.

3 Likes

Indeed the duration of this period is defined in terms of other constants, so it is not naturally exposed by such RPC endpoints. Thanks for the suggestion.

5 Likes

AFAICT the protocol doesn’t force a baker to make payments in line with cycles. In addition, Everstake’s published Terms of Service does permit it to vary the terms of the services offered to its users without notice.

4 Likes

I want to revisit the concept of Liquidity Baking under the R protocol. While concerns about inflation are valid, I believe the impact is minimal. The tez minted for this purpose represents a small fraction of the total supply and delivers significant benefits, like increased liquidity and improved utility for the ecosystem. It’s a strategic trade-off that supports Tezos’ growth and long-term value.

2 Likes

What is the impact on node operators in rolling and full history modes when the cycle duration is shortened?

For example, I understand that nodes operating in full or rolling mode provide certain information up to the “savepoint.” If the cycle duration is shortened, does this also reduce the amount of time that information is available from a rolling or full node?

1 Like

Hi @Anna thanks for reaching out.

  1. 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.

  1. 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.

5 Likes

Let me just restate the most important point from my earlier post so it doesn’t get lost in minutia.

As far as optics and feelings go, wouldn’t it be better to at first give bakers that reach the 66% threshold a 10% bonus in R? Then in a later protocol, this can be changed to be a 10% penalty for bakers that don’t run it.

This way, we’re activating the DAL on a positive note and eliciting greater participation initially.

6 Likes

I’m confused as to how we’re supposed to reach 66% stake running DAL if there aren’t any penalties nor rewards untill we actually reach it.
Am i missing something?

Also is it 66% of all tez? Or 66% of the current stake, meaning 66% of ~20%?

3 Likes

Thank you all for having participated in this first round of feedback for the “R” protocol proposal. Your input and suggestion is quite welcome, and will increase the quality of our final proposal.

Based on the discussions so far, we have decided to make the following adjustments to our proposal:

  • Reduced tolerance to baker inactivity. Based on the feedback received in this thread, we will adjust the proposed value of the new TOLERATED_INACTIVITY_PERIOD constant to 2 cycles instead of 1 cycle, as originally proposed – that is, about 2 days instead of 1 day. This change aims to provide more leeway for bakers who cannot immediately react to technical issues, regardless of the time of the day or the day of the week they occur.

  • Exporting derived periods lengths via RPC. Based on feedback by @simonmcl and other ecosystem members, we plan to extend the chains/<chain>/blocks/<block>/context/constants RPC endpoint to expose periods usually defined in terms of CONSENSUS_RIGHTS_DELAY. This includes unstake_finalization_delay as requested, but also a few similar fields: like issuance_modification_delay for the Adaptive Issuance curve, and consensus_key_activation_delay for managing consensus keys. Please don’t hesitate to reach out or comment in the thread to suggest other similar endpoints which could simplify the development and maintenance of ecosystem tooling.

  • DAL (slashing). Taking in consideration the feedback from this thread, and in consultation with other ecosystem actors and stakeholders, we have decided to modify the slashing mechanism associated with the DAL in protocol R so that misbehaving bakers would only forfeit their DAL rewards from that cycle, but would not see their stake (nor their stakers’) slashed. We believe that this change would ease the adoption of the DAL on Tezos mainnet and address baker concerns regarding the novelty of the mechanism.

  • DAL (participation rewards). In protocol proposal R, the DAL requires indeed 66% of the baking power to attest each published slot. If this threshold is not met in a cycle, the DAL is not considered active, and hence no share of participation rewards is allocated to the DAL. If the DAL is active, a 10% of participation rewards from that cycle will be allocated to DAL rewards, and sufficiently participating bakers will receive their share of rewards. Note that DAL participation rewards would become part of the adaptive rewards and would therefore be shared between the baker and its stakers – and potentially its delegators.

We are still evaluating other suggestions received so far and look forward to considering further feedback.

Thank you all for your valuable contributions!

10 Likes

A quality-of-life improvement for bakers who pay delegation rewards would be the ability to direct these to an account of their choice, can we please add this to R?

I wrote about it in more detail:

4 Likes

Agreed. It would be nice not to have to manually transfer funds from my baker account to my payout account every cycle. Delegation payouts otherwise can be fully automated.

1 Like

Thanks for the update and listening to the community. One thing stays however unclear.
If we need 66% of the baking power to activate the DAL:
As long as the DAL is inactive, all rewards are distributed as usual.
As soon as the DAL is active, all bakers who are not participating receive 10% less than before.
So IMO the easiest way not to get punished (receiving 10% less) is not to run a DAL node.
Running the DAL for the greater good might be enough incentive for some but will it be enough for 66%?
How do we get bakers to participate?

2 Likes

a point of failure is needing to have the ledger plugged into the machine during baking, as it can pin lock. would be great to have ledger authorize a baking key that sits on the baker but cannot be used to drain funds in case of hacking.

1 Like

I understand this request as a request to remove the power to “drain delegate” from the existing implementation of consensus keys.

Note that since the introduction of the new Staking mechanism, the drain delegate operation can only affect the baking key’s liquid/available funds, limiting significantly the impact on bakers – the consensus key cannot stake/unstake tez nor finalize unstaked tez, only the baking key can.

2 Likes

I understand this request as a request to remove the power to “drain delegate” from the existing implementation of consensus keys.

…and removing it does not provide much benefit anyway. Anyone with access to the consensus key can drain your funds through double baking or double attestations. Therefore, drain removal is merely an illusion we may wish to believe in, but it will not save us in a time of need.

3 Likes