docs: fix typos

README.md

@@ -149,21 +149,21 @@ activity on each `hypervm`. Each unit dimension has a unique metering schedule
 (i.e. how many units each resource interaction costs), target, and max utilization
 per rolling 10 second window.
 
-When network resources are independently metered, they can an be granularly priced
+When network resources are independently metered, they can be granularly priced
 and thus better utilized by network participants. Consider a simple example of a
 one-dimensional fee mechanism where each byte is 2 units, each compute cycle is 5 units,
 each storage operation is 10 units, target usage is 7,500 units per block, and the max
 usage in any block is 10,000 units. If someone were to use 5,000 bytes of block data
 without utilizing any CPU/storing data in state, they would exhaust the block capacity
 without using 2 of the 3 available resources. This block would also increase the price
-of each unit because usage is above the target. As a result, the price to use compuate
+of each unit because usage is above the target. As a result, the price to use compute
 and storage in the next block would be more expensive although neither has been used.
 In the `hypersdk`, only the price of bandwidth would go up and the price of CPU/storage
 would stay constant, a better reflection of supply/demand for each resource.
 
 So, why go through all this trouble? Accurate and granular resource metering is required to
 safely increase the throughput of a blockchain. Without such an approach, designers
-need to either overprovision the network to allow for one resource to be utlized to maximum
+need to either overprovision the network to allow for one resource to be utilized to maximum
 capacity (max compute unit usage may also allow unsustainable state growth) or bound capacity
 to a level that leaves most resources unused. If you are interested in reading more analysis
 of multidimensional fee pricing, [Dynamic Pricing for Non-fungible Resources: Designing
@@ -224,7 +224,7 @@ WarmStorageKeyModificationUnits:   5,
 WarmStorageValueModificationUnits: 3,
 ```
 
-#### Avoiding Complex Consruction
+#### Avoiding Complex Construction
 Historically, one of the largest barriers to supporting
 multidimensional fees has been the complex UX it can impose
 on users. Setting a one-dimensional unit price and max unit usage
@@ -336,7 +336,7 @@ the transactions for each account that can be executed at the moment).
 
 ### Avalanche Warp Messaging Support
 `hypersdk` provides support for Avalanche Warp Messaging (AWM) out-of-the-box. AWM enables any
-Avalanche Subnet to send arbitrary messages to any another Avalanche Subnet in just a few
+Avalanche Subnet to send arbitrary messages to any other Avalanche Subnet in just a few
 seconds (or less) without relying on a trusted relayer or bridge (just the validators of the Subnet sending the message).
 You can learn more about AWM and how it works
 [here](https://docs.google.com/presentation/d/1eV4IGMB7qNV7Fc4hp7NplWxK_1cFycwCMhjrcnsE9mU/edit).
@@ -416,7 +416,7 @@ Tree) on-disk but use S3 to store blocks and PostgreSQL to store transaction met
 
 ### Continuous Block Production
 Unlike other VMs on Avalanche, `hypervms` produce blocks continuously (even if empty).
-While this may sound wasteful, it improves the "worst case" AWM verification cost (AWM verfication
+While this may sound wasteful, it improves the "worst case" AWM verification cost (AWM verification
 requires creating a reverse diff to the last referenced P-Chain block), prevents a fallback to leaderless
 block production (which can lead to more rejected blocks), and avoids a prolonged post-bootstrap
 readiness wait (`hypersdk` waits to mark itself as ready until it has seen a `ValidityWindow` of blocks).
@@ -473,7 +473,7 @@ _To ensure the `hypersdk` remains reliable as we optimize and evolve the codebas
 we also run E2E tests in the `tokenvm` on each PR to the `hypersdk` core modules._
 
 ### Expert: `indexvm` [DEPRECATED]
-_The `indexvm` will be rewritten using the new WASM Progams module._
+_The `indexvm` will be rewritten using the new WASM Programs module._
 
 The [`indexvm`](https://github.com/ava-labs/indexvm) is much more complex than
 the `tokenvm` (more elaborate mechanisms and a new use case you may not be
@@ -569,10 +569,10 @@ ActionRegistry *codec.TypeParser[Action, *warp.Message, bool]
 AuthRegistry   *codec.TypeParser[Auth, *warp.Message, bool]
 ```
 
-The `ActionRegistry` and `AuthRegistry` are inform the `hypersdk` how to
+The `ActionRegistry` and `AuthRegistry` inform the `hypersdk` how to
 marshal/unmarshal bytes on-the-wire. If the `Controller` did not provide these,
 the `hypersdk` would not know how to extract anything from the bytes it was
-provded by the Avalanche Consensus Engine.
+provided by the Avalanche Consensus Engine.
 
 _In the future, we will provide an option to automatically marshal/unmarshal
 objects if an `ActionRegistry` and/or `AuthRegistry` is not provided using
@@ -948,7 +948,7 @@ out on the Avalanche Discord._
   of `hypervm` participants (even better if this is made abstract to any implementer
   such that they can just register and request data from it and it is automatically
   handled by the network layer). This module should make it possible for an
-  operator to use a single backend (like S3) to power storage fro multiple
+  operator to use a single backend (like S3) to power storage for multiple
   hosts.
 * Only set `export CGO_CFLAGS="-O -D__BLST_PORTABLE__"` when running on
   MacOS/Windows (will make Linux much more performant)

examples/morpheusvm/README.md

@@ -111,7 +111,7 @@ balance: 1000.000000000 RED
 
 ### Generate Another Address
 Now that we have a balance to send, we need to generate another address to send to. Because
-we use bech32 addresses, we can't just put a random string of characters as the reciepient
+we use bech32 addresses, we can't just put a random string of characters as the recipient
 (won't pass checksum test that protects users from sending to off-by-one addresses).
 ```bash
 ./build/morpheus-cli key generate

examples/tokenvm/DEVNETS.md

@@ -336,7 +336,7 @@ integrated block explorer. To do this, run the following command:
 /tmp/token-cli chain watch --hide-txs
 ```
 
-If you don't plan to load test the devnet, you may wush to just run the
+If you don't plan to load test the devnet, you may wish to just run the
 following command to get additional transaction details:
 ```bash
 /tmp/token-cli chain watch

examples/tokenvm/README.md

@@ -62,7 +62,7 @@ above). Each order requires only 152 bytes of
 state = `orderID=>inAsset|inTick|outAsset|outTick|remaining|owner`. This
 storage format also makes it possible to parallelize the execution of any fills
 that don't touch the same order (there may be hundreds or thousands of orders
-for the same pair, so this stil allows parallelization within a single pair
+for the same pair, so this still allows parallelization within a single pair
 unlike a pool-based trading mechanism like an AMM). This parallelism will take
 effect as soon as it is re-added upstream by the `hypersdk` (no action required
 in the `tokenvm`).
@@ -78,7 +78,7 @@ a simple max heap per pair where we arrange best on the best "rate" for a given
 asset (in/out).
 
 #### Sandwich-Resistant
-Because any fill must explicitly specify an order (it is up the client/CLI to
+Because any fill must explicitly specify an order (it is up to the client/CLI to
 implement a trading agent to perform a trade that may span multiple orders) to
 interact with, it is not possible for a bot to jump ahead of a transaction to
 negatively impact the price of your execution (all trades with an order occur
@@ -269,7 +269,7 @@ _`txID` is the `orderID` of your new order._
 
 The "in tick" is how much of the "in assetID" that someone must trade to get
 "out tick" of the "out assetID". Any fill of this order must send a multiple of
-"in tick" to be considered valid (this avoid ANY sort of precision issues with
+"in tick" to be considered valid (this avoids ANY sort of precision issues with
 computing decimal rates on-chain).
 
 #### Step 5: Fill Part of the Order
@@ -432,7 +432,7 @@ docker-compose -f trace/zipkin.yml down
 ## Deploying to a Devnet
 _In the world of Avalanche, we refer to short-lived, test Subnets as Devnets._
 
-To programaticaly deploy `tokenvm` to a distributed cluster of nodes running on
+To programmatically deploy `tokenvm` to a distributed cluster of nodes running on
 your own custom network or on Fuji, check out this [doc](DEVNETS.md).
 
 ## Future Work

x/programs/rust/README.md

@@ -7,7 +7,7 @@ The `wasm_guest` folder contains the `wasmlanche_sdk`, macros and example progra
 Just a couple things to note. Serialization is minimal, yet there are certain aspects in the code that need to follow a specific format. Specifically there are currently only two places we modify the bytes coming in/out of rust.
 
 - The first is quite minimal. When storing a value in the host, the `wasmlanche_sdk` prepends a single byte representing the type of `ProgramValue` being stored. This single byte is necessary to inform Rust about the variable type when retrieving from the `host`.
-- The second area is a bit more complex and happens during a call to invoke another program. In this case we pass a byte array which contains the parameters for the external function call. To construct the this we marshal all the params with their metadata into one final byte array. Each parameter is added in this order
+- The second area is a bit more complex and happens during a call to invoke another program. In this case we pass a byte array which contains the parameters for the external function call. To construct this we marshal all the params with their metadata into one final byte array. Each parameter is added in this order
   - length of the parameter in bytes(stored as a i64)
   - boolean, [1] if the parameter is an Int, [0] otherwise
   - the actual bytes of the parameter.