Baking and the Oxford Proposal: A Technical Guide

TL;DR: The Oxford upgrade proposal contains changes that affect the workflow of bakers. This blog post covers what to be aware of if Oxford is activated.

• NB 27/03/2024 The features described in this documment have not been included in the Oxford 2 protocol, currently active on Tezos Mainnet. See Oxford 2’s announcement for further detail. The Paris protocol proposals implement revisited version of these features.

The Oxford protocol proposal currently going through Tezos’ on-chain governance process contains several changes that affect not just staking economics, but also how bakers operate.

The most significant changes are subject to a separate vote and will only be activated later, provided they are accepted. However, other changes affecting bakers will take effect immediately after activation, if the Oxford protocol is adopted.

In this blog post we highlight what Tezos bakers should be aware of, and the necessary steps to take for ensuring a smooth transition.

Adaptive Issuance and the new staker role

Adaptive Issuance is a new approach to staking economics on Tezos, adapting the network’s emission of its native token, tez, to fit better with real-world usage. For a deeper dive we recommend our blog post introducing Adaptive Issuance.

Adaptive Issuance will not be automatically enabled upon activation of the Oxford protocol. Instead, bakers will be able to vote using a configuration option when running the baking software. This process is described in detail further below.

Adaptive Issuance also introduces the role of staker, in addition to the existing roles of baker (or delegate) and delegator. However, no account can become a staker unless Adaptive Issuance is voted in by the additional vote.

Changes in a baker’s workflow

In order to ease the potential transition to Adaptive Issuance, additional changes have been included in the Oxford protocol proposal¹, which will take effect immediately from the protocol proposal’s activation.

They do not affect baking/attestation rights or rewards, but they affect the actions required to operate a baker. These changes are:

• No more automatic freezing and unfreezing. Currently, the protocol regularly adjusts the baker’s frozen balance to accommodate for variations in their delegated balance. With Oxford, bakers may adjust their staked balance (which is frozen) via new explicit “stake” and “unstake” operations. This gives them more control, as the protocol will never move tez from their spendable balance without the baker explicitly signing an operation for it.
• Changes to slashing. Double-baking penalties are changed from a fixed sum of 640 tez to 10% of the staked balance². Denunciation rewards (for double-baking and double-attestations) are reduced from one half to one-seventh of the slashed funds.

We also remind bakers that the “endorsement” and “preendorsement” operations are renamed “attestation” and “preattestation”, respectively. This can affect API calls or automated log review setups.The renaming is due to the fact that a baker does not actually endorse a block as much as attest to its existence and validity, which this new terminology makes clear. This change was initiated in Nairobi and is completed with Oxford.

Transitioning from Nairobi to Oxford

A smooth transition to Oxford requires bakers to take steps which they are familiar with from previous protocol upgrades. In this case:

• Update to Octez v18.
• Run both Nairobi and Oxford bakers (and accusers) in parallel at the time of activation. The former will automatically stop participating in consensus, and the latter will take over.

There is no requirement for bakers to take further immediate action in order to continue baking after activation, but some changes need to be taken into consideration for optimal operation of especially public bakers in the longer term.

Frozen deposits become stakes

Upon activation of Oxford, the frozen deposit of existing bakers will be preserved and the same amount will become the baker’s stake.

The baking and attesting rights are calculated in a similar fashion as before:

• Rights are proportional to the baker’s delegated balance, that is, the baker’s own balance plus the balance of all their delegators.
• Rights from delegations are capped at 9x the baker’s own staked balance. Above that, the baker is overdelegated, and any additional delegation does not bring additional rights or rewards.

However, while previously the frozen deposits would automatically adjust to the delegate’s total balance, in Oxford the staked balance does not. This will require manual adjustments.

How to manage stake

Oxford introduces a series of new commands for managing a baker’s staked balance.

Adding tez to the stakebalance is done by executing this CLI command:

octez-client stake 2000 for <baker_key>

This will make 2000 of the baker’s spendable tez immediately unavailable for transfer, and the amount will be included in the computation of baking rights after 6 cycles.

Reducing the staked balance is done with this command:

octez-client unstake 2000 for <baker_key>

If a baker wishes to stop baking, they may bring their stake to zero:

octez-client unstake everything for <baker_key>

After executing unstake commands, the baker must wait for an unfreezing period of 7 cycles. During this time, the amount in question is no longer taken into account to determine baking rights, but is still subject to slashing. Afterwards, they need to finalize their unstake operation with the following command:

octez-client finalize unstake for <baker_key>

Note that these operations are pseudo-operations: a transfer operation, but where the destination matches the source. Therefore they must be signed by the baker’s manager key and not the consensus key.

New bakers must explicitly stake

