Add CryptoX to documentation

source/mainnet/net/browser-wallet/connect-app.rst

@@ -5,7 +5,33 @@
 Connect dApps to wallets
 ===================================
 
-You can connect the |bw| and |mw-gen2| to a `dApp <https://en.wikipedia.org/wiki/Decentralized_application>`__ that has a frontend interface so that you can pay for services. You can initiate the request from within the |bw| or |mw-gen2|, or the dApp can initiate a connection request that you must confirm. Connection can be made by either scanning a QR code or from a link to the dApp service.
+You can connect the |cryptox|, |bw|, and |mw-gen2| to a `dApp <https://en.wikipedia.org/wiki/Decentralized_application>`__ that has a frontend interface so that you can pay for services.
+Connection can be made by either scanning a QR code or from a link to the dApp service.
+Then, the dApp can initiate a request that you can confirm from within the wallet.
+
+.. dropdown:: |cryptox|
+
+ To connect your |cryptox| to a dApp:
+
+ #. Tap the scan QR code button in the Accounts overview |scan-qr-overview|.
+ #. On the next screen, you can choose the account you want to use. Tap **Allow** to continue using your account with the dApp.
+
+ .. image:: ../images/cryptoX/cryptoX-connect-dapps1.png
+ :alt: screen with text boxes for each account
+ :width: 50%
+
+ #. After making your purchase in a dApp, confirm the purchase in the |cryptox|. On the sign transaction screen review the transaction details. Tap **Sign** if you approve the transaction.
+
+ .. image:: ../images/cryptoX/cryptoX-connect-dapps2.png
+ :alt: screen with information about session and options to accept or decline
+ :width: 50%
+
+ #. When the transaction is submitted, tap **Finish** to teturn to the account screen.
+
+ .. image:: ../images/cryptoX/cryptox-connect-dapps3.png
+ :alt: screen with information about session and options to accept or decline
+ :width: 50%
+
 
 .. dropdown:: |bw|
 

source/mainnet/net/concepts/concepts-baker.rst

@@ -2,7 +2,7 @@
 .. _baker-concept:
 
 ==========
-Validators
+Validation
 ==========
 
 Validation is key to the Concordium blockchain. A :term:`node` is a validator node when it participates actively in the network by creating new :term:`blocks<block>` that are added to the chain. The blockchain consists of multiple :term:`validator` nodes. A :term:`validator` collects, orders, and validates the :term:`transactions<transaction>` that are included in a block to maintain the integrity of the blockchain. The validators sign each block that they produce so that the block can be verified and executed by the other validators in the network.
@@ -50,13 +50,23 @@ Time concepts
 
 The Concordium blockchain divides time into :term:`epochs<epoch>`.
 
-When considering the rewards and other validation-related concepts, the concept of an *epoch* is used as a unit of time that defines a period in which the set of current validators and stakes are fixed. Epochs have a duration of 1 hour and the duration is fixed at the :term:`Genesis block`. Each epoch has a nominal ending, and when a block is finalized after this nominal ending then epoch transition occurs.
+When considering the rewards and other validation-related concepts, the concept of an *epoch* is used as a unit of time that defines a period in which the set of current validators and stakes are fixed.
+Epochs have a duration of 1 hour and the duration is fixed at the :term:`Genesis block`. Each epoch has a nominal ending, and when a block is finalized after this nominal ending then epoch transition occurs.
 
-Epochs are subdivided into :term:`rounds<round>`. In each round either a block is produced by the elected leader and validated by (2/3 of) the other validators, or a timeout is produced if the timeout time is reached before a block and its :term:`quorum certificate` are produced. In the case of a timeout, a :term:`timeout certificate` is produced for the block. The timeout time for the next round may shrink or grow depending on whether a block was finalized or a timeout occurred in the previous round. Using :term:`consensus protocol<Concordium Byzantine Fault Tolerance (BFT) protocol>`, a validator has to add the new block after the block from the previous round, unless a timeout occurred in the previous round, in which case they can add their block to an older round. The list of lottery winners that are :term:`elected to be the leader for every round in that epoch<Leader Election>` is established at the beginning of the epoch.
+Epochs are subdivided into :term:`rounds<round>`. In each round either a block is produced by the elected leader and validated by (2/3 of) the other validators,
+or a timeout is produced if the timeout time is reached before a block and its :term:`quorum certificate` are produced.
+In the case of a timeout, a :term:`timeout certificate` is produced for the block. The timeout time for the next round may shrink or grow depending on whether a block was finalized or a timeout occurred in the previous round.
+Using :term:`consensus protocol<Concordium Byzantine Fault Tolerance (BFT) protocol>`, a validator has to add the new block after the block from the previous round,
+unless a timeout occurred in the previous round, in which case they can add their block to an older round.
+The list of lottery winners that are :term:`elected to be the leader for every round in that epoch<Leader Election>` is established at the beginning of the epoch.
 
