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)

Ephemeral message format proposal

Peter Waterland, Kaushal Singh
Created: 2019-04-24 , status: draft

Ephemeral message format proposal


To extend functionality of the QRL beyond the ledger an off-chain network messaging system known as ‘ephemeral’ is proposed. These lifespan-limited internode broadcast messages may be relayed and stored optionally by agreeable qrl-nodes.

A simple initial format with some DDOS protection is suggested, allowing custom implementations from users or applications wishing to interact with the QRL ledger/network.


A suggested message format is:

Ephemeral message | ID | PAYLOAD |TTL |BLOCKHASH | POW — | — | — | — | — | —

The ID field is a 64 byte identifier. It may be accessed as a complete ID field or two 32 byte separate identifiers (ID0 and ID1). The ID is intended to be a unique nonce.

The payload is the body of the message containing user data. The precise contents are left open but some example schemes will be suggested in a future QIP to enable powerful end-end encrypted data channels. Max field length = 8192 bytes.

TTL is a 32 bit network expiry timestamp following unix time specification. This ‘time to live’ value is a timestamp upon which the network renders the message invalid and proceeds with deletion. Whilst messages are relayed across the network by agreeable nodes they are only held transiently until they expire - hence ‘ephemeral’. Alternatively, this could be replaced with a blockheight?

The first 4 bytes of a recent QRL block-header hash must be supplied as a rough message timestamp. The chance of a random 4 byte guess being successful is allowed_ephemeral_message_blockdepth/2^32. In combination with POW this prevents a determined attacker grinding out a huge number of messages over a long period of time which are then used to flood the network.

POW. Any broadcast protocol is susceptible to spam and each message passed through the network will require a variable amount of ‘work’ to be performed and verified via a supplied pow hash prepended by a byte pow algorithm identifier. This adds a small amount of computation time to confirm message validity. Furthermore, the amount of work required is linked to the TTL expiry timestamp - the longer the shelf-life of the message, the greater work must be expended to attain validity. The pow is performed on a cryptographic hash digest of the message (SHA2_256(ID+PAYLOAD+TTL+BLOCKHASH)), with the resultant pow hash (and prepended byte) appended as the final field of the message.


Activating ephemeral messaging requires minor changes to the qrl-node python and go implementations to relay and prioritise additional traffic. It is anticipated the vast majority of traffic will occur using open source public off-chain centralised message repositories.

New qrl-node configuration parameters for:

  1. ephemeral traffic relay flag (enable or disable)
  2. ephemeral traffic storage flag (enable or disable)
  3. maximum TTL timestamp from current timestamp accepted
  4. valid ephemeral message block depth limit (integer value from current blockheight)
  5. specific pow algorithm support flag
  6. proof of work variables for each algorithm in specification
    • numerical value for minimum valid computed work per message prior to adjustment
    • numerical factor applied based upon TTL timestamp

Furthermore, to allow encrypted data channels via ephemeral messages across the network, lattice tx featuring embedded Dilithium and Kyber pk’s must be activated. This requires a hard fork upgrade to all network nodes. Specific end-end data channel cryptographic implementations will be discussed in future QIPs.

Support Tokenization of Securities

Created: 2019-04-19

Support Tokenization of Securities


One of the biggest potential use cases of blockchains in the future is the tokenization of existing securities to be bought and sold by valid parties. Being the only existing blockchain that is quantum resistant from genesis and adding the functionality of smart contracts, QRL is in a unique spot to capitalize on this opportunity. The QRL team should evaluate whether the functionality of the smart contracts that are currently in progress can support the tokenization of securities on the QRL blockchain. If that is not the case, the team should consider adding additional functionality that allows for such tokenization.


The current usefulness of blockchain is highly debated, and there is much conversation about what “killer app” will eventually drive adoption. One current use of blockchain is speculation, and it is very attractive in this area due to the ability to buy fractions of a coin or token. In contrast, many traditional assets require the purchase of an integer number of the asset. For example, it is difficult to obtain a fraction of a stock or real estate property.

Traditional assets, including stocks, real estate, and derivatives, are estimated to be worth a combined amount of over one quadrillion dollars (source: https://money.visualcapitalist.com/worlds-money-markets-one-visualization-2017/). There is incentive to tokenize existing securites and offer new securities on the blockchain, including the “removal of middlemen… to lower fees, faster deal execution, free market exposure, larger potential investor base, automated service functions, and lack of financial institution manipulation” (source: https://medium.com/@apompliano/the-official-guide-to-tokenized-securities-44e8342bb24f). In addition, security tokenization would raise the credibility of blockchain in the eyes of many traditional investors, as there would be “real value” in the underlying assets.

As of now, QRL is the only existing blockchain that is quantum resistance from genesis and implementing smart-contract functionality. Such functionality is necessary for the tokenization of securities, as the buying and selling of securities is restricted by KYC/AML laws. Given QRL’s unmatched quantum resistance and future-oriented security, the QRL blockchain could be a very attractive platform for security tokenization.

The purpose of this QIP is to urge the QRL team to evaluate whether or not the in-progress smart-contract functionality can support the creation and exchange of security tokens. QRL smart contracts are limited in functionality compared to ETH (where security token standards are currently being created), so the author does not automatically assume that such functionality currently exists. If it does not, consideration should be given to add such functionality.


QRL already has the ability to create tokens, but to be compliant with regulations, it must be possible to restrict transactions of security tokens between wallets if the sending and receiving wallets do not meet certain criteria (example: https://thesecuritytokenstandard.org/); therefore, it would have to be possible to make these checks before a token transaction is admitted to the blockchain.


Several entities are working on platforms for tokenization of securities. Polymath, Harbor, Securrency, and tZero are prominent examples. It may be worth reaching out to them for evaluation and implementation.

Implement dPoW

Created: 2019-03-27 , status: draft

Implement dPoW


Purpose of this QIP is to implement a dPoW mechanisme to strengthen QRL protection against attacks like 51%


Because security is the first concern of QRL project, we have to consider all solutions that can improve its security.

Thanks to hash power provider like NiceHash, we know that it is possible to perform a 51% attack against QRL blockchain for little amount of money.

A test done by a community member (curefrankosflue) demonstrates this figures : “20 MH/s @ 0.0090 BTC /(MH/s x day) means 0.0075 BTC/hour, which turns out the cost of a 5 hour attack at 20mhs to be at 0.0375 BTC or 150 $”

Some projects like Komodo solves this issues by using BTC blockchain to benefit from its hash power.

Also, some project like VeriBlock propose to better secure alternative crypto asset networks using Bitcoin blockchain (concept of proof-of-proof (PoP))

QRL should evaluate the level of protection afforded by lowering the reorg limit versus a DPOW solution that would be based on BTC hashpower.


Lorum ipsum

Backward compatibility

Lorum ipsum


Lorum ipsum

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.

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.

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.

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().