ton-community · reveloper · Jan 19, 2025 · Dec 16, 2024 · Dec 16, 2024 · Dec 17, 2024
@@ -1,3 +1,6 @@
+import ConceptImage from '@site/src/components/conceptImage';
+import ThemedImage from '@theme/ThemedImage';
+
 # Cells as Data Storage
 
 Everything in TON is stored in cells. A cell is a data structure containing:
@@ -9,10 +12,17 @@ Bits and references are not intermixed (they are stored separately). Circular re
 
 Thus, all cells constitute a directed acyclic graph (DAG). Here is a good picture to illustrate:
 
-![Directed Acyclic Graph](/img/docs/dag.png)
+<br></br>
+<ThemedImage
+    alt=""
+    sources={{
+        light: '/img/docs/cells-as-data-storage/dag.png?raw=true',
+        dark: '/img/docs/cells-as-data-storage/Cells-as-data-storage_1_dark.png?raw=true',
+    }}
+/>
+<br></br>
 
 ## Cell types
-
 Currently, there are 5 types of cells: _ordinary_ and 4 _exotic_.
 The exotic types are the following:
 * Pruned branch cell

@@ -15,13 +15,14 @@ If the order of transactions doesn't matter, you can omit their labels. This sim
 
 #### Annotation Primitives
 
-|Figure|Description|
-|------|-----------|
-|![](/img/docs/scheme-templates/message-processing-graphs/circle_for_smart_contract.svg?raw=true) | Circle - Smart Contract entity |
-|![](/img/docs/scheme-templates/message-processing-graphs/rectangle_for_regular_message.svg?raw=true)  | Rectangle - Message Entity |
-|![](/img/docs/scheme-templates/message-processing-graphs/dashed_rectgl_for_optional_message.svg?raw=true)  | Dashed Rectangle - Optional Message Entity |
-|![](/img/docs/scheme-templates/message-processing-graphs/line_for_transaction.svg?raw=true) | Transactions (numeration optional)|
-|![](/img/docs/scheme-templates/message-processing-graphs/person_figure_for_actor.svg?raw=true) | Actor|
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/scheme-templates/message-processing-graphs/Graphic-Explanations-Guidelines_1.svg?raw=true',
+    dark: '/img/docs/scheme-templates/message-processing-graphs/Graphic-Explanations-Guidelines_1_dark.svg?raw=true',
+  }}
+/>
+<br></br>
 
 * Avoid using big quantity different and bright colors.
 * Use the modification of figures, such as using a dashed border line.
@@ -35,7 +36,7 @@ If the order of transactions doesn't matter, you can omit their labels. This sim
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_2.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_2.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_2_dark.svg?raw=true',
   }}
 />
 <br></br>
@@ -79,7 +80,7 @@ In the case of complex and repetitive communication schemes between 2-3 actors,
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_7.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_7.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_7_dark.svg?raw=true',
   }}
 />
 </div>

@@ -1,3 +1,6 @@
+import ConceptImage from '@site/src/components/conceptImage';
+import ThemedImage from '@theme/ThemedImage';
+
 # Types of Wallet Contracts
 
 You may have heard about different versions of wallets on the TON Blockchain. But what do these versions actually mean, and how do they differ?
@@ -201,7 +204,15 @@ If `state_init` doesn't make much sense from its name, take a look at the follow
 ### Wallet V5
 
 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={{
+        light: '/img/docs/wallet-contracts/wallet-contract-V5.png?raw=true',
+        dark: '/img/docs/wallet-contracts/wallet-contract-V5_dark.png?raw=true',
+    }}
+/>
+<br></br><br></br><br></br>
 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:

