near · ori-near · Nov 24, 2022 · Jun 21, 2022 · Jun 23, 2022 · Jun 23, 2022
@@ -25,6 +25,7 @@ Changes to the protocol specification and standards are called NEAR Enhancement
 |[0245](https://github.com/near/NEPs/blob/master/neps/nep-0245.md)   | Multi Token Standard | @zcstarr @riqi @jriemann @marcos.sun | Review |
 |[0297](https://github.com/near/NEPs/blob/master/neps/nep-0297.md)   | Events Standard | @telezhnaya | Final |
 |[0330](https://github.com/near/NEPs/blob/master/neps/nep-0330.md)   | Source Metadata | @BenKurrek | Review |
+|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0000.md) | Meta Transactions | @ilblackdragon | Draft |
-|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0000.md) | Meta Transactions | @ilblackdragon | Draft |
+|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | Meta Transactions | @ilblackdragon | Draft |
-|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0000.md) | Meta Transactions | @ilblackdragon | Draft |
+|[0366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) | Meta Transactions | @ilblackdragon | Draft |
 
 
 

@@ -0,0 +1,148 @@
+---
+NEP: 366
+Title: Meta Transactions
+Author: Illia Polosukhin <[email protected]>
+DiscussionsTo: https://github.com/nearprotocol/neps/pull/366
+Status: Draft
+Type: Protocol Track
+Category: Runtime
+Created: 21-Jun-2022
+---
+
+## Summary
+
+In-protocol meta transactions allowing for third-party account to initiate and pay transaction fees on behalf of the account.
+
+## Motivation
+
+NEAR has been designed with simplicity of onboarding in mind. One of the large hurdles right now is that after creating an implicit or even named account the user does not have NEAR to pay gas fees to interact with apps.
+
+For example, apps that pay user for doing work (like NEARCrowd or Sweatcoin) or free-to-play games.
+
+[Aurora Plus](https://aurora.plus) has shown viability of the relayers that can offer some number of free transactions and a subscription model. Shifting the complexity of dealing with fees to the infrastructure from the user space.
+
+## Rationale and alternatives
+
+Proposed here design provides the easiest for users and developers way to onboard and pay for user transactions.
-Proposed here design provides the easiest for users and developers way to onboard and pay for user transactions.
+The proposed design here provides the easiest way for users and developers to onboard and to pay for user transactions.
-Proposed here design provides the easiest for users and developers way to onboard and pay for user transactions.
+The proposed design here provides the easiest way for users and developers to onboard and to pay for user transactions.
+There is no requirement on the user account, including user account may not even exist on chain and implicit account can be used.
-There is no requirement on the user account, including user account may not even exist on chain and implicit account can be used.
+There are no requirements on the user account.  The user account may not even exist on the chain and an implicit account can be used instead.
-There is no requirement on the user account, including user account may not even exist on chain and implicit account can be used.
+There are no requirements on the user account.  The user account may not even exist on the chain and an implicit account can be used instead.
+
+An alternative is proxy contracts deployed on the user account.
+This design has severe limitations as it requires user to deploy such contract and additional costs for storage.
-An alternative is proxy contracts deployed on the user account.
-This design has severe limitations as it requires user to deploy such contract and additional costs for storage.
+An alternative is to use proxy contracts deployed on the user account.
+This design has severe limitations as it requires the user to deploy such contracts and incur additional costs for storage.
-An alternative is proxy contracts deployed on the user account.
-This design has severe limitations as it requires user to deploy such contract and additional costs for storage.
+An alternative is to use proxy contracts deployed on the user account.
+This design has severe limitations as it requires the user to deploy such contracts and incur additional costs for storage.
+
+## Specification
+
+The main flow of the meta transaction will be as follows:
+ - User will sign `DelegateActionMessage` specifying set of actions that they need to be executed. It also includes specific relayer to ensure secure execution.
- - User will sign `DelegateActionMessage` specifying set of actions that they need to be executed. It also includes specific relayer to ensure secure execution.
+ - User signs a `DelegateActionMessage` specifying the set of actions that they need to be executed. It will also specify a relayer to ensure secure execution.
- - User will sign `DelegateActionMessage` specifying set of actions that they need to be executed. It also includes specific relayer to ensure secure execution.
+ - User signs a `DelegateActionMessage` specifying the set of actions that they need to be executed. It will also specify a relayer to ensure secure execution.
+ - User sends signed `DelegateAction` data to the relayer
- - User sends signed `DelegateAction` data to the relayer
+ - User sends the signed `DelegateAction` data to the relayer
- - User sends signed `DelegateAction` data to the relayer
+ - User sends the signed `DelegateAction` data to the relayer
+ - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]`, and signs it with it's key. Note, that such transaction can contain other actions toward user's account (for example calling a function).
- - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]`, and signs it with it's key. Note, that such transaction can contain other actions toward user's account (for example calling a function).
+ - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]` and signs it with it's key. Note that such transactions can contain other actions toward user's account (for example calling a function).
- - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]`, and signs it with it's key. Note, that such transaction can contain other actions toward user's account (for example calling a function).
+ - Relayer forms a `Transaction` with `receiver_id` equal to the user's account and `actions: [DelegateAction { ... }]` and signs it with it's key. Note that such transactions can contain other actions toward user's account (for example calling a function).
+ - This transaction is processed normally, by creating a receipt with copy of the all the actions into the `Receipt`.
- - This transaction is processed normally, by creating a receipt with copy of the all the actions into the `Receipt`.
+ - This transaction is processed normally.  A `Receipt` is created with a copy of the actions in the transaction.
- - This transaction is processed normally, by creating a receipt with copy of the all the actions into the `Receipt`.
+ - This transaction is processed normally.  A `Receipt` is created with a copy of the actions in the transaction.
+ - When processing `DelegateAction` a number of checks are done (see below), mainly `signature` matching user account's key.
- - When processing `DelegateAction` a number of checks are done (see below), mainly `signature` matching user account's key.
+ - When processing a `DelegateAction`, a number of checks are done (see below), mainly a check to ensure that the `signature` matches the user account's key.
- - When processing `DelegateAction` a number of checks are done (see below), mainly `signature` matching user account's key.
+ - When processing a `DelegateAction`, a number of checks are done (see below), mainly a check to ensure that the `signature` matches the user account's key.
+ - When such `Receipt` with valid `DelegateAction` in actions arrives to the user's account it gets executed. The executed means creation of a new Receipt with `receiver_id: AccountId`, `actions: Action` matching `receiver_id` and `actions` inside `DelegateAction`. 
- - When such `Receipt` with valid `DelegateAction` in actions arrives to the user's account it gets executed. The executed means creation of a new Receipt with `receiver_id: AccountId`, `actions: Action` matching `receiver_id` and `actions` inside `DelegateAction`. 
+ - When a `Receipt` with a valid `DelegateAction` in actions arrives at the user's account, it gets executed. Execution means creation of a new Receipt with `receiver_id: AccountId` and `actions: Action` matching `receiver_id` and `actions` in the `DelegateAction`. 
- - When such `Receipt` with valid `DelegateAction` in actions arrives to the user's account it gets executed. The executed means creation of a new Receipt with `receiver_id: AccountId`, `actions: Action` matching `receiver_id` and `actions` inside `DelegateAction`. 
+ - When a `Receipt` with a valid `DelegateAction` in actions arrives at the user's account, it gets executed. Execution means creation of a new Receipt with `receiver_id: AccountId` and `actions: Action` matching `receiver_id` and `actions` in the `DelegateAction`. 
+ - The new `Receipt` looks like normal receipt that would have been originating from user's account, with `predeccessor_id` equal to user's account.
- - The new `Receipt` looks like normal receipt that would have been originating from user's account, with `predeccessor_id` equal to user's account.
+ - The new `Receipt` looks like a normal receipt that could have originated from the user's account, with `predeccessor_id` equal to user's account.
- - The new `Receipt` looks like normal receipt that would have been originating from user's account, with `predeccessor_id` equal to user's account.
+ - The new `Receipt` looks like a normal receipt that could have originated from the user's account, with `predeccessor_id` equal to user's account.
+
+### DelegateAction
+
+Delegate action allows for an account to initiate a batch of actions on behalf of the receiving account, allowing to proxy actions. This is used in implementation of meta transactions.
-Delegate action allows for an account to initiate a batch of actions on behalf of the receiving account, allowing to proxy actions. This is used in implementation of meta transactions.
+Delegate actions allows for an account to initiate a batch of actions on behalf of a receiving account, allowing proxy actions. This can be used to implement meta transactions.
-Delegate action allows for an account to initiate a batch of actions on behalf of the receiving account, allowing to proxy actions. This is used in implementation of meta transactions.
+Delegate actions allows for an account to initiate a batch of actions on behalf of a receiving account, allowing proxy actions. This can be used to implement meta transactions.
+
+```rust
+pub struct DelegateAction {
+    /// Receiver of the delegated actions.
+    receiver_id: AccountId,
+    /// List of actions to be executed.
+    actions: Vec<Action>,
+
+    /// Public key that is used to sign this delegated action.
+    signer_pk: PublicKey,
+    /// Nonce is used to determine that the same delegate action is not sent twice by relayers and should match for given account's `signer_pk`. 
-    /// Nonce is used to determine that the same delegate action is not sent twice by relayers and should match for given account's `signer_pk`. 
+    /// Nonce to ensure that the same delegate action is not sent twice by a relayer and should match for given account's `signer_pk`.  
-    /// Nonce is used to determine that the same delegate action is not sent twice by relayers and should match for given account's `signer_pk`. 
+    /// Nonce to ensure that the same delegate action is not sent twice by a relayer and should match for given account's `signer_pk`.  
+    /// After this action is processed it will increment.
+    nonce: Nonce,
+    /// Signature of the originating user signing `DelegateActionMessage` formed out of the data in the `DelegateAction`.
+    signature: Signature,
+}
+```
+
+ Supporting a batch of `actions` means `DelegateAction` can initiate a complex steps like creating a new account and transferring funds, deploying a contract and executing an initialization function.
- Supporting a batch of `actions` means `DelegateAction` can initiate a complex steps like creating a new account and transferring funds, deploying a contract and executing an initialization function.
+ Supporting batches of `actions` means `DelegateAction` can be used initiate a complex steps like creating new accounts, transferring funds, deploying contracts, and executing an initialization function all within the same transaction.
- Supporting a batch of `actions` means `DelegateAction` can initiate a complex steps like creating a new account and transferring funds, deploying a contract and executing an initialization function.
+ Supporting batches of `actions` means `DelegateAction` can be used initiate a complex steps like creating new accounts, transferring funds, deploying contracts, and executing an initialization function all within the same transaction.
+
+***Validation***:
+To ensure that `DelegateAction` is correct, on receival the verification of signature is done: `verify_signature(hash(message), signer_pk, signature)`.
-To ensure that `DelegateAction` is correct, on receival the verification of signature is done: `verify_signature(hash(message), signer_pk, signature)`.
+To ensure that a `DelegateAction` is correct, on receipt the following signature verification is performed: `verify_signature(hash(message), signer_pk, signature)`.
-To ensure that `DelegateAction` is correct, on receival the verification of signature is done: `verify_signature(hash(message), signer_pk, signature)`.
+To ensure that a `DelegateAction` is correct, on receipt the following signature verification is performed: `verify_signature(hash(message), signer_pk, signature)`.
+
+The `message` is formed in the next format and must be signed by the user:
-The `message` is formed in the next format and must be signed by the user:
+A `message` is formed in the following format and it must be signed by the user:
-The `message` is formed in the next format and must be signed by the user:
+A `message` is formed in the following format and it must be signed by the user:
+```rust
+struct DelegateActionMessage {
+    /// If not None, should match the `predecessor_id` that have created `DelegateAction`.
-    /// If not None, should match the `predecessor_id` that have created `DelegateAction`.
+    /// If not None, then should match the `predecessor_id` that created the `DelegateAction`.
-    /// If not None, should match the `predecessor_id` that have created `DelegateAction`.
+    /// If not None, then should match the `predecessor_id` that created the `DelegateAction`.
+    sender_id: Option<AccountId>,
+    /// Matching the given account_id.
+    signer_id: AccountId,
+    /// Matching the `signer_pk` from `DelegateAction`.
-    /// Matching the `signer_pk` from `DelegateAction`.
+    /// Should match the `signer_pk` from the `DelegateAction`.
-    /// Matching the `signer_pk` from `DelegateAction`.
+    /// Should match the `signer_pk` from the `DelegateAction`.
+    public_key: PublicKey,
+    /// Nonce for the given `public_key` from `DelegateAction`.
-    /// Nonce for the given `public_key` from `DelegateAction`.
+    /// Nonce for the given `public_key` from the `DelegateAction`.
-    /// Nonce for the given `public_key` from `DelegateAction`.
+    /// Nonce for the given `public_key` from the `DelegateAction`.
+    nonce: Nonce,
+    /// Matching the `receiver_id` from `DelegateAction`.
-    /// Matching the `receiver_id` from `DelegateAction`.
+    /// Should match the `receiver_id` from the `DelegateAction`.
-    /// Matching the `receiver_id` from `DelegateAction`.
+    /// Should match the `receiver_id` from the `DelegateAction`.
+    receiver_id: AccountId,
+    /// Block hash to ensure validity.
+    /// Actions matching `actions` from `DelegateAction`.
-    /// Actions matching `actions` from `DelegateAction`.
+    /// Should match `actions` from the `DelegateAction`.
-    /// Actions matching `actions` from `DelegateAction`.
+    /// Should match `actions` from the `DelegateAction`.
+    actions: Vec<Action>,
+}
+```
+
+The next set of security concerns are addressed by this format:
+ - If format matches `Transaction`, the relayer can just send it directly, not receiving payment.
- - If format matches `Transaction`, the relayer can just send it directly, not receiving payment.
+ - If format matches `Transaction`, then the relayer can just send it directly, not receiving payment.
- - If format matches `Transaction`, the relayer can just send it directly, not receiving payment.
+ - If format matches `Transaction`, then the relayer can just send it directly, not receiving payment.
+ - Because set of actions can include pay back to the relayer (for example by paying in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
- - Because set of actions can include pay back to the relayer (for example by paying in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
+ - Because the set of actions can include payment for the relayer (for example in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
- - Because set of actions can include pay back to the relayer (for example by paying in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
+ - Because the set of actions can include payment for the relayer (for example in FT), the `sender_id` is added directly into the message to ensure that nobody else can send this message.
+ - `nonce` is included to ensure that this message can't be replayed again.
- - `nonce` is included to ensure that this message can't be replayed again.
+ - `nonce` is included to ensure that a message can not be replayed.
- - `nonce` is included to ensure that this message can't be replayed again.
+ - `nonce` is included to ensure that a message can not be replayed.
+ - `public_key` and `signer_id` are needed to ensure the on the right account, work across rotating keys and fetch correct `nonce`.
+
+The permissions are verified based on kind `AccessKeyPermission` of `signer_pk`:
-The permissions are verified based on kind `AccessKeyPermission` of `signer_pk`:
+The permissions are verified based on the variant of `signer_pk`:
-The permissions are verified based on kind `AccessKeyPermission` of `signer_pk`:
+The permissions are verified based on the variant of `signer_pk`:
+ - `AccessKeyPermission::FullAccess`, all actions are allowed.
+ - `AccessKeyPermission::FunctionCall`, only a single `FunctionCall` action is allowed in `actions`. 
+    - `DelegateAction.receiver_id` must match to the `account[public_key].receiver_id`
+    - `DelegateAction.actions[0].method_name` must be in the `account[public_key].method_names`
+
+***Outcomes***:
+- If `signature` matches receiver's accounts `signer_pk`, new receipt is created from this account with set of `ActionReceipt { receiver_id, action }` for each item in `actions`. 
- If `signature` matches receiver's accounts `signer_pk`, new receipt is created from this account with set of `ActionReceipt { receiver_id, action }` for each item in `actions`. 
+- If the `signature` matches the receiver's account's `signer_pk`, a new receipt is created from this account with a set of `ActionReceipt { receiver_id, action }` for each action in `actions`. 
- If `signature` matches receiver's accounts `signer_pk`, new receipt is created from this account with set of `ActionReceipt { receiver_id, action }` for each item in `actions`. 
+- If the `signature` matches the receiver's account's `signer_pk`, a new receipt is created from this account with a set of `ActionReceipt { receiver_id, action }` for each action in `actions`. 
+
+#### Errors
+
+**Validation Error**
+- If `signer_pk` does not exist for the given account, the following error will be returned
- If `signer_pk` does not exist for the given account, the following error will be returned
+- If the `signer_pk` does not exist for the given account, the following error will be returned
- If `signer_pk` does not exist for the given account, the following error will be returned
+- If the `signer_pk` does not exist for the given account, the following error will be returned
+```rust
+/// Signer key for delegate action is missing from given account
-/// Signer key for delegate action is missing from given account
+/// Signer key for delegate action is missing from the given account
-/// Signer key for delegate action is missing from given account
+/// Signer key for delegate action is missing from the given account
+DelegateActionSignerDoesNotExist
+```
+
+- If `nonce` does not exist match `signer_pk` for  `receiver_id`, the following error will be returned
- If `nonce` does not exist match `signer_pk` for  `receiver_id`, the following error will be returned
+- If the `nonce` does not exist match the `signer_pk` for  the `receiver_id`, the the following error will be returned
- If `nonce` does not exist match `signer_pk` for  `receiver_id`, the following error will be returned
+- If the `nonce` does not exist match the `signer_pk` for  the `receiver_id`, the the following error will be returned
+```rust
+/// Nonce must be account[signer_pk].nonce + 1
+DelegateActionInvalidNonce
+```
+
+- If `signature` does not match to the data and `signer_pk` of the given key, the following error will be returned
- If `signature` does not match to the data and `signer_pk` of the given key, the following error will be returned
+- If the `signature` does not match the data and the `signer_pk` of the given key, then the following error will be returned
- If `signature` does not match to the data and `signer_pk` of the given key, the following error will be returned
+- If the `signature` does not match the data and the `signer_pk` of the given key, then the following error will be returned
+```rust
+/// Signature does not match the provided actions and given signer public key.
+DelegateActionInvalidSignature
+```
+
+
+See the [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for details.
+
+## Security Implications
+
+Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (eg relayer in meta transaction case). Although it is possible to override `signer_pk` in the context with one from `DelegateAction`, there is no clear value to do that.
-Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (eg relayer in meta transaction case). Although it is possible to override `signer_pk` in the context with one from `DelegateAction`, there is no clear value to do that.
+Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (e.g. the relayer in the meta transaction case). Although it is possible to override the `signer_pk` in the context with one from the `DelegateAction`, there is no clear value in that.
-Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (eg relayer in meta transaction case). Although it is possible to override `signer_pk` in the context with one from `DelegateAction`, there is no clear value to do that.
+Delegate actions do not override `signer_pk`, leaving that to the original signer that initiated transaction (e.g. the relayer in the meta transaction case). Although it is possible to override the `signer_pk` in the context with one from the `DelegateAction`, there is no clear value in that.
+
+See ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what user signs and validation of actions with different permissions.
-See ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what user signs and validation of actions with different permissions.
+See the ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what the user signs and the validation of actions with different permissions.
-See ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what user signs and validation of actions with different permissions.
+See the ***Validation*** section in [DelegateAction specification](specs/RuntimeSepc/Actions.md#DelegateAction) for security considerations around what the user signs and the validation of actions with different permissions.
+
+## Drawbacks
+
+Increases complexity of the the NEAR's transactional model.
-Increases complexity of the the NEAR's transactional model.
+Increases complexity of NEAR's transactional model.
-Increases complexity of the the NEAR's transactional model.
+Increases complexity of NEAR's transactional model.
+
+Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account and only after that to the real destination.
-Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account and only after that to the real destination.
+Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account, and only after that to the real destination.
-Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account and only after that to the real destination.
+Meta transactions take an extra block to execute, as they first need to be included by the originating account, then routed to the delegate account, and only after that to the real destination.
+
+Delegate actions are not programmable as they require having signatures. Original proposal contained a new `AccessKey` kind that would support programmable delegated actions. On the other hand, that would be limiting without programmability of smart contracts, hence that idea evolved into [Account Extensions](https://github.com/nearprotocol/neps/pull/346).
+
+## Future possibilities
+
+Supporting ZK proofs instead of just signatures can allow for an anonymous transactions, which pay fees to relayers in anonymous way.
-Supporting ZK proofs instead of just signatures can allow for an anonymous transactions, which pay fees to relayers in anonymous way.
+Supporting ZK proofs instead of just signatures can allow for anonymous transactions, which pay fees to relayers anonymously.
-Supporting ZK proofs instead of just signatures can allow for an anonymous transactions, which pay fees to relayers in anonymous way.
+Supporting ZK proofs instead of just signatures can allow for anonymous transactions, which pay fees to relayers anonymously.
+
+## Copyright
+[copyright]: #copyright
+
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
@@ -1,6 +1,6 @@
 # Receipt
 
-All cross-contract (we assume that each account lives in it's own shard) communication in Near happens trough Receipts.
+All cross-contract (we assume that each account lives in it's own shard) communication in Near happens through Receipts.
 Receipts are stateful in a sense that they serve not only as messages between accounts but also can be stored in the account storage to await DataReceipts.
 
 Each receipt has a [`predecessor_id`](#predecessor_id) (who sent it) and [`receiver_id`](#receiver_id) the current account.