From 9ea1ad0de87a68f43093027c73526732e5b578ac Mon Sep 17 00:00:00 2001
From: Antonoff <35700168+memearchivarius@users.noreply.github.com>
Date: Wed, 29 Jan 2025 12:50:21 +0300
Subject: [PATCH] MD Corrections & Op-code list transfer

Moving known op-codes to Message management, md formatting.
---
 .../contracts-specs/wallet-contracts.md       | 318 ++++++++----------
 .../message-management/internal-messages.md   | 144 +++++---
 2 files changed, 246 insertions(+), 216 deletions(-)

diff --git a/docs/v3/documentation/smart-contracts/contracts-specs/wallet-contracts.md b/docs/v3/documentation/smart-contracts/contracts-specs/wallet-contracts.md
index 5c2bb8fa2b..aa5678fab9 100644
--- a/docs/v3/documentation/smart-contracts/contracts-specs/wallet-contracts.md
+++ b/docs/v3/documentation/smart-contracts/contracts-specs/wallet-contracts.md
@@ -9,9 +9,10 @@ In this article, we’ll explore the various versions and modifications of TON w
 
 :::info
 Before we start, there are some terms and concepts that you should be familiar with to fully understand the article:
- - [Message management](/v3/documentation/smart-contracts/message-management/messages-and-transactions), because this is the main functionality of the wallets.
- - [FunC language](/v3/documentation/smart-contracts/func/overview), because we will heavily rely on implementations made using it.
-:::
+
+- [Message management](/v3/documentation/smart-contracts/message-management/messages-and-transactions), because this is the main functionality of the wallets.
+- [FunC language](/v3/documentation/smart-contracts/func/overview), because we will heavily rely on implementations made using it.
+  :::
 
 ## Common concept
 
@@ -22,8 +23,7 @@ So the question is: what functionality do they provide and how it differs betwee
 
 You can consider each wallet version as a smart-contract implementation providing a standard external interface, allowing different external clients to interact with the wallets in the same way. You can find these implementations in FunC and Fift languages in the main TON monorepo:
 
- * [ton/crypto/smartcont/](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/) 
-
+- [ton/crypto/smartcont/](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/)
 
 ## Basic wallets
 
@@ -32,25 +32,29 @@ You can consider each wallet version as a smart-contract implementation providin
 This is the simplest one. It only allows you to send four transactions at a time and doesn't check anything besides your signature and seqno.
 
 Wallet source code:
- * [ton/crypto/smartcont/wallet-code.fif](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/new-wallet.fif) 
+
+- [ton/crypto/smartcont/wallet-code.fif](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/new-wallet.fif)
 
 This version isn’t even used in regular apps because it has some major issues:
- - No easy way to retrieve the seqno and public key from the contract.
- - No `valid_until` check, so you can't be sure that the transaction won't be confirmed too late.
+
+- No easy way to retrieve the seqno and public key from the contract.
+- No `valid_until` check, so you can't be sure that the transaction won't be confirmed too late.
 
 The first issue was fixed in `V1R2` and `V1R3`. The `R` stands for "revision". Usually, revisions are just small updates that only add get methods; you can find all of those in the changes history of `new-wallet.fif`. Hereinafter, we will consider only the latest revisions.
 
 Nevertheless, because each subsequent version inherits the functionality of the previous one, we should still stick to it, as this will help us with later versions.
 
 #### Persistent memory layout
- - <b>seqno</b>: 32-bit long sequence number.
- - <b>public-key</b>: 256-bit long public key.
+
+- <b>seqno</b>: 32-bit long sequence number.
+- <b>public-key</b>: 256-bit long public key.
 
 #### External message body layout
+
 1. Data:
