doc/testnet: edit for grammar and clarity

doc/src/arch/dao.md

@@ -47,9 +47,9 @@ Brief description of the DAO bulla params:
   a proposal to pass. Normally this is implemented as min % of voting
   power, but we do this in absolute value
 * **early_exec_quorum**: minimal threshold of participating total
-  tokens needed for a proposal to be considered as strongly supported,
-  enabling early execution. Must be greater or equal to normal quorum.
-* **approval_ratio**: the ratio of winning/total votes needed for a
+  tokens needed for a proposal to be considered strongly supported,
+  enabling early execution. Must be greater than or equal to normal quorum.
+* **approval_ratio**: the ratio of yes/total votes needed for a
   proposal to pass.
 * **gov_token_id**: DAO's governance token ID.
 * **notes_public_key**: notes(coins) decryption public key
@@ -421,8 +421,8 @@ it can be executed early. We should add this option to DarkFi DAO params.
 > The full voting period must pass in order to be able to execute a
 > proposal. A new configuration parameter was introduced, called early
 > exec quorum, where we can define the quorum for a proposal to be
-> considered as strongly supported/voted on, which should always be
-> greater or equal to normal quorum. With this addition, we can execute
+> considered strongly supported/voted on, which should always be
+> greater than or equal to normal quorum. With this addition, we can execute
 > proposals before the voting period has passed, if they were accepted.
 
 ~~Currently the DAO public key is used for:~~

doc/src/spec/contract/dao/concepts.md

@@ -50,14 +50,14 @@ no longer vote on the proposal, and it is considered *expired*.
 
 ### Quorum
 
-Quorum is defined as the minimal threshold of participating total governance tokens need for
+Quorum is defined as the minimal threshold of participating total governance tokens needed for
 a proposal to pass. Normally this is implemented as min % of voting power, but we do this in
 absolute value.
 
 ### Early Execution Quorum
-Early execytuib quorum is defined as the minimal threshold of participating total tokens needed
-for a proposal to be considered as strongly supported, enabling early execution. Must be greater
-or equal to normal quorum.
+Early execution quorum is defined as the minimal threshold of participating total tokens needed
+for a proposal to be considered strongly supported, enabling early execution. Must be greater
+than or equal to normal quorum.
 
 ### Approval Ratio
 

doc/src/testnet/atomic-swap.md

@@ -1,17 +1,22 @@
 # Atomic Swaps
 
-In order to do an atomic swap with someone, you will first have to
-agree on what tokens you wish to swap. For example purposes, let's say
-you want to swap `40` `ANON` (which is the balance you should have left
-over after doing the payment from the previous page) for your
-counterparty's `20` `DAWN`. For this tutorial the counterparty is
-yourself.
-
-To protect your anonymity from the counterparty, the swap can only send
-entire coins. To create a smaller coin denomination, send yourself the
-amount you want to swap. Then check you have a spendable coin to swap
-with. Note that the coin overview might look very different depending
-on your activity:
+In order to do an atomic swap with someone, you will first have to agree
+on what tokens you wish to swap. For example, let's say you want to swap
+`40` `ANON` for your counterparty's `20` `DAWN`. You can do this tutorial
+with a real counterparty or with yourself. This tutorial assumes the
+counterparty is yourself, but we will indicate which steps differ so
+you should be able to do the tutorial with a real counterparty as well.
+
+The swap uses one coin per party so the counterparty only sees the
+single coin you're using, not your other coins.
+
+Note: A "coin" is a single cryptographic record. Your wallet balance is
+the sum of all coins you own, and each coin must be spent entirely.
+
+You must use a coin worth the exact amount you want to swap. To create a
+smaller coin denomination, send yourself the amount you want to swap. Then
+check you have a spendable coin to swap with. Note that the coin overview
+might look very different depending on your activity:
 
 ```shell
 drk> wallet coins
@@ -28,19 +33,24 @@ drk> wallet coins
 
 You'll have to initiate the swap and build your half of the swap tx:
 
+
 ```shell
 drk> otc init 40.0:20.0 ANON:DAWN > half_swap
 ```
 
-Then you can send this `half_swap` file to your counterparty and they
+Then you can send this `half_swap` file to the counterparty and they
 can create the other half and sign it by running:
 
 ```shell
 drk> otc join < half_swap > full_swap
 ```
 
-They can now send it back to you. Finally, to make the swap transaction
-valid, you need to sign it as well
+The counterparty can now send it back to you. Finally, to make the swap
+transaction valid, you need to sign it as well.
+
+Note: If you are doing this tutorial by yourself, you don't need to send
+the `half_swap` or `full_swap` file anywhere, and can just create the
+`full_swap` followed by the `signed_swap` directly.
 
 ```shell
 drk> otc sign < full_swap > signed_swap
