Document wallet module. [skip ci]

Author: dnadales

oddchain/README.md

@@ -64,7 +64,7 @@ Tolerant (BFT) consensus protocol, whereas the clients submit random
 transactions to their corresponding nodes.
 
 What you should see is a terminal split in `numNodes * 2` panes, where the top
-layer show the node output, and the bottom layer shows the client (simple
+layer shows the nodes' output, and the bottom layer shows the clients' (simple
 wallet) output. At this bottom layer you should see the blocks produced being
 reported, and of course, all the clients should agree on the blocks they see
 :slightly_smiling_face:.
@@ -74,7 +74,7 @@ reported, and of course, all the clients should agree on the blocks they see
 If you wish to run nodes individually, this can be done as follows:
 
 ```sh
-stack run   oddnode -- \
+stack exec oddnode -- \
 --numberOfCoreNodes 3 \
 --nodeId 2 \
 --enableTracers Consensus \
@@ -117,23 +117,23 @@ instances, which are defined in `module OddChain`. The major instances one has t
   support.
 - `BlockSupportsProtocol` class instance. This determines how to obtain the data
   required to validate the given header according to the consensus rules
-  ('ValidateView') and how to obtain the data required to select among competing
-  chains ('SelectView').
+  (`ValidateView`) and how to obtain the data required to select among competing
+  chains (`SelectView`).
 - `LedgerSupportsProtocol` class instance. This links the ledger to the
   protocol, by having the former giving the necessary information to the latter.
   The consensus algorithm uses this information to determine if the node should
   produce a block (`LedgerView`). For the BFT protocol, the ledger view is just
   `()`, since leader election is based on a round-robin schedule. More
   sophisticated consensus protocols, such as
   [Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/),
-  might require other information such as some approximation of the stake
+  might require other information like some approximation of the stake
   distribution.
 - `UpdateLedger` class instance. This defines how blocks can be applied to the
-  ledger state to update it. This, this is where the ledger logic lives.
+  ledger state to update it. This is where the ledger logic lives.
 - `ApplyTx` class instance. Similar to `UpdateLedger`, this instance defines how
   to different transactions affect the ledger state. This instance is used by
-  the mempool. See `Test.OddChain.prop_mempool` to see which relation is
-  expected to hold between the instances of these type classes. Be aware that
+  the mempool. Property `Test.OddChain.prop_mempool` defines the relation that
+  is expected to hold between the instances of these type classes. Be aware that
   there might be other properties that aren't currently captured in the tests.
 - `RunNode` instance. This defines, among other things, functions to:
   - forge blocks when the node is the leader (given, among other things, a
@@ -155,7 +155,10 @@ When defining the ledger state is **important** that that the ledger state can
 retrieve the header hash of the last applied block (see the instance of function
 `ledgerTipPoint`).
 
-Tests for the implementation are defined in these modules
+The `OddWallet` module contains the implementation of a simple wallet that
+submits random transactions to the node it is connected to.
+
+Tests for the implementation are defined in the following modules:
 
 - `Test.ThreadNet.OddChain` which contains:
   - a test to check that the consensus layer is behaving as expected for the odd
@@ -221,7 +224,7 @@ Applying a **valid** block `blk` on state `st` should result in the same state
 as ticking the ledger state by the block slot, and then applying the
 transactions inside the block. Note that here **validity** of block is crucial.
 If the block is invalid in the given state, then we can't say anything about the
-equality. Formally, for all blocks valid :
+equality. Formally, for all valid blocks:
 
 ```
    applyLedgerBlock cfg blk st