Fix typos (#2383)

* fix typos

docs/3.tutorials/crosswords/03-intermediate/01-access-key-solution.md

@@ -31,7 +31,7 @@ There have been several incidents of this and it continues to be an issue.
 
 ## How?
 
-We're doing to do something unique — and frankly unusual — with our crossword puzzle. We're going to use function-call access keys in a new way.
+We're going to do something unique — and frankly unusual — with our crossword puzzle. We're going to use function-call access keys in a new way.
 
 Our crossword puzzle smart contract will add a function-call access key to itself. The private key is derived from the solution, used as a seed phrase.
 
@@ -45,7 +45,7 @@ A seed phrase is a series of words (usually 12 or 24 words) that create a privat
 Seed phrases typically use a [BIP-30 wordlist](https://github.com/bitcoin/bips/blob/master/bip-0039/bip-0039-wordlists.md), but *they do not need to* use a wordlist or have a certain number of words. As long as the words create entropy, a crossword puzzle solution can act as a deterministic seed phrase.
 :::
 
-So when we add a new puzzle, we'll use the `AddKey` Action to add a limited, function-call access key can that *only* call the `submit_solution` method.
+So when we add a new puzzle, we'll use the `AddKey` Action to add a limited, function-call access key that can *only* call the `submit_solution` method.
 
 The first user to solve the puzzle will essentially "discover" the private key and call that method. Think of it like a safe that contains a function-call access key.
 

docs/3.tutorials/nfts/4-core.md

@@ -126,11 +126,11 @@ This way, we can effectively **attach an NFT to a function call**.
 
 The function will first assert that the caller attached exactly 1 yocto for security purposes. It will then transfer the NFT using `internal_transfer` and start the cross contract call. It will call the method `nft_on_transfer` on the `receiver_id`'s contract, and create a promise to call back `nft_resolve_transfer` with the result. This is a very common workflow when dealing with [cross contract calls](../../2.build/2.smart-contracts/anatomy/crosscontract.md).
 
-As dictated by the core standard, the function we are calling (`nft_on_transfer`) needs to return a boolean stating whether or not you should return the NFT to it's original owner.
+As dictated by the core standard, the function we are calling (`nft_on_transfer`) needs to return a boolean stating whether or not you should return the NFT to its original owner.
 
 <Github language="rust" start="146" end="201" url="https://github.com/near-examples/nft-tutorial/blob/main/nft-contract-basic/src/nft_core.rs" />
 
-If `nft_on_transfer` returned true or the called failed, you should send the token back to it's original owner. On the contrary, if false was returned, no extra logic is needed.
+If `nft_on_transfer` returned true or the called failed, you should send the token back to its original owner. On the contrary, if false was returned, no extra logic is needed.
 
 As for the return value of our function `nft_resolve_transfer`, the standard dictates that the function should return a boolean indicating whether or not the receiver successfully received the token or not.
 

docs/5.api/rpc/transactions.md

@@ -877,7 +877,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
 
 ### Receipt by ID {#receipt-by-id}
 
-> Fetches a receipt by it's ID (as is, without a status or execution outcome)
+> Fetches a receipt by its ID (as is, without a status or execution outcome)
 
 - method: `EXPERIMENTAL_receipt`
 - params:

docs/help.md

@@ -110,7 +110,7 @@ These community groups are part of the 31 chats from [nearbuilders.com](https://
 
 ### 🚀 Decentralized Frontend Stack
 
-> Create decentralized frontend components by storing it's source code on the blockchain 🤯.
+> Create decentralized frontend components by storing its source code on the blockchain 🤯.
 
 | Name      | Description | Repo | Latest Release |
 | ----------- | ----------- | --- |--|