@@ -68,7 +78,7 @@ Party B:
 drk> otc sign < signed_full_swap_with_fee > swap.tx
 ```
 
-Now the complete swap transaction can be broadcasted:
+Now the complete swap transaction can be broadcast:
 
 ```shell
 drk> broadcast < swap.tx
@@ -81,7 +91,7 @@ Transaction ID: d2a5e288e6ba44583ee12db9c7a0ed154c736d1aa841d70c7d3fa121c92dfc69
 ```
 
 On success, you should see a transaction ID. This transaction will now
-also be in the mempool, so you should wait again until it's confirmed.
+be in the mempool, and you should wait until it's confirmed.
 
 ![pablo-waiting2](img/pablo2.jpg)
 
@@ -121,7 +131,7 @@ swap: `40.00` `ANON` and `20.00` `DAWN` . The first entry shows the
 `Spent` flag as `true` and the second entry shows the `Spent` flag as
 `false`. This means the transaction was successful. Since we are
 swapping with ourself, we successfully spent the coins in the first
-half of the transaction, and re-minted to ourselves them in the second
+half of the transaction, and re-minted them to ourselves in the second
 half of the transaction.
 
 If you're testing atomic swaps with a counterparty and you can see

doc/src/testnet/contract.md

@@ -22,7 +22,21 @@ $ git clone https://codeberg.org/darkrenaissance/smart-contract
 $ cd smart-contract
 ```
 
-Here, generate the contract WASM bincode and its client by executing:
+We will use the provided Makefile to generate the contract WASM bincode
+and its client. The Makefile uses [zkas][5], DarkFi's zero-knowledge proof
+circuit compiler, to do this.
+
+Running `make` will compile the ZK proof circuits that protect the
+contract's privacy, build the WASM module that runs on the DarkFi network,
+and build a command-line client for interacting with the contract.
+
+We first need to ensure the Makefile is configured so that it can find
+the `zkas` binary. That might mean you need to modify the path shown below.
+
+```
+# Path to the zkas compiler (or just `zkas` if it's in your $PATH)
+ZKAS = ../darkfi/zkas
+```
 
 ```shell
 $ make
@@ -50,7 +64,7 @@ return back to your `drk` interactive shell.
 Each contract is controlled by a secret key, from which its Contract
 ID derives. To deploy a smart contract, we first need to generate an
 authority keypair. The Contract ID shown in the outputs is a placeholder
-for the one that will be generated from you. In rest of the guide, use
+for the one that will be generated from you. In the rest of the guide, use
 the one you generated by replacing the corresponding placeholder. We can
 create our own contract authority by executing the following command:
 
@@ -105,7 +119,7 @@ history. We can also export the deployed data by executing:
 drk> contract export-data {TX_HASH} > membership.dat
 ```
 
-The exported files contains the WASM bincode and instruction data
+The exported file contains the WASM bincode and instruction data
 deployed by that transaction, encoded in `base64` as a tuple.
 
 ## Lock transaction
@@ -163,12 +177,12 @@ Secret key: {IDENTITY_SECRET_KEY}
 Public key: {IDENTITY_PUBLIC_KEY}
 ```
 
-> NOTE: This is a very basic example client so secrets keys are used
-> as plainext for simplicity. Do not run this in a machine with
+> NOTE: This is a very basic example client so secret keys are used
+> as plaintext for simplicity. Do not run this in a machine with
 > commands history or in a hostile environment where your secret key
 > can be exposed.
 
-Now we can can create our `register` call using our membership secret
+Now we can create our `register` call using our membership secret
 key:
 
 ```shell
