A Lisk Improvement Proposal (LIP) is a design document providing information to the Lisk community, or describing a new feature for Lisk or its processes or environment. The LIP should provide a concise technical specification of the feature and a rationale for the feature.

We intend LIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Lisk. The LIP author is responsible for building consensus within the community and documenting dissenting opinions.

Because the LIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.

This LIP proposes to replace the literal 25 transactions per block size limit with a byte based block size limit.

This LIP addresses two issues affecting delegate list uniformity found within the reference implementation of the Lisk protocol. It proposes a way to uniformly order the delegates list by hashing each delegate’s unique identifier together with a unique identifier for the round.

Add support for a 64 byte data field to the type 0 transaction type so that custom identifiers, hashes and other pieces of metadata can be optionally attached to every balance transfer on the network.

Add support for a 64 byte data field to the type 0 transaction type so that custom identifiers, hashes and other pieces of metadata can be optionally attached to every balance transfer on the network.

Add support for a 64 byte data field to the type 0 transaction type so that custom identifiers, hashes and other pieces of metadata can be optionally attached to every balance transfer on the network.

Add support for a 64 byte data field to the type 0 transaction type so that custom identifiers, hashes and other pieces of metadata can be optionally attached to every balance transfer on the network.

This LIP proposes to remove the hash-then-sign paradigm for block and transaction signatures in the Lisk protocol. That means, block or transaction data should be signed instead of the hash digest of block or transaction data. We elaborate on why this paradigm is typically used, and why it provides more disadvantages than advantages in the Lisk protocol, where Ed25519-SHA-512 is used.

This LIP proposes to mitigate transaction replay on different chains by introducing a network identifier as a constitutive component of the signature of a transaction.

This LIP proposes to take the SHA3-256 hash of the block header as the blockID of a block. This implies an increase of the blockID length and the usage of a different hash function. The motivation of the proposal is to increase the security of the Lisk blockchain.

The current protocol allows for and partially enforces the usage of property-value pairs in transaction objects that are neither required nor used. These property-value pairs are contained in the JSON objects used to transmit transactions and in the input messages for the transaction signature and the transactionID generation. This increases the size of transactions and the complexity of the protocol unnecessarily. Therefore, this LIP proposes to remove these redundant properties of transaction objects.

This LIP proposes a dynamic fee system as a free fee market where the fixed fee for all transaction types will be removed and a minimum fee will be defined for every transaction. Any transactions received with a fee below that minimum fee will be rejected. For each transaction, it will be up to the issuer to choose an appropriate transaction fee depending on the network load, which has to be at least the minimum transaction fee.

This LIP proposes to change the consensus algorithm used in Lisk by introducing a mechanism allowing delegates to vote on the correct block at every height and implementing a new fork choice rule. The proposed consensus protocol thereby achieves Byzantine fault tolerance (BFT) and provides block finality guarantees, i.e., guarantees that a block is never reverted.

This LIP proposes to replace timestamps by nonces in transaction objects. No constraints on the order of nonces shall be used. Moreover, the requirement that the combination of address, nonce and network identifier has to be unique is added. This will allow to invalidate pending transactions by reusing the nonce.

This LIP proposes a fee estimation algorithm that suggests a fee depending on the priority of the transaction for the user and the blockchain’s recent history. The algorithm is based on an Exponential Moving Average (EMA). It is implemented in a node of the Lisk network and the wallet queries its output to get the transaction fee estimation for the user.

This LIP proposes some improvements for the multisignature system in Lisk. The first improvement is that only valid transactions from multisignature accounts, i.e. transactions with all required signatures, are accepted and allowed to be forwarded by nodes. This will prevent spamming of the network and the transaction pool. Next, the settings for the account rules become more flexible. This allows, for example, to create accounts that require signatures for m arbitrary public keys from a set of n public keys without making the signature for any public key mandatory. Moreover, the upper bound on the number of participating keys is increased to 64 and the set of signatures of a transaction included in a block becomes immutable. The rules for the existing multisignature accounts do not change with this proposal.

This LIP proposes a new format for addresses (also referred to as Lisk ID). On the protocol level, the proposed address format uses 160 bits of the SHA-256 hash of the public key. On the user interface level, a 30-bit checksum generated by the BCH code proposed in BIP 173 is added and a customized Base32 encoding is used.

The new address format makes the "registration process" (performing at least one transaction per account to associate a public key to an address) obsolete. Moreover, the collision resistance gets significantly increased, and accidentally sending funds to a wrong address becomes almost impossible due to the checksum.