Up until now, an account could become a baker by using just this command:

octez-client register key <baker_key> as delegate

Under Oxford, it is no longer sufficient just to register as a delegate to start baking. It results in no tez being added to the staked balance and hence no baking rights being assigned.

The baker needs to subsequently run the stake command in order to stake at least 6,000 tez, before they will have rights assigned to them:

octez-client stake 6000 for <baker_key>

Set deposits limit operation is removed

Prior to Oxford, baking rewards have accrued to the spendable balance. But at the end of every cycle, the protocol automatically increases or decreases the frozen deposit based on the variations of the delegated balance.

To avoid public bakers risking all of their balance being frozen, with no tez left to pay their delegators, it has been possible to set an upper bound for the frozen balance. This is known as the deposit limit.

In Oxford, the staked balance is always set explicitly, and therefore the “set deposits limit” operation is deprecated.

Adjusting stake as balance changes

Baking requires at least 10% of the total balance staked to maximize rewards. But as the Oxford protocol does not freeze/unfreeze tez automatically, it is the responsibility of the baker to adjust as needed.

As baking/attestation rewards are received, the total balance increases over time. Therefore, it is advisable for a baker without delegators to have a staked balance slightly above 10%, and to adjust it upwards from time to time³.

Note that if Adaptive Issuance is later activated, going above 10% staked will increase rewards, due to staked funds counting twice as much as (self)delegated funds in calculating baking rights and voting power. Hence, staking 100% will generate more rewards than 10%. But until Adaptive Issuance activates, going above 10% will only increase funds at risk of slashing without increasing rewards.

Bakers accepting delegations will want to set their staked balance high enough to leave room for new delegations, while still keeping it below their total balance, so they are able to pay out rewards. A baker can accept up to 9x their staked balance before being overdelegated.

Activation of Adaptive Issuance and new staking mechanism

The activation of Adaptive Issuance and the new _staker _role is decided in a separate signaling vote, which begins if and when the Oxford proposal is activated.

Bakers will be able to vote ‘On’ (in favour), ‘Off’ (against), or ‘Pass’. Abstaining from explicit signaling will have the same effect as a ‘Pass’ vote.

Before voting, bakers are invited to first familiarize themselves with Adaptive Issuance. Should they want to vote in favor of its activation, they must pass the following parameter when running their Oxford baker:

—-adaptive-issuance-vote on

To vote against activation:

—-adaptive-issuance-vote off

To explicitly vote pass:

—-adaptive-issuance-vote pass

The signaling vote is driven by an Exponential Moving Average (EMA) whose half-life is 2 weeks. That is, it takes two weeks for the EMA to raise from 0% to 50% assuming that only On votes are cast. The target threshold is a supermajority of 80% ‘On’ votes out of all ‘On’ and ‘Off’ votes.

The signaling vote has no time limit and continues to run, as long as the threshold is not met. There is also no quorum. Lack of participation (equal to ‘Pass’ votes) is not taken into account by the EMA, and hence only affects the time required to reach the threshold⁴.

If the threshold is met, the Voting phase will complete at the end of the current cycle, and an Adoption phase lasting 7 cycles (about 20 days) will begin.

Oxford on test networks

The protocol-specific ‘Oxfordnet’ test network is now active and available for you to test the new CLI commands. Adaptive Issuance has been enabled on this network, so the distribution of baking rights and reward amounts will differ from the focus of this blog post: the time period where Oxford protocol is activated, but where Adaptive Issuance is not activated.

Should Oxford be voted in during the Promotion Period, the permanent Tezos test network, Ghostnet, will upgrade to Oxford one to two weeks before mainnet. Adaptive Issuance will be off on Ghostnet until voted in by Ghostnet bakers. Ghostnet bakers are recommended to signal vote for Adaptive Issuance being kept ‘Off’ for the time being, so as to mimic mainnet.

Questions?

The Oxford protocol proposal represents a major change to Tezos staking, and it’s natural that questions arise. We invite you to ask questions on the Tezos Stack Exchange, and label them with the tag ‘adaptive-issuance’. This way, we will build a community-driven, collaborative knowledge base on the topic for all to benefit from.

For further information on Adaptive Issuance and other changes brought about by the Oxford protocol proposal, consider the following resources:

Announcing Oxford, Tezos’ 15th protocol upgrade proposal (Nomadic Labs)

Adaptive Issuance and Staking (Nomadic Labs)

A Walkthrough of Tezos’ New Staking Mechanism (Nicolas Ochem / Oxhead Alpha)

Understanding “Adaptive Issuance” In Less Than 10 Minutes (Cryptonio.tez / Tezos Commons)

Special thanks to Nicolas Ochem for his contributions to this blog post.

Notes