The delegation process bonds stake to a validator, converting unbonded PEN to bonded PENb. Delegations may be performed in any block, but only take effect in the next epoch.

Delegations are accomplished by creating a transaction with a DelegateDescription. The delegate description specifies a validator , consumes PEN from the transaction’s balance, produces a new shielded note with PENb associated to that validator, and includes an encryption of the delegation amount to the validators’ shared decryption key . Here is the index of the next epoch, when the delegation will take effect.

In the last block of epoch , the validators sum the encrypted bonding amounts from all delegate descriptions for validator in the entire epoch to obtain an encryption of the total bonding amount and decrypt to obtain the total bonding amount without revealing any individual transaction’s bonding amount . These total amounts are used to update the size of each validator’s delegation pool for the next epoch.

Revealing only the total amount of newly bonded stake in each epoch helps avoid linkability. For instance, if the size of each delegation were revealed directly, a delegation of size followed by an undelegation of size could be correlated if an observer notices that there are some epochs so that

This risk is still present when only the total amount -- the minimum disclosure required for consensus -- is revealed, because there may be few (or no) other delegations to the same validator in the same epoch. Some care should be taken in client implementations and user behavior to mitigate the effects of this information disclosure, e.g., by splitting delegations (and undelegations and votes) into multiple transactions in different epochs involving randomized sub-portions of the stake. However, the best mitigation would simply be to have many users.


  • specify the exact data in a delegate description