Multisignature Accounts

In this article we give an overview of the main improvements related to multisignature accounts introduced in the Network Economics phase of the Lisk Protocol Roadmap. All these changes are formally specified in the Lisk Improvement Proposal 0017 (LIP 0017) that has been thoroughly researched and reviewed.

By Maxime Gagnebin Ph.D.

17 Jun 2020


In this article we give an overview of the main improvements related to multisignature accounts introduced in the Network Economics phase of the Lisk Protocol Roadmap. All these changes are formally specified in the Lisk Improvement Proposal 0017 (LIP 0017) that has been thoroughly researched and reviewed.

We will start with the motivation for supporting multisignature accounts and a quick overview of the current possibilities in the Lisk network. This is followed by describing the improvements that LIP 0017 brings, the new features that will be available after the implementation of the LIP, and how to set up a multisignature account. To conclude, we will present different use cases where multisignature accounts are useful.

![LiskResearch.jpeg </Image> ](

Accounts and Signatures

The concept of multisignature accounts is common in traditional banking or in other blockchain projects like Bitcoin. If you have a multisignature account at your local bank, it may be required to go there in person with the other signers and together do a bank transaction.

On blockchains like Lisk, accounts are linked to public keys, and when a transaction is signed, the network can verify the correspondence between the digital signature and the public key. If the signature is valid, the transaction is processed; on the other hand if it is invalid, the transaction is rejected. Multisignature accounts are very similar except that they are linked to multiple public keys. Transactions spending tokens from a multisignature account need to be signed with signatures corresponding to the set of predefined public keys.

Multisignature accounts are usually described as M-out-of-N. This means that N public keys have been designated as potential signers, however any group of M of them is enough to sign a transaction.


There is often also the option to make some of the signatures from the public key set mandatory. For example, in the setting below, the signature of A is always required with either the signature of B or C.


Current Multisignature Accounts in Lisk

The Lisk blockchain currently offers two functionalities which modify the set of signatures required for a transaction to be valid:

  • Second signature registration is used to add a second mandatory key to a Lisk account.
  • Multisignature registration is used to add optional keys to a Lisk account.

In both those options, a signature corresponding to the original public key is always required. Moreover, adding more than one mandatory public key is only possible by always requiring all registered public keys. The main goal of LIP 0017 is to remove those restrictions and make multisignature registration more flexible.

New Multisignature Accounts

With LIP 0017, the multisignature functionality is improved. The new multisignature registration is more flexible, as it will allow any number of mandatory keys combined with any number of optional keys.

The new multisignature accounts will be characterized by the following three properties:

  • The mandatory keys: Outgoing transactions will require signatures for every public key in this set.
  • The optional keys: Outgoing transactions will require a given number of signatures for public keys in this set.
  • The number of signatures required: This number is the total number of signatures required for outgoing transactions.

The current functionalities of both second signature and multisignature accounts can still be easily reproduced:

  • Current second signature accounts: These correspond to new 2-out-of-2 multisignature accounts with two mandatory public keys, the original public key and the second public key.
  • Current multisignature account: These correspond to new multisignature accounts with one mandatory key and the other keys as optional.
  • Current multisignature and second signature accounts: As a combination of the two above cases, these accounts correspond to new multisignature accounts with two mandatory public keys and other keys as optional.

Following these points, it is possible to register your account with the new multisignature to reproduce any of the current behavior (and more). The current second signature registration is thus no longer useful and is removed. All accounts that are currently registered with a second signature or as a multisignature account, will be automatically converted to new multisignature accounts as described above without any changes to their access rules.

Setting Up a Multisignature Account in Lisk

Any account can be registered as a multisignature account. The only requirement is to send a dedicated multisignature registration transaction from the account to transform the account into a multisignature account. The transaction contains all the information related to the new public keys.


The asset of the Multisignature registration transaction contains all the public keys necessary to set up the multisignature account.

The multisignature registration transaction also has to contain a signature for every key in the multisignature registration (whether mandatory or optional). This avoids the situation of being included in a multisignature account without your consent.

Delegate Account with Multisignature

As you may have noticed, the new multisignature does not require the original public key to be part of the mandatory keys. This can be very convenient as it allows you to create new accounts, register them as a multisignature account with the public keys of the participants, and then forget the keys originally used to create the accounts. Therefore, you only need to remember one key pair, regardless of the number of multisignature accounts you might be part of.

However, if the multisignature account is also registered as a delegate, the original key pair has to be retained. The key pair used for signing block headers is always the original key, and it is not modified by the multisignature registration. Registering delegate accounts with a multisignature is useful to protect the funds in the event of losing the forging key. Nevertheless, it is prudent to keep in mind that delegates who have registered a multisignature should still be careful with the forging key. An attacker could use it to create contradicting blocks, which could result in the delegate being punished for misbehavior.

Use Cases

Additional Safety

Having a 2-out-of-3 multisignature account can be safer than a regular account. The setup could be as described here. One passphrase is stored (encrypted), on your smartphone; one passphrase is stored (also encrypted), on your laptop and the last backup passphrase is stored physically in a safe.

This guarantees that if you lose your phone, or in case your computer fails or gets hacked, you can recover and transfer your tokens to a new account using the backup passphrase. Furthermore, if the phone is stolen, and the thief (or the laptop hacker), manages to decrypt the stolen passphrase, they only have one key and cannot steal the tokens in the account.

Joint Account

A 1-out-of-2 account with no mandatory key can be shared by partners. Each has a key allowing them to spend the tokens in the account. In this way, it is clear who has signed which transaction.

Community Accounts

An account with 1 mandatory signature and 1 optional out-of-N could be used by a social club. The account would require the signature of the accountant and one other member. This way the accountant approves every transaction, which in turn allows them to keep an eye on all the club's expenditure. Additionally, each transaction is also signed by one member of the club, prohibiting the accountant from stealing any of the funds.

Delegate Operated by Multiple Users

Securing enough self-votes to be an active delegate might be easier to achieve for a group than for a single individual. For example, three people could each participate in a multisignature account with three mandatory keys and register this account as a delegate. Now the forging node can safely be operated by any of the participants without risk of losing any funds.

The uses for multisignature accounts are numerous and the above examples are only a small selection of the potential possibilities. For more examples, most of the Bitcoin use cases can be translated to Lisk with this new improvement.

A Technical Note on Broadcasting Transactions from Multisignature Accounts

The current implementation of the peer-to-peer network accepts and broadcasts transactions which do not have all the required signatures if they are sent from a multisignature account. This allows users to share their transaction through the Lisk peer-to-peer network before they are fully signed.

However, this has a significant impact on the performance of the Lisk network and allows the network to be spammed by unsigned transactions which are stored and broadcasted. LIP 0017 removes this problem by requiring that all transactions are validly signed to be accepted by the network. For transactions from multisignature accounts, this means that users have to coordinate and gather the signatures before sending them to the network.

If the key pairs are held by a single user, or in the case of a 1-out-of-N multisignature, gathering the signature will be done directly by the Lisk wallet. Otherwise, the transaction has to be stored, locally or remotely, until the correct number of signatures is reached and the transaction is ready to be broadcasted.

This blog post is a general overview and all the details are given in the specific LIP. For further questions and comments on the topic, we will host an AMA on with Maxime Gagnebin (Research Scientist) this Thursday, June the 18th at 5 pm CEST. We also invite all community members to go to the Lisk Research forum where we are always happy to hear your feedback and to participate in discussions on this and other topics.