@@ -26,7 +26,7 @@ __A__ sent 0.1 TON to __B__, [msg_fwd_fees](/v3/documentation/smart-contracts/tr
 
 State after transaction: Account A has 0.9 TON, Account B has 1.096 TON
 
-![](/img/docs/message-modes-cookbook/send_regular_message.svg)
+![](/img/docs/message-modes-cookbook/send_regular_message_1.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -46,7 +46,7 @@ Funds included with an ignored message will still be [credited to the receiving
 If no errors the result is the same as [`mode = 0`](#1-send-a-regular-message).
 :::
 
-![](/img/docs/message-modes-cookbook/send_regular_message_and_ignore_errors.svg)
+![](/img/docs/message-modes-cookbook/send_regular_message_2.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -61,11 +61,13 @@ In case of an error during [action phase](https://retracer.ton.org/?tx=e9dccba82
 
 State after transaction with error: Account A has 1 - ([total_fee](/v3/documentation/smart-contracts/transaction-fees/fees#basic-fees-formula) + `fwd_fee`) TON, Account B has 1 TON
 
+![](/img/docs/message-modes-cookbook/send_regular_message_3_error.svg)
+
 :::info tip
 If no errors the result is the same as [`mode = 0`](#1-send-a-regular-message).
 :::
 
-![](/img/docs/message-modes-cookbook/send_regular_message_and_bounce_if_error.svg)
+![](/img/docs/message-modes-cookbook/send_regular_message_3_noerror.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -79,7 +81,7 @@ __A__ sent 0.1 TON to __B__, `msg_fwd_fees` are 0.004 TON, actual received value
 
 State after transaction: Account A has 0.896 TON, Account B has 1.1 TON
 
-![](/img/docs/message-modes-cookbook/send_regular_and_pay_fees_separately.svg)
+![](/img/docs/message-modes-cookbook/send_regular_message_4.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -94,11 +96,13 @@ In case of an error during [action phase](https://retracer.ton.org/?tx=e9dccba82
 
 State after transaction with error: Account A has 1 - ([total_fee](/v3/documentation/smart-contracts/transaction-fees/fees#basic-fees-formula) + `fwd_fee`) TON, Account B has 1 TON
 
+![](/img/docs/message-modes-cookbook/send_regular_message_5_error.svg)
+
 :::info tip
 If no errors the result is the same as [`mode = 1`](#4-send-a-regular-message-with-separate-fees).
 :::
 
-![](/img/docs/message-modes-cookbook/send_regular_message_pay_fee_separately_bounce_if_error.svg)
+![](/img/docs/message-modes-cookbook/send_regular_message_5_noerror.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -116,7 +120,7 @@ State after transaction: Account A has 0.896 TON, Account B has 0.5 TON, Account
 You might check [this example](https://retracer.ton.org/?tx=4340b5ecbd83227cc64e10b1ca7628352133cda1d608081fb2ed58d299f00936&testnet=true)
 :::
 
-![](/img/docs/message-modes-cookbook/carry_all_the_remaining_value.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_6.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -134,7 +138,7 @@ State after transaction: Account A has 0.896 TON, Account B has 0.5 - (total_fee
 You might check [this example](https://retracer.ton.org/?tx=5c2525feeb3b93db594b7b11f3250430f02dd8616595cf2b1583ebc7da79d15b&testnet=true)
 :::
 
-![](/img/docs/message-modes-cookbook/carry_all_the_remaining_value_and_pay_fees_separately.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_7.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -149,12 +153,13 @@ In case of an error during action phase, the message will bounce and `total_fee`
 
 State after transaction with error: Account A has 1 - (total_fee + `fwd_fee`) TON, Account B has 1 TON, Account C has 1 TON
 
+![](/img/docs/message-modes-cookbook/carry_remaining_value_8_error.svg)
 
 :::info tip
 If no errors the result is the same as [`mode = 64`](#6-carry-remaining-value-with-new-message).
 :::
 
-![](/img/docs/message-modes-cookbook/carry_all_the_remaining_value_and_if_error_bounce.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_8_noerror.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -169,12 +174,13 @@ In case of an error during action phase, the message will bounce and `total_fee`
 
 State after transaction with error: Account A has 1 - (total_fee + `fwd_fee`) TON, Account B has 1 TON, Account C has 1 TON
 
+![](/img/docs/message-modes-cookbook/carry_remaining_value_9_error.svg)
 
 :::info tip
 If no errors the result is the same as [`mode = 65`](#7-carry-remaining-value-with-new-message-with-separate-fees).
 :::
 
-![](/img/docs/message-modes-cookbook/carry_all_the_remaining_value_and_pay_fees_separately_and_if_error_bounce.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_9_noerror.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -188,7 +194,7 @@ __A__ sent 0.1 TON to __B__ after that __B__ sent 0.5 TON to __C__ with `mode` =
 
 State after transaction: Account A has 0.896 TON, Account B has 0 TON, Account C has ~2.09 TON
 
-![](/img/docs/message-modes-cookbook/send_all_received_tokens_with_balance.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_10.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -202,12 +208,13 @@ __A__ sent 0.1 TON to __B__ after that __B__ sent 0.5 TON to __C__ with `mode` =
 
 State after transaction with error: Account A has 1 - (total_fee + `fwd_fee`) TON, Account B has 1 TON, Account C has 1 TON
 
+![](/img/docs/message-modes-cookbook/carry_remaining_value_11_error.svg)
 
 :::info tip
 If no errors the result is the same as [`mode = 128`](#10-send-all-received-tokens-together-with-the-contract-balance).
 :::
 
-![](/img/docs/message-modes-cookbook/send_all_received_tokens_with_balance_and_if_error_bounce.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_11_noerror.svg)
 
 | Mode and Flags | Code |
 |:-|:-|
@@ -222,7 +229,7 @@ __A__ sent 0.1 TON to __B__ after that __B__ sent 0.5 TON to __C__ with `mode` =
 State after transaction: Account A has 0.896 TON, Account B has 0 TON and `nonexist`, Account C has ~2.09 TON
 When the balance reaches 0 TON destroy the contract.
 
-![](/img/docs/message-modes-cookbook/send_all_received_tokens_with_balance_and_destroy_sc.svg)
+![](/img/docs/message-modes-cookbook/carry_remaining_value_12.svg)
 
 | Mode and Flags | Code |
 |:-|:-|

@@ -15,7 +15,7 @@ A message is a packet of data exchanged between actors (users, applications, or
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_1.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_1.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_1_dark.svg?raw=true',
   }}
 />
 </div>
@@ -42,7 +42,7 @@ A transaction in TON consists of the following:
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_2.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_2.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_2_dark.svg?raw=true',
   }}
 />
 <br></br>
@@ -106,7 +106,7 @@ It is strictly guaranteed that the transaction resulting from a message will hav
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_3.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_3.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_3_dark.svg?raw=true',
   }}
 />
 <br></br>
@@ -125,7 +125,7 @@ If `msg1_lt < msg2_lt` => `tx1_lt < tx2_lt`.
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_5.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_5.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_5_dark.svg?raw=true',
   }}
 />
 </div>
@@ -147,7 +147,18 @@ It therefore seems like _lt_ solves the issue about message delivery order, beca
 
 Suppose that there are two contracts - _A_ and _B_. _A_ receives an external message which triggers it to send two internal messages to _B_, let's call these messages _1_ and _2_. In this simple case, we can be 100% sure that _1_ will be processed by _B_ before _2_ because it has a lower _lt_.
 
-<ConceptImage src="/img/docs/msg-delivery-1.png" />
+<br></br>
+<div class="text--center">
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/message-delivery/msg-delivery-1.png?raw=true',
+    dark: '/img/docs/message-delivery/msg-delivery-1_dark.svg?raw=true',
+  }}
+/>
+</div>
+<br></br>
+
 
 But this is just a simple case when we only have two contracts. How does our system works in more complex cases?
 
@@ -166,7 +177,7 @@ We have two possible traces for these transaction,
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_6.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_6.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_6_dark.svg?raw=true',
   }}
 />
 </div>
@@ -180,21 +191,63 @@ We have two possible traces for these transaction,
   alt=""
   sources={{
     light: '/img/docs/message-delivery/message_delivery_7.svg?raw=true',
-    dark: '/img/docs/message-delivery/message_delivery_7.svg?raw=true',
+    dark: '/img/docs/message-delivery/message_delivery_7_dark.svg?raw=true',
   }}
 />
 </div>
 <br></br>
 
 The same thing happens in the reverse case, when two contracts _B_ and _C_ send a message to one contract _A_. Even if message `B -> A` was sent before `C -> A`, we can't know which one of them will be delivered first. The `B -> A` route may require more shard chain hops.
 
-<ConceptImage src="/img/docs/msg-delivery-3.png" />
+<br></br>
+<div class="text--center">
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/message-delivery/msg-delivery-3.png?raw=true',
+    dark: '/img/docs/message-delivery/msg-delivery-3_dark.svg?raw=true',
+  }}
+/>
+</div>
+<br></br>
 
 There can be many possible scenarios of smart contract interactions, and in any scenario with more than 2 contracts, the order of messages delivery may be arbitrary. The only guarantee is that messages from any contract _A_ to any contract _B_ will be processed in order of their logical time. Some examples are below.
 
-<ConceptImage src="/img/docs/msg-delivery-4.png" />
-<ConceptImage src="/img/docs/msg-delivery-5.png" />
-<ConceptImage src="/img/docs/msg-delivery-6.png" />
+<br></br>
+<div class="text--center">
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/message-delivery/msg-delivery-4.png?raw=true',
+    dark: '/img/docs/message-delivery/msg-delivery-4_dark.svg?raw=true',
+   }}
+/>
+</div>
+<br></br>
+
+<br></br>
+<div class="text--center">
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/message-delivery/msg-delivery-5.png?raw=true',
+    dark: '/img/docs/message-delivery/msg-delivery-5_dark.svg?raw=true',
+  }}
+/>
+</div>
+<br></br>
+
+<br></br>
+<div class="text--center">
+<ThemedImage
+  alt=""
+  sources={{
+    light: '/img/docs/message-delivery/msg-delivery-6.png?raw=true',
+    dark: '/img/docs/message-delivery/msg-delivery-6_dark.svg?raw=true',
+  }}
+/>
+</div>
+<br></br>
 
 ## Conclusion