Upcoming hard forks

The first planned QRL network hardfork will soon be announced after upcoming Ledger integration.

Future forks will follow an annual/biannual planned upgrade schedule based upon community consensus.

Upcoming hard fork feature list

  • Multisig addresses
  • Deterministic address support
  • Extended message transaction functionality
  • Decentralised on-chain poll support
  • Backwards incompatible state upgrades and optimisations

Features anticipated for 2019/2020 hard forks include

  • Smart Contracts (Project Silicon)
  • Ephemeral messaging
  • Consensus mechanism change (PoS, dPoS)

Current QRL improvement proposal (QIPs)

Multi-Signature Wallet

Kaushal Singh, Peter Waterland
Created: 2019-02-11 , status: Open

Multi-Signature Wallet


Purpose of this QIP is to initiate development of multi signature wallet support on QRL network, based on finalised specification.


Currently, QRL doesn’t have support to multi-signature wallet address. So to execute any transaction only a proof of signature is required either by the main address or the slave address. Thus the introduction of multi-signature wallet address will fill this gap and will allow multiple authorities to have a transaction from a single wallet once the consent has been established.


In order to create and spend from a multisig wallet new transaction types are required. multisig_create and multisig_spend are the two new transaction types which will be introducted to support multisig wallet.

multisig_create transaction type will be used to create a new multi sig wallet. It will have following input fields other than common transaction fields.

  1. Signatories - List of qrl addresses, will act as signatory. There could be maximum 100 signatories and minimum 2.
  2. Weights - List of integer values which will be denoting the weightage of each signatory.
  3. Threshold - Threshold value is an integer value and any successful multisig transaction must have sum of weights greater than or equals to threshold value.

multisig_spend transaction type is to move funds from a multisig wallet to another address which could be a normal qrl address or another multisig address. It will have following input fields other than common transaction fields.

  1. Multi Sig Address - Multi Sig Address from which amount needs to be spent
  2. Address To - Address which will receive the amount. This could be a normal QRL address or another multi sig address.
  3. Amount - Amount to be spent
  4. Shared Key - Shared key refers to the multi sig spend transaction hash. In case a shared key is provided, this transaction, will not require other details such as multi sig address, address to and amount as these details will be derived from the shared key.

multisig_spend transaction will only be executed once minimum required threshold is met.

Address format of a multisig address

MultiSig addresses will be derived by following to maintain the standard QRL address format.

Prefix ‘Q’ + 3 bytes descriptor + hash of (descriptor + txn hash) + last 4 bytes of the hash of (descriptor + previous hash)

Descriptor Format (https://docs.theqrl.org/developers/address/)

Name Bits Count Description
HF 0 .. 3 4 SHA2-256
SIG 4 .. 7 4 Signature Scheme
P1 8 .. 11 4 Height
P2 12 .. 15 4 Address Format
P3 16 .. 23 8 Not used
  • HF will be 1 for SHA2-256.
  • SIG will be 1 to represent multisig addresses.
  • P1 will be 0 as the multi sig addresses itself doesn’t have any height.
  • P2 will be 0.
  • P3 will be 0 as it is unused.

So a multi sig address generated by multisig_create transaction having transaction hash 5a4c37ef7e5b7cc5a2a58ab730269ed8f4cbf08a005dc3508e31465535e1d6bb will be derived by following

Prefix = ‘Q’

Descriptor = 110000

SHA2_256(Descriptor+Txn hash) = 3674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7

SHA2_256(Descriptor+Prev Hash) = fe2088fb

MultiSig Address = Q1100003674370317e1cac0ca13f896ab5b6472a261ba0d2b2961d3adba1b9060f6e8f7fe2088fb

Backward Compatibility

The introduction of multisig wallet on QRL Node will need a hard fork, as two new transaction will be introduced in it. Therefore, the changes will not be backward compatible.


Implementation of Multisig wallet is in progress.

Extending message transaction functionality

Peter Waterland
Created: 2019-02-21 , status: draft


Message transactions sent on the QRL blockchain network allow broadcast and decentralised storage of 80 bytes of data per transaction for purposes such as notarisation and data stamping. This minor QIP extends the message transaction format to include an optional payee/receipt address.


It would be useful to direct message transactions to a specific destination address rather than simply writing them into the chain in a broadcast manner.

Potential benefits include: 1) allowing message-based interaction between user and smart contract addresses 2) enabling user addresses to exchange message data directly between themselves

For example a smart contract may be scripted to perform certain actions based upon specific message transaction input from a given address. Or a smart contract address associated with a user address could alert a user address with a message transaction if certain thresholds are met (such as changes in balance) or to acknowledge receipt of a payment from a user address to a payee contract address.

