What Is Lisk?

Lisk is a Blockchain application platform, established in early 2016. Based on its own Blockchain network and token LSK, Lisk will enable developers to create, distribute and manage decentralized Blockchain applications by deploying their own sidechain linked to the Lisk network, including a custom token. Thanks to the flexibility of sidechains, developers can implement and customize their Blockchain applications entirely.

How Lisk Helps?

In early 2016, after several years participating within the Blockchain industry, Max Kordek and Oliver Beddows saw a lack of developer adoption. With the vision to make Blockchain technology more accessible, they imagined a Blockchain framework which accelerates and simplifies development.

How Lisk Different From Other Platform?

Lisk is more than just developer tools. It’s an opportunity to become part of the biggest technological innovation since the Internet. Lisk aims to make Blockchain technology more accessible with an SDK written in JavaScript, special focus on user experience, developer support and in-depth documentation.

The Lisk Foundation set itself the goal to inspire and educate entrepreneurs and developers alike. The ultimate goal is to bring talent into the Blockchain industry by enabling developers to build the decentralized future with our SDK. Hereby, we will provide an easy entry to take people from the idea to the product.

Most alternative solutions are either single Blockchain based or are tailored for private Blockchains. Lisk strives to offer the best of both worlds. The Lisk mainchain offers stability and security while sidechains are utilized to have unlimited flexibility.

This way, Lisk offers developers an environment where they have full control to create their own Blockchain network as a sidechain but don’t have to confront the complexity of creating a Blockchain network from scratch.

Getting Started With Lisk

Application Development

Decentralized applications or Blockchain applications are exactly what the name suggests. Applications of any sort running on many servers, providing unseen security, uptime and entirely new business models. A powerful component of the Lisk application platform is the ability to deploy, distribute and manage decentralized applications all in one place with a seamless user experience.

Decentralized applications include the whole package of front-end (what the user sees) and back-end (the logic behind it). A smart contract on the other hand, consists only of the back-end, and often only a small part of it. This means that if you want to create a decentralized application on a smart contract system (i.e. not with Lisk), you have to combine several smart contracts and rely on 3rd party systems for the front-end.

Possible use cases include applications that offer proof-of-ownership, improved online identity verification or asset management.

Lisk strives to make Blockchain technology accessible for everybody. A seamless user experience on the Lisk platform and understandable documentation should make it possible for anyone to send LSK, download applications and educate themselves without being a technical genius.

In order to build your own application it requires a developer to code it in JavaScript. By offering an SDK written in JavaScript, Lisk enables millions of developers around the world an accessible way to create their own decentralized applications by deploying their own Blockchain sidechain next to the Lisk network.

How To Get A Lisk Wallet?

Lisk Nano

lisk nano

Lisk Nano enables the user to send and receive transactions on the Lisk network and provides a simple user interface for more advanced features like delegate voting or registering a second passphrase. With Lisk Nano, there is no need for blockchain synchronisation as it connects to official Lisk nodes hosted by the Lisk Foundation. For the use of API calls and other advanced features please use Lisk Core.

Lisk Core

lisk core

Binary - Prerequisites

This details how to prepare a Linux operating system for the installation of Lisk Node. It will guide you through installation of important dependencies and user creation.

Determine if your platform can run Lisk Node

Supported Architectures

To complete the installation there are prerequisites that need to be completed. If you have already performed these, please proceed to the installation document for your desired network. Follow these instructions to load required software to your system.

Linux Installation Pre-Requisites

Ensure you are logged in as root.


Install curl, wget, tar, sudo, unzip, zip

if [[ -f "/etc/redhat-release" ]]; then

yum update

yum install curl wget tar sudo unzip zip

elif [[ -f "/etc/debian_version" ]]; then

apt-get update

apt-get install curl wget tar sudo unzip zip


Create a user to run lisk, create sudo group and give the lisk user sudo permissions

useradd -d /home/lisk -m lisk

groupadd sudo

usermod -a -G sudo lisk

Set a password for the lisk user

passwd lisk

Setup the sudoers file


After you've opened the file, paste the following line at the bottom of the file:


On Ubuntu: Click Ctrl+ X then: Y to exit the document and save it.

