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
-you go with a full-stack blockchain and command line tool for transacting.
+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.
 
 ## 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
-with types defined in other repos), to easily embed an arbitrary tx inside another
-without specifying the type, and provide an automatic json representation to
-provide to users (or apps) to inspect the chain.
+types there. This allows us to deserialize the entire transaction in one location
+(even with types defined in other repos), to easily embed an arbitrary tx inside
+another without specifying the type, and provide an automatic json representation
+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
-`<module name>/xxx`. The dispatcher grabs the appropriate module name from
- the tx name and routes it if the module is present.
+so we just look at the registered name of this transaction, which should be
+of the form `<module name>/xxx`. The dispatcher grabs the appropriate module
+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
-should see a Counter value of 1 representing the number of valid transactions.
-If we send another transaction, and then query again, we will see the value
-increment.  Note that we need the sequence number here to send the coins
-(it didn't increment when we just pinged the counter)
+Tada! We can now see that our custom counter plugin transactions went through.
+You should see a Counter value of 1 representing the number of valid
+transactions. If we send another transaction, and then query again, we will
+see the value increment. Note that we need the sequence number here to send the
+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,
-we use `glide` for dependency management.
+If the dependencies have been updated with breaking changes,
+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
-may strip off one level, like an onion. As such, the transaction must be
-constructed to mirror the execution stack, and each middleware module should
-allow embedding an arbitrary tx for the next layer in the stack.
+uniquely by each application. From the multiple layers of transaction, each
+middleware may strip off one level, like an onion. As such, the transaction
+must be constructed to mirror the execution stack, and each middleware module
+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
-that belongs to their module. (This must be explicitly authorized by the
-same module, so only the eg. coin module can authorize a `SendTx` to another
-chain).
+by calling `CreatePacketTx` over IPC (inter-plugin communication) with a
+transaction that belongs to their module. (This must be explicitly authorized
+by the same module, so only the eg. coin module can authorize a `SendTx` to
+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