Adding a destination address also allows future consensus voting within the QRL network to be refined. (i.e. voting for a specific QIP proposal, contentious network decision or election of addresses to positions of authority within smart contract constructions such as multisignature contract wallets).


Whilst a minor extension to the existing message transaction format this is not backwards compatible with existing versions of qrl-node and therefore requires a hard fork.

MessageTransaction Encoded Message Standard

Scott Donald
Created: 2018-11-03 , updated: 2018-11-12 , status: Open

A standard message encoding format to indicate encoded data in MessageTransaction transactions


The QRL network supports arbitrary messages up to 80 bytes in length to be stored on chain through the MessageTransaction transaction subtype.

There is the capability for second layer clients to read and interpret the data contained within these message transactions, and format interfaces accordingly. This can be seen with the currently implemented Document Notarisation transaction type found on both the QRL Wallet and QRL Explorer applications, and further implemented in the explorer-helpers repository.


This QIP aims to create a new base layer for a standard message encoding format such that other usecases have a framework to build within - for example the coinvote proposal mentioned by @surg0r.


The following will describe the base requirements to indicate a message contains encoded data, and provide further context on earlier usage as has been implemented in the Document Notarisation transaction type.

There are a total of 80 bytes available in a MessageTransaction transaction that are usable. For the purposes of describing the format in this document, we will represent all data as HEX strings. It is worth noting however that the data is later converted to binary bytes for storage by a QRL node.

To indicate a message is an encoded message, the first two bytes are reserved for the following HEX string:


The subsequent two bytes should indicate a unique encoded message transaction type. Each proposal to the community for a new encoded message type will be allocated a unique HEX string for these bytes for client implementations.

eg: 0001, AA01 etc.

The remaining 76 bytes contain any data relevant to the encoded message, and should be proposed to the community through a QIP.

If this QIP is accepted, a record of accepted message transaction sub type and their respective QIP should be kept updated on docs.theqrl.org such that client implementations have the technical detail available to implement with ease. A Github repository will be setup on https://github.com/theQRL/standard-message-encoding to allow community pull requests into this standard encoding format.

Document Notarisation Specification

The following describes the structure of the Document Notarisation message transaction sub type for historical purposes. There are approximately 25 transactions from early stages of the network that utilise this format. It is optional to implement for display purposes.

First 2 bytes: AFAF - Indicates encoded message. Subsequent Half byte: A - Indicates this is a document notarisation message transaction sub type. Subsequent Half byte: 1, 2, or 3 indicating which hash function has been used to notarise the document as per below:

1 - SHA1 (Now deprecated in user interfaces when notarising a document) 2 - SHA256 3 - MD5 (Now deprecated in user interfaces when notarising a document)

The remaining 77 bytes are reserved for both the hash of the document, and a variable amount of free form text depending which hash function was use. For each hash function above, the following describes the remaining 77 bytes utilisation.

1 - SHA1 - Subsequent 20 bytes store the SHA1 hash, with the remaining 57 bytes available for free form text. 2 - SHA256 - Subsequent 32 bytes store the SHA256 hash, with the remaining 45 bytes available for free form text. 3 - MD5 - Subsequent 16 bytes store the SHA1 hash, with the remaining 61 bytes available for free form text.


No immediate implementation work is required for this QIP as it simply states a standard for encoding messages using the QRL networks MessageTransaction transaction type.

Eventual work will be required in any client implementations that wish to adhere to the standard encoding format, such as the public QRL Wallet or Block Explorer

Migrate to Cryptonote v8

Andrew Chiw
Created: 2018-10-30 , status: Open

QIP 1: Migrate to Cryptonote v8 (Cryptonote Variant 2)


This QIP explores the feasibility of migrating to Cryptonote v8, and continuing to change the POW algorithm just like Monero.


ASIC resistance is the most obvious reason, so that GPU miners can participate, thus making mining truly decentralized, instead of the select few who can afford to buy and setup ASICs.

Implementation at library level

Currently, qryptonight implements Cryptonote v7 via hooking into a few important files in xmr-stak, and putting a SWIG wrapper around it.

Since xmr-stak 2.5.0 (931bd5fef17f908afc62836ae7b6ea087d1441ca, unify cpu cryptonight implementations), the internals have changed enough that qryptonight needs to be modified, and xmr-stak needs to be forked.

Once this is done, having qryptonight use Cryptonote v8 is as simple as changing this line:

Cryptonight_hash<1>::template hash<cryptonight_monero, false, false>(input.data(), input.size(), output.data(), &context);

