Fix typos

README.md

@@ -1,6 +1,6 @@
 # TON Enhancement Proposals (TEPs)
 
-> :warning: **WARNING:** this proposal system is experimental now, the process is a subject to change.
+> :warning: **WARNING:** this proposal system is experimental now, the process is subject to change.
 
 The main goal of TON Enhancement Proposals is to provide a convenient and formal way to propose changes to TON Blockchain
 and standardize ways of interaction between different parts of ecosystem.
@@ -48,7 +48,7 @@ In particular "Status" below has the following sense:
 | [123](https://github.com/ton-blockchain/TEPs/pull/123/files)          | Address Guideline update             | Guidelines         | 13.06.2023 | 🛠️Partially Deployed🛠️ |
 | [126](https://github.com/ton-blockchain/TEPs/pull/126/files)          | Compressed NFT Standard              | Contract Interface | 28.07.2023 | 🛠️Partially Deployed🛠️ |
 | [127](https://github.com/ton-blockchain/TEPs/pull/127/files)          | TON Storage in Metadata              | Contract Interface | 23.09.2023 | Proposed |
-| [130](https://github.com/ton-blockchain/TEPs/pull/130/files)          | Rebase Jettons standart              | Contract Interface | 04.12.2023 | Proposed |
+| [130](https://github.com/ton-blockchain/TEPs/pull/130/files)          | Rebase Jettons standard              | Contract Interface | 04.12.2023 | Proposed |
 | [131](https://github.com/ton-blockchain/TEPs/pull/131/files)          | Referral code in Query ID            | Contract Interface | 26.12.2023 | 🛠️Partially Deployed🛠️ |
 | [137](https://github.com/ton-blockchain/TEPs/pull/137/files)          | Jetton Wallet Balance Query          | Contract Interface | 09.01.2024 | Proposed |
 | [140](https://github.com/ton-blockchain/TEPs/pull/140/files)          | Programmable Action Phase            | Core               | 20.01.2024 | Proposed |

text/0085-sbt-standard.md

@@ -137,7 +137,7 @@ https://github.com/getgems-io/nft-contracts/blob/main/packages/contracts/sources
 #### Minting
 It can be done using basic NFT collection, SBT should be an item. In mint message additionally authority address should be passed, [after content](https://github.com/getgems-io/nft-contracts/blob/main/packages/contracts/sources/sbt-item.fc#L90). 
 
-Before mint, issuer is recommended to check the wallet code and confirm that it is standartized wallet and not some transferrable contract that can be sold to 3rd parties.
+Before mint, issuer is recommended to check the wallet code and confirm that it is standardized wallet and not some transferrable contract that can be sold to 3rd parties.
 
 #### Proving you ownership to contracts
 SBT contracts has a feature that let you implement interesting mechanics with contracts by proving ownership onchain. 
@@ -241,19 +241,19 @@ slice calculate_sbt_address(slice collection_addr, cell sbt_item_code, int wc, i
 
 - **Why is this design the best in the space of possible designs?**
 
-This design allows us to use SBT as certificates, with revoke and onchain proofs, and in the same time allows to make true SBT if authority in not set.
+This design allows us to use SBT as certificates, with revoke and onchain proofs, and at the same time allows to make true SBT if authority in not set.
 
 - **What other designs have been considered and what is the rationale for not choosing them?**
 
-Initially, the design similar to ETH with address-bounded tokens was considered, but it was extended with usefull onchain proofs and revoke option.
+Initially, the design similar to ETH with address-bounded tokens was considered, but it was extended with useful onchain proofs and revoke option.
 
 - **What is the impact of not doing this?**
 
 Currently, TON have no owner-bounded token standard, so it is a problem to issue tokens that cannot be transferred to 3rd parties. So, if we ignore this or any similar standard that introduces such mechanics, TON could miss some interesting and perspective products.
 
 # Prior art
 
-In ETH ([EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973)) - SBT was done as an NFT which could not be transferred between accounts at all. We did tha same but extended the logic with onchain proofs, and added authority which can revoke, so SBT can be used as fully functional certificate.
+In ETH ([EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973)) - SBT was done as an NFT which could not be transferred between accounts at all. We did the same but extended the logic with onchain proofs, and added authority which can revoke, so SBT can be used as fully functional certificate.
 # Drawbacks
 
 [EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973) has equip/unequip mechanics which allows to show/hide SBT temporarily. In current proposal we can only destroy SBT. Actually not sure that show/hide logic is needed for us.