From 96656368a71293298db4d7a3c6c00d8241bb068d Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 11 Nov 2025 14:55:39 +0300 Subject: [PATCH 1/8] Initial --- docs.json | 4 +- foundations/messages/modes.mdx | 119 +++++++++++++++++++++++++++++++ foundations/messages/sending.mdx | 0 3 files changed, 122 insertions(+), 1 deletion(-) create mode 100644 foundations/messages/modes.mdx create mode 100644 foundations/messages/sending.mdx diff --git a/docs.json b/docs.json index d901eb966..be66f95c7 100644 --- a/docs.json +++ b/docs.json @@ -533,7 +533,9 @@ "group": "Messages", "pages": [ "foundations/messages/overview", - "foundations/messages/internal" + "foundations/messages/internal", + "foundations/messages/sending", + "foundations/messages/modes" ] }, "foundations/status", diff --git a/foundations/messages/modes.mdx b/foundations/messages/modes.mdx new file mode 100644 index 000000000..f74677c52 --- /dev/null +++ b/foundations/messages/modes.mdx @@ -0,0 +1,119 @@ +--- +title: "Sending modes" +--- + +The standard (without any send modes) message sending process has the following properties: +- the forward fees are paid from the indicated message value, so it is decreased by the amount of forward fees before sending; +- if sending fails, the transaction is rolled back and a bounce message is not sent. + +The purpose of send modes is to modify the above logic by specifying: +- what exactly value should be in the outgoing message (will it be increased by something or even reset to some value); +- whether to pay forward fees from the account balance or from the message value; +- whether to rollback the transaction and send a bounce message if sending fails, etc. + +The send modes are specified via an 8-bit bitmask `mode` parameter of the [`SENDRAWMSG`](/tvm/instructions#fb00-sendrawmsg) instruction. The resulting mode value can have the following base modes: +| Mode value | Convenient name | Description | +| ---------: | :------------------------ | ------------------------------------------------------- | +| `0` | `SendDefaultMode` | Default mode. | +| `64` | `SendRemainingValue` | Complex logic. Will be described bellow. | +| `128` | `SendRemainingBalance` | Send all remaining balance of the account. | + +Additionally, the resulting `mode` can have the following optional flags added: +| Flag value | Convenient name | Description | +| ---------: | :------------------------ | --------------------------------------------------------------------------------- | +| `+1` | `SendPayFwdFeesSeparately`| Pay forward fees separately from the message value. | +| `+2` | `SendIgnoreErrors` | Ignore errors during sending. No bounce message will be sent on failure. | +| `+16`| `SendBounceIfActionFail` | Bounce the transaction in case of any errors during the action phase. | +| `+32`| `SendDestroyIfZero` | The current account (contract) will be destroyed if its resulting balance is zero. This flag has effect only if mode 128, SendRemainingBalance, is used. | + +## Behavior + +Notation: + +- `value` – the amount of Toncoin indicated in the outgoing message. +- `mode` – the bitmask passed to the `SENDRAWMSG` instruction. +- `msg_balance_remaining` – the remaining value of the incoming message. At the start of the action phase it equals either the incoming message value or account's balance before compute phase if it was less than the value of incoming message with bounce flag set to `false`. At the start of sending message process, it is zero if there was the previous sending message action with modes `SendRemainingBalance` or `SendRemainingValue`, otherwise it equals the value described above. +- `remaining_balance` – the remaining balance of the account at the start of the action. +- `fwd_fees` – the amount of forward fees for sending the message. +- `gas_fees` – the fees paid for gas used during the computation phase. +- `action_fine` – the accumulated fine for the previous failed and skipped send message actions. +- `final_value` – the final value of the outgoing message. +- `req` – value that will be deducted from the account balance. + +The algorithm for the resulting message value fro outgoing internal message and amount of nanotoncoins that will be deducted from account's balance is as follows: + +1. Check that `mode` has flag `SendBounceIfActionFail`: + - if so, then in case of any failure the action phase will be interrupted, the bounce phase will be initiated; + - if not, then in case of any failure the action phase will be interrupted but no bounce message will be sent. +2. Check that `mode` has flag `SendIgnoreErrors`: + - if so, then in case of almost all failure (errors on which this mode is not work are described in [Errors subsection](/foundations/messages/modes##erros).) during sending the message an error will be ignored and the action phase will continue; +3. Set `final_value` to the `value`. +4. Check that `mode` has base mode `SendRemainingBalance`: + - if so, then set `final_value` to `remaining_balance` and remove `+1` flag from `mode` if it is presented. +5. Otherwise, check that `mode` has base mode `SendRemainingValue`: + 1. Check that `mode` has flag `SendPayFwdFeesSeparately`: + - if so, then increase `final_value` by `msg_balance_remaining`; + - otherwise, increase `final_value` by `msg_balance_remaining - gas_fees - action_fine`. +6. Set `req` to `final_value`. +7. Check that `mode` has flag `SendPayFwdFeesSeparately`: + - if so, then increase `req` by `fwd_fees`. + - otherwise, decrease `final_value` by `fwd_fees`. +8. Set `msg_balance_remaining` to zero if `mode` has base modes `SendRemainingValue` or `SendRemainingBalance`. +9. Decrease `remaining_balance` by `req`. +10. Check that `mode` has flag `SendDestroyIfZero` and base mode `SendRemainingBalance`: + - if so, then destroy the current account (contract) if `remaining_balance` is zero. + +### Example + +Assume that +- `value = 0.1 TON`; +- `mode = 80 = 10010000` (that is, `SendRemainingValue + SendBounceIfActionFail`); +- `msg_balance_remaining = 0 TON` (for instance, there was previous sending message action with mode `SendRemainingValue`); +- `remaining_balance = 2 TON`; +- `fwd_fees = 0.01 TON`; +- `gas_fees = 0.005 TON`; +- `action_fine = 0 TON`. + +Then the sending proceeds as follows: +- `mode` has flag `SendBounceIfActionFail`? Yes. +- `mode` has flag `SendIgnoreErrors`? No. +- Set `final_value = 0.1 TON`. +- `mode` has base mode `SendRemainingBalance`? No. +- `mode` has base mode `SendRemainingValue`? Yes. + - `mode` has flag `SendPayFwdFeesSeparately`? No. + - Increase `final_value` by `msg_balance_remaining - gas_fees - action_fine = 0 TON - 0.005 TON - 0 TON = -0.005 TON`. + - Now, `final_value = 0.1 TON - 0.005 TON = 0.095 TON`. +- Set `req = final_value = 0.095 TON`. +- `mode` has flag `SendPayFwdFeesSeparately`? No. + - Decrease `final_value` by `fwd_fees = 0.01 TON`. + - Now, `final_value = 0.095 TON - 0.01 TON = 0.085 TON`. +- Set `msg_balance_remaining` to zero (it is already zero). +- Decrease `remaining_balance` by `req = 0.095 TON`. + - Now, `remaining_balance = 2 TON - 0.095 TON = 1.905 TON`. + +### Outgoing external messages + +The algorithm above describew the sending process only for outgoing internal messages. However, outgoing external message can have only the following three modes: `SendBounceIfActionFail`, `SendIgnoreErrors`, and `SendPayFwdFeesSeparately` (use of any other leads to an error). `SendPayFwdFeesSeparately` can be used, but have no effect. `SendBounceIfActionFail` and `SendIgnoreErrors` have the same behavior, i.e. send bounce message in acse of any error and ignore almost all errors during the processing. + +There is no `value` field in external messages, so the forward fees are always deducted from account's balance. + +## Errors + +The following errors can occur during the sending message flow: +- Simultaneous use of modes `SendRemainingBalance` and `SendRemainingValue`, `34` exit code. +- Modes except `SendIgnoreErrors`, `SendBounceIfActionFail`, and `SendPayFwdFeesSeparately` used for outbound external messages, `34` exit code. +- Source address in the outbound message is not equal to `addr_none` or the contract address, `35` exit code. +- Some ploblems with repacking the message body and StateInit into references if the message body or StateInit is too big to be located inplace, `34` exit code. +- Malformed message structure, `34` exit code. +- Invalid destination address in the outbound message, `36` exit code. +- Not enough value to transfer with the message: all of the inbound message value has been consumed, `37` exit code. +- No enough funds for processing all message references, `40` exit code. +- The number of bits or references in StateInit and message body is too large, `40` exit code. +- Message has Merkle depth more than two, `40` exit code. +- If a message has only one `SendRemainingValue` base mode and `final_value` after the step `5` is negative, then an error with `37` exit code is thrown. +- If `final_value` after step `7` is negative, then an error with `37` exit code is thrown. +- If `remaining_balance` after step `9` is negative, then an error with `37` exit code is thrown. +- If `remaining_balance` after pay forward fees step is negative in a case of outgoing external message, then an error with `37` exit code is thrown. +- Problems related to extra-currency, exit codes `37`, `44`, `38`. + +The `SendIgnoreErrors` mode ignore all the above errors except the four first ones (simultaneous use of modes, invalid modes for external messages, source address problems, and problems with repacking). diff --git a/foundations/messages/sending.mdx b/foundations/messages/sending.mdx new file mode 100644 index 000000000..e69de29bb From 706a5411f11af65cebcb4d868dd916e79fa7b41e Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 11 Nov 2025 15:25:38 +0300 Subject: [PATCH 2/8] Formater --- foundations/messages/modes.mdx | 73 +++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 33 deletions(-) diff --git a/foundations/messages/modes.mdx b/foundations/messages/modes.mdx index f74677c52..a07ba81c7 100644 --- a/foundations/messages/modes.mdx +++ b/foundations/messages/modes.mdx @@ -3,28 +3,32 @@ title: "Sending modes" --- The standard (without any send modes) message sending process has the following properties: + - the forward fees are paid from the indicated message value, so it is decreased by the amount of forward fees before sending; - if sending fails, the transaction is rolled back and a bounce message is not sent. The purpose of send modes is to modify the above logic by specifying: + - what exactly value should be in the outgoing message (will it be increased by something or even reset to some value); - whether to pay forward fees from the account balance or from the message value; - whether to rollback the transaction and send a bounce message if sending fails, etc. The send modes are specified via an 8-bit bitmask `mode` parameter of the [`SENDRAWMSG`](/tvm/instructions#fb00-sendrawmsg) instruction. The resulting mode value can have the following base modes: -| Mode value | Convenient name | Description | -| ---------: | :------------------------ | ------------------------------------------------------- | -| `0` | `SendDefaultMode` | Default mode. | -| `64` | `SendRemainingValue` | Complex logic. Will be described bellow. | -| `128` | `SendRemainingBalance` | Send all remaining balance of the account. | + +| Mode value | Convenient name | Description | +| ---------: | :--------------------- | ------------------------------------------ | +| `0` | `SendDefaultMode` | Default mode. | +| `64` | `SendRemainingValue` | Complex logic. Will be described bellow. | +| `128` | `SendRemainingBalance` | Send all remaining balance of the account. | Additionally, the resulting `mode` can have the following optional flags added: -| Flag value | Convenient name | Description | -| ---------: | :------------------------ | --------------------------------------------------------------------------------- | -| `+1` | `SendPayFwdFeesSeparately`| Pay forward fees separately from the message value. | -| `+2` | `SendIgnoreErrors` | Ignore errors during sending. No bounce message will be sent on failure. | -| `+16`| `SendBounceIfActionFail` | Bounce the transaction in case of any errors during the action phase. | -| `+32`| `SendDestroyIfZero` | The current account (contract) will be destroyed if its resulting balance is zero. This flag has effect only if mode 128, SendRemainingBalance, is used. | + +| Flag value | Convenient name | Description | +| ---------: | :------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| `+1` | `SendPayFwdFeesSeparately` | Pay forward fees separately from the message value. | +| `+2` | `SendIgnoreErrors` | Ignore errors during sending. No bounce message will be sent on failure. | +| `+16` | `SendBounceIfActionFail` | Bounce the transaction in case of any errors during the action phase. | +| `+32` | `SendDestroyIfZero` | The current account (contract) will be destroyed if its resulting balance is zero. This flag has effect only if mode 128, SendRemainingBalance, is used. | ## Behavior @@ -45,27 +49,28 @@ The algorithm for the resulting message value fro outgoing internal message and 1. Check that `mode` has flag `SendBounceIfActionFail`: - if so, then in case of any failure the action phase will be interrupted, the bounce phase will be initiated; - if not, then in case of any failure the action phase will be interrupted but no bounce message will be sent. -2. Check that `mode` has flag `SendIgnoreErrors`: +1. Check that `mode` has flag `SendIgnoreErrors`: - if so, then in case of almost all failure (errors on which this mode is not work are described in [Errors subsection](/foundations/messages/modes##erros).) during sending the message an error will be ignored and the action phase will continue; -3. Set `final_value` to the `value`. -4. Check that `mode` has base mode `SendRemainingBalance`: +1. Set `final_value` to the `value`. +1. Check that `mode` has base mode `SendRemainingBalance`: - if so, then set `final_value` to `remaining_balance` and remove `+1` flag from `mode` if it is presented. -5. Otherwise, check that `mode` has base mode `SendRemainingValue`: - 1. Check that `mode` has flag `SendPayFwdFeesSeparately`: - - if so, then increase `final_value` by `msg_balance_remaining`; - - otherwise, increase `final_value` by `msg_balance_remaining - gas_fees - action_fine`. -6. Set `req` to `final_value`. -7. Check that `mode` has flag `SendPayFwdFeesSeparately`: - - if so, then increase `req` by `fwd_fees`. - - otherwise, decrease `final_value` by `fwd_fees`. -8. Set `msg_balance_remaining` to zero if `mode` has base modes `SendRemainingValue` or `SendRemainingBalance`. -9. Decrease `remaining_balance` by `req`. -10. Check that `mode` has flag `SendDestroyIfZero` and base mode `SendRemainingBalance`: - - if so, then destroy the current account (contract) if `remaining_balance` is zero. +1. Otherwise, check that `mode` has base mode `SendRemainingValue`: + 1. Check that `mode` has flag `SendPayFwdFeesSeparately`: + - if so, then increase `final_value` by `msg_balance_remaining`; + - otherwise, increase `final_value` by `msg_balance_remaining - gas_fees - action_fine`. +1. Set `req` to `final_value`. +1. Check that `mode` has flag `SendPayFwdFeesSeparately`: + - if so, then increase `req` by `fwd_fees`. + - otherwise, decrease `final_value` by `fwd_fees`. +1. Set `msg_balance_remaining` to zero if `mode` has base modes `SendRemainingValue` or `SendRemainingBalance`. +1. Decrease `remaining_balance` by `req`. +1. Check that `mode` has flag `SendDestroyIfZero` and base mode `SendRemainingBalance`: + - if so, then destroy the current account (contract) if `remaining_balance` is zero. ### Example Assume that + - `value = 0.1 TON`; - `mode = 80 = 10010000` (that is, `SendRemainingValue + SendBounceIfActionFail`); - `msg_balance_remaining = 0 TON` (for instance, there was previous sending message action with mode `SendRemainingValue`); @@ -75,31 +80,33 @@ Assume that - `action_fine = 0 TON`. Then the sending proceeds as follows: + - `mode` has flag `SendBounceIfActionFail`? Yes. - `mode` has flag `SendIgnoreErrors`? No. - Set `final_value = 0.1 TON`. - `mode` has base mode `SendRemainingBalance`? No. - `mode` has base mode `SendRemainingValue`? Yes. - - `mode` has flag `SendPayFwdFeesSeparately`? No. - - Increase `final_value` by `msg_balance_remaining - gas_fees - action_fine = 0 TON - 0.005 TON - 0 TON = -0.005 TON`. - - Now, `final_value = 0.1 TON - 0.005 TON = 0.095 TON`. + - `mode` has flag `SendPayFwdFeesSeparately`? No. + - Increase `final_value` by `msg_balance_remaining - gas_fees - action_fine = 0 TON - 0.005 TON - 0 TON = -0.005 TON`. + - Now, `final_value = 0.1 TON - 0.005 TON = 0.095 TON`. - Set `req = final_value = 0.095 TON`. - `mode` has flag `SendPayFwdFeesSeparately`? No. - - Decrease `final_value` by `fwd_fees = 0.01 TON`. - - Now, `final_value = 0.095 TON - 0.01 TON = 0.085 TON`. + - Decrease `final_value` by `fwd_fees = 0.01 TON`. + - Now, `final_value = 0.095 TON - 0.01 TON = 0.085 TON`. - Set `msg_balance_remaining` to zero (it is already zero). - Decrease `remaining_balance` by `req = 0.095 TON`. - - Now, `remaining_balance = 2 TON - 0.095 TON = 1.905 TON`. + - Now, `remaining_balance = 2 TON - 0.095 TON = 1.905 TON`. ### Outgoing external messages The algorithm above describew the sending process only for outgoing internal messages. However, outgoing external message can have only the following three modes: `SendBounceIfActionFail`, `SendIgnoreErrors`, and `SendPayFwdFeesSeparately` (use of any other leads to an error). `SendPayFwdFeesSeparately` can be used, but have no effect. `SendBounceIfActionFail` and `SendIgnoreErrors` have the same behavior, i.e. send bounce message in acse of any error and ignore almost all errors during the processing. There is no `value` field in external messages, so the forward fees are always deducted from account's balance. - + ## Errors The following errors can occur during the sending message flow: + - Simultaneous use of modes `SendRemainingBalance` and `SendRemainingValue`, `34` exit code. - Modes except `SendIgnoreErrors`, `SendBounceIfActionFail`, and `SendPayFwdFeesSeparately` used for outbound external messages, `34` exit code. - Source address in the outbound message is not equal to `addr_none` or the contract address, `35` exit code. From 911eb862c3d274cb0fd0e074ad94aa62801a4301 Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 11 Nov 2025 15:29:41 +0300 Subject: [PATCH 3/8] Spell --- foundations/messages/modes.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/foundations/messages/modes.mdx b/foundations/messages/modes.mdx index a07ba81c7..0568a0293 100644 --- a/foundations/messages/modes.mdx +++ b/foundations/messages/modes.mdx @@ -99,7 +99,7 @@ Then the sending proceeds as follows: ### Outgoing external messages -The algorithm above describew the sending process only for outgoing internal messages. However, outgoing external message can have only the following three modes: `SendBounceIfActionFail`, `SendIgnoreErrors`, and `SendPayFwdFeesSeparately` (use of any other leads to an error). `SendPayFwdFeesSeparately` can be used, but have no effect. `SendBounceIfActionFail` and `SendIgnoreErrors` have the same behavior, i.e. send bounce message in acse of any error and ignore almost all errors during the processing. +The algorithm above describe the sending process only for outgoing internal messages. However, outgoing external message can have only the following three modes: `SendBounceIfActionFail`, `SendIgnoreErrors`, and `SendPayFwdFeesSeparately` (use of any other leads to an error). `SendPayFwdFeesSeparately` can be used, but have no effect. `SendBounceIfActionFail` and `SendIgnoreErrors` have the same behavior, i.e. send bounce message in a case of any error and ignore almost all errors during the processing. There is no `value` field in external messages, so the forward fees are always deducted from account's balance. @@ -110,7 +110,7 @@ The following errors can occur during the sending message flow: - Simultaneous use of modes `SendRemainingBalance` and `SendRemainingValue`, `34` exit code. - Modes except `SendIgnoreErrors`, `SendBounceIfActionFail`, and `SendPayFwdFeesSeparately` used for outbound external messages, `34` exit code. - Source address in the outbound message is not equal to `addr_none` or the contract address, `35` exit code. -- Some ploblems with repacking the message body and StateInit into references if the message body or StateInit is too big to be located inplace, `34` exit code. +- Some problems with repacking the message body and StateInit into references if the message body or StateInit is too big to be located in place, `34` exit code. - Malformed message structure, `34` exit code. - Invalid destination address in the outbound message, `36` exit code. - Not enough value to transfer with the message: all of the inbound message value has been consumed, `37` exit code. From 5c8e6b50002046a33c95c197dd8946b229644e46 Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 11 Nov 2025 15:32:17 +0300 Subject: [PATCH 4/8] Fix --- docs.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs.json b/docs.json index 23fe22656..667ce4235 100644 --- a/docs.json +++ b/docs.json @@ -537,7 +537,7 @@ "foundations/messages/overview", "foundations/messages/internal", "foundations/messages/sending", - "foundations/messages/modes" + "foundations/messages/modes", "foundations/messages/external", "foundations/messages/tick-tock", "foundations/messages/split-prepare", From f6544cced90f8e7a843e1fa71ceacec81f031d99 Mon Sep 17 00:00:00 2001 From: Alex Date: Tue, 11 Nov 2025 16:12:54 +0300 Subject: [PATCH 5/8] Add links --- contract-dev/testing/reference.mdx | 2 +- foundations/messages/sending.mdx | 7 +++++++ languages/func/cookbook.mdx | 2 +- standard/tokens/nft/how-it-works.mdx | 2 +- standard/wallets/highload/v2/specification.mdx | 2 +- standard/wallets/highload/v3/send-batch-transfers.mdx | 2 +- standard/wallets/highload/v3/send-single-transfer.mdx | 2 +- standard/wallets/highload/v3/specification.mdx | 2 +- 8 files changed, 14 insertions(+), 7 deletions(-) diff --git a/contract-dev/testing/reference.mdx b/contract-dev/testing/reference.mdx index 1f747f99f..06a84c219 100644 --- a/contract-dev/testing/reference.mdx +++ b/contract-dev/testing/reference.mdx @@ -931,7 +931,7 @@ Sends a single message via the treasury contract. **Parameters:** - `provider` — `ContractProvider` -- `args` — `SenderArguments` including value, body, and send mode +- `args` — `SenderArguments` including value, body, and [send mode](/foundations/messages/modes) #### `getSender()` diff --git a/foundations/messages/sending.mdx b/foundations/messages/sending.mdx index e69de29bb..37e432aed 100644 --- a/foundations/messages/sending.mdx +++ b/foundations/messages/sending.mdx @@ -0,0 +1,7 @@ +--- +title: "Sending messages" +--- + +import { Stub } from '/snippets/stub.jsx'; + + \ No newline at end of file diff --git a/languages/func/cookbook.mdx b/languages/func/cookbook.mdx index e5febbd28..22946bc6b 100644 --- a/languages/func/cookbook.mdx +++ b/languages/func/cookbook.mdx @@ -2096,7 +2096,7 @@ Refer to the sending messages page for further details on sending modes in the ` ### How to send a message with the entire balance -To transfer the entire balance of a smart contract, use send mode `128`. +To transfer the entire balance of a smart contract, use [send mode `128`](/foundations/messages/modes). This is particularly useful for proxy contracts that receive payments and forward them to the main contract. ```func diff --git a/standard/tokens/nft/how-it-works.mdx b/standard/tokens/nft/how-it-works.mdx index 862e5e811..68165f9b0 100644 --- a/standard/tokens/nft/how-it-works.mdx +++ b/standard/tokens/nft/how-it-works.mdx @@ -108,7 +108,7 @@ The transfer must be rejected if: ## Get static data -Anyone can send a `get_static_data` message to an NFT item to request its static data (index and collection address). The item responds with `report_static_data` message using send-mode `64` (return message amount except gas fees). +Anyone can send a `get_static_data` message to an NFT item to request its static data (index and collection address). The item responds with `report_static_data` message using [send mode `64`](/foundations/messages/modes) (return message amount except gas fees). Get static data message body contains the following data: diff --git a/standard/wallets/highload/v2/specification.mdx b/standard/wallets/highload/v2/specification.mdx index cedc6e94d..19c69cc73 100644 --- a/standard/wallets/highload/v2/specification.mdx +++ b/standard/wallets/highload/v2/specification.mdx @@ -189,7 +189,7 @@ Dictionary of messages to send in this transaction. - **Value:** `mode:uint8` + `^Cell` (reference to internal message) **How it works:**\ -The contract iterates through the dictionary and sends each message with its corresponding send mode: +The contract iterates through the dictionary and sends each message with its corresponding [send mode](/foundations/messages/modes): ```func int i = -1; diff --git a/standard/wallets/highload/v3/send-batch-transfers.mdx b/standard/wallets/highload/v3/send-batch-transfers.mdx index 95136f5ec..b7cef9a59 100644 --- a/standard/wallets/highload/v3/send-batch-transfers.mdx +++ b/standard/wallets/highload/v3/send-batch-transfers.mdx @@ -83,7 +83,7 @@ for (let i = 1; i <= 10; i++) { Each message in the batch: - **`type: 'sendMsg'`** — specifies that this is an outgoing message action -- **`mode`** — send mode for each individual message +- **`mode`** — [send mode](/foundations/messages/modes) for each individual message - **`outMsg`** — the internal message to send