Celebrating Six Years of Post-Quantum Security: The Journey of QRL

Read More

The QRL Hardfork blockheight has been set! Bromine code is released!

Blockheight is set for 942375 — approximately April 6th

technical multisig bromine

23rd March 2020

The QRL Hardfork (codename Bromine) is set to trigger at blockheight of 942,375 — approximately April 6th.

The code has been released as well, which means everyone who’s running a mainnet node** is encouraged to update** (instructions below).

Update to the latest release

If you are not running a node and just holding Quanta, there’s nothing that you need to do (Though we’d encourage you to run a node!).

If you are running a mainnet node, you can update to the latest release now by stopping your node and issuing the following command:

`pip3 install qrl --upgrade`

The first thing it will do is update the previous state which can take several hours (~8). You can read more here: https://docs.theqrl.org/hardfork/bromine/information/ Release can be found here: https://github.com/theQRL/QRL/releases/tag/v2.0.0

Major changes

Quantum secure multisignature addresses & transactions

Multisig allows multiple parties governance over how allocated funds can be spent.

Examples are numerous, including:

  • Petty joint account — where either party can spend funds

  • Savings account — where signatures from both parties are required to spend funds.

  • Two-factor Authentication wallet — where you have the confirm the transaction from another device.

To use it, you’ll need to use the latest wallet after the hardfork. From there it’s a matter of 1, 2, 3… 4, 5.

  1. Create a multisignature wallet.
  2. Add funds to a multisignature wallet.
  3. Any signatory can submit a spend transaction proposal
  4. Votes are cast to accept or reject the proposal
  5. When the threshold is reached before the blockheight is hit, the transaction is issued.

For more information on this, be sure to check out our youtube video “What Does a Quantum Secure Implementation of MultiSig Look Like? — Episode 005”

Ephemeral messaging latticeTX — Project Mercury

Dubbed as “Project Mercury”, ephemeral messaging has been a long awaited feature of QRL but was temporarily set aside to ensure the timely release of mainnet, and the stability of the core network.

Now with the Bromine hardfork release, you’ll be able to use all the functionality to create an ephemeral messaging application with the qrl-cli: https://github.com/theQRL/qrl-cli/

For the moment, you’ll still need to create your own off-chain network, but this sets the stage for go-qrl, where everything can be incorporated on-chain for a fully decentralized, quantum secure, ephemeral messaging network!

From https://github.com/jplomas/ephemeral-chat-pocvery WIP

If you want to get into the details of ephemeral messaging, be sure to take a look at our ephemeral messaging system whitepaper: https://github.com/theQRL/ephemeral/blob/master/EMS_whitepaper_v1.pdf

Other minor changes

Environment switch

Ability to toggle mainnet or testnet with a network-type argument to start_qrl.

Note: To run both at the same time, it’s still necessary to change ports in config.yml of one of the nodes.

Added addr_to field in message transaction

Now an address can be added to an 80 byte message transaction, allowing for assignable messages on the blockchain.

Added message_data to transfer transaction

Allows for on-chain transactions to include references to transaction ID’s in things like e-commerce applications.


  • New API has been added to support data related to new transactions
  • Address State has been optimized
  • Legacy API support for wallet daemon & grpcProxy
  • grpcProxy & wallet daemon both support — network-type as an argument
  • Updated versions for some of the dependencies
  • Added more unit tests covering different scenarios

Jack Matier


Jack Matier