Qclient commands

With the release of Quilibrium 2.0, the node application comes with the /client folder for you to have better visibility on your node's conditions, earned rewards and perform transfer transactions.

The Q1 - Node Manager has now an option to open a "Qclient Actions" submenu with all the Qclient commands for easy of use.

How to run the qclient commands

For the commands to work you need to be in your "ceremonyclient/client" folder: cd ~/ceremonyclient/client/ for default node installations, or in the folder where your client binary is located.

To run the qclient commands, you need to execute your qclient binary, followed by the command and optional flags. One important flag is --config /path/to/config, without this flag the command will fail, unless you run it from inside the "node" directory (or whichever directory contains your .confg folder). Here is an example of a command:

./qclient-version-os-arch command --config /path/to/config

This translates to the following for v2.0.1 on Linux:

./qclient-2.0.1-linux-amd64 token balance --config $HOME/ceremonyclient/node/.config

Every time you see "qclient" in the commands below, it actually refers to something like ./qclient-version-os-arch

Querying Balance

The command line tool accepts arguments in either decimal (xx.xxxxx) format or raw unit (0x00000) format. Note that raw units are a multiple of QUIL: 1 QUIL = 0x1DCD65000 units

Command:

qclient token balance

Response:

$ qclient token balance
50.0 QUIL (Account 0x23c0f371e9faa7be4ffedd616361e0c9aeb776ae4d7f3a37605ecbfa40a55a90)

Querying Individual Coins

Users may want to view the individual coins:

Command:

Response:

Creating a Pending Transaction

Quilibrium's token application has two modes: a two-stage transfer/accept (or reject), or a single-stage mutual transfer.

Commands in Qclient 2.0.x

Here is the command you run in qclient 2.0.x

Commands in Qclient 2.1.x

From Qclient 2.1.x you can send more complex commands and you will receive a more complete response

Omitting the RefundAccount will simply provide your own originating account. The option to specify exists so that you can maintain anonymity when sending by creating a fresh account to receive the refund. The RefundAccount cannot be the same as the ToAccount.

The first is a user-friendly version of a transfer, similar to what account-based networks like Ethereum and Solana do, where you operate on a balance. Behind the scenes, the client is actually splitting and/or merging coins as needed to create the required amount to send as a discrete coin. The second is an application-aware version of a transfer, similar to what UTXO-based networks like Bitcoin do, where you operate on the raw coin balance under a specific address. If you have good reason to manage coins separately (yet under the control of the same managing account), you will want to use the second option in conjunction with split/merge operations if needed:

Splitting and merging commands

Both token merge and token split support also operating on up to 100 coins or amounts at a time (although not recommended to use so many). In other words, you can input 3,4,5... 10 coins IDs or amounts instead of just 2.

Accepting a Pending Transaction

To accept a pending transaction, you simply run:

The same applies for rejecting a pending transaction

This creates a separate pending transaction because if the refund address is specified by the originator, and were they to specify another of your own addresses, it would be no different from accepting.

Performing a Mutual Transfer

Pending transactions introduce friction, but without that friction, users can be spammed coins they don't want, or sent coins from an address they do not wish to interact with. If both parties agree in advance to transact, they can perform a mutual transfer, where both parties must be online, but can avoid having to deal with the two-phase transaction. This is great for maintaining privacy (each party's account is private) as well as ensuring a timely completion of a transaction:

On the receiver's side:

and after the sender connects:

On the sender's side:

or if using the raw Coin address:

This will likely be the first unique experience Quilibrium provides to users already familiar with other networks, as privacy preservation is an immediately obvious and first class experience here by showing the user what it can (or cannot) see.

Claiming Rewards

Tokens issued after 1.5.0 are issued by nodes providing their proofs to the Mint Authority functionality of the token application. Claiming those rewards can be configured to be performed automatically (default, generates a new Coin every claim and merges them), or in lump sums at intervals, manually. It is recommended for ease of management that the defaults are applied, so that in the event of hardware failure no rewards go unclaimed.

If you wish to do it manually, however, you will need to run:


Last updated