docs: address comments & other updates

README.md

@@ -26,8 +26,7 @@ application customization. For example, does your app require fees, how do you
 want to log messages, do you enable IBC, do you even have a cryptocurrency? In
 this way, the Cosmos SDK is the **Rails of cryptocurrencies**.
 
-Within this repository, the `basecoin` app serves as a reference implementation for how we build ABCI applications in Go, and is the framework in which we implement the [Cosmos Hub](https://cosmos.network). **It's easy to use, and doesn't require any forking** - just implement your plugin, import the libraries, and away
+Within this repository, the `basecoin` app serves as a reference implementation for how we build ABCI applications in Go, and is the framework in which we implement the [Cosmos Hub](https://cosmos.network). **It's easy to use, and doesn't require any forking** - just implement your plugin, import the libraries, and away you go with a full-stack blockchain and command line tool for transacting.
-you go with a full-stack blockchain and command line tool for transacting.
 
 ## Prerequisites
 

docs/architecture/API.md

@@ -14,7 +14,7 @@ By default we will serve on `http://localhost:2024`.  CORS will be disabled by d
 The MVP will allow us to move around money.  This involves the
 following functions:
 
-## Construct an unsigned tx
+## Construct an unsigned transaction
 
 `POST /build/send`
 

docs/glossary.md

@@ -20,10 +20,10 @@ binary and json encodings and decodings for `struct` or  interface` objects.
 Here, encoding and decoding operations are designed to operate with interfaces
 nested any amount times (like an onion!). There is one public `TxMapper`
 in the basecoin root package, and all modules can register their own transaction
-types there. This allows us to deserialize the entire tx in one location (even
+types there. This allows us to deserialize the entire transaction in one location
-with types defined in other repos), to easily embed an arbitrary tx inside another
+(even with types defined in other repos), to easily embed an arbitrary tx inside
-without specifying the type, and provide an automatic json representation to
+another without specifying the type, and provide an automatic json representation
-provide to users (or apps) to inspect the chain.
+to provide to users (or apps) to inspect the chain.
 
 Note how we can wrap any other transaction, add a fee level, and not worry
 about the encoding in our module any more?
@@ -172,9 +172,9 @@ implements the `Handler` interface. We then register a list of modules with
 the dispatcher. Every module has a unique `Name()`, which is used for
 isolating its state space. We use this same name for routing transactions.
 Each transaction implementation must be registed with go-wire via `TxMapper`,
-so we just look at the registered name of this tx, which should be of the form
+so we just look at the registered name of this transaction, which should be
-`<module name>/xxx`. The dispatcher grabs the appropriate module name from
+of the form `<module name>/xxx`. The dispatcher grabs the appropriate module
- the tx name and routes it if the module is present.
+name from the tx name and routes it if the module is present.
 
 This all seems like a bit of magic, but really we're just making use of go-wire
 magic that we are already using, rather than add another layer. For all the

docs/guide/basecoin-plugins.md

@@ -79,7 +79,7 @@ both use the same library of commands, including one for signing and
 broadcasting `SendTx`.
 
 Counter transactions take two custom inputs, a boolean argument named `valid`,
-and a coin amount named `countfee`.  The transaction is only accepted if both
+and a coin amount named `countfee`. The transaction is only accepted if both
 `valid` is set to true and the transaction input coins is greater than
 `countfee` that the user provides.
 
@@ -126,11 +126,11 @@ them.  Of course, we can also expose queries on our plugin:
 countercli query counter
 ```
 
-Tada! We can now see that our custom counter plugin tx went through.  You
+Tada! We can now see that our custom counter plugin transactions went through.
-should see a Counter value of 1 representing the number of valid transactions.
+You should see a Counter value of 1 representing the number of valid
-If we send another transaction, and then query again, we will see the value
+transactions. If we send another transaction, and then query again, we will
-increment.  Note that we need the sequence number here to send the coins
+see the value increment. Note that we need the sequence number here to send the
-(it didn't increment when we just pinged the counter)
+coins (it didn't increment when we just pinged the counter)
 
 ```shelldown[4]
 countercli tx counter --name cool --countfee=2mycoin --sequence=2 --valid

docs/guide/install.md

@@ -4,14 +4,14 @@ If you aren't used to compile go programs and just want the released
 version of the code, please head to our [downloads](https://tendermint.com/download)
 page to get a pre-compiled binary for your platform.
 
-On a good day, basecoin can be installed like a normal Go program:
+Usually, Cosmos SDK can be installed like a normal Go program:
 
 ```
-go get -u github.com/tendermint/basecoin/cmd/...
+go get -u github.com/cosmos/cosmos-sdk/cmd/...
 ```
 
-In some cases, if that fails, or if another branch is required,
+If the dependencies have been updated with breaking changes,
-we use `glide` for dependency management.
+or if another branch is required, `glide` is used for dependency management.
 Thus, assuming you've already run `go get` or otherwise cloned the repo,
 the correct way to install is:
 
@@ -30,4 +30,3 @@ If you need another branch, make sure to run `git checkout <branch>`
 before `make all`. And if you switch branches a lot, especially
 touching other tendermint repos, you may need to `make fresh` sometimes
 so glide doesn't get confused with all the branches and versions lying around.
-

docs/overview.md

@@ -19,13 +19,14 @@ overviews.
 
 ## Framework Overview
 
-### Transactions
+### Transactions (tx)
 
 Each transaction passes through the middleware stack which can be defined
-uniquely by each application. From the multiple layers of tx, each middleware
+uniquely by each application. From the multiple layers of transaction, each
-may strip off one level, like an onion. As such, the transaction must be
+middleware may strip off one level, like an onion. As such, the transaction
-constructed to mirror the execution stack, and each middleware module should
+must be constructed to mirror the execution stack, and each middleware module
-allow embedding an arbitrary tx for the next layer in the stack.
+should allow an arbitrary transaction to be embedded for the next layer in
+the stack.
 
 <img src="graphics/tx.png" width=250>
 

docs/stdlib.md

@@ -108,10 +108,10 @@ block), and this generally requires approval of an authorized registrar (which
 may be a multi-sig role). Updating a registered chain can be done by anyone,
 as the new header can be completely verified by the existing knowledge of the
 chain. Also, modules can initiate an outgoing IBC message to another chain
-by calling `CreatePacketTx` over IPC (inter-plugin communication) with a tx
+by calling `CreatePacketTx` over IPC (inter-plugin communication) with a
-that belongs to their module. (This must be explicitly authorized by the
+transaction that belongs to their module. (This must be explicitly authorized
-same module, so only the eg. coin module can authorize a `SendTx` to another
+by the same module, so only the eg. coin module can authorize a `SendTx` to
-chain).
+another chain).
 
 `PostPacketTx` can post a transaction that was created on another chain along
 with the merkle proof, which must match an already registered header. If this