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. There is a set of different transaction types and each of these types defines a specific logic for modifying accounts depending on the transaction data. In the table below, a summary of these transaction types and the purpose each of them serve is shown.
Transmit funds to another Lisk account
Register a delegate for the account
Submit or remove vote(s) for delegates
Unlock locked tokens
Register a multisignature in the account
Submit a proof-of-misbehavior of a delegate
Every transaction object in the Lisk protocol, regardless of the type, has a common set of properties. These properties are shown in the subsection below.
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 type of transaction.
For example, in Lisk Mainnet, for a balance 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.
This property contains the data specific to the type of the transaction.
type value, there exist a unique
The section Transaction types describes the different transaction types with respect to the
asset property of each of them.
An array with the signatures of the transaction.
If the account associated to
senderPublicKey does not have the
keys property, the object containing the five properties,
asset, has to be signed by the private key corresponding to the
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.
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 hash of the serialized transaction.
A balance 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 transactions types available in 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 type-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.
This transaction type 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
This transaction offers the possibility to send a message in the optional property
This transaction registers the sender account as a delegate with the name given in
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
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).
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
This transaction is only valid if it is issued after the unlocking period has been completed since
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).
This transaction registers the sender account as a multisignature account.
The set of mandatory keys needs to be specified in
mandatoryKeys whereas the set of optional keys have to be specified in
The total number of keys required for every future outgoing transaction from the account is given in
Once this transaction is included in a block, every transaction from this account has to be signed by an applicable set of private keys.
This transaction submits a proof of misbehaviour of a certain delegate.
It contains the information necessary to prove that the delegate who signed the block headers given in
header2 has violated the Lisk-BFT protocol.
The Punishment of Lisk-BFT protocol violations section provides the details regarding implications of this transaction type.