-    - <b>signature</b>: 512-bit long ed25519 signature.
-    - <b>msg-seqno</b>: 32-bit long sequence number.
-    - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
+   - <b>signature</b>: 512-bit long ed25519 signature.
+   - <b>msg-seqno</b>: 32-bit long sequence number.
+   - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
 2. Up to 4 references to cells containing messages.
 
 As you can see, the main functionality of the wallet is to provide a safe way to communicate with the TON blockchain from the outside world. The `seqno` mechanism protects against replay attacks, and the `Ed25519 signature` provides authorized access to wallet functionality. We will not dwell in detail on each of these mechanisms, as they are described in detail in the [external message](/v3/documentation/smart-contracts/message-management/external-messages) documentation page and are quite common among smart contracts receiving external messages. The payload data consists of up to 4 references to cells and the corresponding number of modes, which will be directly transferred to the [send_raw_message(cell msg, int mode)](/v3/documentation/smart-contracts/func/docs/stdlib#send_raw_message) method.
@@ -60,36 +64,39 @@ Note that the wallet doesn't provide any validation for internal messages you se
 :::
 
 #### Exit codes
-| Exit code      | Description                                                       |
-|----------------|-------------------------------------------------------------------|
-| 0x21           | `seqno` check failed, reply protection accured                    |
-| 0x22           | `Ed25519 signature` check failed                                  |
-| 0x0            | Standard successful execution exit code.                          |
+
+| Exit code | Description                                    |
+| --------- | ---------------------------------------------- |
+| 0x21      | `seqno` check failed, reply protection accured |
+| 0x22      | `Ed25519 signature` check failed               |
+| 0x0       | Standard successful execution exit code.       |
 
 :::info
 Note that [TVM](/v3/documentation/tvm/tvm-overview) has [standart exit codes](/v3/documentation/tvm/tvm-exit-codes) (`0x0` - is one of them), so you can get one of them too, if you run out of [gas](https://docs.ton.org/develop/smart-contracts/fees), for example, you will get `0xD` code.
 :::
 
 #### Get methods
+
 1. int seqno() returns current stored seqno.
 2. int get_public_key returns current stored public key.
 
 ### Wallet V2
 
 Wallet source code:
- 
- * [ton/crypto/smartcont/wallet-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet-code.fc)
+
+- [ton/crypto/smartcont/wallet-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet-code.fc)
 
 This version introduces the `valid_until` parameter, which is used to set a time limit for a transaction in case you don't want it to be confirmed too late. This version also does not have the get-method for the public key, which was added in `V2R2`.
 
 All differences compared to the previous version are a consequence of adding the `valid_until` functionality. A new exit code was added: `0x23`, marking the failure of the valid_until check. Additionally, a new UNIX-time field has been added to the external message body layout, setting the time limit for the transaction. All get methods remain the same.
 
 #### External message body layout
+
 1. Data:
-    - <b>signature</b>: 512-bit long ed25519 signature.
-    - <b>msg-seqno</b>: 32-bit long sequence number.
-    - <b>valid-until</b>: 32-bit long Unix-time integer.
-    - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
+   - <b>signature</b>: 512-bit long ed25519 signature.
+   - <b>msg-seqno</b>: 32-bit long sequence number.
+   - <b>valid-until</b>: 32-bit long Unix-time integer.
+   - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
 2. Up to 4 references to cells containing messages.
 
 ### Wallet V3
@@ -97,39 +104,44 @@ All differences compared to the previous version are a consequence of adding the
 This version introduces the `subwallet_id` parameter, which allows you to create multiple wallets using the same public key (so you can have only one seed phrase and multiple wallets). As before, `V3R2` only adds the get-method for the public key.
 
 Wallet source code:
- * [ton/crypto/smartcont/wallet3-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet3-code.fc)
+
+- [ton/crypto/smartcont/wallet3-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet3-code.fc)
 
 Essentially, `subwallet_id` is just a number added to the contract state when it’s deployed. Since the contract address in TON is a hash of its state and code, the wallet address will change with a different `subwallet_id`. This version is the most widely used right now. It covers most use cases and remains clean, simple, and mostly the same as previous versions. All get methods remain the same.
 
 #### Persistent Memory Layout
+
 - <b>seqno</b>: 32-bit sequence number.
 - <b>subwallet</b>: 32-bit subwallet ID.
 - <b>public-key</b>: 256-bit public key.
 
 #### External Message Layout
+
 1. Data:
-    - <b>signature</b>: 512-bit ed25519 signature.
-    - <b>subwallet-id</b>: 32-bit subwallet ID.
-    - <b>msg-seqno</b>: 32-bit sequence number.
-    - <b>valid-until</b>: 32-bit UNIX time integer.
-    - <b>(0-4)mode</b>: Up to four 8-bit integers defining the sending mode for each message.
+   - <b>signature</b>: 512-bit ed25519 signature.
+   - <b>subwallet-id</b>: 32-bit subwallet ID.
+   - <b>msg-seqno</b>: 32-bit sequence number.
+   - <b>valid-until</b>: 32-bit UNIX time integer.
+   - <b>(0-4)mode</b>: Up to four 8-bit integers defining the sending mode for each message.
 2. Up to 4 references to cells containing messages.
 
 #### Exit Codes
-| Exit Code      | Description                                                              |
-|----------------|--------------------------------------------------------------------------|
-| 0x23           | `valid_until` check failed; transaction confirmation attempted too late  |
-| 0x23           | `Ed25519 signature` check failed                                         |
-| 0x21           | `seqno` check failed; reply protection triggered                         |
-| 0x22           | `subwallet-id` does not match the stored one                             |
-| 0x0            | Standard successful execution exit code.                                 |
+
+| Exit Code | Description                                                             |
+| --------- | ----------------------------------------------------------------------- |
+| 0x23      | `valid_until` check failed; transaction confirmation attempted too late |
+| 0x23      | `Ed25519 signature` check failed                                        |
+| 0x21      | `seqno` check failed; reply protection triggered                        |
+| 0x22      | `subwallet-id` does not match the stored one                            |
+| 0x0       | Standard successful execution exit code.                                |
 
 ### Wallet V4
 
 This version retains all the functionality of the previous versions but also introduces something very powerful: `plugins`.
 
 Wallet source code:
- * [ton-blockchain/wallet-contract](https://github.com/ton-blockchain/wallet-contract)
+
+- [ton-blockchain/wallet-contract](https://github.com/ton-blockchain/wallet-contract)
 
 This feature allows developers to implement complex logic that works in tandem with a user's wallet. For example, a DApp may require a user to pay a small amount of coins every day to use certain features. In this case, the user would need to install the plugin on their wallet by signing a transaction. The plugin would then send coins to the destination address daily when requested by an external message.
 
@@ -138,10 +150,11 @@ This feature allows developers to implement complex logic that works in tandem w
 Plugins are essentially other smart contracts on TON that developers are free to implement as they wish. In relation to the wallet, they are simply addresses of smart contracts stored in a [dictionary](/v3/documentation/smart-contracts/func/docs/dictionaries) in the wallet's persistent memory. These plugins are allowed to request funds and remove themselves from the "allowed list" by sending internal messages to the wallet.
 
 #### Persistent memory layout
- - <b>seqno</b>: 32-bit long sequence number.
- - <b>subwallet-id</b>: 32-bit long subwallet-id.
- - <b>public-key</b>: 256-bit long public key.
- - <b>plugins</b>: dictionary containing plugins(may be empty)
+
+- <b>seqno</b>: 32-bit long sequence number.
+- <b>subwallet-id</b>: 32-bit long subwallet-id.
+- <b>public-key</b>: 256-bit long public key.
+- <b>plugins</b>: dictionary containing plugins(may be empty)
 
 #### Receiving internal messages
 
@@ -149,52 +162,57 @@ All previous versions of wallets had a straightforward implementation for receiv
 
 - <b>op-code?</b>: 32-bit long operation code. This is an optional field; any message containing less than 32 bits in the message body, an incorrect op-code, or a sender address that isn't registered as a plugin will be considered as simple transfer, similar to previous wallet versions.
 - <b>query-id</b>: 64-bit long integer. This field has no effect on the smart contract's behavior; it is used to track chains of messages between contracts.
+
 1. op-code = 0x706c7567, request funds operation code.
-    - <b>toncoins</b>: VARUINT16 amount of requested toncoins.
-    - <b>extra_currencies</b>: Dictionary containing the amount of requested extra currencies (may be empty).
+   - <b>toncoins</b>: VARUINT16 amount of requested toncoins.
+   - <b>extra_currencies</b>: Dictionary containing the amount of requested extra currencies (may be empty).
 2. op-code = 0x64737472, request removal of plugin-sender from the "allowed list".
 
 #### External message body layout
 
- - <b>signature</b>: 512-bit long ed25519 signature.
- - <b>subwallet-id</b>: 32-bit long subwallet ID.
- - <b>valid-until</b>: 32-bit long Unix-time integer.
- - <b>msg-seqno</b>: 32-bit long sequence integer.
- - <b>op-code</b>: 32-bit long operation code.
+- <b>signature</b>: 512-bit long ed25519 signature.
+- <b>subwallet-id</b>: 32-bit long subwallet ID.
+- <b>valid-until</b>: 32-bit long Unix-time integer.
+- <b>msg-seqno</b>: 32-bit long sequence integer.
+- <b>op-code</b>: 32-bit long operation code.
+
 1. op-code = 0x0, simple send.
-    - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
-    - <b>(0-4)messages</b>:Up to four references to cells containing messages.
-2. op-code = 0x1, deploy and install plugin. 
-    - <b>workchain</b>: 8-bit long integer.
-    - <b>balance</b>: VARUINT16 toncoins amount of initial balance.
-    - <b>state-init</b>: Cell reference containing plugin initial state.
-    - <b>body</b>: Cell reference containing body.
+   - <b>(0-4)mode</b>: up to four 8-bit long integer's defining sending mode for each message.
+   - <b>(0-4)messages</b>:Up to four references to cells containing messages.
+2. op-code = 0x1, deploy and install plugin.
+   - <b>workchain</b>: 8-bit long integer.
+   - <b>balance</b>: VARUINT16 toncoins amount of initial balance.
+   - <b>state-init</b>: Cell reference containing plugin initial state.
+   - <b>body</b>: Cell reference containing body.
 3. op-code = 0x2/0x3, install plugin/remove plugin.
-    - <b>wc_n_address</b>: 8-bit long workchain_id + 256-bit long plugin address.
-    - <b>balance</b>: VARUINT16 toncoins amount of initial balance.
-    - <b>query-id</b>: 64-bit long integer.
+   - <b>wc_n_address</b>: 8-bit long workchain_id + 256-bit long plugin address.
+   - <b>balance</b>: VARUINT16 toncoins amount of initial balance.
+   - <b>query-id</b>: 64-bit long integer.
 
 As you can see, the fourth version still provides standard functionality through the `0x0` op-code, similar to previous versions. The `0x2` and `0x3` operations allow manipulation of the plugins dictionary. Note that in the case of `0x2`, you need to deploy the plugin with that address yourself. In contrast, the `0x1` op-code also handles the deployment process with the state_init field.
 
 :::tip
 If `state_init` doesn't make much sense from its name, take a look at the following references:
- * [addresses-in-ton-blockchain](/v3/documentation/smart-contracts/addresses#workchain-id-and-account-id)
- * [send-a-deploy-message](/v3/documentation/smart-contracts/func/cookbook#how-to-send-a-deploy-message-with-stateinit-only-with-stateinit-and-body)
- * [internal-message-layout](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout)
-:::
+
+- [addresses-in-ton-blockchain](/v3/documentation/smart-contracts/addresses#workchain-id-and-account-id)
+- [send-a-deploy-message](/v3/documentation/smart-contracts/func/cookbook#how-to-send-a-deploy-message-with-stateinit-only-with-stateinit-and-body)
+- [internal-message-layout](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout)
+  :::
 
 #### Exit Codes
-| Exit Code      | Description                                                                  |
-|----------------|------------------------------------------------------------------------------|
-| 0x24           | `valid_until` check failed, transaction confirmation attempted too late      |
-| 0x23           | `Ed25519 signature` check failed                                             |
-| 0x21           | `seqno` check failed, reply protection triggered                             |
-| 0x22           | `subwallet-id` does not match the stored one                                 |
-| 0x27           | Plugins dictionary manipulation failed (0x1-0x3 recv_external op-codes)      |
-| 0x50           | Not enough funds for the funds request                                       |
-| 0x0            | Standard successful execution exit code.                                     |
+
+| Exit Code | Description                                                             |
+| --------- | ----------------------------------------------------------------------- |
+| 0x24      | `valid_until` check failed, transaction confirmation attempted too late |
+| 0x23      | `Ed25519 signature` check failed                                        |
+| 0x21      | `seqno` check failed, reply protection triggered                        |
+| 0x22      | `subwallet-id` does not match the stored one                            |
+| 0x27      | Plugins dictionary manipulation failed (0x1-0x3 recv_external op-codes) |
+| 0x50      | Not enough funds for the funds request                                  |
+| 0x0       | Standard successful execution exit code.                                |
 
 #### Get methods
+
 1. int seqno() returns current stored seqno.
 2. int get_public_key() returns current stored public key.
 3. int get_subwallet_id() returns current subwallet ID.
@@ -206,8 +224,8 @@ If `state_init` doesn't make much sense from its name, take a look at the follow
 It is the most modern wallet version at the moment, developed by the Tonkeeper team, aimed at replacing V4 and allowing arbitrary extensions.
 <br></br>
 <ThemedImage
-    alt=""
-    sources={{
+alt=""
+sources={{
         light: '/img/docs/wallet-contracts/wallet-contract-V5.png?raw=true',
         dark: '/img/docs/wallet-contracts/wallet-contract-V5_dark.png?raw=true',
     }}
@@ -216,10 +234,12 @@ It is the most modern wallet version at the moment, developed by the Tonkeeper t
 The V5 wallet standard offers many benefits that improve the experience for both users and merchants. V5 supports gas-free transactions, account delegation and recovery, subscription payments using tokens and Toncoin, and low-cost multi-transfers. In addition to retaining the previous functionality (V4), the new contract allows you to send up to 255 messages at a time.
 
 Wallet source code:
- * [ton-blockchain/wallet-contract-v5](https://github.com/ton-blockchain/wallet-contract-v5)
+
+- [ton-blockchain/wallet-contract-v5](https://github.com/ton-blockchain/wallet-contract-v5)
 
 TL-B scheme:
- * [ton-blockchain/wallet-contract-v5/types.tlb](https://github.com/ton-blockchain/wallet-contract-v5/blob/main/types.tlb)
+
+- [ton-blockchain/wallet-contract-v5/types.tlb](https://github.com/ton-blockchain/wallet-contract-v5/blob/main/types.tlb)
 
 :::caution
 In contrast to previous wallet version specifications, we will rely on [TL-B](/v3/documentation/data-formats/tlb/tl-b-language) scheme, due to the relative complexity of this wallet version's interface implementation. We will provide some description for each of those. Nevertheless, a basic understanding is still required, in combination with the wallet source code, it should be enough.
@@ -228,15 +248,14 @@ In contrast to previous wallet version specifications, we will rely on [TL-B](/v
 #### Persistent memory layout
 
 ```
-contract_state$_ 
-    is_signature_allowed:(## 1) 
-    seqno:# 
-    wallet_id:(## 32) 
-    public_key:(## 256) 
+contract_state$_
+    is_signature_allowed:(## 1)
+    seqno:#
+    wallet_id:(## 32)
+    public_key:(## 256)
     extensions_dict:(HashmapE 256 int1) = ContractState;
 ```
 
-
 As you can see, the `ContractState`, compared to previous versions, hasn't undergone major changes. The main difference is the new `is_signature_allowed` 1-bit flag, which restricts or allows access through the signature and stored public key. We will describe the importance of this change in later topics.
 
 #### Authentification process
@@ -252,8 +271,8 @@ signed_request$_             // 32 (opcode from outer)
 
 internal_signed#73696e74 signed:SignedRequest = InternalMsgBody;
 
-internal_extension#6578746e 
-    query_id:(## 64) 
+internal_extension#6578746e
+    query_id:(## 64)
     inner:InnerRequest = InternalMsgBody;
 
 external_signed#7369676e signed:SignedRequest = ExternalMsgBody;
@@ -271,8 +290,8 @@ The first thing that we should notice is `InnerRequest`, which we have already s
 
 ```
 out_list_empty$_ = OutList 0;
-out_list$_ {n:#} 
-    prev:^(OutList n) 
+out_list$_ {n:#}
+    prev:^(OutList n)
     action:OutAction = OutList (n + 1);
 
 action_send_msg#0ec3c86d mode:(## 8) out_msg:^(MessageRelaxed Any) = OutAction;
@@ -296,31 +315,32 @@ Note that the maximum number of actions is 255; this is a consequence of the rea
 
 #### Exit Codes
 
-| Exit Code      | Description                                                                      |
-|----------------|----------------------------------------------------------------------------------|
-| 0x84           | Authentication attempt through signature while it's disabled                     |
-| 0x85           | `seqno` check failed, reply protection occurred                                  |
-| 0x86           | `wallet-id` does not correspond to the stored one                                |
-| 0x87           | `Ed25519 signature` check failed                                                 |
-| 0x88           | `valid-until` check failed                                                       |
-| 0x89           | Enforce that `send_mode` has the +2 bit (ignore errors) set for external message.|
-| 0x8A           | `external-signed` prefix doesn't correspond to the received one                  |
-| 0x8B           | Add extension operation was not successful                                       |
-| 0x8C           | Remove extension operation was not successful                                    |
-| 0x8D           | Unsupported extended message prefix                                              |
-| 0x8E           | Tried to disable auth by signature while the extension dictionary is empty       |
-| 0x8F           | Attempt to set signature to an already set state                                 |
-| 0x90           | Tried to remove the last extension when signature is disabled                    |
-| 0x91           | Extension has the wrong workchain                                                |
-| 0x92           | Tried to change signature mode through external message                          |
-| 0x93           | Invalid `c5`, `action_send_msg` verification failed                              |
-| 0x0            | Standard successful execution exit code.                                         |
+| Exit Code | Description                                                                       |
+| --------- | --------------------------------------------------------------------------------- |
+| 0x84      | Authentication attempt through signature while it's disabled                      |
+| 0x85      | `seqno` check failed, reply protection occurred                                   |
+| 0x86      | `wallet-id` does not correspond to the stored one                                 |
+| 0x87      | `Ed25519 signature` check failed                                                  |
+| 0x88      | `valid-until` check failed                                                        |
+| 0x89      | Enforce that `send_mode` has the +2 bit (ignore errors) set for external message. |
+| 0x8A      | `external-signed` prefix doesn't correspond to the received one                   |
+| 0x8B      | Add extension operation was not successful                                        |
+| 0x8C      | Remove extension operation was not successful                                     |
+| 0x8D      | Unsupported extended message prefix                                               |
+| 0x8E      | Tried to disable auth by signature while the extension dictionary is empty        |
+| 0x8F      | Attempt to set signature to an already set state                                  |
+| 0x90      | Tried to remove the last extension when signature is disabled                     |
+| 0x91      | Extension has the wrong workchain                                                 |
+| 0x92      | Tried to change signature mode through external message                           |
+| 0x93      | Invalid `c5`, `action_send_msg` verification failed                               |
+| 0x0       | Standard successful execution exit code.                                          |
 
 :::danger
 Note that the `0x8E`, `0x90`, and `0x92` wallet exit codes are designed to prevent you from losing access to wallet functionality. Nevertheless, you should still remember that the wallet doesn't check whether the stored extension addresses actually exist in TON. You can also deploy a wallet with initial data consisting of an empty extensions dictionary and restricted signature mode. In that case, you will still be able to access the wallet through the public key until you add your first extension. So, be careful with these scenarios.
 :::
 
 #### Get methods
+
 1. int is_signature_allowed() returns stored `is_signature_allowed` flag.
 2. int seqno() returns current stored seqno.
 3. int get_subwallet_id() returns current subwallet ID.
@@ -340,14 +360,15 @@ Consequently, there will be services (such as [Tonkeeper's Battery](https://blog
 #### Flow
 
 1. When sending USDt, the user signs one message containing two outgoing USDt transfers:
-    1. USDt transfer to the recipient's address.
-    2. Transfer of a small amount of USDt in favor of the Service.
+   1. USDt transfer to the recipient's address.
+   2. Transfer of a small amount of USDt in favor of the Service.
 2. This signed message is sent off-chain by HTTPS to the Service backend. The Service backend sends it to the TON blockchain, paying Toncoins for network fees.
 
 Beta version of the gasless backend API is available on [tonapi.io/api-v2](https://tonapi.io/api-v2). If you are developing any wallet app and have feedback about these methods please share it ton [@tonapitech](https://t.me/tonapitech) chat.
 
 Wallet source code:
- * [ton-blockchain/wallet-contract-v5](https://github.com/ton-blockchain/wallet-contract-v5)
+
+- [ton-blockchain/wallet-contract-v5](https://github.com/ton-blockchain/wallet-contract-v5)
 
 ## Special wallets
 
@@ -368,86 +389,27 @@ It allows you to set the time until which you won't be able to withdraw anything
 For example: you can create a wallet which will hold 1 million coins with total vesting time of 10 years. Set the cliff duration to one year, so the funds will be locked for the first year after the wallet is created. Then, you can set the unlock period to one month, so `1'000'000 TON / 120 months = ~8333 TON` will unlock every month.
 
 Wallet source code:
- * [ton-blockchain/lockup-wallet-contract](https://github.com/ton-blockchain/lockup-wallet-contract)
+
+- [ton-blockchain/lockup-wallet-contract](https://github.com/ton-blockchain/lockup-wallet-contract)
 
 ### Restricted wallet
 
 This wallet's function is to act like a regular wallet, but restrict transfers to only one pre-defined destination address. You can set the destination when you create this wallet and then you'll be only able to transfer funds from it to that address. But note that you can still transfer funds to validation contracts so you can run a validator with this wallet.
 
 Wallet source code:
- * [EmelyanenkoK/nomination-contract/restricted-wallet](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet)
 
-## Known op codes
-
-:::info
-Also op-code, op::code and operational code
-:::
-
-
-| Contract type   | Hex code        | OP::Code                   |
-|-----------------|-----------------|----------------------------|
-| Global          | 0x00000000      | Text Comment               |
-| Global          | 0xffffffff      | Bounce                     |
-| Global          | 0x2167da4b      | [Encrypted Comment](/v3/documentation/smart-contracts/message-management/internal-messages#messages-with-encrypted-comments) |
-| Global          | 0xd53276db      | Excesses                   |
-| Elector         | 0x4e73744b      | New Stake                  |
-| Elector         | 0xf374484c      | New Stake Confirmation     |
-| Elector         | 0x47657424      | Recover Stake Request      |
-| Elector         | 0x47657424      | Recover Stake Response     |
-| Wallet          | 0x0f8a7ea5      | Jetton Transfer            |
-| Wallet          | 0x235caf52      | [Jetton Call To](https://testnet.tonviewer.com/transaction/1567b14ad43be6416e37de56af198ced5b1201bb652f02bc302911174e826ef7) |
-| Jetton          | 0x178d4519      | Jetton Internal Transfer   |
-| Jetton          | 0x7362d09c      | Jetton Notify              |
-| Jetton          | 0x595f07bc      | Jetton Burn                |
-| Jetton          | 0x7bdd97de      | Jetton Burn Notification   |
-| Jetton          | 0xeed236d3      | Jetton Set Status          |
-| Jetton-Minter   | 0x642b7d07      | Jetton Mint                |
-| Jetton-Minter   | 0x6501f354      | Jetton Change Admin        |
-| Jetton-Minter   | 0xfb88e119      | Jetton Claim Admin         |
-| Jetton-Minter   | 0x7431f221      | Jetton Drop Admin          |
-| Jetton-Minter   | 0xcb862902      | Jetton Change Metadata     |
-| Jetton-Minter   | 0x2508d66a      | Jetton Upgrade             |
-| Vesting         | 0xd372158c      | [Top Up](https://github.com/ton-blockchain/liquid-staking-contract/blob/be2ee6d1e746bd2bb0f13f7b21537fb30ef0bc3b/PoolConstants.ts#L28) |
-| Vesting         | 0x7258a69b      | Add Whitelist              |
-| Vesting         | 0xf258a69b      | Add Whitelist Response     |
-| Vesting         | 0xa7733acd      | Send                       |
-| Vesting         | 0xf7733acd      | Send Response              |
-| Dedust          | 0x9c610de3      | Dedust Swap ExtOut         |
-| Dedust          | 0xe3a0d482      | Dedust Swap Jetton         |
-| Dedust          | 0xea06185d      | Dedust Swap Internal       |
-| Dedust          | 0x61ee542d      | Swap External              |
-| Dedust          | 0x72aca8aa      | Swap Peer                  |
-| Dedust          | 0xd55e4686      | Deposit Liquidity Internal |
-| Dedust          | 0x40e108d6      | Deposit Liquidity Jetton   |
-| Dedust          | 0xb56b9598      | Deposit Liquidity all      |
-| Dedust          | 0xad4eb6f5      | Pay Out From Pool          |
-| Dedust          | 0x474а86са      | Payout                     |
-| Dedust          | 0xb544f4a4      | Deposit                    |
-| Dedust          | 0x3aa870a6      | Withdrawal                 |
-| Dedust          | 0x21cfe02b      | Create Vault               |
-| Dedust          | 0x97d51f2f      | Create Volatile Pool       |
-| Dedust          | 0x166cedee      | Cancel Deposit             |
-| StonFi          | 0x25938561      | Swap Internal              |
-| StonFi          | 0xf93bb43f      | Payment Request            |
-| StonFi          | 0xfcf9e58f      | Provide Liquidity          |
-| StonFi          | 0xc64370e5      | Swap Success               |
-| StonFi          | 0x45078540      | Swap Success ref           |
-
-:::info
-[DeDust docs](https://docs.dedust.io/docs/swaps)
-
-[StonFi docs](https://docs.ston.fi/docs/developer-section/architecture#calls-descriptions)
-:::
+- [EmelyanenkoK/nomination-contract/restricted-wallet](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet)
 
 ## Conclusion
 
 As you see, there are many different versions of wallets in TON. But in most cases, you only need `V3R2` or `V4R2`. You can also use one of the special wallets if you want to have some additional functionality like a periodic unlocking of funds.
 
 ## See Also
- - [Working With Wallet Smart Contracts](/v3/guidelines/smart-contracts/howto/wallet)
- - [Sources of basic wallets](https://github.com/ton-blockchain/ton/tree/master/crypto/smartcont)
- - [More technical description of versions](https://github.com/toncenter/tonweb/blob/master/src/contract/wallet/WalletSources.md)
- - [Wallet V4 sources and detailed description](https://github.com/ton-blockchain/wallet-contract)
- - [Lockup wallet sources and detailed description](https://github.com/ton-blockchain/lockup-wallet-contract)
- - [Restricted wallet sources](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet)
- - [Gasless transactions on TON](https://medium.com/@buidlingmachine/gasless-transactions-on-ton-75469259eff2)
\ No newline at end of file
+
+- [Working With Wallet Smart Contracts](/v3/guidelines/smart-contracts/howto/wallet)
+- [Sources of basic wallets](https://github.com/ton-blockchain/ton/tree/master/crypto/smartcont)
+- [More technical description of versions](https://github.com/toncenter/tonweb/blob/master/src/contract/wallet/WalletSources.md)
+- [Wallet V4 sources and detailed description](https://github.com/ton-blockchain/wallet-contract)
+- [Lockup wallet sources and detailed description](https://github.com/ton-blockchain/lockup-wallet-contract)
+- [Restricted wallet sources](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet)
+- [Gasless transactions on TON](https://medium.com/@buidlingmachine/gasless-transactions-on-ton-75469259eff2)
diff --git a/docs/v3/documentation/smart-contracts/message-management/internal-messages.md b/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
index 6b6a832f92..725c847a21 100644
--- a/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
+++ b/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
@@ -1,8 +1,8 @@
 # Internal messages
 
-## Overview 
+## Overview
 
-Smart contracts interact with each other by sending so-called **internal messages**. When an internal message reaches its intended destination, an ordinary transaction is created on behalf of the destination account, and the internal message is processed as specified by the code and the persistent data of this account (smart contract). 
+Smart contracts interact with each other by sending so-called **internal messages**. When an internal message reaches its intended destination, an ordinary transaction is created on behalf of the destination account, and the internal message is processed as specified by the code and the persistent data of this account (smart contract).
 
 :::info
 In particular, the processing transaction can create one or several outbound internal messages, some of which may be addressed to the source address of the internal message being processed. This can be used to create simple "client-server applications" when a query is encapsulated in an internal message and sent to another smart contract, which processes the query and sends back a response again as an internal message.
@@ -22,7 +22,8 @@ message$_ {X:Type} ... body:(Either X ^X) = Message X;
 
 The receiving smart contract should accept at least internal messages with embedded message bodies (whenever they fit into the cell containing the message). If it accepts message bodies in separate cells (using the `right` constructor of `(Either X ^X)`), the processing of the inbound message should not depend on the specific embedding option chosen for the message body. On the other hand, it is perfectly valid not to support message bodies in separate cells for simpler queries and responses.
 
-### Internal Message Body 
+### Internal Message Body
+
 The message body typically begins with the following fields:
 
     * A 32-bit (big-endian) unsigned integer `op`, identifying the `operation` to be performed, or the `method` of the smart contract to be invoked.
@@ -31,66 +32,133 @@ The message body typically begins with the following fields:
 
 ### Simple Message with Comment
 
-If `op` is zero, then the message is a "simple transfer message with comment". The comment is contained in the remainder of the message body (without any `query_id` field, i.e., starting from the fifth byte). If it does not begin with the byte `0xff`, the comment is a text one; it can be displayed "as is" to the end user of a wallet (after filtering out invalid and control characters and checking that it is a valid UTF-8 string). 
+If `op` is zero, then the message is a "simple transfer message with comment". The comment is contained in the remainder of the message body (without any `query_id` field, i.e., starting from the fifth byte). If it does not begin with the byte `0xff`, the comment is a text one; it can be displayed "as is" to the end user of a wallet (after filtering out invalid and control characters and checking that it is a valid UTF-8 string).
+
+When comment is long enough that it doesn't fit in a cell, non-fitting end of the line is put to the first reference of the cell. This process continues recursively to describe comments that don't fit in two or more cells:
 
-   When comment is long enough that it doesn't fit in a cell, non-fitting end of the line is put to the first reference of the cell. This process continues recursively to describe comments that don't fit in two or more cells:   
 ```
 root_cell("0x00000000" - 32 bit, "string" up to 123 bytes)
          ↳1st_ref("string continuation" up to 127 bytes)
                  ↳1st_ref("string continuation" up to 127 bytes)
                          ↳....
 ```
-   The same format is used for comments for NFT and [jetton](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md#forward_payload-format) transfers.
-   
-   For instance, users may indicate the purpose of a simple transfer from their wallet to the wallet of another user in this text field. On the other hand, if the comment begins with the byte `0xff`, the remainder is a "binary comment", which should not be displayed to the end user as text (only as a hex dump if necessary). The intended use of "binary comments" is, e.g., to contain a purchase identifier for payments in a store, to be automatically generated and processed by the store's software.
 
-   Most smart contracts should not perform non-trivial actions or reject the inbound message on receiving a "simple transfer message". In this way, once `op` is found to be zero, the smart contract function for processing inbound internal messages (usually called `recv_internal()`) should immediately terminate with a zero exit code indicating success (e.g., by throwing exception `0`, if no custom exception handler has been installed by the smart contract). This will lead to the receiving account being credited with the value transferred by the message without any further effect.
+The same format is used for comments for NFT and [jetton](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md#forward_payload-format) transfers.
+
+For instance, users may indicate the purpose of a simple transfer from their wallet to the wallet of another user in this text field. On the other hand, if the comment begins with the byte `0xff`, the remainder is a "binary comment", which should not be displayed to the end user as text (only as a hex dump if necessary). The intended use of "binary comments" is, e.g., to contain a purchase identifier for payments in a store, to be automatically generated and processed by the store's software.
+
+Most smart contracts should not perform non-trivial actions or reject the inbound message on receiving a "simple transfer message". In this way, once `op` is found to be zero, the smart contract function for processing inbound internal messages (usually called `recv_internal()`) should immediately terminate with a zero exit code indicating success (e.g., by throwing exception `0`, if no custom exception handler has been installed by the smart contract). This will lead to the receiving account being credited with the value transferred by the message without any further effect.
 
 ### Messages with Encrypted Comments
 
 If `op` is `0x2167da4b`, then the message is a "transfer message with encrypted comment". This message is serialized as follows:
 
-   Input:
-   
-   * `pub_1` and `priv_1` - Ed25519 public and private keys of the sender, 32 bytes each.
-   * `pub_2` - Ed25519 public key of the receiver, 32 bytes.
-   * `msg` - a message to be encrypted, arbitrary byte string. `len(msg) <= 960`.
-   
-   Encryption algo is as follows:
-   
-   1. Calculate `shared_secret` using `priv_1` and `pub_2`.
-   2. Let `salt` be the [bas64url representation](/v3/documentation/smart-contracts/addresses#user-friendly-address) of the sender wallet address with `isBounceable=1` and `isTestnetOnly=0`.
-   3. Select byte string `prefix` of length between 16 and 31 such that `len(prefix+msg)` is divisible by 16. The first byte of `prefix` is equal to `len(prefix)`, other bytes are random. Let `data = prefix + msg`.
-   4. Let `msg_key` be the first 16 bytes of `hmac_sha512(salt, data)`.
-   5. Calculate `x = hmac_sha512(shared_secret, msg_key)`. Let `key=x[0:32]` and `iv=x[32:48]`.
-   6. Encrypt `data` using AES-256 in CBC mode with `key` and `iv`.
-   7. Construct the encrypted comment:
-       1. `pub_xor = pub_1 ^ pub_2` - 32 bytes. This allows each party to decrypt the message without looking up other's public key.
-       2. `msg_key` - 16 bytes.
-       3. Encrypted `data`.
-   8. The body of the message starts with the 4-byte tag `0x2167da4b`. Then this encrypted comment is stored:
-       1. Byte string is divided into segments and is stored in a chain of cells `c_1,...,c_k` (`c_1` is the root of the body). Each cell (except for the last one) has a reference to the next.
-       2. `c_1` contains up to 35 bytes (not including 4-byte tag), all other cells contain up to 127 bytes.
-       3. This format has the following limitations: `k <= 16`, max string length is 1024.
-
-   The same format is used for comments for NFT and jetton transfers, note that public key of sender address and receiver address (not jetton-wallet addresses) should be used.
-   
+Input:
+
+- `pub_1` and `priv_1` - Ed25519 public and private keys of the sender, 32 bytes each.
+- `pub_2` - Ed25519 public key of the receiver, 32 bytes.
+- `msg` - a message to be encrypted, arbitrary byte string. `len(msg) <= 960`.
+
+Encryption algo is as follows:
+
+1.  Calculate `shared_secret` using `priv_1` and `pub_2`.
+2.  Let `salt` be the [bas64url representation](/v3/documentation/smart-contracts/addresses#user-friendly-address) of the sender wallet address with `isBounceable=1` and `isTestnetOnly=0`.
+3.  Select byte string `prefix` of length between 16 and 31 such that `len(prefix+msg)` is divisible by 16. The first byte of `prefix` is equal to `len(prefix)`, other bytes are random. Let `data = prefix + msg`.
+4.  Let `msg_key` be the first 16 bytes of `hmac_sha512(salt, data)`.
+5.  Calculate `x = hmac_sha512(shared_secret, msg_key)`. Let `key=x[0:32]` and `iv=x[32:48]`.
+6.  Encrypt `data` using AES-256 in CBC mode with `key` and `iv`.
+7.  Construct the encrypted comment:
+    1.  `pub_xor = pub_1 ^ pub_2` - 32 bytes. This allows each party to decrypt the message without looking up other's public key.
+    2.  `msg_key` - 16 bytes.
+    3.  Encrypted `data`.
+8.  The body of the message starts with the 4-byte tag `0x2167da4b`. Then this encrypted comment is stored:
+    1.  Byte string is divided into segments and is stored in a chain of cells `c_1,...,c_k` (`c_1` is the root of the body). Each cell (except for the last one) has a reference to the next.
+    2.  `c_1` contains up to 35 bytes (not including 4-byte tag), all other cells contain up to 127 bytes.
+    3.  This format has the following limitations: `k <= 16`, max string length is 1024.
+
+The same format is used for comments for NFT and jetton transfers, note that public key of sender address and receiver address (not jetton-wallet addresses) should be used.
+
 :::info
 Learn from examples of the message encryption algorithm:
-* [encryption.js](https://github.com/toncenter/ton-wallet/blob/master/src/js/util/encryption.js)
-* [SimpleEncryption.cpp](https://github.com/ton-blockchain/ton/blob/master/tonlib/tonlib/keys/SimpleEncryption.cpp)
-:::
+
+- [encryption.js](https://github.com/toncenter/ton-wallet/blob/master/src/js/util/encryption.js)
+- [SimpleEncryption.cpp](https://github.com/ton-blockchain/ton/blob/master/tonlib/tonlib/keys/SimpleEncryption.cpp)
+  :::
 
 ### Simple Transfer Messages Without Comments
+
 A "simple transfer message without comment" has an empty body (without even an `op` field). The above considerations apply to such messages as well. Note that such messages should have their bodies embedded into the message cell.
 
 ### Distinction Between Query and Response Messages
+
 We expect "query" messages to have an `op` with the high-order bit clear, i.e., in the range `1 .. 2^31-1`, and "response" messages to have an `op` with the high-order bit set, i.e., in the range `2^31 .. 2^32-1`. If a method is neither a query nor a response (so that the corresponding message body does not contain a `query_id` field), it should use an `op` in the "query" range `1 .. 2^31 - 1`.
 
 ### Handling of Standard Response Messages
+
 There are some "standard" response messages with the `op` equal to `0xffffffff` and `0xfffffffe`. In general, the values of `op` from `0xfffffff0` to `0xffffffff` are reserved for such standard responses.
 
     * `op` = `0xffffffff` means "operation not supported". It is followed by the 64-bit `query_id` extracted from the original query, and the 32-bit `op` of the original query. All but the simplest smart contracts should return this error when they receive a query with an unknown `op` in the range `1 .. 2^31-1`.
     * `op` = `0xfffffffe` means "operation not allowed". It is followed by the 64-bit `query_id` of the original query, followed by the 32-bit `op` extracted from the original query.
 
-   Notice that unknown "responses" (with an `op` in the range `2^31 .. 2^32-1`) should be ignored (in particular, no response with an `op` equal to `0xffffffff` should be generated in response to them), just as unexpected bounced messages (with the "bounced" flag set).
+Notice that unknown "responses" (with an `op` in the range `2^31 .. 2^32-1`) should be ignored (in particular, no response with an `op` equal to `0xffffffff` should be generated in response to them), just as unexpected bounced messages (with the "bounced" flag set).
+
+## Known op codes
+
+:::info
+Also op-code, op::code and operational code
+:::
+
+| Contract type | Hex code   | OP::Code                                                                                                                               |
+| ------------- | ---------- | -------------------------------------------------------------------------------------------------------------------------------------- |
+| Global        | 0x00000000 | Text Comment                                                                                                                           |
+| Global        | 0xffffffff | Bounce                                                                                                                                 |
+| Global        | 0x2167da4b | [Encrypted Comment](/v3/documentation/smart-contracts/message-management/internal-messages#messages-with-encrypted-comments)           |
+| Global        | 0xd53276db | Excesses                                                                                                                               |
+| Elector       | 0x4e73744b | New Stake                                                                                                                              |
+| Elector       | 0xf374484c | New Stake Confirmation                                                                                                                 |
+| Elector       | 0x47657424 | Recover Stake Request                                                                                                                  |
+| Elector       | 0x47657424 | Recover Stake Response                                                                                                                 |
+| Wallet        | 0x0f8a7ea5 | Jetton Transfer                                                                                                                        |
+| Wallet        | 0x235caf52 | [Jetton Call To](https://testnet.tonviewer.com/transaction/1567b14ad43be6416e37de56af198ced5b1201bb652f02bc302911174e826ef7)           |
+| Jetton        | 0x178d4519 | Jetton Internal Transfer                                                                                                               |
+| Jetton        | 0x7362d09c | Jetton Notify                                                                                                                          |
+| Jetton        | 0x595f07bc | Jetton Burn                                                                                                                            |
+| Jetton        | 0x7bdd97de | Jetton Burn Notification                                                                                                               |
+| Jetton        | 0xeed236d3 | Jetton Set Status                                                                                                                      |
+| Jetton-Minter | 0x642b7d07 | Jetton Mint                                                                                                                            |
+| Jetton-Minter | 0x6501f354 | Jetton Change Admin                                                                                                                    |
+| Jetton-Minter | 0xfb88e119 | Jetton Claim Admin                                                                                                                     |
+| Jetton-Minter | 0x7431f221 | Jetton Drop Admin                                                                                                                      |
+| Jetton-Minter | 0xcb862902 | Jetton Change Metadata                                                                                                                 |
+| Jetton-Minter | 0x2508d66a | Jetton Upgrade                                                                                                                         |
+| Vesting       | 0xd372158c | [Top Up](https://github.com/ton-blockchain/liquid-staking-contract/blob/be2ee6d1e746bd2bb0f13f7b21537fb30ef0bc3b/PoolConstants.ts#L28) |
+| Vesting       | 0x7258a69b | Add Whitelist                                                                                                                          |
+| Vesting       | 0xf258a69b | Add Whitelist Response                                                                                                                 |
+| Vesting       | 0xa7733acd | Send                                                                                                                                   |
+| Vesting       | 0xf7733acd | Send Response                                                                                                                          |
+| Dedust        | 0x9c610de3 | Dedust Swap ExtOut                                                                                                                     |
+| Dedust        | 0xe3a0d482 | Dedust Swap Jetton                                                                                                                     |
+| Dedust        | 0xea06185d | Dedust Swap Internal                                                                                                                   |
+| Dedust        | 0x61ee542d | Swap External                                                                                                                          |
+| Dedust        | 0x72aca8aa | Swap Peer                                                                                                                              |
+| Dedust        | 0xd55e4686 | Deposit Liquidity Internal                                                                                                             |
+| Dedust        | 0x40e108d6 | Deposit Liquidity Jetton                                                                                                               |
+| Dedust        | 0xb56b9598 | Deposit Liquidity all                                                                                                                  |
+| Dedust        | 0xad4eb6f5 | Pay Out From Pool                                                                                                                      |
+| Dedust        | 0x474а86са | Payout                                                                                                                                 |
+| Dedust        | 0xb544f4a4 | Deposit                                                                                                                                |
+| Dedust        | 0x3aa870a6 | Withdrawal                                                                                                                             |
+| Dedust        | 0x21cfe02b | Create Vault                                                                                                                           |
+| Dedust        | 0x97d51f2f | Create Volatile Pool                                                                                                                   |
+| Dedust        | 0x166cedee | Cancel Deposit                                                                                                                         |
+| StonFi        | 0x25938561 | Swap Internal                                                                                                                          |
+| StonFi        | 0xf93bb43f | Payment Request                                                                                                                        |
+| StonFi        | 0xfcf9e58f | Provide Liquidity                                                                                                                      |
+| StonFi        | 0xc64370e5 | Swap Success                                                                                                                           |
+| StonFi        | 0x45078540 | Swap Success ref                                                                                                                       |
+
+:::info
+[DeDust docs](https://docs.dedust.io/docs/swaps)
+
+[StonFi docs](https://docs.ston.fi/docs/developer-section/architecture#calls-descriptions)
+:::