A Lisk account consists of a unique identifier called an address, an amount of tokens referred to as a balance, and possibly some additional properties used in other parts of the Lisk protocol.

The account state is not stored as part of the blockchain, however it can be computed by executing all transactions contained in previous blocks. Verification of the validity of a transaction requires the state of the referenced accounts.

Account properties

This section lists the properties of a Lisk account. The properties, except the address as the account identifier, are organized into four different objects, each corresponding to one of the account schemas defined in the four default modules: Token, Sequence, Keys, and DPoS.



The address is the main identifier of the account. For example, it is used to identify the recipient when transferring the balance between users. The address is calculated as the first 20 bytes of the SHA-256 (Secure Hash Algorithm 256), of the public key.

For the front end, a user-friendly address format is provided, whereby each address starts with the prefix “lsk" and a checksum is appended to prevent accidental typing mistakes.


The balance is an integer value indicating how many tokens are stored in the account and available to be used. It belongs to the token object of the account. The total number of tokens owned by an account is the sum of the balance and the tokens locked into sentVotes and unlocking. The balance can be sent from one account to another using a token transfer transaction.


By default, a transaction issued by an account has to be signed with the private key corresponding to the original public key that generated the account address. However, this default configuration can be changed, and issuing a transaction can require signatures by multiple different private keys (and not necessarily the default one). The corresponding public keys are stored in the keys property. These public keys can be either mandatory or optional: All mandatory keys have to sign the transaction, and the total number of signatures (mandatory plus optional) has to be equal to numberOfSignatures (also stored in keys). Users can update the keys property with a multisignature group registration transaction, specifying the mandatory and optional keys and the number of required signatures.


This property stores the current nonce of the account. It belongs to the sequence object of the account. Starting from zero, each transaction sent from the account increases the nonce value by one. Hence the current nonce corresponds to the number of transactions sent from the account.


The dpos object contains all account properties related to the DPoS protocol.

The following properties are part of the dpos object in the default Lisk protocol.


Accounts registered as delegates store extra information related to block forging in this property, such as the delegate’s username or the number of consecutive missed blocks.


In Lisk Delegated Proof-of-Stake, users vote for accounts that are registered as delegate accounts. Votes issued by a user are stored in their account as a list of tuples, each with the voted-delegate address and the amount of voted tokens (in beddows). Tokens used for voting are locked, and cannot be used (or moved from the account) before they have been unlocked.


Tokens used to vote for a delegate are locked, and have to be unlocked to make them available again. Similarly to the sentVotes property, this property stores the voted-delegate’s address and the amount, but also the block in which the votes have been removed from the delegate. After the appropriate waiting time, the user can then unlock the tokens with a token unlock transaction.