Merge branch 'master' into bos-extintion

docs/1.concepts/basics/accounts/access-keys.md

@@ -2,33 +2,33 @@
 id: access-keys
 title: Access Keys
 ---
-In blockchain, using an account actually refers to using a `private key` to sign [transactions](../transactions/overview.md).
+In blockchain, using an account refers to using a `private key` to sign [transactions](../transactions/overview.md).
 
 NEAR Accounts have the unique feature of holding multiple [public/private key pairs](https://en.wikipedia.org/wiki/Public-key_cryptography),
-called Access Keys, each with their **own set of permissions**.
+called Access Keys, each with its **own set of permissions**.
 
 Access Keys are similar to [OAuths](https://en.wikipedia.org/wiki/OAuth), enabling you to grant **limited access** over your account
 to third-parties.
 
 ---
 
 ## Benefits of Access Keys
-Since the concept of Access Keys is unique to NEAR it is worth to first understand why and how they can be used.
+Since the concept of Access Keys is unique to NEAR it is worth understanding why and how they can be used.
 
 #### Using An App Safely
 Imagine that you want to play a web3 game consisting of a web-app and a smart contract. You can create a key that only
-allows to **call specific methods** in the game's contract.
+allows you to **call specific methods** in the game's contract.
 
 You can safely give the key to the game, so it can sign **game-related transactions** for you without needing to interrupt
 the gameplay on each transaction.
 
 #### Replacing Keys
 If you think any of your keys could be compromised, you can simply remove them or swap them with a new one. Just as how
-you would change your password on any website.
+you can change your password on any website.
 
 #### Implementing Key Recovery
 You could implement a key-recovery [contract](smartcontract.md) in your account, and create a
-"recovery key" for someone you trust. Such key could only be used to start the recovery.
+"recovery key" for someone you trust. Such a key could only be used to start the recovery.
 
 When needed, that third-party component could trigger the recovery process, helping to create a new master for you.
 
@@ -46,7 +46,7 @@ As the name suggests, `FullAccess` keys have full control of an account, similar
 Particularly, Full Access keys can be used to sign transactions doing [any action](https://nomicon.io/RuntimeSpec/Actions) in your account's behalf:
 
 1. Create immediate [sub-accounts](account-id.md#rules-for-creating-named-accounts) and [top-level accounts](account-id.md#named-accounts) if the account ID's length is at least 32 characters.
-2. Delete your account (but **not** sub-accounts, since they have their own keys).
+2. Delete your account (but **not** sub-accounts, since they have their keys).
 3. Add or remove Access Keys.
 4. Deploy a smart contract in the account.
 5. Call methods on any contract (yours or others).
@@ -85,6 +85,6 @@ If the dApps requests to transfer **any amount of tokens** with the `FunctionCal
 If you remove all keys from an account, then the account will become **locked**, meaning that no external actor can perform transactions in the
 account's name.
 
-In practice, this means that only the account's smart contract can transfer assets, create sub-accounts, or update its own code.
+In practice, this means that only the account's smart contract can transfer assets, create sub-accounts, or update its code.
 
 Locking an account is very useful when one wants to deploy a contract, and let the community be assured that only the contract is in control of the account.

docs/1.concepts/web3/near.md

@@ -127,7 +127,7 @@ In general, cross-contract call graphs can be quite complex (one contract may ca
 
 We’ve already discussed the storage model on NEAR, but only in abstract terms, without bringing the exact structure, so it’s time to dive a bit deeper. 
 
-Natively, NEAR smart contracts store data as key-value pairs. This is quite limiting, since even simplest applications usually need more advanced data structures. To help in development, NEAR provides [SDK for smart contracts](https://github.com/near/near-sdk-rs), which includes data structures [like vectors, sets and maps](../../1.concepts/storage/data-collections.md#rust-collection-types-rust-collection-types). While they are very useful, it’s important to remember a few things about them:
+Natively, NEAR smart contracts store data as key-value pairs. This is quite limiting, since even simplest applications usually need more advanced data structures. To help in development, NEAR provides [SDK for smart contracts](https://github.com/near/near-sdk-rs), which includes data structures like [vectors, sets and maps](../../1.concepts/storage/data-collections.md#rust-collection-types-rust-collection-types). While they are very useful, it’s important to remember a few things about them:
 - Ultimately, they are stored as binary values, which means it takes some gas to serialize and deserialize them. Also, different operations cost different amounts of gas ([complexity table](../../1.concepts/storage/data-collections.md#big-o-notation-big-o-notation-1)). Because of this, careful choice of data structures is very important. Moving to a different data structure later will not be easy and would probably require data migration.
 - While very useful, vectors, maps and sets won’t match the flexibility and power of classical relational databases. Even implementations of simple filtering and searching might be quite complex and require a lot of gas to execute, especially if multiple entities with relations between them are involved.
 - They are limited to a single contract. If data from multiple contracts is required, aggregation should be performed using cross-contract calls or on a client side, which is quite expensive in terms of gas and time.

docs/2.develop/integrate/quickstart.md

@@ -11,7 +11,7 @@ Most interactions with the NEAR ecosystem can be grouped in 2 categories:
 1. Interacting with a [NEAR smart contract](/develop/contracts/quickstart).
 2. Interacting with a [NEAR component](/bos/tutorial/quickstart).
 
-In this guide we will show you how to quickly spin-up an application were users can **login** using their wallets and interact with both **contracts** and **components**.
+In this guide we will show you how to quickly spin-up an application where users can **login** using their wallets and interact with both **contracts** and **components**.
 
 Furthermore, the application readily integrates a `Web3 wallet`, allowing people to use `Metamask` to interact with multi-chain components.
 
@@ -161,4 +161,4 @@ That's it for our quickstart  tutorial. You have now seen a fully functional fro
 
 If you have any questions, do not hesitate in joining us on [Discord](https://near.chat). We regularly host Office Hours, in which you can join our voice channel and ask questions.
 
-Happy coding!
+Happy coding!

docs/5.api/rpc/transactions.md

@@ -470,36 +470,6 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \
 </p>
 </details>
 
-<blockquote class="warning">
-<strong>heads up</strong><br /><br />
-
-In the case of function call transactions, this query will not wait for **all** receipts generated by this transaction to finish before returning a result. Rather, it will only wait for its return value to finish before returning; _which could be a promise_.
-
-Let's say a transaction only contains a "function call" action that calls a `transfer()` method like the one below _(written in [Rust](https://www.rust-lang.org/))_. It will only wait for the "function call" receipt, not necessarily the receipt from the actual transfer of funds to finish before returning a result.
-
-```rust
-pub fn transfer(receiver_id: String) {
-    Promise::new(receiver_id).transfer(10);
-}
-```
-
-However, if we slightly modify the function to have the promise as a return value, then the `tx` status query will wait for this promise to finish _before_ returning results.
-
-```rust
-pub fn transfer_promise(receiver_id: String) -> Promise {
-    Promise::new(receiver_id).transfer(10)
-}
-```
-
-Despite such design, the `tx` endpoint can be used to check whether all receipts have finished.
-
-Instead of looking at the main result `status`, we can check all of the receipts
-returned `status` and see if any are `Unknown`. If none of the receipts statuses are unknown, we can be certain that all receipts generated have finished.
-
-In addition, `tx` endpoint does not provide finality guarantees. To make sure that the entire execution is final, it suffices to ensure every `block_hash` in every outcome is `final`.
-
-</blockquote>
-
 #### What could go wrong? {#what-could-go-wrong-2}
 
 When API request fails, RPC server returns a structured error response with a limited number of well-defined error variants, so client code can exhaustively handle all the possible error cases. Our JSON-RPC errors follow [verror](https://github.com/joyent/node-verror) convention for structuring the error response: