TZIP + Feature proposal: consensus key

@G_B_Fefe and myself have been working on a protocol proposal called consensus key and would like to suggest it for inclusion in protocol K.

It allows a Tezos baker to use a separate key (the consensus key) to bake and endorse blocks, and rotate it at will, enhancing their operational security.

One version of the Florence protocol was doing something like this but it did not get voted in. Our proposal has key differences. It is minimalist by design and implements nothing but the consensus key:

  • it does not let smart contacts be bakers,
  • it does not change the 10% ratio of self-stake to total stake, or pave the way to doing so,
  • it introduces no breaking changes.

More details in the links below:

Last time, some community members were adamant that the consensus key should be spendable (see discussion). But in our proposal, the account associated with the consensus key has its own balance separate from the baker’s balance. Therefore, we introduce a new Drain_delegate operation that lets the consensus key transfer all the free balance of the baker to themselves. Effectively, this makes the consensus key spendable.

We also introduce a new governance toggle to allow a majority of bakers (by stake) to disable this Drain_delegate operation later, shall they prefer the consensus key not being spendable.

If the community’s position has changed, we can also resubmit a simpler version of this proposal without the Drain_delegate operation and the governance toggle. The consensus key would be non-spendable from the get-go in this case. Please let us know.

We are attaching an invoice to this proposal. The proposed amounts are 30,000 tez to G.-B. Fefe and 20,000 tez to (my company), credited to our respective accounts at protocol activation, shall this proposal be part of it.


Have you ensured that key rotation cannot be used in a hidden branch shorter than the no-fork point to escape slashing?

Consensus key updates are delayed by PRESERVED_CYCLE + 1.


Please, consider the analysis Proto: allow bakers to set a consensus key (!5106) · Merge requests · Tezos / tezos · GitLab for Drain_delegate.

Following your analysis, the TZIP has been updated.

From my personal perspective, I would be interested to see this feature. If I’ve understood it correctly, one would be able to deploy a key for baking in the field (obviously still secured properly) and only sign baking blocks. Other operations (delegation, voting, funds transfer) would be done with a different key away from the baking environment. Along with the ability to rotate the key, it has to be something that bakers would like for security reasons.

The consensus key feature has been merged into Octez and will be part of the next protocol proposal:

1 Like