illustrations

foundations/statuses.mdx

@@ -2,6 +2,8 @@
 title: "Account statuses"
 ---
 
+import { Image } from '/snippets/image.jsx';
+
 This article describes the four possible states of an account on TON Blockchain.
 Understanding these states is crucial for accurately predicting transaction outcomes and ensuring the correct deployment.
 
@@ -42,7 +44,11 @@ We present here a diagram that describes all potential changes in the account st
 
 In the diagram below, there are four nodes representing the four different account statuses. Each arrow and loop corresponds to a change in the account status at the end of a given transaction. The parameters in the blocks above the arrows (and loops) briefly describe what caused the transaction and also contain some fields that affect the change in the account status.
 
-![alt text](/resources/images/status-changes-diagram.svg)
+<Image
+  src="/resources/images/statuses_light.svg"
+  darkSrc="/resources/images/statuses_dark.svg"
+  alt="Status changes diagram"
+/>
 
 So, let's look at what changes can occur to a `nonexist` account depending on the messages that come to it.
 

standard/wallets/highload/v3/specification.mdx

@@ -4,6 +4,7 @@ sidebarTitle: "Specification"
 ---
 
 import { Aside } from '/snippets/aside.jsx';
+import { Image } from '/snippets/image.jsx';
 
 This page provides a complete technical specification for Highload Wallet v3, covering storage structure, message formats, replay protection, limitations, and security mechanisms.
 
@@ -48,7 +49,7 @@ _ shift:uint13 bit_number:(## 10) { bit_number >= 0 } { bit_number < 1023 } = Qu
 ### External message structure
 
 ```tlb
-_ {n:#} subwallet_id:uint32 message_to_send:^Cell send_mode:uint8 query_id:QueryId 
+_ {n:#} subwallet_id:uint32 message_to_send:^Cell send_mode:uint8 query_id:QueryId
   created_at:uint64 timeout:uint22 = MsgInner;
 
 msg_body$_ {n:#} signature:bits512 ^(MsgInner) = ExternalInMsgBody;
@@ -455,43 +456,11 @@ Highload v3 can send **only ONE internal message** per external message. For bat
 
 Highload v3 uses a two-transaction pattern to safely send messages:
 
-```text
-+------------------------------------------+
-|   Transaction 1: External Message        |
-|                                          |
-|  1. Verify signature (exit 33)           |
-|  2. Check subwallet_id (exit 34)         |
-|  3. Check timeout matches (exit 38)      |
-|  4. Check created_at validity (exit 35)  |
-|     - Not too old (> now - timeout)      |
-|     - Not from future (<= now)           |
-|  5. Check query_id in old_queries (36)   |
-|  6. Check query_id in queries (36)       |
-|  7. Mark query_id as processed           |
-|  8. Commit storage changes               |
-|  9. Validate message_to_send (exit 37)   |
-| 10. Send INTERNAL message to self        |
-|                                          |
-|  ✓ Replay protection applied             |
-|  ✓ Storage changes committed             |
-+------------------------------------------+
-                   |
-                   v
-+------------------------------------------+
-|   Transaction 2: Internal Message        |
-|   (wallet sends to itself)               |
-|                                          |
-|  1. Validate sender = self               |
-|  2. Check op = 0xae42e5a4                |
-|  3. Extract action list from message     |
-|  4. Apply actions (send messages)        |
-|  5. Prevent code changes (set_code)      |
-|                                          |
-|  Note: If this transaction fails,        |
-|  replay protection from Transaction 1    |
-|  remains intact (no rollback)            |
-+------------------------------------------+
-```
+<Image
+  src="/resources/images/wallets/msg_flow_light.svg"
+  darkSrc="/resources/images/wallets/msg_flow_dark.svg"
+  alt="Message sending flow"
+/>
 
 <Aside type="note">
   **Why two transactions?**

standard/wallets/history.mdx

@@ -4,6 +4,7 @@ sidebarTitle: "History"
 ---
 
 import { Aside } from '/snippets/aside.jsx'
+import { Image } from '/snippets/image.jsx';
 
 You may have heard about different versions of wallets on TON Blockchain. But what do these versions actually mean, and how do they differ?
 
@@ -271,7 +272,11 @@ As you can see, the fourth version still provides standard functionality through
 
 It is the most modern wallet version at the moment, developed by the Tonkeeper team, aimed at replacing V4 and allowing arbitrary extensions.
 
-![v5](/resources/images/wallets/wallet-contract-V5.png)
+<Image
+  src="/resources/images/wallets/wallet_contract_v5_light.svg"
+  darkSrc="/resources/images/wallets/wallet_contract_v5_dark.svg"
+  alt="Wallet contract V5"
+/>
 
 The V5 wallet standard offers many benefits that improve the experience for both users and merchants. V5 supports gasless 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.
 
@@ -393,7 +398,11 @@ We can consider `InnerRequest` as two lists of actions: the first, `OutList`, is
 
 Starting with v5, the wallet smart contract supports owner-signed internal messages (`internal_signed`), which enables gasless transactions—for example, paying network fees in USDt when transferring USDt. The common scheme looks like this:
 
-![Gasless transaction flow diagram](/resources/images/wallets/gasless.jpg)
+<Image
+  src="/resources/images/wallets/gasless_light.svg"
+  darkSrc="/resources/images/wallets/gasless_dark.svg"
+  alt="Gasless transaction flow diagram"
+/>
 
 #### Flow