-A :term:`pay day` is the point at which new CCDs are minted and rewards are distributed to validators and delegators. The stakes of validators and delegators are updated each pay day (but the changes for each pay day are fixed one epoch before). Pay day is thus when new validators begin producing blocks, and updates to delegation and validation take effect, such as increasing stake, restaking preferences, adding delegation. In the case of decreasing stake or removing delegation or validation, there is a longer cool-down period, after which the change is executed at the **next pay day after the cool-down period ends**. The cool-down period is 3 weeks. Pay day is every 24 hours (i.e., 24 epochs) at approximately 09:00 UTC on Mainnet and approximately 12:00 UTC on Testnet.
+A :term:`pay day` is the point at which new CCDs are minted and rewards are distributed to validators and delegators.
+The stakes of validators and delegators are updated each pay day (but the changes for each pay day are fixed one epoch before).
+Pay day is thus when new validators begin producing blocks, and updates to delegation and validation take effect.
+Pay day is every 24 hours (i.e., 24 epochs) at approximately 09:00 UTC on Mainnet and approximately 12:00 UTC on Testnet.
 
-A :term:`cool-down period` describes a period of time during which certain activities or transactions are frozen. For example, if you decrease a valiator's stake, the stake will be decreased at the first pay day after the cool-down period ends. The cool-down period is 3 weeks. During the cool-down period, you’ll not be able update the stake. After the cool-down period, the amount by which you decreased your stake is returned to your disposable balance at the next :term:`pay day` and your stake is reduced to the amount you specified. (This also means that any rewards that are earned in this period, if restaking earnings is enabled, will also be unstaked after the cool-down period.)
+In the case of decreasing stake or removing delegation or validation there is a :term:`cool-down period` of three weeks during which the unstaked funds are frozen.
+For example, if you decrease a valiator's stake, the stake will be decreased at the first pay day but the funds will not be released to your disposable balance until after the cool-down period ends.
 
 Validator keys
 ==============
@@ -68,13 +78,13 @@ Validator account
 
 Each account can use a set of validator keys to register a validator. Whenever a validator produces a valid block that gets included in the chain, a reward is paid to the validator's account (and the staking pool delegators if they have a pool) at :term:`pay day`. The reward is derived from transaction fees paid for transactions included in the block and its predecessors, as well as from newly-minted CCDs.
 
-The account can be viewed in the Desktop Wallet, the |mw-gen2|, the |mw-gen1|, or the |bw| depending on where the account was created.
+The account can be viewed in the |cryptox|, the Desktop Wallet, the |mw-gen2|, the |mw-gen1|, or the |bw| depending on where the account was created.
 
 Rewards are added to the staked amount by default. However, you can choose to receive the rewards in the account balance instead of staking them automatically.
 
 .. Note::
 
- It is not possible to have multi-signature validator accounts in |mw-gen2|, |mw-gen1|, or |bw|. If you need this functionality, you need to run the Desktop Wallet.
+ It is not possible to have multi-signature validator accounts in |cryptox|, |mw-gen2|, |mw-gen1|, or |bw|. If you need this functionality, you need to run the Desktop Wallet.
 
 Staking pool
 ============
@@ -97,7 +107,7 @@ A block is final at a minimum of two seconds after its creation. A new block has
 Tools to be a validator
 =======================
 