@@ -213,7 +227,7 @@ Transaction ID: f3304e6f5673d9ece211af6dd85c70ec8c8e85e91439b8cffbcf5387b11de1d0
 ```
 
 When the transaction gets confirmed, our membership commitment will
-will not exist in our contract registry.
+not exist in our contract registry.
 
 ### Extending the smart contract client
 
@@ -221,7 +235,7 @@ The template client is barebones and doesn't provide us with a way to
 view the on chain records of our registry. For that purpose we can
 create a new small program, or extend the client to support this
 functionality. Following you will find example code for retrieving
-a smart contract's on-chain records from the [JSON-RPC][5] server in
+a smart contract's on-chain records from the [JSON-RPC][6] server in
 `darkfid` which we can use to list our registry records:
 
 {{#tabs }}
@@ -293,4 +307,5 @@ with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
 [2]: ../arch/sc/sc.md
 [3]: https://codeberg.org/darkrenaissance/smart-contract
 [4]: ../spec/crypto-schemes.md#poseidonhash-function
-[5]: ../clients/darkfid_jsonrpc.md
+[5]: ../zkas/zkas.md
+[6]: ../clients/darkfid_jsonrpc.md

doc/src/testnet/dao.md

@@ -1,20 +1,20 @@
 # DAO
 
-On the testnet, we are also able to create an anonymous DAO. Using
-the `drk` CLI tool, we have a `dao` subcommand that can perform the
-necessary operations.
+On the testnet, we can also create anonymous DAOs. Using the `drk`
+CLI tool, we have a `dao` subcommand that can perform the necessary
+operations.
 
 DarkFi DAOs have several configurable parameters, including:
 
 - **Proposer_limit**: the minimum amount of governance tokens needed to
 open a proposal.
 - **Quorum**: The minimal threshold of participating total tokens
-needed for a proposal to pass (expressed as an absolute value).
+needed for a proposal to pass.
 - **Early execution quorum**: The minimal threshold of participating
-total tokens needed for a proposal to be considered as strongly
-supported, enabling early execution. Must be greater or equal to normal
+total tokens needed for a proposal to be considered strongly supported,
+enabling early execution. Must be greater than or equal to normal
 quorum.
-- **Approval_ratio**: The ratio of winning/total votes needed for a
+- **Approval_ratio**: The ratio of yes/total votes needed for a
 proposal to pass.
 - **Governance token**: The DAO's governance token ID.
 
@@ -47,9 +47,9 @@ FLAGS:
 ARGS:
     <proposer-limit>       The minimum amount of governance tokens needed to open a proposal for this DAO
     <quorum>               Minimal threshold of participating total tokens needed for a proposal to pass
-    <early-exec-quorum>    Minimal threshold of participating total tokens needed for a proposal to be considered as
-                           strongly supported, enabling early execution. Must be greater or equal to normal quorum
-    <approval-ratio>       The ratio of winning votes/total votes needed for a proposal to pass (2 decimals)
+    <early-exec-quorum>    Minimal threshold of participating total tokens needed for a proposal to be considered
+                           strongly supported, enabling early execution. Must be greater than or equal to normal quorum
+    <approval-ratio>       The ratio of yes votes/total votes needed for a proposal to pass (2 decimals)
     <gov-token-id>         DAO's governance token ID
 ```
 
@@ -86,13 +86,23 @@ Early Exec Secret key: 9r9URX...TZCHPL
 Bulla blind: 6TVkmM...Jjd5zC
 ```
 
-Since its a normal `toml` file, you may open it with you favourite
-editor, modify the keys configuration and/or maintain different config
-versions for different DAO members. By default all keys are different,
-so its up to the DAO founders to chose what configuration they are
-going to use. After configuring the file(s) properly, it can be shared
-among DAO members, so they hold the generated DAO information and keys.
-The view command will show us the parameters. If everything looks fine,
+The DAO configuration includes several keypairs controlling different
+permissions:
+
+- **Proposer key**: Required to create new proposals
+- **Exec key**: Required to execute proposals after voting ends
+- **Early Exec key**: Required to execute strongly supported proposals immediately
+- **Notes key**: Required to decrypt encrypted DAO-related notes
+- **Proposals/Votes keys**: Required to view proposals and votes on-chain
+
+By default, all keys are unique, giving DAO founders flexibility in
+access control. DAO founders may share certain keys (e.g., proposer
+key with all members, exec key only with trusted executors) or maintain
+separation of duties.
+
+Since its a normal `toml` file, you can edit it with any text editor to
+modify keys or maintain different versions for different members. The
+view command will show us the parameters. If everything looks fine,
 we can now import it into our wallet:
 
 ```shell
@@ -140,10 +150,9 @@ Wallet Address: DX7N6v...5Lz8Pp
 
 ## Minting
 
