In Lisk, the state of accounts is updated by transactions included in a block. Every account can issue a transaction, with the corresponding signature and data. Similar transactions are grouped together into one module. Apart from the module-specific account properties, a module defines the validation and execution logic for every transaction contained within that module. The Lisk protocol contains four default modules, Token, Sequence, Keys, and DPoS, which contain the six transactions shown in the table below.

Transaction Module Purpose

token transfer


Transmit funds to another Lisk account

delegate registration


Register a delegate for the account

delegate vote


Submit or remove vote(s) for delegates

token unlock


Unlock locked tokens

multisignature group registration


Register a multisignature group for the account

delegate misbehavior report


Report a misbehavior of a delegate

Transaction properties


Every transaction object in the Lisk protocol has a common set of properties. These properties are shown in the subsection below.


An integer identifying the module the transaction belongs to.


An integer identifying the specific asset for the transaction in the module.


An integer that accounts for the number of transactions from the sender account. For a transaction to be valid, this integer has to be equal to the nonce stored in the sender account. If due to network congestion, a transaction was not included in a block because its fee was too low, a user can broadcast a new transaction using the same nonce value but with a higher fee. Once one of the two transactions is included in the blockchain, the other one becomes invalid as the nonce has already been used.


The fee to be spent by the transaction. This fee has to be equal or greater than a minimum value for the transaction to be valid. The minimum value is calculated as the size of the transaction object multiplied by a constant, minFeePerByte, given by the protocol. The value of minFeePerByte is 1000 (10-5 LSK/byte in Lisk Mainnet). Note that for delegate registration transactions there is an extra summand of 109 (10 LSK in Lisk Mainnet) added to the minimum fee to account for the name space used by this transaction.

For example, in Lisk Mainnet, for a token transfer transaction with a size of 133 bytes, the minimum fee is 10-5 LSK/byte × 133 bytes = 0.00133 LSK. In the case of delegate registration transaction with a size of 124 bytes, the minimum fee of the transaction is 10 LSK + 10-5 LSK/byte × 124 bytes = 10.00124 LSK.

This required minimum fee paid by every transaction is burned, in other words, it is not assigned to any account balance. The remaining fee on top of this is assigned to the delegate forging the block in which the transaction is included. This implies that under normal circumstances delegates give priority to transactions with higher remaining fees.


The public key of the account issuing the transaction. Note that this public key does not necessarily sign the transaction. For simplicity, the account issuing the transaction is called the sender account in this document. The senderPublicKey is used to compute the address under which the sender account information is stored.


This property contains the data specific to the type of the transaction. Every pair of values (moduleID,assetID) must uniquely correspond to one asset schema defined in the respective module, which defines how to deserialize the bytes provided in the transaction asset. The section Transactions below contains the asset schemas and a description of the general execution logic for the default transactions listed above.


An array with the signatures of the transaction. If the account associated to senderPublicKey does not have the keys property, the object containing the six properties, moduleID, assetID, nonce, fee, senderPublicKey, and asset, has to be signed by the private key corresponding to the senderPublicKey. Otherwise, the signing process has to be repeated for each of the private keys associated with an applicable set of public keys specified in the keys property of the account. In the Appendix section more details about the signing process are given.

Transaction ID

In Lisk, every transaction is associated with a transaction ID, which uniquely identifies a transaction in the blockchain. The transaction ID is the SHA-256 (Secure Hash Algorithm 256), hash of the serialized transaction.

Minimum balance

A token transfer transaction must make the balance of the receiving account equal to or greater than 5 × 106 (0.05 LSK in Lisk Mainnet). Subsequently, any transaction sent from an account is only valid if the resulting balance of the sender account is at least 5 × 106. This constraint exists to account for the cost of creating and storing accounts in Lisk.


The 6 different transactions from the default modules of the Lisk protocol are listed in the table displayed above. Each one induces a concrete operation on accounts and is defined by a unique schema and transaction logic. The specific data is given in the asset property previously mentioned. The key points and useful information for each of these transactions are commented in the following subsections.

Token transfer


This transaction transfers the amount of tokens specified in the amount property from the account corresponding to the senderPublicKey, i.e. the sender account, to the account specified in recipientAddress. This transaction offers the possibility to send a message in the optional property data. The maximum length for a string in data is 64 characters.

Delegate registration


This transaction registers the sender account as a delegate with the name given in username. A valid name contains only characters from the set [a-z0-9!@$&_.] and has to be at most 20 characters long.

Delegate vote


This transaction submits the votes specified in votes from the sender account. This is accomplished by specifying the Lisk address of the voted delegate in delegateAddress together with the amount of support given to this delegate in amount. The quantity given in amount is subsequently locked and cannot be used for other transactions. If the amount is negative, it implies that the specified amount of votes are removed from the delegate. The maximum number of votes that can be cast in a single transaction is 20 and amount has to be a multiple of 109 (10 LSK in Lisk Mainnet).

Token unlock


This transaction unlocks the tokens specified in amount that were previously unvoted for the delegate specified by delegateAddress by a vote transaction at the height given in the property unvoteHeight. This transaction is only valid if it is issued after the unlocking period has been completed since unvoteHeight. For a regular vote the unlocking period is 2000 blocks (around 5 hours). For self-votes, i.e. if the delegateAddress property of the transaction is equal to the account address, this period is 260,000 blocks (around 30 days).

As described in the Punishment of Lisk-BFT protocol violations section, the validity of the unlock transaction also depends on potential misbehaviors by the unvoted delegate. An unvote for a punished delegate has its unlocking period extended. For regular votes, this period is extended from 2000 blocks to 260,000 blocks (from 5 hours to 30 days). For self-votes, this period is extended from 260,000 blocks to 780,000 blocks (from 30 days to 3 months). This affects any amount currently voting for the punished delegate or amounts that were used for voting for this delegate, but were still in the unlocking period at the inclusion height of the proof-of-misbehavior.

Multisignature group registration


This transaction registers the sender account as a multisignature group account. The set of mandatory keys needs to be specified in mandatoryKeys whereas the set of optional keys have to be specified in optionalKeys. The total number of keys required for every future outgoing transaction from the account is given in numberOfSignatures. Once this transaction is included in a block, every transaction from this account has to be signed by an applicable set of private keys.

Delegate misbehavior report


This transaction can be utilized to report a misbehavior of a certain delegate. It contains the information necessary to prove that the delegate who signed the block headers given in header1 and header2 has violated the Lisk-BFT protocol. The Punishment of Lisk-BFT protocol violations section provides the details regarding the implications of this transaction.