Formatting.

docs/sdk-and-tools/sdk-py/mxpy-cli.md

@@ -5,11 +5,11 @@ title: mxpy CLI cookbook
 
 [comment]: # (mx-abstract)
 
-mxpy (Command Line Interface)
+## mxpy (Command Line Interface)
 
 **mxpy**, as a command-line tool, can be used to simplify and automate the interaction with the MultiversX network - it can be easily used in shell scripts, as well. It implements a set of **commands**, organized within **groups**. 
 
-The complete Command Line Interface is listed [here](https://github.com/multiversx/mx-sdk-py-cli/blob/main/CLI.md). Command usage and description are available through the `--help` or `-h` flags.
+The complete Command Line Interface is listed [**here**](https://github.com/multiversx/mx-sdk-py-cli/blob/main/CLI.md). Command usage and description are available through the `--help` or `-h` flags.
 
 For example:
 
@@ -95,7 +95,7 @@ If you'd like to build a smart contract directly using `sc-meta` instead, please
 
 ## Deploying a smart contract
 
-After you've built your smart contract, it's ready to be deployed on the network.
+After you've built your smart contract, it can be deployed on the network.
 
 For deploying a smart contract the following command can be used:
 ```sh
@@ -104,16 +104,16 @@ mxpy contract deploy
 
 To deploy a smart contract you have to send a transaction to the **Smart Contract Deploy Address** and that address is `erd1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq6gq4hu`, but you don't have to worry about setting the receiver of the transaction because the above command takes care of it.
 
-The `--bytecode` argument specifies the path to your previously-built contract. If you've built the smart contract using `mxpy`, the generated `.wasm` file will be in a folder called _output_.
+The `--bytecode` argument specifies the path to your previously-built contract. If you've built the smart contract using `mxpy`, the generated `.wasm` file will be in a folder called `output`.
 
-For example, if your contract is in `~/contracts/adder` the `adder.wasm` file that is the built contract will be in `~/contracts/adder/output`. So, when providing the `--bytecode` argument the path should be `~/contracts/adder/output/adder.wasm`.
+For example, if your contract is in `~/contracts/adder`, the generated bytecode file `adder.wasm` will be in `~/contracts/adder/output`. So, when providing the `--bytecode` argument the path should be `~/contracts/adder/output/adder.wasm`.
 
 The `mxpy contract deploy` command needs a multitude of other parameters that can be checked out [here](https://github.com/multiversx/mx-sdk-py-cli/blob/main/CLI.md#contractdeploy) or by simply typing the following:
 ```sh
 mxpy contract deploy --help
 ```
 
-Let's see an example:
+Let's see a simple example:
 
 ```sh
 mxpy contract deploy --bytecode ~/contracts/adder/output/adder.wasm \
@@ -127,7 +127,7 @@ mxpy contract deploy --bytecode ~/contracts/adder/output/adder.wasm \
 
 Verifying a smart contract means ensuring that the contract deployed on the network matches a specific version of the original source code. That is done by an external service that, under the hood, performs a reproducible build of the given contract and compares the resulting bytecode with the one deployed on the network.
 
-To learn more about reproducible builds, please follow [this](/developers/reproducible-contract-builds). If you'd like to set up a Github Workflow that performs a reproducible build of your smart contract, follow the examples in [this repository](https://github.com/multiversx/mx-reproducible-contract-build-example-sc).
+To learn more about reproducible builds, please follow [**this page**](/developers/reproducible-contract-builds). If you'd like to set up a Github Workflow that performs a reproducible build of your smart contract, follow the examples in [**this repository**](https://github.com/multiversx/mx-reproducible-contract-build-example-sc).
 
 The command used for verifying contracts is:
 ```sh
@@ -151,7 +151,7 @@ The account that triggers the code verification process must the owner of the co
 :::
 
 :::info
-The _packaged source_ passed to `--packaged-src` can be obtained either from [the Github Workflows for reproducible builds](https://github.com/multiversx/mx-reproducible-contract-build-example-sc/tree/main/.github/workflows) set up on your own repository, or from locally invoking a reproducible build, as depicted [here](https://docs.multiversx.com/developers/reproducible-contract-builds/#reproducible-build-using-mxpy).
+The _packaged source_ passed as `--packaged-src` can be obtained either from [the Github Workflows for reproducible builds](https://github.com/multiversx/mx-reproducible-contract-build-example-sc/tree/main/.github/workflows) set up on your own repository, or from locally invoking a reproducible build, as depicted [here](https://docs.multiversx.com/developers/reproducible-contract-builds/#reproducible-build-using-mxpy).
 :::
 
 ## Converting a wallet
@@ -165,8 +165,8 @@ mxpy wallet convert
 
 The available formats are:
  - `raw-mnemonic` - secret phrase in plain text
- - `keystore-mnemonic` - secret phrase, as an encrypted JSON keystore file
- - `keystore-secret-key` - secret key (irreversibly derived from the secret phrase), as an encrypted JSON keystore file
+ - `keystore-mnemonic` - secret phrase, as a password-encrypted JSON keystore file
+ - `keystore-secret-key` - secret key (irreversibly derived from the secret phrase), as a password-encrypted JSON keystore file
  - `pem` - secret key (irreversibly derived from the secret phrase), as a PEM file
 
 :::info