-If parameters are shown, this means the DAO was successfully imported
-into our wallet. We use the DAO name to reference it. Now we can create
-a transaction that will mint the DAO on-chain, if we hold all its keys,
-and broadcast it:
+The parameters shown confirm the DAO was successfully imported. We use the
+DAO name to reference it. Now we can create and broadcast a transaction to
+mint the DAO on-chain (requires holding all its keys):
 
 ```shell
 drk> dao mint AnonDAO | broadcast
@@ -154,7 +163,7 @@ Broadcasting transaction...
 Transaction ID: 2e7931f200c1485ea7752076e199708b011a504d71e69d60ed606817c5ff4bd5
 ```
 
-Now the transaction is broadcasted to the network. After confirmation
+Now the transaction has been broadcast to the network. After confirmation
 you should see a leaf position, a mint height and a transaction hash
 when running:
 
@@ -194,7 +203,7 @@ Wallet Address: DX7N6v...5Lz8Pp
 
 Let's send some tokens to the DAO's treasury so we're able to make
 a proposal to send those somewhere. First, find the DAO wallet address,
-the DAO bulla and the dao contract spend hook.
+the DAO bulla and the DAO contract spend hook.
 
 Then create a transfer transaction as follows:
 
@@ -259,11 +268,11 @@ drk> dao balance AnonDAO
 
 ## Creating a proposal
 
-Now that the DAO has something in its treasury, we can generate a
-transfer proposal to send it somewhere, that will be up to vote
-for 1 [block period][blockwindow](~4h), if we hold the DAO proposer
-key. Let's propose to send 5 of the 10 tokens to our address (we can
-find that with `wallet address`):
+Now that the DAO has funds, we can create a transfer proposal to send
+tokens somewhere. The proposal will be open to vote for 1 [block
+period][blockwindow](~4h), if we hold the DAO proposer key. Let's
+propose sending 5 of the 10 tokens to our address (we can find that with
+`wallet address`):
 
 [blockwindow]: ../spec/contract/dao/model.md#blockwindow
 
@@ -273,8 +282,8 @@ drk> dao propose-transfer AnonDAO 1 5 DAWN {YOUR_ADDRESS}
 Generated proposal: {PROPOSAL_BULLA}
 ```
 
-After command was executed, it will output the generated proposal
-bulla, which we will use to view the proposal full information:
+The command outputs the proposal bulla, which we can use to view the
+proposal's full details:
 
 ```shell
 drk> dao proposal {PROPOSAL_BULLA}
@@ -310,7 +319,7 @@ Voting status: Ongoing
 Current proposal outcome: Unknown
 ```
 
-We can export this proposal, to share with rest DAO members.
+We can export this proposal to share with the rest of the DAO.
 The exported file will be encrypted using the DAO proposals view key,
 so only its members can decrypt and import it.
 
@@ -332,11 +341,10 @@ Broadcasting transaction...
 Transaction ID: 2149d7e3a60be12c96b6c6fc7ba009717d8b229b815dd4006bbe120c31681f38
 ```
 
-Members that didn't receive the encrypted file will receive the
-proposal when they scan the corresponding block, but its plaintext
-data will be missing, so they should ask the DAO for it.
-Once confirmed, you should see a leaf position, a mint height and a
-transaction hash when running:
+Members who didn't receive the encrypted file will see the proposal
+when scanning the block, but the plaintext data will be missing, so
+they should ask the DAO for it.  Once confirmed, you should see a leaf
+position, a mint height and a transaction hash when running:
 
 ```shell
 drk> dao proposal {PROPOSAL_BULLA}
@@ -375,7 +383,7 @@ Current proposal outcome: Unknown
 ## Voting on a proposal
 
 Now the DAO members are ready to cast their votes.
-First lets check the `dao vote` subcommand usage.
+First, let's check the `dao vote` subcommand usage.
 
 ```shell
 $ ./drk help dao vote
@@ -453,11 +461,10 @@ Current proposal outcome: Approved
 
 ## Executing the proposal
 
-Once the block period has passed(~4h) and enough votes have been cast
-that meet the required minimum (quorum), and assuming the yes:no votes
-ratio is bigger than the approval ratio, then we are ready to confirm
-the vote. Only DAO members with the executor key can perform this
-action.
+Once the voting period ends (~4 hours), if enough votes were cast to
+meet the quorum requirement and the yes:no ratio exceeds the approval
+ratio, the proposal is ready to execute. Only DAO members with the
+executor key can perform this action.
 
 ```shell
 drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -469,9 +476,9 @@ Broadcasting transaction...
 Transaction ID: 808b75685d91c766574dd5a3d46206b8e145b29f3647736161d2e2b2db051444
 ```
 
