An account consists of a unique identifier / address, an amount of tokens referred to as balance and possibly some additional properties used in other parts of the blockchain application.

Account Address

Addresses are unique identifiers for accounts in the Lisk blockchain. They are the 20-byte hash value of the public key that controls the account initially. In all front-end products, addresses are displayed in a human-readable representation called Lisk32 representation. An example for an address in Lisk32 presentation is lskxwnb4ubt93gz49w3of855yy9uzntddyndahm6s. When referring to addresses in Lisk, we always assume the Lisk32 representation, without explicitly having to mention it. In the Lisk protocol and SDK only the 20 byte value is stored for efficiency and sometimes the hexadecimal representation of the address is used. Further details regarding other address representations can be seen here in the table for different data types on the schema reference page.

Active Delegate

An active delegate can mostly be considered as a forging delegate, who is able to forge new blocks for the Lisk blockchain. Rank 1-101.

AES-256-CBC - Advanced Encryption Standard

The Advanced Encryption Standard (AES), has a key length of 256 bits and is a block cipher adopted as an encryption standard by the U.S. government for military and government use. CBC (Cipher Blocker Chaining), is an advanced form of block cipher encryption. A detailed description of how AES functions can be found here.


BCH Codes - Bose, Chaudhuri and Hocquenghem codes

BCH codes are error-correcting codes. The Bose, Chaudhuri and Hocquenghem (BCH) codes form a large class of powerful random error-correcting cyclic codes.


A Beddow is the smallest unit of a LSK token. 100 million Beddows is equal to 1 LSK.


A temporary, public testing network for the Lisk Core beta candidate.

BFT - Byzantine Fault Tolerance

In a system whereby components need to come to an agreement to reach consensus, byzantine failures will prevent those components from reaching an agreement, (usually caused by errors that are hard to detect). A Byzantine Fault Tolerant system ensures that measures are taken to manage such failures.

BIP - Bitcoin Improvement Proposal

A Bitcoin Improvement Proposal (BIP), can be defined as a standard for proposing changes to the Bitcoin protocol. For example, BIP39 is one of many bitcoin improvement proposals. In this particular proposal it describes the mnemonic code or mnemonic sentence implementation, and how to create a human readable mnemonic sentence including how to convert that mnemonic into a seed.

Blockchain Application

A blockchain application is any kind of application which uses its own blockchain as a database layer. For example, this can be an application running on its own blockchain built with the Lisk SDK.

Blockchain App

Short form of blockchain application.

Block Height

The number of blocks in the blockchain between the genesis block and the block of the specified block height.




An account which performed the delegate registration and is now able to receive votes.

Delegate misbehaviour report transaction

A delegate misbehavior report refers to a transaction type on the Mainnet which reports a delegates misbehavior.
Any misbehavior of a delegate is indicated by two contradicting block headers signed by the delegate.

Delegate registration transaction

A delegate registration is achieved by sending a delegate registration transaction, which registers a delegate to participate in the Delegated Proof-of-Stake consensus algorithm.

Delegate Weight

The delegate weight is an indicator which shows the active support received by a delegate that is present in the network. To maintain a secure and effective setup, the delegate weight is bound to 10 times the self-votes.


A blockchain network for development purposes. The Lisk SDK provides dedicated genesis block and configurations to conveniently set up a local Devnet during development of a blockchain application.

DPoS - Delegated Proof of Stake

DPoS is the mechanism of determining eligible block creators achieved by voting for registered delegate accounts, which are then able to create blocks depending on their vote weight. It is part of the consensus algorithm of a blockchain and used on Lisk Mainnet and in the Lisk SDK.


Ed25519 - High Speed High Security Signature

Ed25519 is a public-key signature system with several attractive features: Fast single-signature verification. Ed25519 signatures are elliptic-curve signatures, carefully engineered at several levels of design and implementation to achieve very high speeds without compromising security.



A Faucet is generally defined in the blockchain world as a tool whereby users can receive a certain amount of tokens for free. For Lisk blockchain apps, the faucet plugin can be registered with the application to provide a basic faucet, which is useful during the development phase, and also for proof-of-concept blockchain applications.


How delegates produce new blocks on the Lisk blockchain.