This LIP proposes to use the full SHA-256 hash of a transaction as the transactionID to avoid potential collisions of transactionIDs.

This LIP proposes to take the full SHA-256 hash of the block header as the blockID of a block. This implies an increase of the blockID length. The motivation of the proposal is to increase the security of the Lisk blockchain.

This LIP proposes to include two standby delegates in the forging delegate list of every round to incentivize a greater number of online nodes in the Lisk network. The selection of these standby delegates is done by a Randao-based weighted random selection scheme to ensure the fairness and unpredictability of the process. This scheme is also used to reorder the forging delegates list in every round.

This LIP proposes a change of the voting system used to choose block forgers in Lisk. We suggest to move closer to a proof of stake system by having voters lock their tokens when casting a vote. Consequently, accounts can still vote for multiple delegates, but a given LSK can only be used in a single vote. The goal is to increase the decentralization of the network by creating a healthy competition for active delegate slots.

We also modify the computation of the delegate weights to account for the amount of self-votes cast by the delegates. The proposed system will encourage delegates to maintain a secure and efficient setup as well as have an open communication about their node setup.

This LIP addresses the same issues as the withdrawn LIP 0021 "Change to one vote per account". That LIP and the corresponding forum thread contain valuable information used to create this proposal. We encourage community members to read that LIP in order to understand the similarities and differences between these proposals.

This LIP introduces consequences for breaching the BFT protocol. Adding finality and BFT guarantees to Lisk has been discussed in LIP 0014 "Introduce BFT consensus protocol". That LIP introduces the rules for detecting protocol violations, however, it does not define how to record and punish these violations. This LIP introduces a new transaction type called “Proof of Misbehavior”. This transaction allows users to reveal to the network any BFT protocol violation.

This proposal also specifies the consequences of such a breach of protocol. This is done by modifying the delegate weight calculation and the validity of unlock transactions.

This LIP introduces a new rule for the validity of transactions, which implies that the balances of sender and recipient cannot go below a certain constant value, minBalance, defined by the protocol.

This LIP introduces a procedure to assert the validity of blocks containing multiple interdependent transactions. This is done by defining a general way to order transactions. We then consider a block valid if every transaction is valid against the transitory state leading up to it.

This LIP proposes a serialization method that is generic, deterministic, size efficient and deserializable. This method could be used to serialize arbitrary data for hashing and signing but also for storing and transmitting. This could be applied to (custom) transactions, blocks or account states. Concrete use cases will be defined in separate LIPs.

The encoding is based on protocol buffers proto2, also referred to as protobuf, with a few additional requirements. Instead of providing a .proto file, users will specify the serialization schema as a JSON schema. The encoding is kept compatible with protobuf in the sense that protobuf implementations with the adequate .proto file deserialize binary messages correctly.

This LIP defines a generic serialization for transactions by specifying the appropriate JSON schema. The proposed serialization method is applied in two steps, first to the asset property, where type-specific properties are defined, and then to the base transaction object. It will be used for signing but also for storing and transmitting transactions in the Lisk protocol. Further, this shall be the default serialization method for custom transactions created via the Lisk SDK.

This LIP defines how the generic serialization defined in LIP 0027 is applied to blocks by specifying the appropriate JSON schema. We restructure the block header and introduce the block asset property, storing properties specific to the corresponding chain. We further specify the block-asset schema for the Lisk mainchain.

This LIP defines how the generic serialization algorithm will be applied to accounts by specifying the appropriate JSON schema. We specify how the different address format introduced in LIP 0018 will be handled, to ensure that all of the account states are consistent across all Lisk nodes.

The purpose of this LIP is to define a generic Merkle Tree structure and a format for proof-of-inclusion that can be used in different parts of the Lisk protocol.

This LIP proposes to remove the payloadHash value stored in each block header and replace it with transactionRoot, the root of a Merkle tree built from the transactions included in the payload.

This LIP proposes a consistent versioning system for transaction types. This versioning system may also be used in the SDK for custom transaction development.

This LIP defines a new block asset schema that allows to specify an initial state of accounts and an initial delegate list valid for a certain bootstrapping period.

This LIP defines how a unique snapshot block can be computed from the Lisk mainnet blockchain up to a certain height.

This LIP proposes to replace the type property in transaction objects by two new properties: moduleID and assetID. Both properties moduleID and assetID together must correspond to one unique transaction schema, transaction validation and execution logic.