-Validation is possible with |bw|, |mw-gen2|, |mw-gen1|, ``Concordium-client``, and Desktop Wallet, however the process differs between them. The overviews below give a brief description of the process.
+Validation is possible with |cryptox|, |bw|, |mw-gen2|, |mw-gen1|, ``Concordium-client``, and Desktop Wallet, however the process differs between them. The overviews below give a brief description of the process.
 
 .. Attention::
 
@@ -181,18 +191,19 @@ This overview describes the recommended scenario for running a node and becoming
 
 For information about how to update your validator or stop validation, see :ref:`Change validator options<update-baker-mw>`.
 
-Validation with |mw-gen1| and |mw-gen2|
----------------------------------------
 
-This overview describes the recommended scenario for running a node and becoming a validator on the Concordium blockchain when using |mw-gen1| or |mw-gen2| and running a node.
+Validation with |mw-gen1|, |mw-gen2|, and |cryptox|
+---------------------------------------------------
+
+This overview describes the recommended scenario for running a node and becoming a validator on the Concordium blockchain when using |mw-gen1|, |mw-gen2|, or |cryptox|.
 
 .. dropdown:: Step 1: Set up the node
 
  For validation you must be running a node on the Concordium blockchain. You can run a node :ref:`on Windows<run-node-windows>`, :ref:`on macOS<run-node-macos>`, :ref:`on Ubuntu<run-node-ubuntu>` or using :ref:`Docker<run-a-node>`. You can also have a third-party run a node on your behalf.
 
 .. dropdown:: Step 2: Set up the Wallet
 
- The |mw-gen1| and |mw-gen2| are available for iOS and Android devices. For instructions about download and setup of |mw-gen2|, see :ref:`setup-g2-mobile-wallet`.
+ The |mw-gen1|, |mw-gen2|, and |cryptox| are available for iOS and Android devices. For instructions about download and setup of |mw-gen2|, see :ref:`setup-g2-mobile-wallet`. For instructions about download and setup of |cryptox|, see :ref:`setup-cryptox-wallet`.
 
 .. dropdown:: Step 3: Set up an identity and account
 

source/mainnet/net/concepts/concepts-delegation.rst

@@ -48,14 +48,15 @@ The commission rates for passive delegation are fixed at 25% for both block comm
 Time and cool-downs
 ===================
 
-Changes to the pools take effect every 24 hours at :term:`pay day`. So opening a pool, increasing the stake, moving the stake between pools or between passive delegation and a stakiing pool all take effect at the :term:`pay day`. At pay day, rewards gathered over a 24 hour period are distributed at the same time. If, however, you make a change in delegation in the last :term:`epoch` before pay day, then the change has to wait until the second pay day.
+Changes to the pools take effect every 24 hours at :term:`pay day`. So opening a pool, changing the stake, moving the stake between pools or between passive delegation and a stakiing pool all take effect at the :term:`pay day`.
+At pay day, rewards gathered over a 24 hour period are distributed at the same time. If, however, you make a change in delegation in the last :term:`epoch` before pay day, then the change has to wait until the second pay day.
 
-But decreasing the stake (whether for delegators or validators) is subject to a cool-down period. In other words, once the transaction has been included in a block the cool-down period starts. Unstaking takes effect at the pay day event after the cool-down has elapsed, and the party's stake will be unlocked. During the cool down, the stake is still invested in the pool and earns rewards as before.
+When decreasing or removing the stake (whether for delegators or validators), the unstaked funds are not released until after a :term:`cool-down period`.
 
 Where delegation is available
 =============================
 
-You can :ref:`delegate CCDs<add-delegation>` in the Desktop Wallet, |mw-gen1|, |mw-gen2|, and |bw|. You can also delegate from :ref:`Concordium Client<transactions>`. It is recommended that you use :ref:`CCDScan<ccd-scan>` to research the various validators and pools prior to delegation if you plan to delegate to a specific pool.
+You can :ref:`delegate CCDs<add-delegation>` in the Desktop Wallet, |cryptox|, |mw-gen1|, |mw-gen2|, and |bw|. You can also delegate from :ref:`Concordium Client<transactions>`. It is recommended that you use :ref:`CCDScan<ccd-scan>` to research the various validators and pools prior to delegation if you plan to delegate to a specific pool.
 
 Summary
 =======