fix: typographical errors in multiple files

app/square_size.go

@@ -10,7 +10,7 @@ func (app *App) MaxEffectiveSquareSize(ctx sdk.Context) int {
 	// TODO: fix hack that forces the max square size for the first height to
 	// 64. This is due to our fork of the sdk not initializing state before
 	// BeginBlock of the first block. This is remedied in versions of the sdk
-	// and comet that have full support of PreparePropsoal, although
+	// and comet that have full support of PrepareProposal, although
 	// celestia-app does not currently use those. see this PR for more details
 	// https://github.com/cosmos/cosmos-sdk/pull/14505
 	if ctx.BlockHeader().Height <= 1 {

docs/architecture/adr-011-optimistic-blob-size-independent-inclusion-proofs-and-pfb-fraud-proofs.md

@@ -51,7 +51,7 @@ A PFB Fraud Proof = PFB Inclusion Proof + Blob Inclusion Proof
 After you verify the PFB Inclusion Proof you will get the:
 
 - index where the blob is located
-- how long the bob is
+- how long the blob is
 - the commitment of the blob
 
 With the information that you now confirmed you can confirm the blob inclusion proof of the shares that start at the index for the given length.

docs/architecture/adr-021-restricted-block-size.md

@@ -106,7 +106,7 @@ func (app *App) GovMaxSquareSize(ctx sdk.Context) int {
 	// TODO: fix hack that forces the max square size for the first height to
 	// 64. This is due to tendermint not technically supposed to be calling
 	// PrepareProposal when heights are not >= 1. This is remedied in versions
-	// of the sdk and comet that have full support of PreparePropsoal, although
+	// of the sdk and comet that have full support of PrepareProposal, although
 	// celestia-app does not currently use those. see this PR for more
 	// details https://github.com/cosmos/cosmos-sdk/pull/14505
 	if ctx.BlockHeader().Height == 0 {

specs/src/cat_pool.md

@@ -60,7 +60,7 @@ Given this criteria, it is feasible, yet unlikely that a node receives two `Seen
 
 A `SeenTx` MAY be sent for each transaction currently in the transaction pool when a connection with a peer is first established. This acts as a mechanism for syncing pool state across peers.
 
-The `SeenTx` message MUST only be broadcasted after validation and storage. Although it is possible that a node later drops a transaction under load shedding, a `SeenTx` should give as strong guarantees as possible that the node can be relied upon by others that don't yet have the transcation to obtain it.
+The `SeenTx` message MUST only be broadcasted after validation and storage. Although it is possible that a node later drops a transaction under load shedding, a `SeenTx` should give as strong guarantees as possible that the node can be relied upon by others that don't yet have the transaction to obtain it.
 
 > **Note:**
 > Inbound transactions submitted via the RPC do not trigger a `SeenTx` message as it is assumed that the node is the first to see the transaction and by gossiping it to others it is implied that the node has seen the transaction.

x/blob/ante/blob_share_decorator.go

@@ -59,7 +59,7 @@ func (d BlobShareDecorator) getMaxSquareSize(ctx sdk.Context) int {
 	// TODO: fix hack that forces the max square size for the first height to
 	// 64. This is due to our fork of the sdk not initializing state before
 	// BeginBlock of the first block. This is remedied in versions of the sdk
-	// and comet that have full support of PreparePropsoal, although
+	// and comet that have full support of PrepareProposal, although
 	// celestia-app does not currently use those. see this PR for more details
 	// https://github.com/cosmos/cosmos-sdk/pull/14505
 	if ctx.BlockHeader().Height <= 1 {

x/blob/ante/max_total_blob_size_ante.go

@@ -62,7 +62,7 @@ func (d MaxTotalBlobSizeDecorator) getMaxSquareSize(ctx sdk.Context) int {
 	// TODO: fix hack that forces the max square size for the first height to
 	// 64. This is due to our fork of the sdk not initializing state before
 	// BeginBlock of the first block. This is remedied in versions of the sdk
-	// and comet that have full support of PreparePropsoal, although
+	// and comet that have full support of PrepareProposal, although
 	// celestia-app does not currently use those. see this PR for more details
 	// https://github.com/cosmos/cosmos-sdk/pull/14505
 	if ctx.BlockHeader().Height <= 1 {

x/tokenfilter/README.md

@@ -7,7 +7,7 @@ their native token within their state machine.
 
 ## Context
 
-When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholdent to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholdent to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`.
+When tokens are transferred through the IBC transfer module, the denomination of that token is modified at each hop. It's more accurate to think of the tokens transferring to another network to actually remain held in escrow at the origin chain and the destination chain minting a "wrapped" equivalent. Thus tokens moved to a non-native state machine are beholden to the security of both chains. The denomination is denoted as the path it's taken from the origin chain. To provide an example, imagine 3 chains: A, B and C with native tokens "a", "b", "c". With IBC's transfer module, when a user transfers token "a" from A to B, the wrapped token is prefixed with the source port and source channel (i.e. `portidone/channel-0/a`), this is Ba. If the token is further transferred to C it becomes BCa (or `portidtwo/channel-1/portidone/channel-0/a`). This token is now beholden to the security of B, C and A. Also note that this is different if "a" were to go directly to C. In other words: `Ca != BCa`.
 
 This context is important in recognising when a native token is returning to its origin state machine. Each IBC packet contains metadata including the source port and channel. Therefore if the denomination of the token is prefixed with the same source port and channel as detailed in the packet, we can conclude that the denomination originally came from the receiving chain.