On RHEL: type :wq!

Update the systems Locale

if [[ -f "/etc/redhat-release" ]]; then

localedef -v -c -i en_US -f UTF-8 en_US.UTF-8

localectl set-locale LANG=en_US.UTF-8

elif [[ -f "/etc/debian_version" ]]; then

locale-gen en_US.UTF-8

update-locale LANG=en_US.UTF-8


Set the systems operating language to en_US.UTF-8

Reboot your system to apply changes


Docker - Prerequisites

This describes how to install Lisk Node as a Docker based container. It will guide users to downloading and installing Docker Toolbox or login to a Docker VM through an SSH client.

Supported Platforms

Not Supported

Docker is supported on most operating systems. Follow the section below that applies to your operating system to setup Docker.

Windows / Mac OS X

Download and install Docker Toolbox for your operating system.

Open the Docker Quickstart Terminal.

PuTTY / SSH Access

You can optionally login to your Docker virtual machine, using PuTTY or any other SSH client.

To do so, please use the following credentials:


Port: 22

Login: docker

Password: tcuser

Ubuntu / Debian / CentOS / Fedora

Log onto your Ubuntu based server and enter the following commands:

NOTE: The following information is applicable to: Ubuntu 14.04, 16.04 (LTS) or 16.10 - x86_64.

curl -sL https://downloads.lisk.io/scripts/setup_docker.Linux | sudo -E bash -

sudo apt-get install -y docker-engine

Post Install

Proceed to the Installation Landing Page order to install Lisk using the newly prepared Docker system.

Source - Prerequisites

Determine if your platform can install Lisk Core from source

Supported Platforms

Prerequisite Program Installations

Tool chain components -- Used for compiling dependencies

sudo apt-get install -y python build-essential curl automake autoconf libtool

Git -- Used for cloning and updating Lisk

sudo apt-get install -y git

Node.js -- Node.js serves as the underlying engine for code execution.

System wide via package manager

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

sudo apt-get install -y nodejs

Locally using nvm

curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.0/install.sh | bash

source ~/.bashrc

nvm install v6.10.1

Install PostgreSQL (version 9.6.2)

curl -sL "https://downloads.lisk.io/scripts/setup_postgresql.Linux" | bash -

sudo -u postgres createuser --createdb $USER

sudo -u postgres createdb lisk_test

sudo -u postgres createdb lisk_main

sudo -u postgres psql -d lisk_test -c "alter user "$USER" with password 'password';"

sudo -u postgres psql -d lisk_main -c "alter user "$USER" with password 'password';"

Bower -- Bower helps to install required JavaScript dependencies.

npm install -g bower

Grunt.js -- Grunt is used to compile the frontend code and serves other functions.

npm install -g grunt-cli

PM2 -- PM2 manages the node process for Lisk (Optional)

npm install -g pm2

Binary - Main Network

This section describes how to install the Lisk Node using pre-built binary packages. When completed, you will have a functioning installation on the Lisk Main Network.

If you are looking to upgrade your current Lisk Node installation, please see the section Upgrading Binary - Main Network.

Login to the Lisk user

The user was created in the Binary - Prerequisites Section. If you are already logged in to this user, please skip this step.

su - lisk

Execute the installation script

This will configure the environment, download and install the Lisk client.

wget https://downloads.lisk.io/lisk/main/installLisk.sh

bash installLisk.sh install -r main

You will be prompted for your installation directory, pressing enter will choose the default.

Accessing Lisk

If you are running the node locally, you can access the Lisk web client by opening a browser and navigate to the following web address.


The Lisk web client should launch successfully.

If you are not running Lisk locally, you will need to follow the Configuration - API document to enable access for yourself.

With all of the above steps complete you are ready to move on to the configuration documentation if you wish to enable forging or SSL. Please see Lisk Client Configuration for more information.

Docker - Main Network

Install Lisk through Docker

To install the latest version of Lisk as a docker container, please proceed with the following:

Install the docker image (executed only once per installation)

docker run -d --restart=always -p lisk/mainnet

NOTE: On Windows or Mac OS X, these commands are issued from within the Docker Quickstart Terminal. Upon successful completion, you will have a running Lisk node with an up-to-date snapshot of the blockchain. The container is configured to automatically restart upon reboot of the server or any occurrence of an error.

