Merge branch 'master' into restrict-ethereum-address

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
 

neps/nep-0366.md

@@ -3,10 +3,12 @@ NEP: 366
 Title: Meta Transactions
 Author: Illia Polosukhin <[email protected]>, Egor Uleyskiy ([email protected]), Alexander Fadeev ([email protected])
 DiscussionsTo: https://github.com/nearprotocol/neps/pull/366
-Status: Draft
+Status: Approved
 Type: Protocol Track
 Category: Runtime
+Version: 1.1.0
 Created: 19-Oct-2022
+LastUpdated: 03-Aug-2023
 ---
 
 ## Summary
@@ -149,7 +151,7 @@ DelegateActionInvalidSignature
 
 ```rust
 /// Receiver of the transaction doesn't match Sender of the delegate action
-DelegateActionSenderDoesNotMatchReceiver
+DelegateActionSenderDoesNotMatchTxReceiver
 ```
 
 - If the current block is equal or greater than `max_block_height`
@@ -180,13 +182,6 @@ DelegateActionInvalidNonce
 DelegateActionNonceTooLarge
 ```
 
-- If the list of delegated actions contains another `DelegateAction`
-
-```rust
-/// DelegateAction actions contain another DelegateAction
-DelegateActionCantContainNestedOne
-```
-
 - If the list of Transaction actions contains several `DelegateAction`
 
 ```rust
@@ -214,6 +209,13 @@ See the **_Validation_** section in [DelegateAction specification](/specs/Runtim
 
 Supporting ZK proofs instead of just signatures can allow for anonymous transactions, which pay fees to relayers anonymously.
 
+## Changelog
+
+### 1.1.0 - Adjust errors to reflect deployed reality (03-Aug`2023)
+
+- Remove the error variant `DelegateActionCantContainNestedOne` because this would already fail in the parsing stage.
+- Rename the error variant `DelegateActionSenderDoesNotMatchReceiver` to `DelegateActionSenderDoesNotMatchTxReceiver` to reflect published types in [near_primitives](https://docs.rs/near-primitives/0.17.0/near_primitives/errors/enum.ActionErrorKind.html#variant.DelegateActionSenderDoesNotMatchTxReceiver).
+
 ## Copyright
 
 Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).

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
@@ -151,7 +150,9 @@ Every account has its own storage. It's a persistent key-value trie. Keys are or
 The storage can only be modified by the contract on the account.
 Current implementation on Runtime only allows your account's contract to read from the storage, but this might change in the future and other accounts's contracts will be able to read from your storage.
 
-NOTE: Accounts are charged recurrent rent for the total storage. This includes storage of the account itself, contract code, contract storage and all access keys.
+NOTE: To pay for blockchain storage, the protocol locks a token amount per account proportional to its state size.
+This includes storage of the account itself, contract code, contract storage and all access keys.
+See [Storage Staking](https://docs.near.org/concepts/storage/storage-staking) in the docs.
 
 #### Access Keys