Introduce unlocking condition for incentivizing certificate generation

Hello everyone,

I want to propose another new LIP for the roadmap objective “Update Lisk-BFT for interoperability”. This LIP introduces an additional condition for an unlocking transaction in DPoS to be valid.

I’m looking forward to your feedback.

Here is the complete LIP draft:

LIP: <LIP number>
Title: Introduce unlocking condition for incentivizing certificate generation
Author: Jan Hackfeld <>
Type: Standards Track
Created: <YYYY-MM-DD>
Updated: <YYYY-MM-DD>
Requires: Introduce a certificate generation mechanism LIP


This LIP introduces an additional incentive for delegates and voters in DPoS for generating certificates by requiring the generation of a certificate for a certain height before tokens previously used for voting can be unlocked.


This LIP is licensed under the Creative Commons Zero 1.0 Universal.


The “Introduce a certificate generation mechanism” LIP specifies a mechanism for blockchains in the Lisk ecosystem to generate certificates. Certificates are the key object facilitating interoperability and every blockchain in the Lisk ecosystem has to regularly generate certificates so that new outgoing cross-chain messages can be submitted to other chains via cross-chain updates, see the “Introduce cross-chain update transactions” LIP for details. In particular, the minimum requirement for any sidechain is to submit at least one certificate to the Lisk mainchain in any 30 day period. Otherwise, the connection of the sidechain to the mainchain is terminated and the submission of further cross-chain updates from that sidechain is no longer possible. Similarly, at least one certificate from the Lisk mainchain has to be submitted to a sidechain in every 30 day period as otherwise the connection of the Lisk mainchain on the sidechain is terminated.

It is therefore crucial for the usability of cross-chain messaging and maintaining interoperability that every chain in the Lisk ecosystem continuously generates certificates. In order to ensure the certificate generation for blockchains utilizing DPoS, this LIP introduces the requirement of generating a certificate for a certain height before tokens previously used for voting can be unlocked.


In the DPoS system introduced in LIP 0023 any tokens used for voting are locked. After unvoting an amount of tokens, the account holder has to wait a certain number of blocks before being able to unlock this amount. The purpose of the locking period is to disincentivize malicious behavior by delegates or voters as they have a certain amount of tokens at stake that cannot be quickly transferred and sold.

Using a similar approach we want to ensure that delegates constructively participate in the certificate generation, i.e., they generate and share certificate signatures for heights where they are active. In particular, we want to prevent a group of delegates from leaving the set of active delegates, but refusing to sign a certificate that attests this change. We want to achieve this by only letting a delegate and its voters unlock, after the delegate was voted out of the active set, if a certificate is generated for the last height where the delegate was active. This certificate will attest that the respective delegate is no longer part of the active set of delegates of the chain.

Figure 1: The result of an unvote transaction t included in round r only comes into effect in round r+3 as the vote snapshots for delegate selection are taken from two rounds ago.

More concretely, consider one unvote transaction t included at height h in round r that results in a delegate d leaving the set of active delegates, see also the figure above as illustration. The vote snapshots used for selecting the active delegates at the beginning of a round are taken from two rounds ago. This means that the last block b of round r+2 is the last block when delegate d is active. In particular, the validators hash property in block b attests a validator set not including d. As certificates are generated for all end-of-round blocks, we require that the certificate signature for the certificate derived from block b is included in the chain, before the account submitting the unvote transaction can unlock. This means that the following inequality has to hold for the unlock included at height h to be valid:

lastHeightRound(h + 2 * ROUND_LENGTH) <= certifiedHeight.

Here ROUND_LENGTH is the round length in the DPoS chain and lasthHeightRound() returns the last height of a round for any given height, see also the table at the beginning of specifications.



Name Value Description
ROUND_LENGTH configurable per chain
Lisk Mainnet: 103
This number is equal to the number of active plus standby delegates in a Lisk DPos chain.

Basic Functions

Name Value Description
lastHeightRound(h) uint32 For a height h of round r as input, this function returns the height of the last block of round r. In particular, if h is the last height of a round, we have h=lastHeightRound(h).

New Unlocking Condition

The validity condition for an unlocking transaction from LIP 0023 is updated to require the effect of the unlocking to be attested. For this, we additionally require that for every unlock object U in an unlock transaction the function isCertificateGenerated(U) defined below returns true. All previous requirements for the validity of the unlock transactions stay the same, in particular, hasWaited(U) has to return true. Note that the property certifiedHeight is introduced in “Introduce a certificate generation mechanism” LIP.

function isCertificateGenerated(U):
  certifiedHeight = value of the property certifiedHeight before applying the current block

  if lastHeightRound(U.unvoteHeight + 2 * ROUND_LENGTH) > certifiedHeight:
    return false
    return true

Backwards Compatibility

This LIP introduces a soft-fork as the validity condition for the unlocking transaction becomes more strict.