To access the Lisk web client, open: http://localhost:8000/

The Lisk web client should launch successfully.

Source - Main Network

Installing Lisk from Source (GitHub)

Clone the Lisk repository using Git and initialize the modules

git clone https://github.com/LiskHQ/lisk.git

cd lisk

git checkout master

npm install

Install Lisk Node, a specialized version of Node.js used to execute blockchain applications within a virtual machine

wget https://downloads.lisk.io/lisk-node/lisk-node-Linux-x86_64.tar.gz

tar -zxvf lisk-node-Linux-x86_64.tar.gz

rm -f lisk-node-Linux-x86_64.tar.gz

NOTE: Lisk Node has to be in [LISK_DIR]/nodejs/node.

Load required git submodules (lisk-ui and lisk-js)

git submodule init

git submodule update

Build the Lisk user-interface

cd public

npm install

bower install

grunt release

Initiating Lisk Node Installation

Using PM2 you can start Lisk and allow it to be monitored with the following command:

pm2 start --name lisk app.js

After the process is started, its runtime status and log location can be retrieved by issuing the following command:

pm2 show lisk

To stop Lisk after it has been started with pm2, issue the following command:

pm2 stop lisk

Lisk Core enables delegate forging, provides blockchain synchronisation, and includes the complete API for developers. Please note, installing Lisk Core is for advanced technical users looking to build on top of the Lisk Platform, securing the network infrastructure or attain delegate forging access.

Lisk Tools

Lisk Resources

How To Buy Lisk?

LSK tokens can be bought and sold on several major exchanges including Bittrex, Poloniex, YoBit and Jubi. There, LSK tokens can be exchanged for other cryptocurrencies including Bitcoin.

Except for the Chinese Yuan and Japanese Yen, it is currently not possible to buy LSK tokens directly with other FIAT currencies. Our goal is to make this possible in the future.

Exchanges have their own safety measurements before accepting incoming transactions or confirming outgoing transactions. Like stated on the previous question, the Lisk Blockchain takes ten seconds for a transaction to go through. However, we have no control over how many confirmations exchanges require.

It is impossible to send tokens other than LSK to your Lisk address. We can’t recover those tokens since it is another Blockchain and therefore out of our control.

We recommend that everybody stores their LSK tokens in our Lisk Nano wallet.

In the event of sending LSK to an incorrect address you will lose access to your funds. There is nothing we can do from our side to help retrieve your tokens.

How To Earn Lisk?

Lisk is a cryptocurrency that offers a next generation platform that allows for the development and distribution of JavaScript based blockchain applications. Lisk provides an easy to use interface and access full featured ecosystem.

Through Lisk, developers can build, publish, distribute, and monetize their applications within a cryptocurrency powered system that allows for the use of customized blockchains, smart contracts, cloud storage, and computing nodes.

Where To Spend Lisk?

All cryptocurrencies utilize tokens to create a secure system of utilization. As a result, Lisk offers a cryptocurrency token called LSK. This token is used to pay various fees in order generate transactions and to use the system.

LSK tokens can be acquired through various means, such as purchasing them from an exchange or from another individual using Fiat or Bitcoin (BTC).

What Is Lisk Mining?

Technical Background

Lisk as a software has three major components, the JavaScript code, NodeJS as a compute engine and PostgreSQL as a storage and database solution.


JavaScript is undeniably the language of the internet. Nearly every website on the Internet uses some form of JavaScript to provide rich functionality for end users. Lisk is written in JavaScript for these same reasons and because the language is very accessible to any developer.

With nearly any browser a user can write and test JavaScript code, and with Lisk's aim to be the premiere blockchain application platform it makes sense to use a language that runs on every desktop machine.


Lisk utilizes NodeJS as the backend computing engine for JavaScript code. NodeJS itself is extremely flexible and can be deployed to all desktop architectures and many IoT (Internet Of Things) devices. This flexibility gives Lisk the ability to run on any device that has the hardware to support the client.


All blockchains preserve data in different ways, some choose to use SQLite while others use LevelDB. These solutions work fine for pure blockchain solutions but don't provide the robust features of PostgreSQL.