-Since in our tutorial the `ANON` governance tokens we used surpass the
-early execution quorum, we can execute the proposal right away, if we
-hold both the DAO executor and early executor keys:
+Since our vote exceeds the early execution quorum, we can execute the
+proposal immediately (requires both the executor and early executor
+keys):
 
 ```shell
 drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -483,9 +490,9 @@ Broadcasting transaction...
 Transaction ID: 808b75685d91c766574dd5a3d46206b8e145b29f3647736161d2e2b2db051444
 ```
 
-After the proposal has been executed on chain, we will see that the DAO
-balance has been reduced by 5 `DAWN`, if we hold the DAO notes key,
-while our own balance has been increased by the same amount:
+After the proposal has been executed on-chain, we will see the DAO's
+balance reduced by 5 `DAWN`, and our own balance increased by the same
+amount (if we hold the DAO notes key):
 
 ```shell
 drk> dao balance AnonDAO
@@ -507,8 +514,8 @@ drk> wallet balance
 
 ## Generic proposal
 
-DAOs can vote on off-chain operations by creating what is known as
-generic proposals, meaning that no on-chain action is tied to it:
+DAOs can vote on off-chain actions by creating generic proposals,
+which have no on-chain execution tied to them:
 
 ```shell
 drk> dao propose-generic AnonDAO 1
@@ -536,7 +543,7 @@ Broadcasting transaction...
 Transaction ID: 47240cd8ae28eb4d1768029b488d93fe6df6c2c6847cc987ce79f75dfcd56cdc
 ```
 
-And execute it, after the vote period(1 block period) has passed:
+Execute it after the voting period (1 block period) ends:
 
 ```shell
 drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -547,7 +554,7 @@ Broadcasting transaction...
 Transaction ID: a9d77e2d6a64372cb1cf33ed062e0439e617b88ca6374917c83cd284d788d1ce
 ```
 
-Or right away, since the early execution quorum has been reached:
+Or immediately, since the early execution quorum was reached:
 
 ```shell
 drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -558,15 +565,15 @@ Broadcasting transaction...
 Transaction ID: a9d77e2d6a64372cb1cf33ed062e0439e617b88ca6374917c83cd284d788d1ce
 ```
 
-Executing the proposal will just confirm it on-chain, without any
-other actions taken.
+Executing the proposal confirms it on-chain without taking any
+additional actions.
 
 ## DAO->DAO
 
 Let's now try some more exotic operations!
 
 Since we hold the mint authority of the `ANON` token,
-instead of transfering some to the DAO, we will mint them
+instead of transferring tokens to the DAO, we mint them
 directly into it:
 
 ```shell
@@ -592,7 +599,7 @@ drk> dao balance AnonDAO
  {TOKEN2} | DAWN    | 5
 ```
 
-Now we will create a second dao:
+Now we'll create a second DAO:
 
 ```shell
 drk> dao create 20 10 10 0.67 DAWN | dao import DawnDAO
@@ -600,7 +607,7 @@ drk> dao create 20 10 10 0.67 DAWN | dao import DawnDAO
 Importing "DawnDAO" DAO into the wallet
 ```
 
-And mint it on-chain:
+Mint it on-chain:
 
 ```shell
 drk> dao mint DawnDAO | broadcast
@@ -672,7 +679,7 @@ Broadcasting transaction...
 Transaction ID: 9dd81f166115563e88262ef9ed83b15112dd72247bf48ce7b161779405830a63
 ```
 
-And execute it, after the vote period(1 block period) has passed:
+Execute it after the voting period (1 block period) ends:
 
 ```shell
 drk> dao exec {PROPOSAL_BULLA} | broadcast
@@ -684,7 +691,7 @@ Broadcasting transaction...
 Transaction ID: b78824d5d6c6e6fdb6a002848353dc60279e1c8800e2741062f8944c44796582
 ```
 
-Or right away, since the early execution quorum has been reached:
+Or immediately, since the early execution quorum was reached:
 
 ```shell
 drk> dao exec --early {PROPOSAL_BULLA} | broadcast
@@ -719,9 +726,8 @@ drk> dao balance DawnDAO
 
 ## Mining for a DAO
 
