Fix spelling issue (#20968)

Co-authored-by: son trinh <trinhleson2000@gmail.com>

docs/build/building-apps/02-app-mempool.md

@@ -42,7 +42,7 @@ baseAppOptions = append(baseAppOptions, mempoolOpt)
 ### No-op Mempool
 
 A no-op mempool is a mempool where transactions are completely discarded and ignored when BaseApp interacts with the mempool.
-When this mempool is used, it assumed that an application will rely on CometBFT's transaction ordering defined in `RequestPrepareProposal`,
+When this mempool is used, it is assumed that an application will rely on CometBFT's transaction ordering defined in `RequestPrepareProposal`,
 which is FIFO-ordered by default.
 
 > Note: If a NoOp mempool is used, PrepareProposal and ProcessProposal both should be aware of this as

docs/build/building-apps/03-app-upgrade.md

@@ -22,7 +22,7 @@ This section is currently incomplete. Track the progress of this document [here]
 
 Let's assume we are running v0.38.0 of our software in our testnet and want to upgrade to v0.40.0.
 How would this look in practice? First of all, we want to finalize the v0.40.0 release candidate
-and there install a specially named upgrade handler (eg. "testnet-v2" or even "v0.40.0"). An upgrade
+and then install a specially named upgrade handler (eg. "testnet-v2" or even "v0.40.0"). An upgrade
 handler should be defined in a new version of the software to define what migrations
 to run to migrate from the older version of the software. Naturally, this is app-specific rather
 than module specific, and must be defined in `app.go`, even if it imports logic from various

docs/learn/advanced/00-baseapp.md

@@ -146,7 +146,7 @@ To avoid unnecessary roundtrip to the main state, all reads to the branched stor
 
 ### CheckTx State Updates
 
-During `CheckTx`, the `checkState`, which is based off of the last committed state from the root
+During `CheckTx`, the `checkState`, which is based on the last committed state from the root
 store, is used for any reads and writes. Here we only execute the `AnteHandler` and verify a service router
 exists for every message in the transaction. Note, when we execute the `AnteHandler`, we branch
 the already branched `checkState`.