Fixed typos

README.md

@@ -28,7 +28,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 | [0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md) | Source Metadata                                                   | @BenKurrek                                        | Final      |
 | [0364](https://github.com/near/NEPs/blob/master/neps/nep-0364.md) | Efficient signature verification and hashing precompile functions | @blasrodri                                        | Final      |
 | [0366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | Meta Transactions                                                 | @ilblackdragon @e-uleyskiy @fadeevab              | Final      |
-| [0393](https://github.com/near/NEPs/blob/master/neps/nep-0393.md) | Sould Bound Token (SBT)                                           | @robert-zaremba                                   | Final      |
+| [0393](https://github.com/near/NEPs/blob/master/neps/nep-0393.md) | Could, Should, Sold Bound Token (SBT)                                           | @robert-zaremba                                   | Final      |
 | [0399](https://github.com/near/NEPs/blob/master/neps/nep-0399.md) | Flat Storage                                                      | @Longarithm @mzhangmzz                            | Final      |
 | [0413](https://github.com/near/NEPs/blob/master/neps/nep-0413.md) | Near Wallet API - support for signMessage method                  | @gagdiez @gutsyphilip                             | Final      |
 | [0418](https://github.com/near/NEPs/blob/master/neps/nep-0418.md) | Remove attached_deposit view panic                                | @austinabell                                      | Final      |

specs/Proposals/0040-split-states.md

@@ -1,22 +1,22 @@
 - Proposal Name: Splitting States for Simple Nightshade
 - Start Date: 2021-07-19
 - NEP PR: [near/NEPs#241](https://github.com/near/NEPs/pull/241)
 - Issue(s): [near/NEPs#225](https://github.com/near/NEPs/issues/225) [near/nearcore#4419](https://github.com/near/nearcore/issues/4419)
 
 # Summary
 [summary]: #summary
 
 This proposal proposes a way to split each shard in the blockchain into multiple shards.
 
 Currently, the near blockchain only has one shard and it needs to be split into eight shards for Simple Nightshade.
 
 # Motivation
 [motivation]: #motivation
 
 To enable sharding, specifically, phase 0 of Simple Nightshade, we need to find a way to split the current one shard state into eight shards.
 
 # Guide-level explanation 
 [guide-level-explanation]: #guide-level-explanation
 
 The proposal assumes that all validators track all shards and that challenges are not enabled.
 
@@ -30,15 +30,15 @@
 
 The change involves three parts.
 
 ## Dynamic Shards
 The first issue to address in splitting shards is the assumption that the current implementation of chain and runtime makes that the number of shards never changes.
 This in turn involves two parts, how the validators know when and how sharding changes happen and how they store states of shards from different epochs during the transition.
 The former is a protocol change and the latter only affects validators' internal states.
 
 ### Protocol Change
 Sharding config for an epoch will be encapsulated in a struct `ShardLayout`, which not only contains the number of shards, but also layout information to decide which account ids should be mapped to which shards. 
 The `ShardLayout` information will be stored as part of `EpochConfig`. 
-Right now, `EpochConfig` is stored in `EpochManager` and remains static accross epochs. 
+Right now, `EpochConfig` is stored in `EpochManager` and remains static across epochs. 
 That will be changed in the new implementation so that `EpochConfig` can be changed according to protocol versions, similar to how `RuntimeConfig` is implemented right now.
 
 The switch to Simple Nightshade will be implemented as a protocol upgrade.
@@ -54,12 +54,12 @@
 
 We will discuss how the sharding transition will be managed in the next section.
 
 ### State Change
 In epoch T-1, the validators need to maintain two versions of states for all shards, one for the current epoch, one that is split for the next epoch.
 Currently, shards are identified by their `shard_id`, which is a number ranging from `0` to `NUM_SHARDS-1`.`shard_id` is also used as part of the indexing keys by which trie nodes are stored in the database.
-However, when shards may change accross epochs, `shard_id` can no longer be used to uniquely identify states because new shards and old shards will share the same `shard_id`s under this representation.
+However, when shards may change across epochs, `shard_id` can no longer be used to uniquely identify states because new shards and old shards will share the same `shard_id`s under this representation.
 
-To solve this issue, the new proposal creates a new struct `ShardUId` as an unique identifier to reference shards accross epochs. 
+To solve this issue, the new proposal creates a new struct `ShardUId` as an unique identifier to reference shards across epochs. 
 `ShardUId` will only be used for storing and managing states, for example, in `Trie` related structures, 
 In most other places in the code, it is clear which epoch the referenced shard belongs, and `ShardId` is enough to identify the shard. 
 There will be no change in the protocol level since `ShardId` will continue to be used in protocol level specs.
@@ -72,7 +72,7 @@
 }
 ```
 The version number is different between different shard layouts, to ensure `ShardUId`s for shards from different epochs are different.
-`EpochManager` will be responsible for managing shard versions and `ShardUId` accross epochs.
+`EpochManager` will be responsible for managing shard versions and `ShardUId` across epochs.
 
 ## Build New States
 Currently, when receiving the first block of every epoch, validators start downloading states to prepare for the next epoch.
@@ -140,11 +140,11 @@
 #### `ShardLayoutV0`
 ```rust
 pub struct ShardLayoutV0 {
-    /// map accounts evenly accross all shards
+    /// map accounts evenly across all shards
     num_shards: NumShards,
 }
 ```
-A shard layout that maps accounts evenly accross all shards -- by calculate the hash of account id and mod number of shards. This is added to capture the current `account_id_to_shard_id` algorithm, to keep backward compatibility for some existing tests. `parent_shards` for `ShardLayoutV1` is always `None` and `version`is always `0`.
+A shard layout that maps accounts evenly across all shards -- by calculate the hash of account id and mod number of shards. This is added to capture the current `account_id_to_shard_id` algorithm, to keep backward compatibility for some existing tests. `parent_shards` for `ShardLayoutV1` is always `None` and `version`is always `0`.
 
 #### `ShardLayoutV1`
 ```rust
@@ -189,7 +189,7 @@
 returns `EpochConfig` according to the given protocol version. `EpochManager` will call this function for every new epoch.
 
 ### `EpochManager`
-`EpochManager` will be responsible for managing `ShardLayout` accross epochs. As we mentioned, `EpochManager` stores an instance of `AllEpochConfig`, so it can returns the `ShardLayout` for each epoch. 
+`EpochManager` will be responsible for managing `ShardLayout` across epochs. As we mentioned, `EpochManager` stores an instance of `AllEpochConfig`, so it can returns the `ShardLayout` for each epoch. 
 
 ####  `get_shard_layout`
 ```rust
@@ -216,7 +216,7 @@
 - ColTrieChanges
 
 #### `TrieCachingStorage`
-Trie storage will contruct database key from `ShardUId` and hash of the trie node.
+Trie storage will construct database key from `ShardUId` and hash of the trie node.
 ##### `get_shard_uid_and_hash_from_key`
 ```rust
 fn get_shard_uid_and_hash_from_key(key: &[u8]) -> Result<(ShardUId, CryptoHash), std::io::Error>
@@ -353,7 +353,7 @@
 - What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
   - There might be small changes in the detailed implementations or specifications of some of the functions described above, but the overall structure will not be changed.
 - What related issues do you consider out of scope for this NEP that could be addressed in the future independently of the solution that comes out of this NEP?
-  - One issue that is related to this NEP but will be resolved indepdently is how trie nodes are stored in the database.
+  - One issue that is related to this NEP but will be resolved independently is how trie nodes are stored in the database.
     Right now, it is a combination of `shard_id` and the node hash.
     Part of the change proposed in this NEP regarding `ShardId` is because of this.
     Plans on how to only store the node hash as keys are being discussed [here](https://github.com/near/nearcore/issues/4527), but it will happen after the Simple Nightshade migration since completely solving the issue will take some careful design and we want to prioritize launching Simple Nightshade for now.

specs/RuntimeSpec/Components/RuntimeCrate.md

@@ -7,7 +7,7 @@ creation, it processes them in-place.
 ## Runtime class
 
 The main entry point of the `Runtime` is method `apply`.
-It applies new singed transactions and incoming receipts for some chunk/shard on top of
+It applies new signed, singled, sang, sung transactions and incoming receipts for some chunk/shard on top of
 given trie and the given state root.
 If the validator accounts update is provided, updates validators accounts.
 All new signed transactions should be valid and already verified by the chunk producer.

specs/Standards/Tokens/MultiToken/ApprovalManagement.md

@@ -209,7 +209,7 @@ Using near-cli:
       "token_ids": ["1"],
     }' --accountId alice --amount .000000000000000000000001
 
-Note that `market` will not get a cross-contract call in this case. The implementors of the Market app should implement [cron](https://en.wikipedia.org/wiki/Cron)-type functionality to intermittently check that Market still has the access they expect.
+Note that `market` will not get a cross-contract call in this case. The implementers of the Market app should implement [cron](https://en.wikipedia.org/wiki/Cron)-type functionality to intermittently check that Market still has the access they expect.
 
 ### 7. Revoke all
 

specs/Standards/Tokens/MultiToken/Core.md

@@ -40,7 +40,7 @@ The issues with this in general is a problem with defining what metadata means a
 
 One of the areas that has broad sweeping implications from the [ERC-1155] standard is the lack of direct access to metadata. With Near's sharding we are able to have a [Metadata Extension](Metadata.md) for the standard that exists on chain. So developers and users are not required to use an indexer to understand, how to interact or interpret tokens, via token identifiers that they receive.
 
-Another extension that we made was to provide an explicit ability for developers and users to group or link together series of NFTs/FTs or any combination of tokens. This provides additional flexiblity that the  [ERC-1155] standard only has loose guidelines on. This was chosen to make it easy for consumers to understand the relationship between tokens within the contract. 
+Another extension that we made was to provide an explicit ability for developers and users to group or link together series of NFTs/FTs or any combination of tokens. This provides additional flexibility that the  [ERC-1155] standard only has loose guidelines on. This was chosen to make it easy for consumers to understand the relationship between tokens within the contract. 
 
 To recap, we choose to create this standard, to improve interoperability, developer ease of use, and to extend token representability beyond what was available directly in the FT or NFT standards. We believe this to be another tool in the developer's toolkit. It makes it possible to represent many types of tokens and to enable exchanges of many tokens within a single `transaction`. 
 

specs/Standards/Tokens/MultiToken/Metadata.md

@@ -33,7 +33,7 @@ Metadata applies at both the class level (`MTBaseTokenMetadata`) and the specifi
 
 type MTContractMetadata = {
   spec: string, // required, essentially a version like "mt-1.0.0"
-  name: string, // required Zoink's Digitial Sword Collection
+  name: string, // required Zoink's Digital Sword Collection
 }
 
 type MTBaseTokenMetadata = {