Note that this proposal would not enable the activation of Adaptive Issuance, nor extend the proposed Staking mechanism to delegators – that is, as it is the case with the Nairobi protocol active on Mainnet, only bakers can put funds as stake.
The business logic inherited from the original Oxford proposal implementing these features will be set behind a disabled feature flag.
Our focus has been to work on improving the UX of the new Staking mechanism for bakers, fixing the issues reported with slashing in the original Oxford proposal, and improving balance updates so that they report more meaningful information to upstream infrastructure (e.g. block explorers or wallets).
At this point, the team would like to share the following documents with the community in order to gather feedback on the design (of a subset of the) proposed changes.
Draft: O² Staking – describes our strategy to introduce the new Staking mechanism for bakers in the code base while preserving as much of Nairobi behavior as possible.
We kindly ask you to use this thread to provide feedback, ask questions, and raise concerns.
Note that these documents describe work in progress and are updated as the implementation evolves and as a result of this feedback.
Just a question: why 7% and not any other value, for double baking?
Staking
I’m not sure I understood properly, so please correct me if I’m wrong (I’m taking risks here by putting my credibility at stake ): with O², the staked-frozen amount directly depends on the baking power, thus on the amount delegated by others. But in case of private baking (no delegators) or just to ensure a minimal baking power when underdelegated, it will be possible to delegate to self (autostaking)?
For example, if my baker has 10 000 XTZ but only one delegator of 1 000 XTZ, my baker’s staked-frozen amount will by default be 100,XTZ and its baking power will be based on 1 100XTZ. But if I make my baker to autostake, we’ll end up with a baking power based on 11 000XTZ unless a lower deposit limit is set.
Is this right? Sorry if this does not make any sense, this is just what I understood.
Also, set_deposit_limit will be kept unchanged as Adaptive Issuance and Staking (formerly co-baking) features will remain disabled for now?
Should I got it properly, these sounds good, no further comments.
Thanks a lot for sharing these documents, that’s really helpful !
The voting mechanism will still be here, but the EMA will not be able to activate Adaptive Issuance, and it will be reset to 0 at the start of the next Protocol, so it will have no effect in Oxford 2.
About the motivation for 7% for double baking slashing:
It is the value that we think makes sense to both keep the security high and fair with respect to the bakers.
For staking, what autostaking means is that the new staking mechanism will be used automatically to ensure that the behavior from Nairobi is preserved. In Nairobi, the amount of frozen tez was proportional to the delegation, from the baker’s own funds and its delegators. In Oxford 2, it will be the same.
With your example, a baker with 10k XTZ and 1k from delegation will automatically have 1100 XTZ staked, which would have been the amount frozen in Nairobi.
Regarding rights, it will also be the same, everything that is not overdelegated will contribute to the baking rights, as it was before.
And finally yes, set_deposit_limit will indeed be kept unchanged
Thank you for sharing these documents. We have reviewed them. Regarding slashing, it’s good to see the decreasing amount for double backing from 10% to 7%.
Concerning O² staking, is this the final version, or do you anticipate making further adjustments to this mechanism in the future?
Also, am I correct that there will be a change from frozen deposits to a staked-frozen amount in O² ? So, the tokens will be staked instead of being locked?
The O² staking document describes the staking mechanism as it is currently implemented for Oxford 2 proposal, with minor differences as there will be no switch to manual staking so only automatic staking will be in our proposal. We will update the document next week, and will make a comment here.
In Oxford 2, the staking for Bakers will preserve the behavior of Nairobi, you should have nothing to change in your setup.
If Oxford 2 is voted by the bakers, we might make other proposals built upon it, any of such proposals will be discussed in a feedback loop to make sure they are made with the community.
In particular, it would be the case if we propose a staking mechanism that allows staking from non baker.
About a change from frozen deposits to a staked-frozen amount in O²: it is just a question of vocabulary, but there are the same things.
In terms of implementation, the team chose the simpler and less time-consuming solution to disable the per-block voting feature.
It’s already disabled and disabled in a simple way.
One more point we want to discuss:
While the slashing parameters have seen reductions, we believe they remain high, posing considerable risks for bakers. Instances of slashing in Tezos are very rare. So, elevating these parameters from 640 tez to 7% for double-baking amplifies risks, possibly resulting in increased commissions by bakers which means which means users will pay for the risks. Is there potential for reducing the slashing parameters to 5% instead of the current 7% parameter suggested in Oxford2?
@zaynah in terms of implementation it takes one additional line of code to make EMA static/non moving. In a simple way as you said. Why not do that?
@Anna can you elaborate how you did you get the 5%/why 5%? Double bake is not common situation. It happens only if you did something wrong or if you are double baking willingly. Personally I would expect the number to be much higher.
No need to investigate on what it would cost to implement this, but in a perfect world we would see slashing as incremental to allow one mistake to be made (accidents happen, when trying to set up a failover instance for example) but to punish recidive.
However, this is so rare that this doesn’t deserve so much work, at least for now.
For a fixed penalty, 5% looks low to us too, but that’s way better than the former 640 XTZ which is nothing for a big baker but a lot for a very small one.
We are currently seeking a harmonious consensus between the initially set value of 10% and the revised 7%. However, even with this reduction, the associated risks remain notably heightened at 7%. Therefore, our proposal aims to mitigate these risks. It’s essential to note that a 7% value holds significance for both big and small bakers alike.
Anna, when you speak of risks, do you mean the risk of baking twice accidentally during a maintenance operation or anything similar? Everstake is not a small bakery, so I expect your team to handle redundancy, which is where the risk could come from, but is my assumption right?
Thanks for the fruitful discussions and feedback. Oxford 2 in a Nutshell - Google Docs describes the main changes in the Oxford 2 proposal (staking parts), it also contains links to the updated technical documentation shared above.
We added a document O2 receipts - Google Docs that goes into more details on receipts in Oxford 2.
Since the Frozen Deposit is no longer in effect, I am trying to determine how much of a balance I should maintain to optimize my validator service to not lose out on rewards. Is there a formula that I can use to guide my balance management?
So, I was using tzkt.io’s “Frozen Deposit” to guide my required amount. There was a short time after moving to the Oxford 2 protocol upgrade that TzKt’s “Frozen Deposit” was not populating and was broken. This has since been fixed, so please ignore my post above!
): with O², the staked-frozen amount directly depends on the baking power, thus on the amount delegated by others. But in case of private baking (no delegators) or just to ensure a minimal baking power when underdelegated, it will be possible to delegate to self (autostaking)?