A fork can basically be defined as an occurrence of a blockchain diverging into two forward paths in the network. In other words it is whereby an alternative version of the blockchain is created by generating two blocks on different parts of the network simultaneously. For further detailed information regarding forking in the Lisk network, see the following Lisk Mainnet hard fork process description in the Lisk Mainnet Regenesis page

Framework Plugin

A self-contained, off chain component which extends the standard feature set of the Lisk SDK by a specific use case, e.g. a node monitor plugin or delegate forging plugin. Typically there is no state change on the blockchain.


Genesis Block

The genesis block describes the very first block in the blockchain. It defines the initial state of the blockchain on start of the network. A genesis block must be given to the application, and all networks should have a different genesis block.


Hash Onion

The hash onion stores the random seeds of the delegate and is required for each forging round, this can be generated by the Lisk Commander. More details can be found in the enable forging section.





Lisk Framework

Lisk Framework is an application framework responsible for establishing and maintaining the interactions between the modules of a blockchain application compatible with the Lisk protocol. It provides an application where off-chain and on-chain logic can be extended with user defined plugins and modules.

LIP - Lisk Improvement Proposal

A LIP is a document usually structured by the research team defining technical changes in the Lisk protocol. In addition, it can also cover an implementation or a non technical process surrounding Lisk. Furthermore, a LIP also describes the requirements, rationale and motivation for the required changes.

Lisk SDK

The Lisk SDK is an open-source software development kit which enables developers to easily build scalable Blockchain applications using JavaScript.

Lisk32 representation

The Lisk32 representation of an Account Address starts with the letters "lsk" followed by a custom Base32 encoding of the 20 bytes of the address appended with a BCH checksum. The checksum is used to check for small errors in the address. Any errors in up to 4 characters are guaranteed to be detected and errors in more than 5 characters are likely to be detected. The choice of the Lisk32 representation of addresses does not modify the address, but is introduced to provide a safer and more pleasant experience to users.


The token used in the Lisk Mainnet.



A mainnet is a fully developed functional and independent blockchain, running on its own network and using its own protocol and technology. It is the official main network within Lisk.

Module Asset

A module asset allows a module to execute specific state changes on the blockchain based on transactions. A Transaction with the corresponding module & asset ID needs to be sent to the Blockchain Application in order to trigger the logic defined in a certain module asset. The data provided in the Transaction asset provides the required input data to execute the desired state changes.

Multisignature group registration transaction

A transaction type on all networks based on the Lisk protocol which registers a multisignature group. This transaction registers the sender account as a multisignature group account.


NFT - Non Fungible Token

NFTs are digital assets in the form of unique cryptographic tokens. Examples can represent real-world objects such as art, music, games, and videos, which due to their uniqueness can result in them becoming collectible items of value.


A blockchain application built with the Lisk SDK, e.g. Lisk Core, which is connected to other nodes. Together, they form a blockchain network. Nodes fulfill many important roles in the network, like synchronising new events in the network between each other, adding new blocks to the blockchain, and providing APIs for external services in order to communicate with the network.


A nonce is an abbreviation for "number only used once" and is a random number that can only be used one time. In the Lisk network it can be defined as an integer that represents for the number of outgoing transactions of an account. For a transaction to be valid, transaction nonce 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.




NPM distribution of a library.


A set of 12 words used to access an Account.

PBKDF2 - Password Based Key Derivation Function 2

PBKDF2 can be defined as key derivation functions with a sliding computational cost, in order to reduce vulnerabilities to brute force attacks.

PoS - Proof of Stake

Proof of Stake is a type of consensus mechanism used to achieve agreement over a distributed network. With PoS the consensus is determined based upon the stake of each user in the network.
With PoS users are required to stake their tokens in order to become a validator in the network. Validators are responsible for ordering transactions and creating new blocks, so that all nodes are able to agree on the current state of the network.

PoW - Proof of Work

Proof of Work is a type of consensus mechanism used to achieve agreement over a distributed network. With PoW in order to complete the transactions on a given network, the miners have to solve complex mathematical problems in order to be rewarded with the tokens. In a nutshell, the PoW consensus algorithm is used to confirm transactions and produce new blocks to the chain. The miners have to compete against each other to complete transactions on the network to receive their rewards. Hence, the PoW mechanism allows consensus to be reached whilst simultaneously maintaining the network security.