PostgreSQL is one of the oldest open source relational database systems. With Postgres, a user can store information of any type, such as binary files or even music files. This makes PostgreSQL a perfect fit for the Lisk system and provides the necessary database engine to support blockchain applications. In addition to these features, the backup functionality and fault tolerance Postgres offers is unmatched in the open source space.


Lisk uses cryptographic hashing in order to secure all aspects of the system. The system uses EdDSA as it provides a much faster mechanism for hashing and providing security [see http://cr.yp.to/highspeed/coolnacl-20120725.pdf]; rather than ECDSA which is found in many other cryptocurrencies, such as Bitcoin.

Key pair

A keypair is consists of a private key and a public key. A private key is a piece of information known only to the owner of the key. The public key is derived from the private key and can be used to validate that the private key belongs to the owner, but not provide access to the owners private key. Elliptic curve cryptography is used to generate cryptographically secure key pairs.

The process used to generate the key pair operates under the following assumptions:

When a user creates an account, a BIP39 [2] mnemonics (the passphrase) is generated for the user. This passphrase is hashed using the SHA-256 hash function into a 256 bits string. This hash is subsequently used as a seed in ed25519 [3] to generate the private key ks and derives its public key kp.


With this private key, the user is able to sign transactions into a transaction object and broadcast that object to the network. The public key is included as part of the transaction and the nodes that receive the transaction are able to verify the validity of the signature using kp. This provides effective security for both the user and the network since ks is known only to the user and kp can validate that the signature is valid.

Second pass phrase

Lisk offers an additional layer of security for the user. Using a specific class of transaction, the user can register a second pass phrase that is associated with the kp. This relationship requires that all subsequent transactions to be signed using the second pass phrase in order to be considered valid. The process of generating the second key pair is the same as the one for the main key pair.


Lisk supports multisignature accounts as another security system for users requiring even greater security. A multisignature account is an account that requires multiple signers to submit signature transactions. Any user may enable multisignature on their account by issuing a special transaction (See Multisignature Registration Transaction) specifying a group of ksn and the require minimum amount of signatures required to confirm a transaction as valid.

It is then mandated in the blockchain that any transactions originating from this account must be signed by a minimum quorum of associated accounts before any transaction from the account may be processed.


An address or the wallet ID is derived from the public key. The public key is hashed using SHA-256 then the first 8 bytes of the hash are reversed. The account ID is the numerical representation of those 8 bytes, with the ’L’ character appended at the end. The following figure is the representation of an address and its associated account details.



"address": "16009998050678037905L",

"unconfirmedBalance": "0",

"balance": "0",

"publicKey": "73ec4adbd8f99f0d46794aeda3c3d86b245bd9d27be2b282cdd38ad21988556b",

"unconfirmedSignature": 0,

"secondSignature": 0,

"secondPublicKey": null,

"multisignatures": [],

"u_multisignatures": []



A blockchain is composed of blocks, and a block is composed of a header and a list of confirmed transactions. When a delegate is assigned a slot and has a node running, that delegate generates the next block and confirms up to 25 transactions from the transaction pool. These confirmed transactions will be added the payload of the block and subsequently signed into that block.

Block Header

The block header contains all the information about the block. The following fields compose the block header:

A 32 bit integer identifying the version of the block

A 32 bit epoch timestamp of when the block was created

The 64 bit Id of the previous block

A 32 bit integer corresponding to the number of transactions processed in the block

A 64 bit integer corresponding to the total amount of Lisk transferred

A 64 bit integer corresponding to the total amount of fees associated with the block

A 64 bit integer corresponding to the Lisk reward for the delegate

A 32 bit integer corresponding to the length the payload

The 256 bit hash of the payload

The 256 bit public key of the delegate who generated the block

The following figure is the representation of the complete structure of a block header:


JSON Representation:

JSON { "id": "15787022670460703397", "version": 0, "timestamp": 23039010, "height": 1574052, "previousBlock": "4576781903037947065", "numberOfTransactions": 0, "totalAmount": 0, "totalFee": 0, "reward": 500000000, "payloadLength": 0, "payloadHash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "generatorPublicKey": "c0ab189f5a4746725415b17f8092edd3c266d1e758e840f02a3c99547b3a527f", "blockSignature": "c6b2bcc960066be078efbfffed625f61553a7bc18ebde3892636c2f36850de234a9c70ba3e33b606db2eff724398026984e4d391c1fbbe70c94dd9d07ff0060b", "totalForged": "500000000" }

The process for signing the block header is the same as the process for signing a transaction. A SHA-256 hash of the block header is generated, and signed using the key secret of the delegate. Once the block header has been signed, the system generates the blockId following the same logic as transactions.

The completed block header is hashed using SHA-256 and the first 8 bytes of the hash are reversed and used as the blockId. A signed block generates its blockId using the following flow:


Block Payload

The payload of the block is comprised of up to 25 unconfirmed transactions present on the system signing the block. The maximum number of available transactions up to this limit will be included, provided that the payload for a transaction doesn’t exceed the max size for each transaction type. These max sizes are listed below:

lisk block payload

The max size of a block payload can then be determined as 58150 bytes with if every transaction is type 3 and contains the maximum number of assets. A data block is composed using the gathered unconfirmed transactions’ data blocks and signatures. The system then hashes the combined transactional data blocks to generate the block payload.

Block Generation

Block Generation occurs every 10 seconds within the Lisk network using DPoS consensus, as described in Consensus. A delegate is an account that has been given the right to generate blocks by a process of election from other Lisk holders.

Block generation requires 51% of peers to maintain broadhash consensus which is described in Broadhash Consensus. Once broadhash consensus is established the node will generate a block using the techniques described in Blocks.

In Lisk, transactions are designated by type. These transaction types include:

lisk block transaction type

Transaction Signing

Every transaction, regardless of the type, must be signed by the sender prior to being accepted by the network. The process of signing the transaction is identical for every transaction. First, a data block representing the transaction must be generated.

Each data block contains a specific set of standardized information. Additional information contained in the data block will differ depending on the type of the transaction. The following fields must be present in all types of transactions:

A 8 bit integer identifying the type of the transaction

A 32 bit epoch timestamp of when the transaction has been created

The 256 bit public key of the issuer of the transaction

A 64 bit integer representing the amount of Lisk to be transferred

The other fields will be added to this schema depending on the transaction type. Once the data block has been generated, it is hashed using the SHA-256 algorithm, and this hash is signed using the key pair of the issuer. If the issuer has enabled a second pass phrase, the first signature is appended at the end of the data block, and the process is repeated, generating a second signature.

The same concept applies to multisignature accounts. The transactionId is generated from the data block. In order to compute the transactionId the system takes the data block with the completed signature information and hashes this block using SHA-256 and the first 8 bytes of the hash are reversed and which is then used as the transactionId. A signed transaction uses the following flow:


With a second signature the flow looks like this:


Balance Transfer Transaction

A balance transfer transaction (type 0) is a transfer of Lisk from one account to another account. In order to issue a balance transfer transaction, the following fields must be specified:

The account Id of the recipient

The amount of LSK to transfer

The secret of the account

Once those three fields have been specified, the system will begin building the transaction object. First, the public key of the sender is computed using their secret. Following this, the data block is created using the process outlined in Transaction Signing and the additional field, recipientId, is added the to object. The resulting data block is 53 bytes.

This block is then signed using the method described in section 2.1. The final step of the transaction generation process is to compute the fee of the transaction. In the current system, the fee is fixed at 0.1 Lisk. Once all these steps have been completed and the transaction validated, the transaction may be broadcast on the network.

While the transaction may be present on the network, it will remain in unconfirmed status until it has been processed by a delegate. When the transaction is broadcast to the network and it is sent as a JSON object using the HTTP API. The following figure is a representation of a transaction object:


The following figure is a representation of the JSON.

JSON { "type": 0, "amount": Amount, "senderPublicKey": Public key of the sender, "timestamp": Timestamp, "recipientId": Id of the recipient, "signature": Signature of the data block, "id": Id of the transaction, "fee": 10000000, "senderId": Id of the sender, ... }

The final size of a balance transfer transaction with no second pass phrase is 117 bytes, and 181 bytes with a second pass phrase.

Second Signature Registration Transaction

A second signature registration transaction (type 1) is used to register a second passphrase on the blockchain. In order to issue this type of transaction the following fields must be specified:

secret: The secret of the account.

secondSecret: The desired second pass phrase.

Once those two fields have been specified the system will begin building the transaction. The process outlined in section 5.1 is followed for this process. The second public key is generated from the second pass phrase, and the system builds the data block of 85 bytes.

This data block is then signed using the user’s secret ks, and the signature is appended to the object. Following this the computation of the fee is performed for the transaction type. In the existing implementation the fee for a signature transaction is fixed at 5 Lisk. The resulting object is represented by the following diagram:


The JSON object that will be broadcast on the network is represented by the following diagram:

JSON { “type”: 1, “amount”: 0, “senderPublicKey”: Public key of the sender, “timestamp”: Timestamp, “recipientId”: null, “signature”: Signature of the data block, “id”: Id of the transaction, “fee”: 500000000, “senderId”: Id of the sender, “asset”: { “signature”: { “publicKey”: The public key associated with the second passphrase } } … }

The final size of the transaction, with the signature, is 149 bytes.

Delegate Registration Transaction

A delegate transaction (type 2) is used to register the account as a delegate. Refer to section 6.1 for more information about delegates. In order to issue a delegate registration transaction the following fields are required:

secret: The secret of the account.

username: The delegate’s username.

The length of the username must be at least one character and at most twenty characters. Once those fields have been specified, the system can then compute the account's public key, and begin building the transaction’s data block with a maximum 73 bytes.

This data block is then signed using the account's secret, and the signature is appended to the transaction object. The system then computes the fee of the transaction. In the present implementation, the fee for a signature transaction is fixed and costs 25 Lisk. The resulting object is represented by the following diagram:


The JSON object that will be broadcast to the network is the follows the format below:


{ “type”: 2, “amount”: 0, “senderPublicKey”: Public key of the sender, “timestamp”: Timestamp, “recipientId”: null, “signature”: Signature of the data block, “id”: Id of the transaction, “fee”: 10000000000, “senderId”: Id of the sender, “asset”: { “delegate”: { “username”: The chosen username “publicKey”: The public key of the delegate (the sender) } } … }

The final maximum size of the transaction, with the signature, is 137 bytes, and with a second signature, 201 bytes.

Vote Transaction

A vote transaction (type 3) is a transaction used to vote for delegates. In order to issue a vote transaction, the following two fields are required:

secret: The secret of the account.

delegates: An array of votes.

A vote is prepended with a ’+’ for adding stake to the delegate’s public key, and a ’-’ is prepended to the delegate’s public key if the account wants to remove the vote for the delegate. The maximum number of vote applications in one transaction is 33. Once those fields have been specified, the system can then compute the account's public key, and start building the transaction’s data block with a maximum 2198 bytes.

This data block is then signed using the account's secret, and the signature is appended to the transaction object. The system will then compute the fee of the transaction. In the current implementation, the fee for a vote transaction is fixed at 1 Lisk. The resulting object is represented by the following diagram:


The JSON object that will be broadcast to the network is the follows the format below:

JSON { "type": 3, "amount": 0, "senderPublicKey": Public key of the sender, "timestamp": Timestamp, "recipientId": Id of the sender, "signature": Signature of the data block, "id": Id of the transaction, "fee": 100000000, "senderId": Id of the sender, "asset": { "votes": Array of votes } ... }

The final maximum size of the transaction, with the signature is 2262 bytes, and with the second signature is 2326 bytes.

Multisignature Registration Transaction

A multisignature registration transaction (type 4) is a transaction used to add a multisignature to an account. Refer to section 3.3 for more information about multisignatures. The following fields are needed in order to issue a multisignature registration transaction:

secret: The secret of the account the multisignature will be applied to.

keysgroup: The array of keys to add or remove from the multisignature account.

min: The minimum amount of signature required to validate a transaction. (Minimum of 2)

lifetime: The time to wait for enough signatures before removing the transaction.

Each public key in the keys group is prepended with a ’+’ then the public key to be added to the multisignature account. The minimum amount of signature required to validate a transaction must be at least 2 and at most 16. The minimum amount of keys in the keysgroup is two. The lifetime is specified in hours and a must be at least 1 hour and at most 24 hours.

Once those fields have been specified, the system will then compute the account's public key, and start building the transaction’s data block. The size of the data block depends on the amount of keys added to the multisignature registration transaction. Each key is 65 bytes due to the addition of the modifier.

This data block is then signed using the user’s secret, and the signature is appended to the transaction object. The system will then compute the fee of the transaction. In the present implementation the fee for a multisignature registration transaction is 5 Lisk per key in the keygsgroup. Note that the key of the account issuing the transaction is implicitly added in the multisignature. The resulting object is represented by the following diagram:

The JSON object that will be broadcast to the network is the follows the format below:

JSON { "type": 4, "amount": 0, "senderPublicKey": Public key of the sender, "timestamp": Timestamp, "recipientId": null, "signature": Signature of the data block, "id": Id of the transaction, "fee": Transaction fee, "senderId": Id of the sender, "asset": { "multisignature": { "min": The minimum of signature required, "lifetime": The lifetime of the transaction, "keysgroup": Array of keys to add in the multisignature } } ... }

The final size of a transaction with two keys in the keys group is 249 bytes, and 313 bytes if the account has a second pass phrase enabled.


Lisk uses Delegated Proof of Stake (DPoS) [4] as the consensus system. Delegates generate all of the blocks within the system and these delegates are chosen through a highly competitive election system driven by stakeholders. The number N (currently N = 101) of delegates are chosen to forge by all stakeholders.

Each stake holder may vote for up to 101 delegates, and the weight of the vote depends on the amount of Lisk the stake holder possess. A stake holder can vote for a delegate using a vote transaction (See Vote Transaction).

Consensus is a required aspect of any blockchain system. It serves a vital purpose for the system where there are many nodes and all nodes must agree on the integrity of the data. All nodes participating must agree on what transactional data is legitimate in order to move the blockchain forward.


A delegate is a type of account that has registered using a delegate registration transaction, mentioned in section 5.4. These accounts have a special purpose within Lisk as they are allowed to generate blocks for the system provided that the delegate has been allocated enough stake by other users of the system. Any account may become a delegate, but only accounts with the required stake are allowed to generate blocks.

Delegate Round

A round within the system is exactly N blocks in length (N is identical to the total forging delegates). During one round, each delegate will forge exactly one block. If an elected delegate cannot forge during a round another delegate will forge their block instead.

At the beginning of each round, each delegate is assigned a slot indicating their position in the block generation process. Once a node with an enabled active delegate has forged a block, the node associated with the delegate includes up to 25 transactions into the block, signs it and broadcasts that block to the network. Once the block has reached the network, the next delegate will forge in the slot assigned to them.

In Lisk, there are various incentives provided to make running a node appealing. The first of these is the block generation reward and the other reward is the accrual of fees for securing the network as an active delegate for the round in which that delegate participates.

Block Rewards

As with bitcoin and nearly all other blockchain systems, Lisk rewards the block generator a fixed amount of tokens per block successfully generated and accepted by the system. In Lisk's system, all active delegates that successfully participate are rewarded for securing the network. The timeline for these block rewards are represented in the following figure:

lisk reward reduction

The block reward linearly decreases over the lifetime of the network, providing significant incentive to actively participate as an active delegate. The reward will decrease every 3.000.000 blocks from the initial reward block.

Round Fees

The second incentive provided by the system comes in the form of round fees. A round, described in section 6.1, comes to a close after the number of specified blocks has been generated. During this closure process, all transactional fees are aggregated and subsequently split between all active participates in the round.

These fees can provide significant reward for each participant outside of the block generation reward, provided there is significant transactional activity present in the system.

It is possible for a delegate to earn multiple shares of these fees. This may occur if a delegate forges multiple blocks within a round. In most circumstances this will not occur, however occasionally another delegate node may be offline during the delegate's assigned slot and subsequently will be unable to generate a block for the assigned slot. This means that the delegate misses its slot and another delegate will therefor generate multiple blocks during the round instead.

Peers Communication

Peers communication serves a vital function within the Lisk network. The peering mechanisms provide the required architecture to facilitate network consensus, block propagation and transaction propagation.

System Headers

Within the Lisk network system headers are used to identify full nodes and provide a basic set of information about the software running on the system. During peers communications these headers are added to all messages sent between peers. The following JSON object is generated from system data for this purpose and will be broadcast to the network during all communications:

JSON { "os":"darwin16.3.0", "version":"0.6.0a", "port":7000, "height":1574654, "nethash":"da3ed6a45429278bac2666961289ca17ad86595d33b31037615d4b8e8f158bba", "broadhash":"c7e0902a7016205d456a427edda2b09f4b875f98ef40a224018a0274347146ac", "minVersion":">=0.5.0" }

Broadhash Consensus

Broadhash consensus serves a vital function for the Lisk network in order to prevent forks. In the DPoS system, delegates are assigned slots based on timestamp and will attempt to forge a block when the system designates that delegate slot as ready. Broadhash consensus ensures that a majority of available peers agree that it is acceptable to forge.

Broadhash is established as an aggregated rolling hash of the past five blocks present in the database. All peers with the same blocks will produce the same broadhash and propagate that information via the system headers described in section 8.1.

Block Propagation

Block propagation serves a vital function within the Lisk network. Blocks are made in a decentralized fashion and must be sent to all nodes found on the network in order to establish consensus. When a block is generated, it is broadcast to peers which broadcast that block to other peers. Without block propagation, the system would grind to a halt and the blockchain would cease to be functional.

Broadcast Queue

The broadcast queue serves a fundamental role for the Lisk network. Transactions must move from one node to all other nodes in order to be included in blocks. The broadcast queue works by grabbing up to 25 transactions from the transactions pool and aggregating them into a bundle.

This bundle is then broadcast to the network on an interval, which is currently specified as every 5 seconds. In addition to broadcasting the object, the bundle is given a relay limit to prevent over broadcasting of data. In the current implementation the relay limit is set as 2, which means every bundle will be broadcast once from the originating node, and twice more from receiving nodes.

Transaction Pool

The transaction pool provides the Lisk network a very robust solution for preserving unconfirmed transactions that have overflowed into the next block. As mentioned in section 6, each block may only include 25 transactions and the transaction pool allows for up to 5.000 transactions to remain queued for the next block(s). The transaction pool could be thought of as a memory pool keeping transactions ready until they are signed into a block.

The second usage of the transaction pool is to provide a mechanism for propagating transactions. When a node prepares a transaction bundle, that node draws up to 25 transactions from the pool and performs validation on those transactions. These transactions are then broadcast to other nodes in a bundled JSON object. This can be represented as an array of objects of every transaction type listed in section 5.

In order to keep the transaction pool tidy, all transactions are given a time to live. This time to live is defined as 10800 seconds, or 1080 blocks.

The final use for the transaction pool is to house transactions with pending signatures. These transactions with pending signatures following the same model as unconfirmed transactions. This way multisignature transactions that are isolated as incomplete within the transaction pool. Like unconfirmed transactions, these transactions will expire out of the pool based on the lifetime specified when the transaction is first generated.

Latest Lisk News

Lisk Rebrand — Development Timeline

Identity and positioning are essential components of a strong brand strategy. They define how the company communicates with its key stakeholders at every touchpoint. Here at Lisk, we treat these values with utmost importance and have been working tirelessly since the beginning of the year to clearly articulate our vision and ambitions.

what is Lisk

Introducing Six New Lisk Team Members

As the summer comes to a close, great changes are abound here at Lisk. Max and Thomas kicked off their Asia tour in Shanghai with Seoul, Tokyo and Mumbai up next. Be sure to follow Lisk on Twitter and Facebook for updates from their trip. To accommodate the rapid growth Lisk is experiencing, we have hired new talent and are working hard to implement more comprehensive resources for the Lisk community.

Product development is at the top of our priority list so you will see continued growth of our development team over the next months. From a business perspective, one of our biggest endeavours is to help educate people about Blockchain technology, therefore we now have dedicated marketing resources to Lisk Academy.

It is often asked how serious we are about expanding the team. The headcount of our Berlin office has grown by six in the last two weeks alone. These new team members will help promote Lisk’s accelerated growth.

what is Lisk