-A DAO can deploy its own mining nodes and/or other miners can choose to
-directly give their rewards towards one. To retrieve a DAO mining
-configuration, execute:
+A DAO can deploy mining nodes, or miners can direct rewards to a DAO.
+To retrieve a DAO's mining configuration, execute:
 
 ```shell
 drk> dao mining-config {YOUR_DAO}

doc/src/testnet/merge-mining.md

@@ -11,7 +11,7 @@ don't stop a running one to start another.
 
 Each command to execute will be inside a codeblock, on its first line,
 marked by the user `$` symbol, followed by the expected output. For
-longer command outputs, some lines will be emmited to keep the guide
+longer command outputs, some lines will be emitted to keep the guide
 simple.
 
 ## Build binaries from source

doc/src/testnet/node.md

@@ -11,7 +11,7 @@ stop a running one to start another.
 
 Each command to execute will be inside a codeblock, on its first line,
 marked by the user `$` symbol, followed by the expected output. For
-longer command outputs, some lines will be emmited to keep the guide
+longer command outputs, some lines will be emitted to keep the guide
 simple.
 
 We also strongly suggest to first execute next guide steps on a
@@ -146,7 +146,7 @@ wallet_pass = "changeme"
 Once you've changed the default password for your testnet wallet, we
 can proceed with the wallet initialization. We simply have to
 initialize a wallet, and create a keypair. The wallet address shown in
-the outputs is examplatory and will different from the one you get.
+the outputs is explanatory and will be different from the one you get.
 
 ```shell
 $ ./drk wallet initialize
@@ -262,7 +262,7 @@ rpc_listen = "tcp://127.0.0.1:18347"
 > endpoints, so your traffic is not plaintext, as it contains your
 > wallet address used for the block rewards.
 
-To mine on DarkFI we need to add a recipient to `xmrig` that specifies
+To mine on DarkFi we need to add a recipient to `xmrig` that specifies
 where the mining rewards will be minted to. You now have to configure
 `xmrig` to use your wallet address as the rewards recipient, when it
 retrieves blocks from `darkfid` to mine. Make sure you have

doc/src/testnet/payment.md

@@ -1,7 +1,10 @@
 # Payments
 
 Using the tokens we minted, we can make payments to other addresses.
-We will use a dummy recepient, but you can also test this with friends.
+For this tutorial we will use a dummy recipient, but you can also test
+this with friends by replacing the recipient address with your friend's
+address.
+
 Let's try to send some `ANON` tokens to
 `DZnsGMCvZU5CEzvpuExnxbvz6SEhE2rn89sMcuHsppFE6TjL4SBTrKkf`:
 
@@ -15,14 +18,13 @@ Broadcasting transaction...
 Transaction ID: 47b4818caec22470427922f506d72788233001a79113907fd1a93b7756b07395
 ```
 
-On success we'll see a transaction ID. Now again the same confirmation
-process has to occur and
+On success we'll see a transaction ID. Once confirmed within a block,
 `DZnsGMCvZU5CEzvpuExnxbvz6SEhE2rn89sMcuHsppFE6TjL4SBTrKkf` will receive
 the tokens you've sent.
 
 ![pablo-waiting1](img/pablo1.jpg)
 
-We can see the spent coin in our wallet.
+We can now see the spent coin in our wallet.
 
 ```shell
 drk> wallet coins
@@ -36,8 +38,8 @@ drk> wallet coins
  EEneNB...m6mxTC | false | 241vAN...KcLssb | DRK     | 1999442971 (19.97253683) | -          | -         | -
 ```
 
-We have to wait until the next block to see our change balance reappear
-in our wallet.
+We have to wait until the next block to see our change reappear in
+our wallet.
 
 ```shell
 drk> wallet balance

doc/src/testnet/token.md

@@ -1,19 +1,19 @@
 # Native token
 
 Now that you have your wallet set up, you will need some native `DRK`
