In our previous articles, we described many features that our team has been exploring: Adding Support for the Pairing-Equipped Elliptic Curve BLS12–381, Enhancing Baking Accounts, and Stateful Baking Accounts. In this article, we are sharing details with the community about another feature our team has been exploring: the delegation toggle.
This brief article starts by sharing the background and motivations behind this feature and is then followed by a high-level description of the design of the delegation toggle.
Before proceeding, if you are not yet familiar with concepts that Tezos Liquid Proof-of-Stake (LPoS) entails, such as security deposits or overdelegation, we recommend taking a look at the following articles:
Currently bakers do not have any method on chain for indicating whether they are accepting new delegations or not. This results in bakers relying on off-band tools (their website, Twitter, or public platforms such as Reddit or Telegram groups) to communicate and coordinate with their delegators on updates about their bakeries, such as whether they are currently accepting new delegations or not.
Similarly, this is also the case when a baker and a delegator wish to reach an agreement on the sharing of rewards, as well as other terms such as the rewards distribution schedule, since a simple on-chain delegation transaction does not specify nor enforce the basic terms of the service. In other words, a simple delegation transaction on-chain does not necessarily entitle the delegator to receive rewards of any kind.
Off-band coordination tools like the above not only lead misconceptions around baking services, but also to usability problems between bakers and delegators. For instance, in the event of delegators missing the fact that the baker is overdelegated, it would result in the delegator only finding out later on why they did not receive the rewards– which creates a lot of room for dissatisfactory experiences for bakers and delegators.
While keeping the caveat of a simple on-chain delegation transaction does not entitle the delegator to receive rewards in mind, a possible feature that could provide more flexibility for the baker, as well as higher clarity for the delegator is the delegation toggle.
Broadly speaking, the delegation toggle is managed by the baker and has two possible states:
- When the toggle is
on: it means that the baker accepts new delegations. Note that the default toggle value will be
- When the toggle is
off: delegation transactions to this baker will be rejected. A typical use case of setting the toggle to
offwould be when a baker is overdelegated or, due to technical or operational reasons, wishes to not accept new delegations*.
*It is important to note that overdelegation only happens at the point of creating a block and not before, since only at that point does the baker need to have enough XTZ to allocate to the security deposits.
Under the hood, the delegation toggle state is stored on the chain. Before a delegation operation is applied, the protocol performs a check on whether the baker whom the delegation transaction is pointing to is accepting new delegations or not (yes if the toggle is
on; and no if the toggle is
off). In the event a baker that has set the delegation toggle to
off receives a new delegation, the delegation operation will simply fail.
An important caveat is that even when the delegation toggle is set to
off, existing delegators can still increase the balance in their delegated accounts, increasing the number rights that the baker receives.
Integrating the Delegation Toggle
The default delegation toggle state is
on (new delegations accepted) for all existing and newly activated bakers. Should a baker wish to set the delegation toggle to
off (not accepting delegations), the baker will have to submit an operation (a type of transaction). The delegation toggle state can be changed from
off as many times and whenever the baker wishes to and it becomes effective as soon as it is applied. Should this feature be adopted, the
tezos-client will support a command through which bakers can set their delegation toggle state.
The above solution can be integrated with existing tooling for bakers, wallets and explorers. For instance, wallets that support staking and block explorers that display information about bakers could present a new data point corresponding the state of the delegation toggle for each baker.
Currently bakers do not have any method on chain for indicating whether they are accepting new delegations or not. A possible feature that could provide more flexibility for the baker, as well as more clarity for the delegator, is the delegation toggle. The delegation toggle is set by default to
on (delegations accepted) and a baker can set their delegation toggle to
off (not accepting new delegations) and vice versa anytime by submitting an operation.
Should this feature be adopted by the Tezos community, bakers will be able to manage their delegation toggle state via the
tezos-client command-line tool. Furthermore, this feature is designed to be integrateable with baker tooling, wallets, and block explorers.
Final Remarks & What’s Next?
In order to continue facilitating more community involvement in the protocol development process, the delegation toggle feature will be available on upcoming public testnets. This way, different user groups can interact with and test the features beforehand.
Additionally, a detailed changelog and documentation describing the modifications introduced by each feature, including but not limited to the delegation toggle, will be released in the upcoming weeks.
In the meantime, we would like to use this article as research synthesis and discussion reference, in addition to opening this topic for discussion on:
- Tezos Agora: Delegation Toggle Topic
- Core Protocol Development AMA on the 26th of May 2020, from 18:00 to 20:00 CEST / 16:00–18:00 UTC , with members from Nomadic Labs, more contributors and our Team participating. (Thanks Tezos Commons and TQ Tezos for facilitating!)
- Metastate’s official website for more information on current projects and organization
- Metastate’s research blog
For feedback or questions, please do not hesitate to contact us : firstname.lastname@example.org