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.
Transmit funds to another Lisk account
Register a delegate for the account
Submit or remove vote(s) for delegates
Unlock locked tokens
multisignature group registration
Register a multisignature group for the account
delegate misbehavior report
Report a misbehavior of a delegate
Every transaction object in the Lisk protocol 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 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 a 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.
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 (
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 Transactions section 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,
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.
Further information regarding the signing process can be found in the Appendix section.
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.
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 additional useful information for each of these transactions are provided in the following subsections.
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
This transaction offers the possibility to send a message in the optional property
The maximum length for a string in
data is 64 characters.
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 cannot be more than 20 characters long.
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).
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.
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
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 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
header2 has violated the Lisk-BFT protocol.
The Punishment of Lisk-BFT protocol violations section provides the details regarding the implications of this transaction.