-tokens in order to be able to perform transactions, since that token
-is used to pay the transaction fees. You can obtain `DRK` either by
-successfully mining a block that gets confirmed or by asking for some
-by the community on `darkirc` and/or your comrades. Don't forget to
-tell them to add the `--half-split` flag when they create the transfer
-transaction, so you get more than one coins to play with.
-
-After you request some `DRK` and the other party submitted a
-transaction to the network, it should be in the consensus' mempool,
-waiting for inclusion in the next block(s). Depending on your network
-configuration, confirmation of the blocks could take some time. You'll
-have to wait for this to happen. If your `drk` subscription is running,
-then after some time your new balance should be in your wallet.
+in order to be able to perform transactions, since `DRK` is used to pay
+the transaction fees. You can obtain `DRK` either by successfully mining
+a block that gets confirmed or by asking for some from the community on
+`darkirc`.
+
+If the latter, don't forget to tell them to add the `--half-split` flag
+when they create the transfer, so you get more than one coin to play
+with. Once your friend has submitted a transaction to the network, it
+should be in the consensus' mempool, waiting for inclusion in the next
+block(s). Depending on your network configuration, confirmation of the
+blocks could take some time. You'll have to wait for this to happen. If
+your `drk` subscription is running, then after some time your new balance
+should be in your wallet.
 
 ![pablo-waiting0](img/pablo0.jpg)
 
@@ -29,13 +29,20 @@ drk> wallet balance
 
 # Creating tokens
 
-On the DarkFi network, we're able to mint custom tokens with some
-supply. To do this, we need to generate a mint authority keypair,
-and derive a token ID from it. The tokens shown in the outputs are
-placeholders for the ones that will be generated from you. In rest of
-the guide, use the ones you generated by replacing the corresponding
-placeholder. We can simply create our own tokens by executing the
-following command:
+On the DarkFi network, we can mint custom tokens with a given supply. To
+do this, we first need to generate a mint authority keypair, and derive a
+token ID from it.
+
+Note: The token data shown in the outputs (Token ID, Mint Authority,
+Token Blind) are placeholders for the data that will be created by
+you. For the rest of the guide, replace the placeholder token data with the
+data that you generate.
+
+For this tutorial we will be minting two sets of tokens. For each token
+we will create the mint authority keypair that sets the token ID and
+authorizes you to mint the token supply.
+
+We do this by simply executing the following command:
 
 ```shell
 drk> token generate-mint
@@ -43,9 +50,6 @@ drk> token generate-mint
 Successfully imported mint authority for token ID: {TOKEN1}
 ```
 
-This will generate a new token mint authority and will tell you what
-your new token ID is.
-
 You can list your mint authorities with:
 
 ```shell
@@ -57,8 +61,8 @@ drk> token list
 
 ```
 
-For this tutorial we will need two tokens so execute the command again
-to generate another one.
+Now execute the command again to generate the mint authority for a second
+set of tokens.
 
 ```shell
 drk> token generate-mint
@@ -66,7 +70,7 @@ drk> token generate-mint
 Successfully imported mint authority for token ID: {TOKEN2}
 ```
 
-Verify you have two tokens by running:
+Verify you have two token mint authorities by running:
 
 ```shell
 drk> token list
@@ -80,12 +84,12 @@ drk> token list
 
 ## Aliases
 
-To make our life easier, we can create token ID aliases, so when we
-are performing transactions with them, we can use that instead of the
-full token ID. Multiple aliases per token ID are supported.
+To make our life easier, we can create token ID aliases, which we can use
+instead of the token ID when performing transactions. Multiple aliases
+per token ID are supported.
 
 The native token alias `DRK` should already exist, and we can use that
-to refer to the native token when executing transactions using it.
+to refer to `DRK` when executing transactions using it.
 
 We can also list all our aliases using:
 
@@ -97,10 +101,10 @@ drk> alias show
  DRK   | 241vANigf1Cy3ytjM1KHXiVECxgxdK4yApddL8KcLssb
 ```
 
-Note: these aliases are only local to your machine. When exchanging
-with other users, always verify that your aliases' token IDs match.
+Note: these aliases are local to your machine. When exchanging with
+other users, always verify that your aliases' token IDs match.
 
-Now let's add the two token IDs generated earlier to our aliases:
+Now let's create aliases for the two token IDs generated earlier:
 
 ```shell
 drk> alias add ANON {TOKEN1}
@@ -127,7 +131,7 @@ drk> alias show
 ## Mint transaction
 
 Now let's mint some tokens for ourselves. First grab your wallet address,
-and then create the token mint transaction, and finally - broadcast it:
+then create the token mint transaction, and finally - broadcast it:
 
 ```shell
 drk> wallet address
@@ -184,7 +188,7 @@ drk> wallet balance
 
 ## Freeze transaction
 
-We can lock a tokens supply dissallowing further mints by executing:
+We can lock a token's supply and disallow further mints by executing:
 
 
 ```shell