P2P - Peer to Peer

A peer to peer network is a group of nodes (devices), that make up a decentralized network that can collectively share and store data, whereby each node acts as an individual peer.



Reclaim LSK transaction

This transaction is only part of Lisk Core and not the Lisk SDK. A reclaim LSK transaction type on the Mainnet converts a previously non-initialized legacy account’s address to the new address system. Initialization was originally only required for the v2 chain as legacy addresses, generated from the first eight bytes of the public key, were used in older versions of the protocol. However, this is required because the public key is required to convert from the old address system to the new address system. Non-initialized accounts don’t have a public key associated with them yet.


Reducers are functions which can be invoked via Remote-Procedure-Calls (RPC) by other modules. Reducers are able to perform state changes on the blockchain. Modules and module assets can invoke reducers through the reducerHandler. See Modules > Reducers for more information.


Self Vote

A self vote is a vote that a delegate casts for themselves. Self votes are always at least 10% of the delegate weight.

Standby Delegate

A standby delegate, as each delegate is not an Active Delegate. Rank 102-∞.

State Store

The state store is used to mutate the state of the blockchain data, or to retrieve data from the blockchain, and can also be thought of as a temporary data structure that holds a temporary state while processing a block.



The official testing network of Lisk. It can be thought of as an instance of a blockchain which is used for testing purposes, and consists of a the same version of the mainnnet underlying software. All testing and experimentation can be performed on the testnet without jeopardizing the actual mainnet.


A token refers to LSK or any sidechain token. A digital token is designated to a cryptocurrency that is built on top of an existing blockchain, and represents a particular tradable and fungible asset.


An interaction with the Lisk blockchain which permanently writes data to it. A transaction can have multiple purposes, e.g. a balance transfer or delegate registration. Each transaction contains a module ID and an asset ID, defining the transaction type. All properties of a transaction object are described on the Lisk protocol > Transactions page. The input data for the different module assets is stored inside the Transaction asset of a transaction.

Transaction asset

The asset of a transaction contains the custom data which serves as input parameters for the corresponding Module Asset. The transaction asset is part of every Transaction object.

Token transfer transaction

A transaction type which transfers tokens from one account to another one. A token transfer transaction will transfer the amount of tokens specified in the amount property, from the sender of the transaction to the specified recipient.

Total votes received

The total votes received is the sum of all vote amounts (including self-votes), for that specific delegate. The self-votes are always at least 10% of the delegate weight, in order to ensure each delegate is able maintain an adequate amount of votes. The votes are aggregated and used to compute the delegate weight, which in turn is used to assign blocks to delegates. However, it should be noted that as the delegate vote will be capped by the self-vote, the total votes might not be equal to the delgate weight.

Transaction fee

An amount of LSK needed to send a transaction on the Lisk blockchain.

Transaction ID

A hash of a transaction that uniquely identifies a transaction.

Transaction message

A custom message you can attach to a [token-transfer].


Unlock token transaction

The unlock token transaction unlocks the tokens which have been locked previously by voting for a specific delegate. The delegate needs to be unvoted before unlocking the tokens by sending a [vote-delegate] transaction.

UTXO - Unspent Transaction Output

UTXO is an unspent output. In other words it can be thought of as an indivisible chunk of a token, which is under the control of the private keys belonging to the owners.


Vote delegate transaction

Accounts can vote for delegates by sending a vote delegate transaction. The tokens used to vote for delegates will be locked, although the locked tokens can be unlocked again if required, by unvoting the delegate again. The weight of a delegate will determine the sum of all votes for this delegate.


An account deploying their LSK to vote for their favourite delegates.



Wallets can be broken down into three distinct categories: Software, Hardware, and Paper wallets. Software wallets can be defined as either desktop, mobile or online.
In short a wallet will store the public and private keys and can interface with various blockchains, enabling the users to monitor their balance, send tokens and conduct other operations.
A Lisk wallet is available on both Lisk Desktop and Lisk Mobile. They are actively maintained and provide the most secure and easiest way to access the users LSK tokens.