Merge branch 'master' into document_delegate_action

neps/nep-0141.md

@@ -38,7 +38,7 @@ Prior art:
 
 Learn about NEP-141:
 
-- [Figment Learning Pathway](https://learn.figment.io/tutorials/stake-fungible-token)
+- [Figment Learning Pathway](https://web.archive.org/web/20220621055335/https://learn.figment.io/tutorials/stake-fungible-token)
 
 ## Specification
 

specs/DataStructures/Account.md

@@ -2,8 +2,6 @@
 
 ## Account ID
 
-[account_id]: #account_id
-
 NEAR Protocol has an account names system. Account ID is similar to a username. Account IDs have to follow the rules.
 
 ### Account ID Rules
@@ -26,6 +24,7 @@ Regex for a full account ID, without checking for length:
 ```regex
 ^(([a-z\d]+[\-_])*[a-z\d]+\.)*([a-z\d]+[\-_])*[a-z\d]+$
 ```
+
 ### Top Level Accounts
 
 | Name | Value |
@@ -52,7 +51,7 @@ def action_create_account(predecessor_id, account_id):
 
 Valid accounts:
 
-```
+```c
 ok
 bowen
 ek-2
@@ -73,7 +72,7 @@ bro.a
 
 Invalid accounts:
 
-```
+```c
 not ok           // Whitespace characters are not allowed
 a                // Too short
 100-             // Suffix separator
@@ -91,6 +90,7 @@ abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz
 ```
 
 ## System account
+
 `system` is a special account that is only used to identify refund receipts. For refund receipts, we set the predecessor_id to be `system` to indicate that it is a refund receipt. Users cannot create or access the `system` account. In fact, this account does not exist as part of the state. 
 
 ## Implicit account IDs
@@ -107,6 +107,7 @@ The corresponding secret key allows you to sign transactions on behalf of this a
 ### Implicit account creation
 
 An account with implicit account ID can only be created by sending a transaction/receipt with a single `Transfer` action to the implicit account ID receiver:
+
 - The account will be created with the account ID.
 - The account will have a new full access key with the ED25519-curve public key of `decode_hex(account_id)` and nonce `0`.
 - The account balance will have a transfer balance deposited to it.
@@ -117,8 +118,6 @@ Once an implicit account is created it acts as a regular account until it's dele
 
 ## Account
 
-[account]: #account
-
 Data for an single account is collocated in one shard. The account data consists of the following:
 
 - Balance

specs/Standards/Tokens/FungibleToken/Core.md

@@ -12,8 +12,9 @@ The [fungible token metadata standard](Metadata.md) provides the fields needed f
 ## Motivation
 
 NEAR Protocol uses an asynchronous, sharded runtime. This means the following:
- - Storage for different contracts and accounts can be located on the different shards.
- - Two contracts can be executed at the same time in different shards.
+
+- Storage for different contracts and accounts can be located on the different shards.
+- Two contracts can be executed at the same time in different shards.
 
 While this increases the transaction throughput linearly with the number of shards, it also creates some challenges for cross-contract development. For example, if one contract wants to query some information from the state of another contract (e.g. current balance), by the time the first contract receives the balance the real balance can change. In such an async system, a contract can't rely on the state of another contract and assume it's not going to change.
 
@@ -30,11 +31,12 @@ Prior art:
 
 Learn about NEP-141:
 
-- [Figment Learning Pathway](https://learn.figment.io/tutorials/stake-fungible-token)
+- [Figment Learning Pathway](https://web.archive.org/web/20220621055335/https://learn.figment.io/tutorials/stake-fungible-token)
 
 ## Guide-level explanation
 
 We should be able to do the following:
+
 - Initialize contract once. The given total supply will be owned by the given account ID.
 - Get the total supply.
 - Transfer tokens to a new user.
@@ -43,6 +45,7 @@ We should be able to do the following:
 - Remove state for the key/value pair corresponding with a user's account, withdrawing a nominal balance of Ⓝ that was used for storage.
 
 There are a few concepts in the scenarios above:
+
 - **Total supply**: the total number of tokens in circulation.
 - **Balance owner**: an account ID that owns some amount of tokens.
 - **Balance**: an amount of tokens.
@@ -60,27 +63,27 @@ Given that multiple users will use a Fungible Token contract, and their activity
 
 Alice wants to send 5 wBTC tokens to Bob.
 
-**Assumptions**
+##### Assumptions
 
 - The wBTC token contract is `wbtc`.
 - Alice's account is `alice`.
 - Bob's account is `bob`.
 - The precision ("decimals" in the metadata standard) on wBTC contract is `10^8`.
 - The 5 tokens is `5 * 10^8` or as a number is `500000000`.
 
-**High-level explanation**
+##### High-level explanation
 
 Alice needs to issue one transaction to wBTC contract to transfer 5 tokens (multiplied by precision) to Bob.
 
-**Technical calls**
+##### Technical calls
 
 1. `alice` calls `wbtc::ft_transfer({"receiver_id": "bob", "amount": "500000000"})`.
 
 #### Token deposit to a contract
 
 Alice wants to deposit 1000 DAI tokens to a compound interest contract to earn extra tokens.
 
-**Assumptions**
+##### Assumptions
 
 - The DAI token contract is `dai`.
 - Alice's account is `alice`.
@@ -92,14 +95,15 @@ Alice wants to deposit 1000 DAI tokens to a compound interest contract to earn e
 <details>
 <summary>For this example, you may expand this section to see how a previous fungible token standard using escrows would deal with the scenario.</summary>
 
-**High-level explanation** (NEP-21 standard)
+##### High-level explanation (NEP-21 standard)
 
 Alice needs to issue 2 transactions. The first one to `dai` to set an allowance for `compound` to be able to withdraw tokens from `alice`.
 The second transaction is to the `compound` to start the deposit process. Compound will check that the DAI tokens are supported and will try to withdraw the desired amount of DAI from `alice`.
+
 - If transfer succeeded, `compound` can increase local ownership for `alice` to 1000 DAI
 - If transfer fails, `compound` doesn't need to do anything in current example, but maybe can notify `alice` of unsuccessful transfer.
 
-**Technical calls** (NEP-21 standard)
+##### Technical calls (NEP-21 standard)
 
 1. `alice` calls `dai::set_allowance({"escrow_account_id": "compound", "allowance": "1000000000000000000000"})`.
 2. `alice` calls `compound::deposit({"token_contract": "dai", "amount": "1000000000000000000000"})`. During the `deposit` call, `compound` does the following:
@@ -108,11 +112,11 @@ The second transaction is to the `compound` to start the deposit process. Compou
 
 </details>
 
-**High-level explanation**
+##### High-level explanation
 
 Alice needs to issue 1 transaction, as opposed to 2 with a typical escrow workflow.
 
-**Technical calls**
+##### Technical calls
 
 1. `alice` calls `dai::ft_transfer_call({"receiver_id": "compound", "amount": "1000000000000000000000", "msg": "invest"})`. During the `ft_transfer_call` call, `dai` does the following:
    1. makes async call `compound::ft_on_transfer({"sender_id": "alice", "amount": "1000000000000000000000", "msg": "invest"})`.
@@ -124,7 +128,7 @@ Alice needs to issue 1 transaction, as opposed to 2 with a typical escrow workfl
 
 Alice wants to swap 5 wrapped NEAR (wNEAR) for BNNA tokens at current market rate, with less than 2% slippage.
 
-**Assumptions**
+##### Assumptions
 
 - The wNEAR token contract is `wnear`.
 - Alice's account is `alice`.
@@ -133,7 +137,7 @@ Alice wants to swap 5 wrapped NEAR (wNEAR) for BNNA tokens at current market rat
 - The precision ("decimals" in the metadata standard) on wNEAR contract is `10^24`.
 - The 5 tokens is `5 * 10^24` or as a number is `5000000000000000000000000`.
 
-**High-level explanation**
+##### High-level explanation
 
 Alice needs to issue one transaction to wNEAR contract to transfer 5 tokens (multiplied by precision) to `amm`, specifying her desired action (swap), her destination token (BNNA) & maximum slippage (<2%) in `msg`.
 
@@ -143,7 +147,7 @@ Alice needs to attach one yoctoNEAR. This will result in her seeing a confirmati
 
 Altogether then, Alice may take two steps, though the first may be a background detail of the app she uses.
 
-**Technical calls**
+##### Technical calls
 
 1. View `amm::ft_data_to_msg({ action: "swap", destination_token: "bnna", max_slip: 2 })`. Using [NEAR CLI](https://docs.near.org/docs/tools/near-cli):
 
@@ -179,6 +183,7 @@ Altogether then, Alice may take two steps, though the first may be a background
 ## Reference-level explanation
 
 **NOTES**:
+
 - All amounts, balances and allowance are limited by `U128` (max value `2**128 - 1`).
 - Token standard uses JSON for serialization of arguments and results.
 - Amounts in arguments and results have are serialized as Base-10 strings, e.g. `"100"`. This is done to avoid JSON limitation of max integer value of `2**53`.
@@ -322,6 +327,7 @@ function ft_resolve_transfer(
 ## History
 
 See also the discussions:
+
 - [Fungible token core](https://github.com/near/NEPs/discussions/146#discussioncomment-298943)
 - [Fungible token metadata](https://github.com/near/NEPs/discussions/148)
 - [Storage standard](https://github.com/near/NEPs/discussions/145)