to this:

Cryptonight_hash<1>::template hash<cryptonight_monero_v8, false, false>(input.data(), input.size(), output.data(), &context);

Implementation at node level

This breaks the following tests:


From these tests it appears that the code does not depend too much on the POW algorithm, which is good news.

Backwards compatibility

Both algorithms will need to be present in qryptonight, and qryptonight must be modified to accept an extra argument that specifies which hashing algorithm should be used.

The best place for the node to decide which hashing algorithm should be used is BlockHeader, specifically generate_headerhash() and validate().

The exact block height from which Cryptonote v8 should be used instead of v7 should be defined in config.dev.


This work will have to be duplicated in go-qrl.

Should Monero’s future POW algorithms require a different amount of memory than Cryptonight v7/v8, further modifications need to be made to qryptonight and xmr-stak in cryptonote_alloc_ctx().

Extended address functionality from master XMSS wallet

Peter Waterland, Kaushal Singh
Created: 2018-11-04 , status: draft


Extended address functionality from master XMSS wallet


A suggested change to generate multiple deterministic addresses which may be signed using the XMSS tree associated with a user master address.


Currently QRL uses XMSS to sign transactions and create a single re-usable address for users. Prior to signing a transaction the XMSS tree must be generated with varying computational cost dependent upon the signature capability of the address. Further signature capability may be added by signing slave XMSS trees to extend this scheme infinitely.

However, it would be valuable for users to have access to more than one address from which to send or receive QRL, without the prospect of adding significant computation time and worsening the user experience by generating additional XMSS trees. Given QRL is a public blockchain, such a facility would improve privacy for those not wishing to unnecessarily reveal their primary address balance and transaction history to a payor. i.e. a payor may be given an address to send funds to other than the user master address. Additionally, the easy creation of deterministic addresses allows privacy extension through deliberate usage of one of more change addresses to obfuscate user holdings.


A 51 byte unique seed is used to generate a user wallet in the node or webwallet. The first three bytes are extended seed encoding with the following 48 bytes of random entropy providing the cryptographic seed used in PRF generation of the XMSS tree and subsequent master address.

In addition to the master XMSS tree, the 48 byte random seed may, in a cryptographically secure fashion, be used to generate a deterministic sequence of pseudorandom 32 byte values. This sequence can be trivially generated computationally yet retain the appearance of uniform random output when revealed to an external observer. Furthermore, the seed may not be determined using any or all of the PRF sequence values.

Example solution:

prf_output = SHAKE128(SHA_256(SHA_256(SHA_256(seed[:32] ^ SHA_256(seed[32:])))))

i.e. the first 32 bytes of the seed are xored with a hash of the last 16 bytes of the seed and the result is iteratively hashed three times then passed as input into SHAKE128, where output may be derived as a 256 bit pseudorandom deterministic number sequence.

Existing address format:

An existing standard address is created with the following format (pseudocode):

QRL_address = encoding_bytes + hash_function(xmss_pk)

where encoding_bytes includes the required hash function, signature scheme, xmss tree height etc

where xmss_pk = master_xmss_tree_merkle_root + xmss_public_seed

Suggested new extensible address creation:

Assuming a PRF sequence, prf[n], an additional address may be simply created like:

extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n])

In this way, with each new value in the prf sequence a resultant new address is created for use.

Additionally, a user field such as the hash of a pin or seed phrase may be added to generate a different series of addresses.

i.e. extended_address_n = encoding_bytes + hash_function(xmss_pk + prf[n] + hash_of_user_generated_data)

For ease the address encoding_bytes must match the master address XMSS tree encoding to allow appropriate decoding during spend transaction processing.

Change addresses

QRL uses re-usable addresses. An example transaction may move part of the funds from address a to b. After such a standard transfer transaction an outside observer can see precisely what funds remain in the user controlled master address a. The addition of multiple deterministic addresses to a master address means that the following is now possible: all funds may move from a to b, c and perhaps d. The balance of a is now zero, and an outside observer will not know that some funds were moved to address b and that the user controlling a actually controls the addresses c and d. Whilst the effective final balances of the two users in the transfer transaction remain the same – to an outside observer the precise movements and control of funds are obfuscated.

Backwards compatibility

Optional fields (.extended_pk_address_prf and .extended_pk_address_user) to be concatenated and hashed with pk must be added into the transaction logic in the base Transaction class. Minor state changes required to associate extended addresses with existing master address pk’s following a spend transaction (to preserve OTS safety).

Higher level changes required in terms of tracking, displaying balances and allowing spend functionality from within the webwallet. This latter point will require internal discussion.