Skip to main content
This page is for CELO holders and node operators who manage staking keys. The Celo protocol was designed with the understanding that there is often an inherent tradeoff between the convenience of accessing a private key and the security with which that private key can be custodied. In general Celo is unopinionated about how keys are custodied, but also allows users to authorize private keys with specific, limited privileges. This allows users to custody each private key according to its sensitivity (i.e. what is the impact of this key being lost or stolen?) and usage patterns (i.e. how often and under which circumstances will this key need to be accessed).

​
Summary

The table below outlines a summary of the various account roles in the Celo protocol. Note that these roles are often mutually exclusive. An account that has been designated as one role can often not be used for a different purpose. Also note that under the hood, all of these accounts are based on secp256k1 ECDSA private keys. The different account roles are simply a concept encoded into the Celo staking smart contracts, specifically Accounts.sol. For more details on a specific key type, please see the detailed role descriptions.
Two further signer roles exist in Accounts.sol but had duties that ended with the Celo L1: the validator BLS signer (consensus block signing) and the attestation signer (the retired Attestation Service). See About Celo L1.
A Locked CELO Account may have at most one authorized signer of each type at any time. Once a signer is authorized, the only way to deauthorize that signer is to authorize a new signer that has never previously been used as an authorized signer or Locked CELO Account. It follows then that a newly deauthorized signer cannot be reauthorized.