From 813c85499948ecf9a1a5784e9cff19d2f72758b6 Mon Sep 17 00:00:00 2001 From: Damian Parrino Date: Thu, 7 Aug 2025 17:39:39 -0300 Subject: [PATCH 1/4] Update transaction-anatomy.md --- docs/protocol/transaction-anatomy.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/docs/protocol/transaction-anatomy.md b/docs/protocol/transaction-anatomy.md index 818f373d2b8..80b84bd4651 100644 --- a/docs/protocol/transaction-anatomy.md +++ b/docs/protocol/transaction-anatomy.md @@ -21,12 +21,20 @@ In addition, a transaction has the following fields to ensure its integrity and Users create transactions and sign them with their private keys. Then, the **transaction and its signature** are broadcast together to the network, where they are validated and processed. :::tip -Each transaction has exactly one `Signer` and `Receiver`, but can have multiple `Actions` +Each transaction has exactly one `Signer` and `Receiver`, but can have multiple `Actions`. +::: + +:::info About nonce values +- When adding a key, the `nonce` will be automatically assigned, so the `nonce` value in the `ADD_KEY` action is ignored. +- A transaction is accepted only if the `nonce` value is in the range of: + - `[(current_nonce_of_access_key + 1) .. (block_height * 10e6)]`. +- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. ::: --- ## Actions + Each transaction can have **one or multiple** `Actions`, which are the actual operations to be performed on the `Receiver` account. There are 9 types of actions that can be performed: 1. `FunctionCall`: to invoke a function on a contract (optionally attaching NEAR to the call) From 1e9262186316b2534435a70bc902194ac8d525bc Mon Sep 17 00:00:00 2001 From: Damian Parrino Date: Fri, 8 Aug 2025 09:21:02 -0300 Subject: [PATCH 2/4] update --- docs/protocol/transaction-anatomy.md | 2 +- docs/protocol/transaction-execution.md | 14 +++++++++++++- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/docs/protocol/transaction-anatomy.md b/docs/protocol/transaction-anatomy.md index 80b84bd4651..1d4ffef16e3 100644 --- a/docs/protocol/transaction-anatomy.md +++ b/docs/protocol/transaction-anatomy.md @@ -25,7 +25,7 @@ Each transaction has exactly one `Signer` and `Receiver`, but can have multiple ::: :::info About nonce values -- When adding a key, the `nonce` will be automatically assigned, so the `nonce` value in the `ADD_KEY` action is ignored. +- When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. - A transaction is accepted only if the `nonce` value is in the range of: - `[(current_nonce_of_access_key + 1) .. (block_height * 10e6)]`. - Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. diff --git a/docs/protocol/transaction-execution.md b/docs/protocol/transaction-execution.md index 2a3e1107f20..1302d263c15 100644 --- a/docs/protocol/transaction-execution.md +++ b/docs/protocol/transaction-execution.md @@ -27,7 +27,7 @@ While creating the `Receipt`, the `signer` gets $NEAR deducted from its balance If the `signer` and `receiver` coincide - e.g. the `signer` is adding a Key - the `Receipt` is immediately processed in this first block and the transaction is considered final. #### Block #2: The Receipt is Processed -If the `signer` and `receiver` differs - e.g. the `signer` transfers NEAR to the `receiver` - the `Receipt` is processed in a second block. +If the `signer` and `receiver` differs - e.g. the `signer` transfers NEAR to the `receiver` - the `Receipt` is processed in a second block. During this process a `FunctionCall` could span a **cross-contract call**, creating one or multiple new `Receipts`. @@ -114,3 +114,15 @@ See the examples below for more details. :::tip You can check the status of a transaction using the [NearBlocks explorer](https://nearblocks.io/) ::: + +--- + +## Nonce values + +The `nonce` is a number that is incremented for each transaction sent by the transaction's `Signer`. +On a valid transaction, the `nonce` value should follow these rules: + +- When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. +- A transaction is accepted only if the `nonce` value is in the range of: + - `[(current_nonce_of_access_key + 1) .. (block_height * 10e6)]`. +- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. From 1e296183bf86ab63bc3778c5df8588441d81dfe7 Mon Sep 17 00:00:00 2001 From: Damian Parrino Date: Fri, 8 Aug 2025 09:25:21 -0300 Subject: [PATCH 3/4] clear --- docs/protocol/transaction-anatomy.md | 2 +- docs/protocol/transaction-execution.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/protocol/transaction-anatomy.md b/docs/protocol/transaction-anatomy.md index 1d4ffef16e3..6605ebcd8f6 100644 --- a/docs/protocol/transaction-anatomy.md +++ b/docs/protocol/transaction-anatomy.md @@ -27,7 +27,7 @@ Each transaction has exactly one `Signer` and `Receiver`, but can have multiple :::info About nonce values - When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. - A transaction is accepted only if the `nonce` value is in the range of: - - `[(current_nonce_of_access_key + 1) .. (block_height * 10e6)]`. + - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]`. - Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. ::: diff --git a/docs/protocol/transaction-execution.md b/docs/protocol/transaction-execution.md index 1302d263c15..bebeeed6906 100644 --- a/docs/protocol/transaction-execution.md +++ b/docs/protocol/transaction-execution.md @@ -124,5 +124,5 @@ On a valid transaction, the `nonce` value should follow these rules: - When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. - A transaction is accepted only if the `nonce` value is in the range of: - - `[(current_nonce_of_access_key + 1) .. (block_height * 10e6)]`. + - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]`. - Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. From 88b2f221ae1a1ff3c95d479afacc7605ed6838fb Mon Sep 17 00:00:00 2001 From: Guille Date: Tue, 9 Sep 2025 19:10:40 +0200 Subject: [PATCH 4/4] Apply suggestions from code review --- docs/protocol/transaction-anatomy.md | 6 +++--- docs/protocol/transaction-execution.md | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/protocol/transaction-anatomy.md b/docs/protocol/transaction-anatomy.md index 6605ebcd8f6..f512c7ec52d 100644 --- a/docs/protocol/transaction-anatomy.md +++ b/docs/protocol/transaction-anatomy.md @@ -25,10 +25,10 @@ Each transaction has exactly one `Signer` and `Receiver`, but can have multiple ::: :::info About nonce values -- When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. +- When adding a key, the `nonce` is automatically assigned - particularly, it is given the value `block height * 10^6` - so the value in the `ADD_KEY` action is ignored - A transaction is accepted only if the `nonce` value is in the range of: - - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]`. -- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. + - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]` +- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction ::: --- diff --git a/docs/protocol/transaction-execution.md b/docs/protocol/transaction-execution.md index bebeeed6906..5a6bd859d62 100644 --- a/docs/protocol/transaction-execution.md +++ b/docs/protocol/transaction-execution.md @@ -122,7 +122,7 @@ You can check the status of a transaction using the [NearBlocks explorer](https: The `nonce` is a number that is incremented for each transaction sent by the transaction's `Signer`. On a valid transaction, the `nonce` value should follow these rules: -- When adding a key, the `nonce` is automatically assigned, so the value in the `ADD_KEY` action is ignored. +- When adding a key, the `nonce` is automatically assigned - particularly, it is given the value `block height * 10^6` - so the value in the `ADD_KEY` action is ignored - A transaction is accepted only if the `nonce` value is in the range of: - - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]`. -- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction. + - `[(current_nonce_of_access_key + 1) .. (block_height * 10^6)]` +- Once a transaction is accepted, the access key's `nonce` is set to the `nonce` value of the included transaction