diff --git a/contract-dev/blueprint/debug.mdx b/contract-dev/blueprint/debug.mdx
index 98f5e23eb..4eff538eb 100644
--- a/contract-dev/blueprint/debug.mdx
+++ b/contract-dev/blueprint/debug.mdx
@@ -68,7 +68,7 @@ it('should deploy correctly', async () => {
 
 ## Dump values from a contract
 
-There are three TVM debug [instructions](/tvm/instructions#fe-debug): `DUMPSTK`, `STRDUMP`, and `DUMP`.
+There are three TVM debug [instructions](/tvm/instructions#feij-debug): `DUMPSTK`, `STRDUMP`, and `DUMP`.
 
 These instructions are wrapped in functions with different names in each language:
 
@@ -127,7 +127,7 @@ default exception handler, terminating vm with exit code 9
 
 <Aside type="tip">
   To investigate the error in more detail, examine the TVM source code for the `LDU` instruction.
-  Sometimes several instructions are implemented within a single `exec_*` method. For example, [LDU](/tvm/instructions#d3-ldu) (`load_uint`), [LDI](/tvm/instructions#d2-ldi) (`load_int`) and it's preload versions (`preload_uint`and`preload_int`).
+  Sometimes several instructions are implemented within a single `exec_*` method. For example, [`LDU`](/tvm/instructions#d3cc-ldu) (`load_uint`), [`LDI`](/tvm/instructions#d2cc-ldi) (`load_int`) and it's preload versions (`preload_uint`and`preload_int`).
 
   Check how `LDU` [is implemented](https://github.com/ton-blockchain/ton/blob/34823b1ea378edbe3bc59f3bcc48126480a0b768/crypto/vm/cellops.cpp#L981).
 </Aside>
diff --git a/contract-dev/techniques/on-chain-jetton-processing.mdx b/contract-dev/techniques/on-chain-jetton-processing.mdx
index 228ef1636..9be03cc03 100644
--- a/contract-dev/techniques/on-chain-jetton-processing.mdx
+++ b/contract-dev/techniques/on-chain-jetton-processing.mdx
@@ -32,7 +32,7 @@ There are three approaches to verify `JettonNotify` messages, depending on the l
 
 ## Manual wallet management
 
-If the jetton type is known in advance, [calculate the corresponding jetton wallet address off-chain](https://docs.ton.org/standard/tokens/jettons/find) and set it via a message after deployment. It is impossible to hardcode the jetton wallet address in the contract’s [`StateInit`](/foundations/messages/deploy) because the wallet address depends on the contract address and creates a circular dependency. This is the most efficient approach, because it only requires one address comparison.
+If the jetton type is known in advance, [calculate the corresponding jetton wallet address off-chain](/standard/tokens/jettons/find) and set it via a message after deployment. It is impossible to hardcode the jetton wallet address in the contract’s [`StateInit`](/foundations/messages/deploy) because the wallet address depends on the contract address and creates a circular dependency. This is the most efficient approach, because it only requires one address comparison.
 
 The following example of a receiving contract handles `JettonNotify` messages for a trusted jetton wallet address that can be set by the owner of the contract.
 
@@ -228,7 +228,7 @@ If a jetton contract doesn't implement TEP-89, it is possible to compute the jet
   Jettons that do not implement the TEP-89 messages for computing a wallet address on-chain are rare. [TONCO DEX](https://tonco.io/) rejects them, while platforms such as [DeDust](https://dedust.io/) only allow them after a manual approval.
 </Aside>
 
-With the state of a jetton minter, the [RUNVM](/tvm/instructions#db4-runvm) instruction can emulate the execution of the `get_wallet_address` [get-method](/tvm/get-method) to derive the wallet address for any owner.
+With the state of a jetton minter, the [`RUNVM`](/tvm/instructions#db4fff-runvm) instruction can emulate the execution of the `get_wallet_address` [get-method](/tvm/get-method) to derive the wallet address for any owner.
 
 Use the following helper function. It relies on [Fift](/languages/fift/overview) because it's impossible to assign a type to `c7`. It executes the `get_wallet_address` method of a jetton minter on-chain, and calculates the corresponding wallet address for a given owner.
 
diff --git a/contribute/snippets/filetree.mdx b/contribute/snippets/filetree.mdx
index cc8780e95..15e94cbca 100644
--- a/contribute/snippets/filetree.mdx
+++ b/contribute/snippets/filetree.mdx
@@ -22,7 +22,7 @@ import { FileTree } from '/snippets/filetree.jsx';
 
 ## Usage
 
-Specify the structure of files and directories inside the [`items` property](#items) as a JavaScript list of strings, objects, and nested lists.
+Specify the structure of files and directories inside the [`items` property](#items-required) as a JavaScript list of strings, objects, and nested lists.
 
 ```mdx
 import { FileTree } from '/snippets/filetree.jsx';
diff --git a/contribute/snippets/image.mdx b/contribute/snippets/image.mdx
index 6adb2ba53..9c453bf78 100644
--- a/contribute/snippets/image.mdx
+++ b/contribute/snippets/image.mdx
@@ -6,13 +6,13 @@ sidebarTitle: "Image"
 import { Aside } from '/snippets/aside.jsx';
 import { Image } from '/snippets/image.jsx';
 
-To display an image, use the `<Image>` component. It allows displaying either a single image for all themes ([`src`](#src)) or one image per light theme (`src`) and one image for the dark theme ([`darkSrc`](#darksrc)).
+To display an image, use the `<Image>` component. It allows displaying either a single image for all themes ([`src`](#src-required)) or one image per light theme (`src`) and one image for the dark theme ([`darkSrc`](#darksrc)).
 
 <Aside>
   When an `src` path points to the SVG image and there is no [`darkSrc`](#darksrc) alternative, image colors will be inverted in the dark theme.
 </Aside>
 
-Additionally, you can specify the [`href`](#href) property, making an image double as a clickable link. When doing so, the [`target`](#href) property allows to change the browsing context of the link.
+Additionally, you can specify the [`href`](#href) property, making an image double as a clickable link. When doing so, the [`target`](#href) property allows changing the browsing context of the link.
 
 <Aside>
   Making an image into a clickable link disables image zoom capabilities.
@@ -109,13 +109,13 @@ See more: [`alt` attribute on the `<img>` image embed element, MDN](https://deve
 ### `darkSrc`
 
 <Aside>
-  The value of this property is ignored unless the [`src` property](#src) is set.
+  The value of this property is ignored unless the [`src` property](#src-required) is set.
 </Aside>
 
 **type:** `string` <br />
-**default:** [`src`](#src) value
+**default:** [`src`](#src-required) value
 
-Similar to the [`src` property](#src), but specifies the image file URL for the dark theme only.
+Similar to the [`src` property](#src-required), but specifies the image file URL for the dark theme only.
 
 ### `darkAlt`
 
diff --git a/contribute/style-guide-extended.mdx b/contribute/style-guide-extended.mdx
index 3d69bef4b..c17b2fdbf 100644
--- a/contribute/style-guide-extended.mdx
+++ b/contribute/style-guide-extended.mdx
@@ -163,7 +163,7 @@ Rules (binding).
 - Emojis in compact tables **MAY** be used sparingly as visual indicators only when they follow a widely understood convention (for example, `✅` / `❌` for supported/not supported, or `★` to mark a recommended option) and **MUST** be paired with a text label in the same cell or a descriptive header (e.g., “Supported — Yes/No”). Do not rely on an emoji alone to convey meaning, and **MUST NOT** use decorative or non-standard pictograms (for example, a play triangle to indicate videos). (Why: paired, conventional icons preserve clarity for screen readers, localization, and cases where emojis don’t render.)
 - Even where emojis are technically allowed (code/output or compact tables), they **SHOULD** be rare and **MUST** have a clear purpose. If the same meaning is clear without the emoji, remove it. (Why: conventional text remains clearer for global readers and translators.)
 - Use plain terms over legalese/Latinisms. “Use” not “utilize”; “before” not “prior to.” (Why: common words improve comprehension and reduce rereads; they are also translated more consistently.)
-- Avoid first-person pronouns (“we”, “I”, “our”). When an organization, product, or service is the actor, use its proper name (e.g., “Tonkeeper”, “TON”) or a neutral noun (“the node”, “the SDK”). Prefer imperative instructions without “you”. See [§5.8](#58-dont-get-personal) and [§5.10](#510-pronouns-and-person-references). (Why: neutral, explicit actors read cleanly and translate reliably.)
+- Avoid first-person pronouns (“we”, “I”, “our”). When an organization, product, or service is the actor, use its proper name (e.g., “Tonkeeper”, “TON”) or a neutral noun (“the node”, “the SDK”). Prefer imperative instructions without “you”. See [§5.8](#5-8-dont-get-personal) and [§5.10](#5-10-pronouns-and-person-references). (Why: neutral, explicit actors read cleanly and translate reliably.)
 
 Marketing and promotional language (ban).
 
@@ -209,7 +209,7 @@ Objective. Make sentences easy to parse on first read. (Why: clear, low-friction
 
   - Good: “The API returns JSON.”
   - Bad: “The API will return JSON.”
-- Prefer imperative instructions without addressing the reader (“you”). Avoid first-person pronouns (“we”, “I”, “our”); when an organization, product, or service is the actor, use its proper name (e.g., “TON Center”, “TON”). See [§5.8](#58-dont-get-personal) and [§5.10](#510-pronouns-and-person-references). (Why: imperative, neutral phrasing keeps actors clear without personal address.)
+- Prefer imperative instructions without addressing the reader (“you”). Avoid first-person pronouns (“we”, “I”, “our”); when an organization, product, or service is the actor, use its proper name (e.g., “TON Center”, “TON”). See [§5.8](#5-8-dont-get-personal) and [§5.10](#5-10-pronouns-and-person-references). (Why: imperative, neutral phrasing keeps actors clear without personal address.)
 
 ### 5.2 Plain, precise wording
 
@@ -430,7 +430,7 @@ Objective. Remove ambiguity and increase scan speed with consistent mechanics. (
 ### 6.6 Blockquotes
 
 - Blockquotes **MUST** be reserved for literal quotations from a source (another page in these docs or an external source). Include attribution inline or in the sentence introducing the quote; internal quotes **SHOULD** link to the exact anchor; external quotes **SHOULD** link to the canonical HTTPS source. (Why: clear attribution preserves trust and lets readers verify context.)
-- Blockquotes **MUST NOT** be used for callouts/admonitions, warnings, tips, examples, emphasis, or general instructions. Use the `<Aside>` component for callouts (see [§11.2](#112-how-to-write-the-callout), [Appendix A](#a-admonition-levels-and-usage)) and headings/lists for structure. (Why: misusing blockquotes harms structure, accessibility, and localization.)
+- Blockquotes **MUST NOT** be used for callouts/admonitions, warnings, tips, examples, emphasis, or general instructions. Use the `<Aside>` component for callouts (see [§11.2](#11-2-how-to-write-the-callout), [Appendix A](#a-admonition-levels-and-usage)) and headings/lists for structure. (Why: misusing blockquotes harms structure, accessibility, and localization.)
 - Visual callouts (Note/Tip/Caution/Warning) **MUST** use only the `<Aside>` component. The only supported `type` values are `"note"`, `"tip"`, `"caution"`, and `"danger"`; do **NOT** use other components or type values. \[HIGH] (Why: a single component and fixed types keep rendering, accessibility, and localization consistent.)
 - Short phrases or UI/log strings **SHOULD** use inline quotation marks instead of a blockquote. Tokens and identifiers **MUST** use code font, not blockquotes. (Why: inline quotes and code font are more precise and copy-friendly.)
 - Keep quotations brief (prefer ≤ two sentences or one short paragraph). For longer material, summarize in your own words and link to the source. (Why: long quotes impede scanning and duplicate external content.)
@@ -720,7 +720,7 @@ Objective. Reduce duplication and let readers jump straight to detail. (Why: dir
   - Good: `"For more details, see [Validator setup](/validator-setup)."`
   - Good: `"Related guide: [Set up a validator](/validator-setup)."`
 
-- Link labels **SHOULD** be plain text or inline code for identifiers (see [§6.2](#62-quotation-marks-and-emphasis) for emphasis restrictions on link text). (Why: unstyled labels keep links readable and avoid redundant visual emphasis.)
+- Link labels **SHOULD** be plain text or inline code for identifiers (see [§6.2](#6-2-quotation-marks-and-emphasis) for emphasis restrictions on link text). (Why: unstyled labels keep links readable and avoid redundant visual emphasis.)
 
 - Standalone "stub" sentences whose only job is to say "See …" or "Read here …" followed by a link (for example, `[Read here](/standard/wallets/mnemonics) to learn more.` or `See [mnemonics](/standard/wallets/mnemonics) for more details.`) **MUST NOT** appear in running prose. Instead, attach the link to the relevant term or phrase in a normal sentence (for example, `The [mnemonics guide](/standard/wallets/mnemonics) explains why.`). (Why: inline links keep the text flowing and avoid postponing useful links to trailing meta-sentences.) \[HIGH]
 
@@ -801,8 +801,8 @@ Objective. Enforce a single source of truth for terms and casing. (Why: one auth
 
 - A project term bank **MUST** define canonical terms, spellings, hyphenation, casing, and banned variants with replacements (e.g., allowlist/denylist for whitelist/blacklist). (Why: clear entries stop ad-hoc wording and mixed casing from spreading.)
 - You **MUST** consult the term bank before introducing new names; additions **SHOULD** be reviewed by editors. (Why: gatekeeping new terms prevents drift and conflicting synonyms.)
-- The term bank **SHOULD** mark which terms are link-worthy for first-use cross-links and record their canonical doc URLs. First-use linking rules in [§12.2](#122-what-to-link-and-what-not) **SHOULD** apply only to terms above this importance threshold to avoid over-linking minor notions. (Why: a curated set of link-worthy terms keeps pages readable while still making key concepts discoverable.)
-- Flags, parameters, error codes, and data types documented in guides **MUST** be included in this link-worthy set so first-use links in [§12.2](#122-what-to-link-and-what-not) always have a canonical target. This includes TVM exit codes, send modes, reserve modes, and other numeric constants with documented semantics. (Why: treating these technical items as link-worthy ensures readers can jump straight to their reference definitions.) \[HIGH]
+- The term bank **SHOULD** mark which terms are link-worthy for first-use cross-links and record their canonical doc URLs. First-use linking rules in [§12.2](#12-2-what-to-link-and-what-not) **SHOULD** apply only to terms above this importance threshold to avoid over-linking minor notions. (Why: a curated set of link-worthy terms keeps pages readable while still making key concepts discoverable.)
+- Flags, parameters, error codes, and data types documented in guides **MUST** be included in this link-worthy set so first-use links in [§12.2](#12-2-what-to-link-and-what-not) always have a canonical target. This includes TVM exit codes, send modes, reserve modes, and other numeric constants with documented semantics. (Why: treating these technical items as link-worthy ensures readers can jump straight to their reference definitions.) \[HIGH]
 
 ### 13.2 General casing rules
 
@@ -830,7 +830,7 @@ Non-exhaustive; finalize in the term bank. (Why: examples guide writers now, whi
 ### 13.5 Placeholder names
 
 - In commands and prose, placeholders **MUST** be `<ANGLE_CASE>` with descriptive names: `<WALLET_ADDR>`, `<AMOUNT_TON>`, `<RPC_URL>`. (Why: a single, visible pattern reduces copy/paste mistakes.)
-- In programming-language code, placeholders **MAY** use `UPPER_SNAKE` without angle brackets when `< >` would clash with syntax (see [§10.1](#101-general-rules)). (Why: avoids syntax errors while keeping placeholders obvious.)
+- In programming-language code, placeholders **MAY** use `UPPER_SNAKE` without angle brackets when `< >` would clash with syntax (see [§10.1](#10-1-general-rules)). (Why: avoids syntax errors while keeping placeholders obvious.)
 - **MUST NOT** use `{curly}` or `[square]` placeholder syntax in copy-pasteable commands, as they are easy to misread as literal characters. (Why: braces/brackets are often treated as literals by shells and new users.) \[HIGH]
 
 ### 13.6 Banned and preferred terms
@@ -902,7 +902,7 @@ Objective. Ensure content is usable by all readers and easy to localize. (Why: a
 ### 15.3 Localization readiness
 
 - Prefer stable terminology from the term bank ([Appendix B](#b-banned-and-preferred-terms) references) to minimize translation drift. (Why: consistent terms reduce rework and inconsistent translations.)
-- Dates/times already follow ISO conventions (see [§14.3](#143-dates-and-times)), which **SHOULD** simplify localization. (Why: ISO formats are unambiguous across locales and require minimal adaptation.)
+- Dates/times already follow ISO conventions (see [§14.3](#14-3-dates-and-times)), which **SHOULD** simplify localization. (Why: ISO formats are unambiguous across locales and require minimal adaptation.)
 
 Rationale: Clear, inclusive writing and accessible assets improve comprehension for global audiences and translation tools.
 
@@ -996,7 +996,7 @@ Objective. Keep repository structure and UI labels consistent. (Why: predictable
 
 - When an index-style page genuinely needs card-like tiles, you **MAY** use `<Card>`; keep the content inside each card minimal and avoid duplicating information from the linked pages. (Why: cards should support navigation, not introduce a second layer of prose.)
 
-- More generally, follow the “minimal styling” workflow from [§6.2](#62-quotation-marks-and-emphasis): components such as `<Card>`, `<Aside>`, `<Image>`, or tab containers **SHOULD** appear only when they improve comprehension or navigation, not as decoration. (Why: reduced decorative chrome makes structure and behavior stand out.)
+- More generally, follow the “minimal styling” workflow from [§6.2](#6-2-quotation-marks-and-emphasis): components such as `<Card>`, `<Aside>`, `<Image>`, or tab containers **SHOULD** appear only when they improve comprehension or navigation, not as decoration. (Why: reduced decorative chrome makes structure and behavior stand out.)
 
 ## 17. Content hygiene and timeless writing
 
diff --git a/docs.json b/docs.json
index 933626229..1799c27b3 100644
--- a/docs.json
+++ b/docs.json
@@ -1848,12 +1848,12 @@
     },
     {
       "source": "/v3/guidelines/smart-contracts/howto/nominator-pool",
-      "destination": "/ecosystem/nodes/cpp/mytonctrl/pools",
+      "destination": "/ecosystem/staking/nominator-pools",
       "permanent": true
     },
     {
       "source": "/v3/guidelines/smart-contracts/howto/single-nominator-pool",
-      "destination": "/ecosystem/nodes/cpp/mytonctrl/pools",
+      "destination": "/ecosystem/staking/single-nominator",
       "permanent": true
     },
     {
@@ -2138,12 +2138,12 @@
     },
     {
       "source": "/v3/guidelines/nodes/running-nodes/liteserver-node",
-      "destination": "/ecosystem/nodes/overview",
+      "destination": "/ecosystem/nodes/cpp/run-archive-liteserver",
       "permanent": true
     },
     {
       "source": "/v3/guidelines/nodes/running-nodes/validator-node",
-      "destination": "/ecosystem/nodes/overview",
+      "destination": "/ecosystem/nodes/cpp/run-validator",
       "permanent": true
     },
     {
diff --git a/ecosystem/api/toncenter/streaming/reference.mdx b/ecosystem/api/toncenter/streaming/reference.mdx
index 61a09295b..80f11e5e3 100644
--- a/ecosystem/api/toncenter/streaming/reference.mdx
+++ b/ecosystem/api/toncenter/streaming/reference.mdx
@@ -55,7 +55,7 @@ Trace is determined by its `trace_external_hash_norm`.
 Subscriptions that include `"actions"` can receive multiple notifications for the same trace as finality increases.
 
 <Aside type="note">
-  Unlike [traces](#traces) and [transactions](#transactions), actions do not exist on-chain and in blockchain history. Instead, actions are aggregated based on the internal logic of TON Center's [API v3](/ecosystem/api/toncenter/v3/overview).
+  Unlike [traces](#trace) and [transactions](#transactions), actions do not exist on-chain and in blockchain history. Instead, actions are aggregated based on the internal logic of TON Center's [API v3](/ecosystem/api/toncenter/v3/overview).
 </Aside>
 
 Trace is determined by its `trace_external_hash_norm`.
diff --git a/ecosystem/api/toncenter/v2.json b/ecosystem/api/toncenter/v2.json
index 231e6d24a..ff192ac25 100644
--- a/ecosystem/api/toncenter/v2.json
+++ b/ecosystem/api/toncenter/v2.json
@@ -3965,7 +3965,7 @@
           "id": {
             "type": "integer",
             "format": "int32",
-            "description": "A 32-bit integer identifying the extra currency. Currency IDs are defined at the blockchain configuration level and stored in `ConfigParam 7` of the masterchain. Refer to the [extra currency minting documentation](https://docs.ton.org/v3/documentation/infra/minter-flow) for details."
+            "description": "A 32-bit integer identifying the extra currency. Currency IDs are defined at the blockchain configuration level and stored in `ConfigParam 7` of the masterchain. Refer to the [extra currency minting documentation](https://old-docs.ton.org/v3/documentation/network/config-params/extra-currency) for details."
           },
           "amount": {
             "$ref": "#/components/schemas/Int256",
diff --git a/ecosystem/nodes/cpp/mytonctrl/overview.mdx b/ecosystem/nodes/cpp/mytonctrl/overview.mdx
index 329b5ba88..45d001585 100644
--- a/ecosystem/nodes/cpp/mytonctrl/overview.mdx
+++ b/ecosystem/nodes/cpp/mytonctrl/overview.mdx
@@ -75,6 +75,5 @@ Set these variables before running `install.sh` (for example, `ARCHIVE_TTL=86400
 
 ## Related resources
 
-- [Setup MyTonCtrl](/ecosystem/nodes/cpp/setup-mytonctrl)
-- [Baseline install & sync checklist](/ecosystem/nodes/cpp/setup-mytonctrl#baseline-setup-install-and-sync)
-- [Official MyTonCtrl repository](https://github.com/ton-blockchain/mytonctrl)
+- [Set up MyTonCtrl](/ecosystem/nodes/cpp/setup-mytonctrl)
+- [MyTonCtrl repository on GitHub](https://github.com/ton-blockchain/mytonctrl)
diff --git a/ecosystem/nodes/cpp/run-validator.mdx b/ecosystem/nodes/cpp/run-validator.mdx
index 05416b770..18e2e8cd3 100644
--- a/ecosystem/nodes/cpp/run-validator.mdx
+++ b/ecosystem/nodes/cpp/run-validator.mdx
@@ -21,7 +21,7 @@ This guide explains how to run a validator TON node with MyTonCtrl from scratch.
 ### 1.1 Maintain costs and expenses
 
 - 200 TON per month on the validator hot wallet for its operational transactions.
-- Validator deposit stake [1 400 000 TON \~ 4 000 000 TON](/ecosystem/nodes/cpp/run-validator#step-4-set-optimal-stake-for-validator) to cover both validation rounds.
+- Validator deposit stake [1 400 000 TON \~ 4 000 000 TON](#step-4-set-optimal-stake-for-validator) to cover both validation rounds.
 - 100 TB/month traffic at a peak load.
 
 ### 1.2 Minimal hardware requirements
@@ -91,7 +91,7 @@ Configure the network on the server according to the following:
 
 - All outgoing connections are allowed.
 - A static external IP address.
-- [One UDP port open for incoming connections.](/ecosystem/nodes/cpp/run-validator#2-4-verify-validator’s-port)
+- [One UDP port open for incoming connections.](#2-4-verify-validators-port)
 
 ### 1.5 Follow network announcements
 
@@ -175,7 +175,7 @@ sudo apt install -y speedtest-cli
 speedtest-cli
 ```
 
-Ensure download and upload speeds meet the [1 Gbit/s requirement](/ecosystem/nodes/cpp/run-validator#1-2-minimal-hardware-requirements).
+Ensure download and upload speeds meet the [1 Gbit/s requirement](#1-2-minimal-hardware-requirements).
 
 ### 1.8 Harden server security
 
@@ -226,7 +226,7 @@ sudo systemctl restart sshd
 
 #### Firewall configuration
 
-Enable the firewall and allow only the SSH port. The validator UDP port is added after installation in [step 2.5](/ecosystem/nodes/cpp/run-validator#2-5-check-validator's-port).
+Enable the firewall and allow only the SSH port. The validator UDP port is added after installation in [step 2.5](#2-5-check-validator's-port).
 
 ```bash
 sudo ufw allow <SSH_PORT>/tcp
@@ -252,7 +252,7 @@ sudo ufw status
 
 #### Encrypt sensitive directories (optional)
 
-For additional protection, store validator keys and configuration on an encrypted partition. Create an encrypted volume and symlink the [backup directories](/ecosystem/nodes/cpp/run-validator#5-5-organize-validator-backup) from it.
+For additional protection, store validator keys and configuration on an encrypted partition. Create an encrypted volume and symlink the [backup directories](#5-5-organize-validator-backup) from it.
 
 <Aside type="tip">
   After moving directories to the encrypted partition, create symlinks in their original locations so that MyTonCtrl and the validator service continue to function without path changes.
@@ -632,7 +632,7 @@ Test deposit to stake workflow. Any user can deposit to the pool via a standard
 
 ### 3.11 Test withdrawal from pool
 
-Test withdrawal workflow. Only the [owner's cold wallet](/ecosystem/nodes/cpp/run-validator#3-6-create-a-pool) can request a withdrawal.
+Test withdrawal workflow. Only the [owner's cold wallet](#3-6-create-a-pool) can request a withdrawal.
 Send a withdrawal request, a message with `w` comment from `owner` wallet to the single nominator pool address:
 
 <Image
@@ -828,7 +828,7 @@ Before sending funds to the pool:
 
 - Verify that the pool address is correct and uses the **bounceable** format.
 - Confirm that the pool smart contract is still active and not frozen. A pool can become frozen if the entire balance is consumed by storage fees between creation and funding.
-- Follow the [test deposit and withdrawal procedure](/ecosystem/nodes/cpp/run-validator#3-10-test-deposit-to-pool) before depositing the full stake.
+- Follow the [test deposit and withdrawal procedure](#3-10-test-deposit-to-pool) before depositing the full stake.
 
 <Aside type="tip">
   By default, MyTonCtrl splits the pool balance 50/50 between odd and even validation cycles. Ensure the total stake is sufficient to participate in both cycles: `balance > min_stake * 2`.
@@ -844,7 +844,7 @@ MyTonCtrl> mg validator_wallet_001 <POOL_ADDRESS> 5
 
 ### 5.3 Withdraw funds from the pool
 
-Only the owner wallet can withdraw funds. Follow the [test withdrawal procedure](/ecosystem/nodes/cpp/run-validator#3-11-test-withdrawal-from-pool) using the same method.
+Only the owner wallet can withdraw funds. Follow the [test withdrawal procedure](#3-11-test-withdrawal-from-pool) using the same method.
 
 ### 5.4 Follow the TON announcements channel
 
@@ -914,7 +914,7 @@ Set up dashboards to monitor validators using the APIs provided below.
 
 If a validator processes less than 90% of the expected blocks during a validation round, they will be fined 101 TON.
 
-Learn more about the [slashing policy](https://old-docs.ton.org/v3/documentation/nodes/validation/staking-incentives#decentralized-system-of-penalties).
+Learn more about the [slashing policy](/v3/documentation/nodes/validation/staking-incentives#decentralized-system-of-penalties).
 
 ### 5.10 Maintain validator
 
@@ -942,7 +942,7 @@ Check the following indicators:
   Validator efficiency may show 0% at the beginning of a cycle until the validator signs its first blocks. This is normal behavior.
 </Aside>
 
-Confirm that the validator participates in elections and recovers stakes on time by checking the pool balance in a [blockchain explorer](/ecosystem/explorers/overview). For greater observability, [set up the monitoring](/ecosystem/nodes/cpp/run-validator#5-7-set-up-monitoring) of various validator metrics.
+Confirm that the validator participates in elections and recovers stakes on time by checking the pool balance in a [blockchain explorer](/ecosystem/explorers/overview). For greater observability, [set up the monitoring](#5-7-set-up-monitoring) of various validator metrics.
 
 ## Troubleshoot common issues
 
@@ -950,7 +950,7 @@ Confirm that the validator participates in elections and recovers stakes on time
 
 - Verify that the validator UDP port is open: `sudo ufw status`.
 - Check network connectivity to beacon nodes: `ping beacon-eu-01.toncenter.com -c 6`.
-- Ensure disk IOPS meet minimum requirements. Re-run the [benchmark](/ecosystem/nodes/cpp/run-validator#disk-iops).
+- Ensure disk IOPS meet minimum requirements. Re-run the [benchmark](#disk-iops).
 - Check service logs: `journalctl -u validator -f`.
 
 ### Validator efficiency is below 90%
@@ -958,7 +958,7 @@ Confirm that the validator participates in elections and recovers stakes on time
 - Confirm the node is fully synchronized (`Local validator out of sync` ≤ 3 seconds).
 - Check disk performance. Slow storage is the most common cause of low efficiency.
 - Verify that no other resource-intensive processes compete for CPU or RAM.
-- Review hardware against [minimum requirements](/ecosystem/nodes/cpp/run-validator#1-2-minimal-hardware-requirements).
+- Review hardware against [minimum requirements](#1-2-minimal-hardware-requirements).
 
 ### Pool is not participating in elections
 
diff --git a/ecosystem/subsecond.mdx b/ecosystem/subsecond.mdx
index 989776426..388cd5a9d 100644
--- a/ecosystem/subsecond.mdx
+++ b/ecosystem/subsecond.mdx
@@ -264,7 +264,7 @@ Use the [public API endpoints overview](/ecosystem/api/overview) for testnet end
 
 ### How to get test tokens
 
-- For the standard faucet, up to 2 TON per hour, [use Telegram Testgiver TON bot](/ecosystem/wallet-apps/get-coins#how-to-get-coins-on-testnet).
+- For the standard faucet, up to 2 TON per hour, [use Telegram Testgiver TON bot](/ecosystem/wallet-apps/get-coins#use-testgiver-ton-bot).
 - For larger allocations up to 5,000 TON, [use the request form](/ecosystem/wallet-apps/get-coins#use-request-form).
 
 ### What to test
diff --git a/ecosystem/walletkit/web/toncoin.mdx b/ecosystem/walletkit/web/toncoin.mdx
index 6bafbe00f..373146b05 100644
--- a/ecosystem/walletkit/web/toncoin.mdx
+++ b/ecosystem/walletkit/web/toncoin.mdx
@@ -9,7 +9,7 @@ import { Aside } from '/snippets/aside.jsx';
   [Initialize the WalletKit](/ecosystem/walletkit/web/init), [set up at least one TON wallet](/ecosystem/walletkit/web/wallets), handle [connection requests](/ecosystem/walletkit/web/connections) and [transaction requests](/ecosystem/walletkit/web/events) before using examples on this page.
 </Aside>
 
-To work with Toncoin, the wallet service needs to handle [contract balances](#balances) and perform transfers initiated [from dApps](#transfers-from-dapps) and [from within the wallet service itself](#transfers-from-the-wallet-service).
+To work with Toncoin, the wallet service needs to handle [contract balances](#balances) and perform transfers initiated [from dApps](#transfers-from-dapps) and [from the wallet service itself](#transfers-in-the-wallet-service).
 
 ## Balances
 
diff --git a/foundations/actions/change-library.mdx b/foundations/actions/change-library.mdx
index 0edd0ef40..01fac2f51 100644
--- a/foundations/actions/change-library.mdx
+++ b/foundations/actions/change-library.mdx
@@ -6,7 +6,7 @@ Change a library is one of the actions that a smart contract can perform during
 
 - The [`SETLIBCODE`](/tvm/instructions#fb06-setlibcode) instruction.
 - The [`CHANGELIB`](/tvm/instructions#fb07-changelib) instruction.
-- The [`POPCTR`](/tvm/instructions#ed5-popctr) instruction.
+- The [`POPCTR`](/tvm/instructions#ed5i-popctr) instruction.
 
 The change library action consists of
 
diff --git a/foundations/actions/send.mdx b/foundations/actions/send.mdx
index f9aeb1351..f5b3c9a82 100644
--- a/foundations/actions/send.mdx
+++ b/foundations/actions/send.mdx
@@ -4,9 +4,9 @@ title: "Send message"
 
 Sending a message is the most frequent action that a smart contract performs during the [action phase](/foundations/phases#action-phase). It can get into the [out action list](https://github.com/ton-blockchain/ton/blob/5c0349110bb03dd3a241689f2ab334ae1a554ffb/crypto/block/block.tlb#L411) by:
 
-- The [`SENDRAWMSG`](/tvm/instructions#fb00-sendrawms) instruction.
+- The [`SENDRAWMSG`](/tvm/instructions#fb00-sendrawmsg) instruction.
 - The [`SENDMSG`](/tvm/instructions#fb08-sendmsg) instruction.
-- The [`POPCTR`](/tvm/instructions#ed5-popctr) instruction.
+- The [`POPCTR`](/tvm/instructions#ed5i-popctr) instruction.
 
 The sending message action consists of:
 
@@ -39,7 +39,7 @@ If after the second attempt the message is still too large, the exception is thr
 ## Serialization
 
 ```tlb
-action_send_msg#0ec3c86d mode:(## 8) 
+action_send_msg#0ec3c86d mode:(## 8)
     out_msg:^(MessageRelaxed Any) = OutAction;
 
 out_list_node$_ prev:^Cell action:OutAction = OutListNode;
@@ -49,10 +49,10 @@ message$_ {X:Type} info:CommonMsgInfoRelaxed
     body:(Either X ^X) = MessageRelaxed X;
 
 int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool
-    src:MsgAddress dest:MsgAddressInt 
+    src:MsgAddress dest:MsgAddressInt
     value:CurrencyCollection extra_flags:(VarUInteger 16) fwd_fee:Grams
     created_lt:uint64 created_at:uint32 = CommonMsgInfoRelaxed;
 
 ext_out_msg_info$11 src:MsgAddress dest:MsgAddressExt
-    created_lt:uint64 created_at:uint32 = CommonMsgInfoRelaxed;    
+    created_lt:uint64 created_at:uint32 = CommonMsgInfoRelaxed;
 ```
diff --git a/foundations/actions/set-code.mdx b/foundations/actions/set-code.mdx
index 361e2edd5..c7c358c47 100644
--- a/foundations/actions/set-code.mdx
+++ b/foundations/actions/set-code.mdx
@@ -5,7 +5,7 @@ title: "Set code"
 Setting a code is one of the actions that a smart contract can perform during the [action phase](/foundations/phases#action-phase). It can get into the [out action list](https://github.com/ton-blockchain/ton/blob/5c0349110bb03dd3a241689f2ab334ae1a554ffb/crypto/block/block.tlb#L411) by:
 
 - The [`SETCODE`](/tvm/instructions#fb04-setcode) instruction.
-- The [`POPCTR`](/tvm/instructions#ed5-popctr) instruction.
+- The [`POPCTR`](/tvm/instructions#ed5i-popctr) instruction.
 
 The set code action consists of a cell containing the new code of a smart contract.
 
diff --git a/foundations/addresses/derive.mdx b/foundations/addresses/derive.mdx
index 015bc5653..83d4aab66 100644
--- a/foundations/addresses/derive.mdx
+++ b/foundations/addresses/derive.mdx
@@ -61,7 +61,7 @@ The `calculateAddress` function uses the [`AutoDeployAddress`](/languages/tolk/f
 
 ### On-chain — contract sharding
 
-When working with the [contract sharding](/contract-dev/contract-sharding) pattern, child contracts usually have a `StateInit` that depends on the parent. In the example below, the dependence is implemented by adding the parent address to the child `StateInit`. The same logic from the [simple on-chain](#on-chain-simple) case works here, and only `getData` has to be changed.
+When working with the [contract sharding](/contract-dev/contract-sharding) pattern, child contracts usually have a `StateInit` that depends on the parent. In the example below, the dependence is implemented by adding the parent address to the child `StateInit`. The same logic from the [simple on-chain](#on-chain-—-simple) case works here, and only `getData` has to be changed.
 
 ```tolk title="Tolk" expandable
 // Compose an address builder using the AutoDeployAddress built-in.
@@ -125,9 +125,9 @@ fun main() {
 
 The `toShard` field in `AutoDeployAddress` allows smart contracts to have a specific prefix in the address for the purpose of deploying it to a certain shardchain. This can be useful for cross-contract latency optimization, as in [Jetton 2.0](/standard/tokens/jettons/comparison).
 
-This may seem similar to the [vanity](#on-chain-vanity) case, but it serves a different purpose. A vanity generator finds such a `StateInit` that an address composed from its hash will have certain letters in a prefix or suffix. The `toShard` does not alter the whole address and only tells the blockchain to replace the first few bits of the address to which the contract is being deployed. This optimization is used in [Jetton 2.0](/standard/tokens/jettons/comparison).
+This may seem similar to the [vanity](#on-chain-—-vanity) case, but it serves a different purpose. A vanity generator finds such a `StateInit` that an address composed from its hash will have certain letters in a prefix or suffix. The `toShard` does not alter the whole address and only tells the blockchain to replace the first few bits of the address to which the contract is being deployed. This optimization is used in [Jetton 2.0](/standard/tokens/jettons/comparison).
 
-The logic here is more similar to the [simple](#on-chain-simple) case. The only difference is the additional `toShard` field.
+The logic here is more similar to the [simple](#on-chain-—-simple) case. The only difference is the additional `toShard` field.
 
 ```tolk title="Tolk" expandable
 // Compose an address builder using the AutoDeployAddress built-in.
@@ -190,7 +190,7 @@ fun main() {
 
 ### Off-chain — simple
 
-The logic mirrors the [on-chain](#on-chain-simple) example. The `@ton/core` library has the `contractAddress` function that handles `StateInit` hash calculation and composes the address.
+The logic mirrors the [on-chain](#on-chain-—-prefixed) example. The `@ton/core` library has the `contractAddress` function that handles `StateInit` hash calculation and composes the address.
 
 ```ts expandable
 import { contractAddress, Cell, beginCell } from "@ton/core";
@@ -218,7 +218,7 @@ console.log(addr); // EQC235M1tplyIg2OUQZQgG8D3BNF6_TZJ1932iaIV26XBVCH
 
 ### Off-chain — contract sharding
 
-The logic mirrors the [on-chain](#on-chain-contract-sharding) example. The parent address is hardcoded in this example but could just as well be derived on its own.
+The logic mirrors the [on-chain](#on-chain-—-contract-sharding) example. The parent address is hardcoded in this example but could just as well be derived on its own.
 
 ```ts
 import { contractAddress, Cell, beginCell, Address } from "@ton/core";
@@ -250,7 +250,7 @@ console.log(addr);
 
 ### Off-chain — vanity
 
-Similarly to the [on-chain](#on-chain-vanity) case, there is no way to derive the address. Define a constant with the predetermined address obtained in advance.
+Similarly to the [on-chain](#on-chain-—-vanity) case, there is no way to derive the address. Define a constant with the predetermined address obtained in advance.
 
 ```ts
 import { contractAddress, Cell, beginCell, Address } from "@ton/core";
@@ -263,7 +263,7 @@ console.log(addr1);
 
 ### Off-chain — prefixed
 
-The logic mirrors the [on-chain](#on-chain-prefixed) example. Since `@ton/core` does not define helpers for prefixed addresses, the prefix must be replaced manually.
+The logic mirrors the [on-chain](#on-chain-—-simple) example. Since `@ton/core` does not define helpers for prefixed addresses, the prefix must be replaced manually.
 
 ```ts
 import { contractAddress, Cell, beginCell } from "@ton/core";
diff --git a/foundations/config.mdx b/foundations/config.mdx
index 7695fe401..8c1170a82 100644
--- a/foundations/config.mdx
+++ b/foundations/config.mdx
@@ -353,7 +353,7 @@ Note: Param 20 defines gas settings for the masterchain; Param 21 defines gas se
 - `freeze_due_limit` and `delete_due_limit`: Limits of accumulated storage fees (in nanotons) at which a contract is frozen and deleted, respectively.
 
 <Aside>
-  You can find more about `gas_credit` and other parameters in the section of external messages [here](/tvm/instructions#external-messages).
+  You can find more about `gas_credit` and other parameters in the section of external messages [here](/foundations/messages/external-in#accepting-message).
 </Aside>
 
 [Parameter #20 on mainnet](https://tonviewer.com/config#20) | [Parameter #21 on mainnet](https://tonviewer.com/config#21)
diff --git a/foundations/fees.mdx b/foundations/fees.mdx
index 2ce0e6f3a..339fd1142 100644
--- a/foundations/fees.mdx
+++ b/foundations/fees.mdx
@@ -88,15 +88,15 @@ The formula excludes the message root cell because it mainly contains headers. `
 
 ### Action fee
 
-Action fee is the portion of `fwdFee` granted to the validator of the message's source [shard](/foundations/shards#blockchain-sharding). The remaining `fwdFee - actionFee` amount goes to the validator of the destination shard.
+Action fee is the portion of `fwdFee` granted to the validator of the message's source [shard](/foundations/shards). The remaining `fwdFee - actionFee` amount goes to the validator of the destination shard.
 
-Action fee exists only for [internal messages](/foundations/messages/internal#internal-messages).
+Action fee exists only for [internal messages](/foundations/messages/internal).
 
 ```cpp
 action_fee = floor(fwd_fee * first_frac / 2^16)
 ```
 
-Starting with Global Version 4, a failed [SENDMSG action](/foundations/actions/send#send-message) incurs a penalty proportional to the attempted message size. It is calculated as:
+Starting with Global Version 4, a failed [`SENDMSG` action](/foundations/actions/send) incurs a penalty proportional to the attempted message size. It is calculated as:
 
 ```cpp
 fine_per_cell = floor((cell_price >> 16) / 4)
diff --git a/foundations/serialization/boc.mdx b/foundations/serialization/boc.mdx
index 5456780c7..f982cc1bc 100644
--- a/foundations/serialization/boc.mdx
+++ b/foundations/serialization/boc.mdx
@@ -82,7 +82,7 @@ A BoC is called _complete_ if it does not contain any external references. Most
 <Aside type="note">
   This paragraphs provide a textual description of the BoC serialization process. The specific implementation of the serialization and TL-B schemes is left to the choice of developers.
 
-  For a specific example of TL-B schema and pseudocode of related cell serialization, see [TL-B schema](/foundations/serialization/boc#tl-b-schema).
+  For a specific example of TL-B schema and pseudocode of related cell serialization, see [TL-B schema](#serialization).
 </Aside>
 
 The serialization process of a BoC `B` consisting of `n` cells can be outlined as follows.
@@ -111,11 +111,11 @@ A final serialization of the bag of cells must include a magic number indicating
 Only one [serialization scheme of BoCs](https://github.com/ton-blockchain/ton/blob/24dc184a2ea67f9c47042b4104bbb4d82289fac1/crypto/tl/boc.tlb#L25) is used in TON Blockchain (there are also two outdated BoC serialization schemes in the file):
 
 ```tlb PseudoTL-B
-serialized_boc#b5ee9c72 has_idx:(## 1) has_crc32c:(## 1) 
+serialized_boc#b5ee9c72 has_idx:(## 1) has_crc32c:(## 1)
     has_cache_bits:(## 1) flags:(## 2) { flags = 0 }
     size:(## 3) { size <= 4 }
-    off_bytes:(## 8) { off_bytes <= 8 } 
-    cells:(##(size * 8)) 
+    off_bytes:(## 8) { off_bytes <= 8 }
+    cells:(##(size * 8))
     roots:(##(size * 8)) { roots >= 1 }
     absent:(##(size * 8)) { roots + absent <= cells }
     tot_cells_size:(##(off_bytes * 8))
diff --git a/foundations/whitepapers/comments.mdx b/foundations/whitepapers/comments.mdx
index 8a8cc8423..123a2c4c0 100644
--- a/foundations/whitepapers/comments.mdx
+++ b/foundations/whitepapers/comments.mdx
@@ -9,7 +9,7 @@ Descriptions in the original [whitepapers](/foundations/whitepapers/overview) ar
 
 ### 1.3.2. List of control registers
 
-The zero element of the `c7` tuple is an environment information (which itself is also a tuple). The remaining 255 slots are used for global variables. [`[i] SETGLOB`](/tvm/instructions#f87_-setglob) modifies `c7`, inserting an element with index `i`, [`[i] GETGLOB`](/tvm/instructions#f85_-getglob) reads `i`-th element from `c7`.
+The zero element of the `c7` tuple is an environment information (which itself is also a tuple). The remaining 255 slots are used for global variables. [`[i] SETGLOB`](/tvm/instructions#f87_k-setglob) modifies `c7`, inserting an element with index `i`, [`[i] GETGLOB`](/tvm/instructions#f85_k-getglob) reads `i`-th element from `c7`.
 
 See the [TVM registers](/tvm/registers#c7-%E2%80%94-environment-information-and-global-variables) page for details.
 
diff --git a/foundations/whitepapers/tvm.mdx b/foundations/whitepapers/tvm.mdx
index 2faf1379c..bb1abc01e 100644
--- a/foundations/whitepapers/tvm.mdx
+++ b/foundations/whitepapers/tvm.mdx
@@ -599,14 +599,14 @@ The serialization of a hashmap into a tree of cells (or, more generally, into a
 ```
 bit#_ _:(## 1) = Bit;
 
-hm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n) 
+hm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n)
           {n = (~m) + l} node:(HashmapNode m X) = Hashmap n X;
 
 hmn_leaf#_ {X:Type} value:X = HashmapNode 0 X;
-hmn_fork#_ {n:#} {X:Type} left:^(Hashmap n X) 
+hmn_fork#_ {n:#} {X:Type} left:^(Hashmap n X)
            right:^(Hashmap n X) = HashmapNode (n + 1) X;
 
-hml_short$0 {m:#} {n:#} len:(Unary ~n) 
+hml_short$0 {m:#} {n:#} len:(Unary ~n)
             s:(n * Bit) = HmLabel ~n m;
 hml_long$10 {m:#} n:(#<= m) s:(n * Bit) = HmLabel ~n m;
 hml_same$11 {m:#} v:Bit n:(#<= m) = HmLabel ~n m;
@@ -688,15 +688,15 @@ The corresponding Patricia tree consists of a root $A$, two intermediate nodes $
 The corresponding value of type $\texttt{HashmapE}$ 16 ($\texttt{\#\#}$ 16) may be written in human-readable form as:
 
 ```
-(hme_root$1 
-  root:^(hm_edge label:(hml_same$11 v:0 n:8) node:(hm_fork 
-    left:^(hm_edge label:(hml_short$0 len:$110 s:$00) 
+(hme_root$1
+  root:^(hm_edge label:(hml_same$11 v:0 n:8) node:(hm_fork
+    left:^(hm_edge label:(hml_short$0 len:$110 s:$00)
       node:(hm_fork
-        left:^(hm_edge label:(hml_long$10 n:4 s:$1101) 
+        left:^(hm_edge label:(hml_long$10 n:4 s:$1101)
           node:(hm_leaf value:169))
-        right:^(hm_edge label:(hml_long$10 n:4 s:$0001) 
+        right:^(hm_edge label:(hml_long$10 n:4 s:$0001)
           node:(hm_leaf value:289))))
-    right:^(hm_edge label:(hml_long$10 n:7 s:$1101111) 
+    right:^(hm_edge label:(hml_long$10 n:7 s:$1101111)
       node:(hm_leaf value:57121)))))
 ```
 
@@ -704,7 +704,7 @@ The serialization of this data structure into a tree of cells consists of six ce
 
 ```
 A := 1
-A.0 := 11 0 01000 
+A.0 := 11 0 01000
 A.0.0 := 0 110 00
 A.0.0.0 := 10 100 1101 0000000010101001
 A.0.0.1 := 10 100 0001 0000000100100001
@@ -807,21 +807,21 @@ TVM provides some support for [dictionaries, or hashmaps](#3-3-hashmaps%2C-or-di
 The [serialization](#3-3-3-serialization-of-hashmaps) of a *VarHashmap* into a tree of cells (or, more generally, into a *Slice*) is defined by a TL-B scheme:
 
 ```
-vhm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n) 
-           {n = (~m) + l} node:(VarHashmapNode m X) 
+vhm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n)
+           {n = (~m) + l} node:(VarHashmapNode m X)
            = VarHashmap n X;
 vhmn_leaf$00 {n:#} {X:Type} value:X = VarHashmapNode n X;
-vhmn_fork$01 {n:#} {X:Type} left:^(VarHashmap n X) 
-             right:^(VarHashmap n X) value:(Maybe X) 
+vhmn_fork$01 {n:#} {X:Type} left:^(VarHashmap n X)
+             right:^(VarHashmap n X) value:(Maybe X)
              = VarHashmapNode (n + 1) X;
-vhmn_cont$1 {n:#} {X:Type} branch:bit child:^(VarHashmap n X) 
+vhmn_cont$1 {n:#} {X:Type} branch:bit child:^(VarHashmap n X)
             value:X = VarHashmapNode (n + 1) X;
 
 nothing$0 {X:Type} = Maybe X;
 just$1 {X:Type} value:X = Maybe X;
 
 vhme_empty$0 {n:#} {X:Type} = VarHashmapE n X;
-vhme_root$1 {n:#} {X:Type} root:^(VarHashmap n X) 
+vhme_root$1 {n:#} {X:Type} root:^(VarHashmap n X)
             = VarHashmapE n X;
 ```
 
@@ -832,16 +832,16 @@ One special case of a dictionary with variable-length keys is that of a *prefix
 The serialization of a prefix code is defined by the following TL-B scheme:
 
 ```
-phm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n) 
-           {n = (~m) + l} node:(PfxHashmapNode m X) 
+phm_edge#_ {n:#} {X:Type} {l:#} {m:#} label:(HmLabel ~l n)
+           {n = (~m) + l} node:(PfxHashmapNode m X)
            = PfxHashmap n X;
 
 phmn_leaf$0 {n:#} {X:Type} value:X = PfxHashmapNode n X;
-phmn_fork$1 {n:#} {X:Type} left:^(PfxHashmap n X) 
+phmn_fork$1 {n:#} {X:Type} left:^(PfxHashmap n X)
             right:^(PfxHashmap n X) = PfxHashmapNode (n + 1) X;
 
 phme_empty$0 {n:#} {X:Type} = PfxHashmapE n X;
-phme_root$1 {n:#} {X:Type} root:^(PfxHashmap n X) 
+phme_root$1 {n:#} {X:Type} root:^(PfxHashmap n X)
             = PfxHashmapE n X;
 ```
 
@@ -918,7 +918,7 @@ Consider the $\texttt{CALLX}$ or $\texttt{EXECUTE}$ primitive, which takes a con
 
 Apart from doing the stack manipulations described in [4.1.6](#4-1-6-switching-to-another-continuation:-and) and [4.1.7](#4-1-7-determining-the-number-of-arguments-passed-to-the-next-continuation) and setting the new [control registers](#4-1-8-restoring-control-registers-from-the-new-continuation), these primitives perform several additional steps:
 
-1. After the top $n''$ values are [removed](#4-1-7-determining-the-number-of-arguments-passed-to-the-next-continuation) from the current stack, the (usually empty) remainder is not discarded, but instead is stored in the (old) current continuation $\texttt{cc}$.  
+1. After the top $n''$ values are [removed](#4-1-7-determining-the-number-of-arguments-passed-to-the-next-continuation) from the current stack, the (usually empty) remainder is not discarded, but instead is stored in the (old) current continuation $\texttt{cc}$.
 
 2. The old value of the special register $\texttt{c0}$ is saved into the (previously empty) savelist $\texttt{cc.save}$.
 
@@ -2340,19 +2340,19 @@ The "global variables" may be helpful in implementing some high-level smart-cont
 The message and address manipulation primitives listed below serialize and deserialize values according to the following [TL-B scheme](#3-3-4-brief-explanation-of-tl-b-schemes):
 ```
 addr_none$00 = MsgAddressExt;
-addr_extern$01 len:(## 9) external_address:(bits len) 
+addr_extern$01 len:(## 9) external_address:(bits len)
              = MsgAddressExt;
 anycast_info$_ depth:(#<= 30) { depth >= 1 }
    rewrite_pfx:(bits depth) = Anycast;
-addr_std$10 anycast:(Maybe Anycast) 
+addr_std$10 anycast:(Maybe Anycast)
    workchain_id:int8 address:bits256  = MsgAddressInt;
-addr_var$11 anycast:(Maybe Anycast) addr_len:(## 9) 
+addr_var$11 anycast:(Maybe Anycast) addr_len:(## 9)
    workchain_id:int32 address:(bits addr_len) = MsgAddressInt;
 _ _:MsgAddressInt = MsgAddress;
 _ _:MsgAddressExt = MsgAddress;
 
 int_msg_info$0 ihr_disabled:Bool bounce:Bool bounced:Bool
-  src:MsgAddress dest:MsgAddressInt 
+  src:MsgAddress dest:MsgAddressInt
   value:CurrencyCollection ihr_fee:Grams fwd_fee:Grams
   created_lt:uint64 created_at:uint32 = CommonMsgInfoRelaxed;
 ext_out_msg_info$11 src:MsgAddress dest:MsgAddressExt
@@ -2447,9 +2447,9 @@ vm_stk_tinyint#01 value:int64 = VmStackValue;
 vm_stk_int#0201_ value:int257 = VmStackValue;
 vm_stk_nan#02FF = VmStackValue;
 vm_stk_cell#03 cell:^Cell = VmStackValue;
-_ cell:^Cell st_bits:(## 10) end_bits:(## 10) 
-  { st_bits <= end_bits } 
-  st_ref:(#<= 4) end_ref:(#<= 4) 
+_ cell:^Cell st_bits:(## 10) end_bits:(## 10)
+  { st_bits <= end_bits }
+  st_ref:(#<= 4) end_ref:(#<= 4)
   { st_ref <= end_ref } = VmCellSlice;
 vm_stk_slice#04 _:VmCellSlice  = VmStackValue;
 vm_stk_builder#05 cell:^Cell = VmStackValue;
@@ -2464,7 +2464,7 @@ The TVM stack can be serialized as follows:
 
 ```
 vm_stack#_ depth:(## 24) stack:(VmStackList depth) = VmStack;
-vm_stk_cons#_ {n:#} head:VmStackValue tail:^(VmStackList n) 
+vm_stk_cons#_ {n:#} head:VmStackValue tail:^(VmStackList n)
   = VmStackList (n + 1);
 vm_stk_nil#_ = VmStackList 0;
 ```
@@ -2482,7 +2482,7 @@ _ cregs:(HashmapE 4 VmStackValue) = VmSaveList;
 Gas limits in TVM can be serialized as follows:
 
 ```
-gas_limits#_ remaining:int64 _:^[ 
+gas_limits#_ remaining:int64 _:^[
   max_limit:int64 cur_limit:int64 credit:int64 ]
   = VmGasLimits;
 ```
@@ -2502,13 +2502,13 @@ Continuations in TVM can be serialized as follows:
 ```
 vmc_std$00 nargs:(## 22) stack:(Maybe VmStack) save:VmSaveList
    cp:int16 code:VmCellSlice = VmCont;
-vmc_envelope$01 nargs:(## 22) stack:(Maybe VmStack) 
+vmc_envelope$01 nargs:(## 22) stack:(Maybe VmStack)
    save:VmSaveList next:^VmCont = VmCont;
 vmc_quit$1000 exit_code:int32 = VmCont;
 vmc_quit_exc$1001 = VmCont;
 vmc_until$1010 body:^VmCont after:^VmCont = VmCont;
 vmc_again$1011 body:^VmCont = VmCont;
-vmc_while_cond$1100 cond:^VmCont body:^VmCont 
+vmc_while_cond$1100 cond:^VmCont body:^VmCont
    after:^VmCont = VmCont;
 vmc_while_body$1101 cond:^VmCont body:^VmCont
    after:^VmCont = VmCont;
@@ -2520,17 +2520,17 @@ vmc_pushint$1111 value:int32 next:^VmCont = VmCont;
 The total state of TVM can be serialized as follows:
 
 ```
-vms_init$00 cp:int16 step:int32 gas:GasLimits 
+vms_init$00 cp:int16 step:int32 gas:GasLimits
   stack:(Maybe VmStack) save:VmSaveList code:VmCellSlice
   lib:VmLibraries = VmState;
-vms_exception$01 cp:int16 step:int32 gas:GasLimits 
-  exc_no:int32 exc_arg:VmStackValue 
+vms_exception$01 cp:int16 step:int32 gas:GasLimits
+  exc_no:int32 exc_arg:VmStackValue
   save:VmSaveList lib:VmLibraries = VmState;
 vms_running$10 cp:int16 step:int32 gas:GasLimits stack:VmStack
   save:VmSaveList code:VmCellSlice lib:VmLibraries
   = VmState;
-vms_finished$11 cp:int16 step:int32 gas:GasLimits 
-  exit_code:int32 no_gas:Boolean stack:VmStack 
+vms_finished$11 cp:int16 step:int32 gas:GasLimits
+  exit_code:int32 no_gas:Boolean stack:VmStack
   save:VmSaveList lib:VmLibraries = VmState;
 ```
 
@@ -2569,7 +2569,7 @@ The TON Blockchain adopts this approach to validate the runs of TVM (e.g., those
 ### B.2.7. Codepage $-2$
 
 This bootstrapping process could be iterated even further, by providing an emulator of the stripped-down version of TVM written for an even simpler version of TVM that supports only boolean values (or integers 0 and 1)—a "codepage $-2$". All 64-bit arithmetic used in codepage $-1$ would then need to be defined by means of boolean operations, thus providing a reference implementation for the stripped-down version of TVM used in codepage $-1$. In this way, if some of the TON Blockchain validators did not agree on the results of their 64-bit arithmetic, they could regress to this reference implementation to find the correct answer.<a id="ref-fn30"></a><sup>[30](#fn30)</sup>
- 
+
 ---
 
 
@@ -2728,7 +2728,7 @@ We have used 29 operations; assuming one-byte encodings for all stack operations
 Notice as well that we have implicitly used the commutativity of multiplication in this code, computing $de-bf$ instead of $ed-bf$ as specified in high-level language source code. If we were not allowed to do so, an extra $\texttt{XCHG s1}$ would need to be inserted before the third $\texttt{IMUL}$, increasing the total size of the code by one operation and one byte.
 
 The code presented above might have been produced by a rather unsophisticated compiler that simply computed all expressions and subexpressions in the order they appear, then rearranged the arguments near the [top of the stack](#2-2-2-basic-stack-manipulation-primitives-suffice) before each operation. The only "manual" optimization done here involves computing $ec$ before $af$; one can check that the other order would lead to slightly shorter code of 28 operations and bytes (or 29, if we are not allowed to use the commutativity of multiplication), but the $\texttt{ROT}$ optimization would not be applicable.
- 
+
 ### C.1.6. Stack machine with compound stack primitives
 
 A stack machine with [compound stack](#2-2-3-compound-stack-manipulation-primitives) primitives would not significantly improve code density of the code presented above, at least in terms of bytes used. The only difference is that, if we were not allowed to use commutativity of multiplication, the extra $\texttt{XCHG s1}$ inserted before the third $\texttt{IMUL}$ might be combined with two previous operations $\texttt{XCHG s3}$, $\texttt{PUSH s2}$ into one compound operation $\texttt{PUXC s2,s3}$; we provide the resulting code below. To make this less redundant, we show a version of the code that computes subexpression $af$ before $ec$ as specified in the original source file. We see that this replaces six operations (starting from line 15) with five other operations, and disables the $\texttt{ROT}$ optimization:
@@ -3353,7 +3353,7 @@ By contrast, the heavily optimized (with respect to size) code for register mach
 
 <span id="fn25">**25**</span> This is not exactly true. A more precise statement is that usually the codepage of the newly-created continuation is a known function of the current codepage. [Back ↑](#ref-fn25)
 
-<span id="fn26">**26**</span> This is another important mechanism of backward compatibility. All values of newly-added types, as well as values belonging to extended original types that do not belong to the original types (e.g., 513-bit integers that do not fit into 257 bits in the example above), are treated by all instructions (except stack manipulation instructions, which are naturally polymorphic, [Polymorphism of stack manipulation primitives](#2-3-3-polymorphism-of-stack-manipulation-primitives)) in the old codepages as "values of incorrect type", and generate type-checking exceptions accordingly. [Back ↑](#ref-fn26)
+<span id="fn26">**26**</span> This is another important mechanism of backward compatibility. All values of newly-added types, as well as values belonging to extended original types that do not belong to the original types (e.g., 513-bit integers that do not fit into 257 bits in the example above), are treated by all instructions (except stack manipulation instructions, which are [naturally polymorphic](#2-2-6-stack-manipulation-instructions-are-polymorphic)) in the old codepages as "values of incorrect type", and generate type-checking exceptions accordingly. [Back ↑](#ref-fn26)
 
 <span id="fn27">**27**</span> If the cell dumps are hexadecimal, encodings consisting of an integral number of hexadecimal digits (i.e., having length divisible by four bits) might be equally convenient. [Back ↑](#ref-fn27)
 
@@ -3365,4 +3365,4 @@ By contrast, the heavily optimized (with respect to size) code for register mach
 
 <span id="fn31">**31**</span> It is interesting to compare this code with that generated by optimizing C compilers for the x86-64 architecture. First of all, the integer division operation for x86-64 uses the one-address form, with the (double-length) dividend to be supplied in accumulator pair `r2:r0`. The quotient is also returned in `r0`. As a consequence, two single-to-double extension operations (`CDQ` or `CQO`) and at least one move operation need to be added. Secondly, the encoding used for arithmetic and move operations is less optimistic than in our example above, requiring about three bytes per operation on average. As a result, we obtain a total of 43 bytes for 32-bit integers, and 68 bytes for 64-bit integers. [Back ↑](#ref-fn31)
 
-<span id="fn32">**32**</span> Code produced for this function by an optimizing compiler for x86-64 architecture with size-optimization enabled actually occupied 150 bytes, due mostly to the fact that actual instruction encodings are about twice as long as we had optimistically assumed. [Back ↑](#ref-fn32)
\ No newline at end of file
+<span id="fn32">**32**</span> Code produced for this function by an optimizing compiler for x86-64 architecture with size-optimization enabled actually occupied 150 bytes, due mostly to the fact that actual instruction encodings are about twice as long as we had optimistically assumed. [Back ↑](#ref-fn32)
diff --git a/get-support.mdx b/get-support.mdx
index df773a249..f61255749 100644
--- a/get-support.mdx
+++ b/get-support.mdx
@@ -43,8 +43,8 @@ Miscellaneous:
 
 - [TON Security Bug Bounty on GitHub](https://github.com/ton-blockchain/bug-bounty) - description and links to all relevant projects and resources to research vulnerabilities in.
 - [TON Security Bug Bounty bot in Telegram](https://t.me/ton_bugs_bot) - send general blockchain security reports to this Telegram bot.
-- [HackenProof](https://hackenproof.com/programs/ton) - websites, web apps, and Telegram mini-apps operated by TON Foundation.
 
-## GitHub repository
+## GitHub repositories
 
-- [Main TON monorepo](https://github.com/ton-blockchain/ton) - source code for the node and validator, lite-client, tonlib, FunC compiler, and related tools.
+- [Main TON monorepo](https://github.com/ton-blockchain/ton) - source code for the node and validator, `lite-client`, tonlib, Tolk compiler, and other tools.
+- [Acton monorepo](https://github.com/ton-blockchain/acton) - source code for the [Acton toolchain](/contract-dev/acton).
diff --git a/languages/fift/fift-and-tvm-assembly.mdx b/languages/fift/fift-and-tvm-assembly.mdx
index 92819dc15..0b67f1fc4 100644
--- a/languages/fift/fift-and-tvm-assembly.mdx
+++ b/languages/fift/fift-and-tvm-assembly.mdx
@@ -144,4 +144,4 @@ int mul_mod_better(int a, int b, int m) inline_ref {        ;; 1110 gas units
 int mul_mod_best(int a, int b, int m) asm "x{A988} s,";     ;; 65 gas units
 ```
 
-The [`x{A988}` opcode](/tvm/instructions#A988) implements an optimized division operation with built-in multiplication. This specialized instruction directly computes just the modulo remainder of the operation, skipping unnecessary computation steps. The `s,` suffix then handles the result storage - it takes the resulting slice from the stack's top and efficiently writes it into the target builder. Together, this combination delivers substantial gas savings compared to conventional approaches.
+The [`x{A988}` opcode](/tvm/instructions#a988-mulmod) implements an optimized division operation with built-in multiplication. This specialized instruction directly computes just the modulo remainder of the operation, skipping unnecessary computation steps. The `s,` suffix then handles the result storage - it takes the resulting slice from the stack's top and efficiently writes it into the target builder. Together, this combination delivers substantial gas savings compared to conventional approaches.
diff --git a/languages/fift/whitepaper.mdx b/languages/fift/whitepaper.mdx
index be9f84dd2..7df3ade4d 100644
--- a/languages/fift/whitepaper.mdx
+++ b/languages/fift/whitepaper.mdx
@@ -76,13 +76,13 @@ Please note that the current version of this document describes a preliminary te
    3. [Slice primitives](#5-3-slice-primitives)
    4. [Cell hash operations](#5-4-cell-hash-operations)
    5. [Bag-of-cells operations](#5-5-bag-of-cells-operations)
-   6. [Binary file I/O and Bytes manipulation](#5-6-binary-file-i-o-and-bytes-manipulation)
+   6. [Binary file I/O and Bytes manipulation](#5-6-binary-file-i%2Fo-and-bytes-manipulation)
 
 6. [**TON-specific operations**](#6-ton-specific-operations)
    1. [Ed25519 cryptography](#6-1-ed25519-cryptography)
    2. [Smart-contract address parser](#6-2-smart-contract-address-parser)
    3. [Dictionary manipulation](#6-3-dictionary-manipulation)
-   4. [Invoking TVM from Fift](#6-4-invoking-t-v-m-from-fift)
+   4. [Invoking TVM from Fift](#6-4-invoking-tvm-from-fift)
 
 7. [**Using the Fift assembler**](#7-using-the-fift-assembler)
    1. [Loading the Fift assembler](#7-1-loading-the-fift-assembler)
@@ -1189,7 +1189,7 @@ On the other hand, if the word is active, then it is always executed, even if `s
 
 When the Fift interpreter encounters a word that is absent from the dictionary, it invokes the primitive (number) to attempt to parse it as an integer or fractional literal. If this attempt succeeds, then the special value `'nop` is pushed, and the interpretation proceeds in the same way as if an active word were encountered. In other words, if state is zero, then the literal is simply left in the stack; otherwise, (compile) is invoked to modify the current _WordList_ so that it would push the literal when executed.
 
-### 5.4 Defining new active words
+### 4.4 Defining new active words
 
 New active words are defined similarly to new ordinary words, but using `::` instead of `:`. For instance,
 
diff --git a/languages/func/asm-functions.mdx b/languages/func/asm-functions.mdx
index 0f5fc1a31..63c60b732 100644
--- a/languages/func/asm-functions.mdx
+++ b/languages/func/asm-functions.mdx
@@ -102,7 +102,7 @@ For example, this function duplicates its input, so that if the input is `5`, it
 ;; and returns them.
 ```
 
-# Stack registers
+## Stack registers
 
 The so-called _stack registers_ are a way of referring to the values at the top of the stack. In total, there are 256 stack registers, i.e., values held on the stack at any given time.
 
diff --git a/languages/func/built-ins.mdx b/languages/func/built-ins.mdx
index ceb0805ef..74efb3d16 100644
--- a/languages/func/built-ins.mdx
+++ b/languages/func/built-ins.mdx
@@ -268,7 +268,7 @@ forall X -> int null?(X val)
 
 `null?` checks if the given argument is `null`. Returns `0` if the argument is not `null`, and `-1` otherwise.
 
-For more info, see [null values](/languages/func/types#null-values).
+For more info, see [null values](/languages/func/types#special-null-value).
 
 #### `throw`
 
diff --git a/languages/func/cookbook.mdx b/languages/func/cookbook.mdx
index cf0971a7a..35c757814 100644
--- a/languages/func/cookbook.mdx
+++ b/languages/func/cookbook.mdx
@@ -27,7 +27,7 @@ To check whether an event is relevant, use a flag variable of type integer.
 The flag can either be `0`, representing `false`, or `-1`, representing `true`.
 See [absence of boolean type](/languages/func/types#no-boolean-type).
 
-When checking the flag in [if..else statements](/languages/func/statements#if-else-statement), it is unnecessary to use
+When checking the flag in [`if...else` statements](/languages/func/statements#if-else-statement), it is unnecessary to use
 the [`==` operator](/languages/func/operators#equality%2C-%3D%3D), since a `0` evaluates to `false`, and any nonzero value is
 considered to be `true` in `if..else` statements.
 
@@ -102,7 +102,7 @@ while (msg.slice_refs_empty?() != -1) { ;; Iterate while there are refs to proce
 
 ### How to write a do until loop
 
-Use a [`do..until` loop](/languages/func/statements#until-loop) when the loop must execute at least once.
+Use a [`do...until` loop](/languages/func/statements#do-until-loop) when the loop must execute at least once.
 
 ```func
 int flag = 0;
@@ -658,7 +658,7 @@ names~udict_delete?(256, 27);
 ### How to determine if a tuple is empty
 
 When working with `tuples`, checking for existing values before extracting them is crucial.
-Extracting a value from an empty tuple will result in an error: ["not a tuple of valid size" - `exit code 7`](/tvm/exit-codes#7).
+Extracting a value from an empty tuple will result in an error: ["not a tuple of valid size" - `exit code 7`](/tvm/exit-codes#7%3A-type-check-error).
 
 ```func
 ;; Declare the tlen assembler function because it's not present in stdlib
@@ -1965,7 +1965,7 @@ Refer to the sending messages page for further details on sending modes in the `
 
 ### How to send a deploy message
 
-When sending a deploy message, prepare a [`StateInit`](/foundations/messages/deploy) cell, as done in the recipe [How to build a `StateInit` cell](#how-to-build-a-StateInit-cell). Once the `StateInit` cell is ready, prepare a message cell in which the message body is included with the headers, or the message body is included as a separate cell.
+When sending a deploy message, prepare a [`StateInit`](/foundations/messages/deploy) cell, as done in the recipe [How to build a `StateInit` cell](#how-to-build-a-stateinit-cell). Once the `StateInit` cell is ready, prepare a message cell in which the message body is included with the headers, or the message body is included as a separate cell.
 
 The following function illustrates the case for the message body included in the same cell as the headers. The function receives the destination address, the amount to send, the `StateInit` cell, and the message body as a slice.
 
@@ -2320,7 +2320,7 @@ As an example, let's say there is a need to perform the following calculation fo
 
 `(xp + zp) * (xp - zp)`.
 
-Since these operations are commonly used in cryptography, modulo operator for montgomery curves should be used.
+Since these operations are commonly used in cryptography, modulo operator for Montgomery curves should be used.
 
 **Note:**
 Variable names like `xp+zp` are valid as long as there are no spaces between the operators.
@@ -2338,7 +2338,7 @@ Variable names like `xp+zp` are valid as long as there are no spaces between the
 }
 ```
 
-**Reference:** [`muldivmod`](/tvm/instructions#A98C)
+**Reference:** [`MULDIVMOD`](/tvm/instructions#a98c-muldivmod)
 
 ### How to raise a number to a power
 
@@ -2484,7 +2484,7 @@ slice result = string.end_cell().begin_parse();
 - [`end_cell`](/languages/func/stdlib#end_cell)
 - [`begin_parse`](/languages/func/stdlib#begin_parse)
 - [`null`](/languages/func/stdlib#null)
-- [`divmod`](/languages/func/stdlib#divmod)
+- [`divmod`](/languages/func/built-ins#divmod)
 - [`store_uint`](/languages/func/stdlib#store_uint)
 - [List-style lists](/languages/func/stdlib#lisp-style-lists)
 
@@ -2590,4 +2590,4 @@ slice generate_external_address (int address) {
 
 Since there is a need to find the exact number of bits occupied by the address, [declare an asm function](#how-to-write-custom-functions-using-asm-keyword) with the `UBITSIZE` opcode. This function will return the minimum number of bits required to store a given number.
 
-**Reference:** [TVM instructions](/tvm/instructions#B603)
+**Reference:** [TVM instructions](/tvm/instructions#b603-ubitsize)
diff --git a/languages/func/expressions.mdx b/languages/func/expressions.mdx
index 034e4f438..a1ab982d3 100644
--- a/languages/func/expressions.mdx
+++ b/languages/func/expressions.mdx
@@ -27,7 +27,7 @@ An expression in FunC can be:
 We focus on variable declarations and function calls, since the other kind of expressions are explained in their respective articles.
 
 As a general rule, all sub-expressions inside an expression are evaluated from left to right,
-except in cases where [asm stack rearrangement](/languages/func/functions#rearranging-stack-entries) explicitly defines the order.
+except in cases where [asm stack rearrangement](/languages/func/asm-functions#rearranging-stack-entries) explicitly defines the order.
 
 ## Variable declaration
 
@@ -41,7 +41,7 @@ returns the value produced by `expr`, in addition to defining variable `iden` wi
 
 For instance: `(int x = 3) + x;` declares `x` and assigns to it the value `3`. The result of the expression `(int x = 3)` is therefore `3`, which means that `(int x = 3) + x` evaluates to `6`, since `x` has value `3` after the declaration.
 
-Here are further examples of variable declarations, where each line is independent from the other ones. It is possible to use the keyword `var` to let the type checker infer the type, see [hole types](/languages/func/types#hole-type).
+Here are further examples of variable declarations, where each line is independent from the other ones. It is possible to use the keyword `var` to let the type checker infer the type, see [typed holes](/languages/func/types#typed-holes).
 
 ```func
 int x = 2;
diff --git a/languages/func/global-variables.mdx b/languages/func/global-variables.mdx
index c77fcfce8..1a0747511 100644
--- a/languages/func/global-variables.mdx
+++ b/languages/func/global-variables.mdx
@@ -96,7 +96,7 @@ global cell A;    ;; DOES NOT COMPILE, cell should be int
   global int a = 5;  ;; DOES NOT COMPILE
   ```
 
-  Reading a global variable that has not been assigned, will result in the [`null` value](/languages/func/types#null-values).
+  Reading a global variable that has not been assigned, will result in the [`null` value](/languages/func/types#special-null-value).
 </Aside>
 
 <Aside>
diff --git a/languages/func/literals.mdx b/languages/func/literals.mdx
index 6ecdebf5d..3964e9c2f 100644
--- a/languages/func/literals.mdx
+++ b/languages/func/literals.mdx
@@ -25,7 +25,7 @@ FunC supports decimal and hexadecimal integer literals, including those with lea
 FunC allows a broad range of identifiers for functions and variable names. Any single-line string that meets the following conditions qualifies as a valid identifier:
 
 - It **does not** contain special symbols: `;`, `,`, `(`, `)`, `[`, `]`, spaces including tabs, `~`, and `.`.
-- It **does not** start as a [comment](/languages/func/comments) or a [string literal](#string-literals) (i.e., with `"` at the beginning).
+- It **does not** start as a [comment](/languages/func/comments) or a [string literal](#compile-time-built-ins) (i.e., with `"` at the beginning).
 - It is **not** a [number literal](#number-literals).
 - It is **not** an underscore `_`.
 - It is **not** a [reserved keyword](/languages/func/built-ins#reserved-keywords).
diff --git a/languages/func/special-functions.mdx b/languages/func/special-functions.mdx
index dce8fa3d1..7d3c2427f 100644
--- a/languages/func/special-functions.mdx
+++ b/languages/func/special-functions.mdx
@@ -76,7 +76,7 @@ There,
 
   `in_msg_body` will get assigned the value at the top of the stack (which corresponds to the message body slice), and `in_msg_cell` will receive the second value from the top of the stack (which corresponds to the message as a cell). The rest of values in the stack remain unassigned to variables during the execution of `recv_internal`, meaning that they will remain unused in the stack and will be dropped once the TVM finishes execution.
 
-  The declarations of `recv_internal` with fewer arguments consume slightly less gas, because each unused value in the stack is automatically dropped from the stack once `recv_internal` finishes execution, without the need to spend gas by explicitly executing a DROP instruction, which is an alias of [`s0 POP`](/tvm/instructions#3-pop).
+  The declarations of `recv_internal` with fewer arguments consume slightly less gas, because each unused value in the stack is automatically dropped from the stack once `recv_internal` finishes execution, without the need to spend gas by explicitly executing a DROP instruction, which is an alias of [`s0 POP`](/tvm/instructions#3i-pop).
 </Aside>
 
 <Aside
diff --git a/languages/func/statements.mdx b/languages/func/statements.mdx
index 05a9c7be8..d3c26cba4 100644
--- a/languages/func/statements.mdx
+++ b/languages/func/statements.mdx
@@ -374,7 +374,7 @@ try {
 
 In the above example, [`throw_arg(-1, 100)`](/languages/func/built-ins#throw_arg) produces an exception with error code `100` and exception parameter `-1`. However, since the exception parameter can be of any type, which may vary depending on the exception, FunC cannot determine its type at compile time in the `catch` block.
 
-This requires the developer to manually cast the exception parameter. In the example, casting of the exception parameter is achieved with the [assembler](/languages/func/functions#assembler-function-body-definition) and [polymorphic](/languages/func/functions#polymorphism-with-forall) function `cast_to_int`, which receives an argument of any type and returns the same argument as an integer by wrapping the [`NOP` (no operation) TVM instruction](/tvm/instructions#00-nop):
+This requires the developer to manually cast the exception parameter. In the example, casting of the exception parameter is achieved with the [assembler](/languages/func/asm-functions#assembler-function-definition) and [polymorphic](/languages/func/functions#forall-declarator) function `cast_to_int`, which receives an argument of any type and returns the same argument as an integer by wrapping the [`NOP` (no operation) TVM instruction](/tvm/instructions#00-nop):
 
 ```func
 forall X -> int cast_to_int(X x) asm "NOP";
diff --git a/languages/func/stdlib.mdx b/languages/func/stdlib.mdx
index cff39b9f1..3477c0d32 100644
--- a/languages/func/stdlib.mdx
+++ b/languages/func/stdlib.mdx
@@ -29,7 +29,7 @@ Additionally, some less frequently used TVM commands are not yet included in the
 ## Tuple manipulation primitives
 
 Most function names and types in this section are self-explanatory.
-For more details on polymorphic functions, refer to the [Polymorphism with forall](/languages/func/functions#polymorphism-with-forall) section.
+For more details on polymorphic functions, refer to the [`forall` declarator](/languages/func/functions#forall-declarator) section.
 
 **Note:** Currently, values of atomic type `tuple` cannot be converted into composite tuple types (e.g.,`[int, cell]`) and vice versa.
 
@@ -62,7 +62,7 @@ Extracts the head and tail of a lisp-style list.
 forall X -> (tuple, X) list_next(tuple list) asm( -> 1 0) "UNCONS";
 ```
 
-Extracts the head and tail of a lisp-style list. It can be used as a [(non-)modifying method](/languages/func/statements#methods-calls).
+Extracts the head and tail of a lisp-style list. It can be used as a [(non-)modifying method](/languages/func/expressions#non-modifying-notation).
 
 **Example**
 
@@ -820,8 +820,8 @@ Prints the current stack up to the top 255 values and displays the total stack d
 ### Slice primitives
 
 A primitive _loads_ data when it returns both the extracted data and the remainder of the slice.
-It can be used as a [modifying method](/languages/func/statements#modifying-methods).
-A primitive _preloads_ data when it returns only the extracted data, leaving the original slice unchanged. It can be used as a [non-modifying method](/languages/func/statements#non-modifying-methods).
+It can be used as a [modifying method](/languages/func/expressions#modifying-notation).
+A primitive _preloads_ data when it returns only the extracted data, leaving the original slice unchanged. It can be used as a [non-modifying method](/languages/func/expressions#non-modifying-notation).
 Unless specified otherwise, loading and preloading primitives read data from the beginning of the slice.
 
 #### `begin_parse`
@@ -1034,7 +1034,7 @@ otherwise, the returned value is one plus the maximum depths of cells referred t
 
 ### Builder primitives
 
-A primitive _stores_ a value `x` in a builder `b` by returning a modified version `b'` with `x` added at the end. It can also be used as a [non-modifying method](/languages/func/statements#non-modifying-methods).
+A primitive _stores_ a value `x` in a builder `b` by returning a modified version `b'` with `x` added at the end. It can also be used as a [non-modifying method](/languages/func/expressions#non-modifying-notation).
 Each of the following primitives first checks for enough space in the `builder` and then verifies the range of the serialized value.
 
 #### `begin_cell`
@@ -1164,7 +1164,7 @@ Returns the depth of the given `cell c`. If `c` has no references, the function
 int cell_null?(cell c) asm "ISNULL";
 ```
 
-Checks whether the given `cell c` is `null`. In most cases, a `null` cell represents an empty dictionary. FunC also includes a polymorphic `null?` built-in function. See [built-in](/languages/func/built-ins#other-primitives) for more details.
+Checks whether the given `cell c` is `null`. In most cases, a `null` cell represents an empty dictionary. FunC also includes a polymorphic `null?` built-in function. See the [built-ins](/languages/func/built-ins) page for more details.
 
 ## Dictionaries primitives
 
@@ -1183,7 +1183,7 @@ As stated in [TVM.pdf](https://ton.org/tvm.pdf):
 >
 > 1. **As a slice `s`** containing the serialized TL-B value of type `HashmapE(n, X)`. In simpler terms, `s` consists either of a single `0` bit if the dictionary is empty or a `1` bit followed by a reference to a cell containing the binary tree's root — essentially, a serialized value of type `Hashmap(n, X)`.
 >
-> 1. **As a `Maybe cell (c^?)`**, which is either a cell that contains a serialized `Hashmap(n, X)` same as above or `null`, indicating an empty dictionary. See [null values](/languages/func/types#null-values) for details. When using this format, the dictionary is typically referred to as `D`.
+> 1. **As a `Maybe cell (c^?)`**, which is either a cell that contains a serialized `Hashmap(n, X)` same as above or `null`, indicating an empty dictionary. See [null values](/languages/func/types#special-null-value) for details. When using this format, the dictionary is typically referred to as `D`.
 >
 > Most dictionary-related operations use the second format because it is easier to manipulate on the stack. However, when dictionaries are serialized within larger TL-B objects, they follow the first representation.
 
@@ -1204,7 +1204,7 @@ The naming convention of dictionary primitives reflects these distinctions. For
 - `dict_set` applies to dictionaries with slice keys.
 
 In function titles, an **empty prefix** indicates slice keys.
-Additionally, some primitives have counterparts prefixed with `~`, enabling them to be used as [modifying methods](/languages/func/statements#modifying-methods).
+Additionally, some primitives have counterparts prefixed with `~`, enabling them to be used as [modifying methods](/languages/func/expressions#modifying-notation).
 
 ### Dictionary values
 
diff --git a/languages/func/types.mdx b/languages/func/types.mdx
index 7b0428019..4865e37cc 100644
--- a/languages/func/types.mdx
+++ b/languages/func/types.mdx
@@ -76,7 +76,7 @@ _ someFunction(int a) {
 
 the type checker infers that `_` has type `int`, as the return expression `a + 1` is of type `int`.
 
-See [Function declarations](/languages/func/functions#function-declaration) for more details.
+See [Function declarations](/languages/func/functions) for more details.
 
 ## Composite types
 
@@ -186,7 +186,7 @@ For example,
   Type variables in polymorphic functions cannot be instantiated with tensor types. The only exception is a tensor of a single element `(a)`, where `a` is not a tensor type itself. The compiler treats `(a)` as equivalent to `a`.
 </Aside>
 
-For more details, see the [Polymorphism with forall](/languages/func/functions#polymorphism-with-forall) section.
+For more details, see the [`forall` declarator](/languages/func/functions#forall-declarator) section.
 
 ## User-defined types
 
diff --git a/payments/toncoin.mdx b/payments/toncoin.mdx
index 6377536e5..cd439123a 100644
--- a/payments/toncoin.mdx
+++ b/payments/toncoin.mdx
@@ -43,15 +43,15 @@ graph LR
 
 **Comparison table**
 
-| Criteria                     | Invoice-based deposits                                                                                      | Unique deposit addresses                                                                 |
-| ---------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| Security exposure            | One shared hot wallet; a key leak drains the full pool                                                      | Each wallet isolates funds; compromise affects only the impacted user                    |
-| User input requirements      | User must include an invoice ID comment; missing or malformed comments need manual recovery workflows       | User only needs the destination address                                                  |
-| Parsing and validation       | Backend parses comments on every deposit and matches to invoices                                            | No parsing; deposit attribution is address-based                                         |
-| Deployment and storage costs | Deploy and maintain a single wallet; [storage rent](/foundations/fees#storage-fee) limited to that contract | Deploy many wallets; storage rent and deployment gas scale with user count               |
-| Monitoring workload          | Poll one address; comment parsing adds CPU but [RPC calls](/ecosystem/api/overview) stay low                | Track many addresses; RPC queries and state tracking grow with the active user base      |
-| Withdrawal handling          | [Highload wallet](/standard/wallets/highload/overview) can batch withdrawals from one balance               | Need sweeps or coordinated withdrawals from many wallets; extra gas and sequencing logic |
-| Sharding behavior            | All activity hits [one shard](/foundations/shards); throughput limited by that shard                        | Wallets are distributed across shards; helps spread load                                 |
+| Criteria                     | Invoice-based deposits                                                                                       | Unique deposit addresses                                                                 |
+| ---------------------------- | ------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------- |
+| Security exposure            | One shared hot wallet; a key leak drains the full pool                                                       | Each wallet isolates funds; compromise affects only the impacted user                    |
+| User input requirements      | User must include an invoice ID comment; missing or malformed comments need manual recovery workflows        | User only needs the destination address                                                  |
+| Parsing and validation       | Backend parses comments on every deposit and matches to invoices                                             | No parsing; deposit attribution is address-based                                         |
+| Deployment and storage costs | Deploy and maintain a single wallet; [storage rent](/foundations/fees#storage-fees) limited to that contract | Deploy many wallets; storage rent and deployment gas scale with user count               |
+| Monitoring workload          | Poll one address; comment parsing adds CPU but [RPC calls](/ecosystem/api/overview) stay low                 | Track many addresses; RPC queries and state tracking grow with the active user base      |
+| Withdrawal handling          | [Highload wallet](/standard/wallets/highload/overview) can batch withdrawals from one balance                | Need sweeps or coordinated withdrawals from many wallets; extra gas and sequencing logic |
+| Sharding behavior            | All activity hits [one shard](/foundations/shards); throughput limited by that shard                         | Wallets are distributed across shards; helps spread load                                 |
 
 ## Invoice-based deposits
 
diff --git a/standard/tokens/nft/api.mdx b/standard/tokens/nft/api.mdx
index 65bcddfa6..6e9c0efb8 100644
--- a/standard/tokens/nft/api.mdx
+++ b/standard/tokens/nft/api.mdx
@@ -67,7 +67,7 @@ If the `forward_payload` contains a binary message for interacting with the dest
 
 <Aside type="caution">Verify that item belongs to collection via [get method in collection](/standard/tokens/nft/api#get_nft_address_by_index), see more [here](/standard/tokens/nft/verify)</Aside>
 
-#### get\_nft\_data()
+#### `get_nft_data()`
 
 No arguments. Outputs:
 
@@ -83,7 +83,7 @@ No arguments. Outputs:
 
 ### NFT Collection
 
-#### get\_collection\_data()
+#### `get_collection_data()`
 
 No arguments. Outputs:
 
@@ -93,13 +93,13 @@ No arguments. Outputs:
 | `collection_content` | `Cell`       | collection content in a format that complies with TEP-64 |
 | `owner_address`      | `MsgAddress` | collection owner address, zero address if no owner       |
 
-#### get\_nft\_address\_by\_index()
+#### `get_nft_address_by_index()`
 
 Argument: `index` as `int`.
 
 Output: `address` as `MsgAddress`.
 
-#### get\_nft\_content()
+#### `get_nft_content()`
 
 Arguments:
 
@@ -127,7 +127,7 @@ Output: `full_content` as `Cell`.
 | `denominator`           | `uint16`     | royalty denominator                     |
 | `destination`           | `MsgAddress` | address to send royalty                 |
 
-### royalty\_params()
+### `royalty_params()`
 
 No arguments. Outputs:
 
@@ -208,7 +208,7 @@ Royalty share is `numerator / denominator`. For example, if `numerator = 11` and
 | `revoked_at` | `uint64`      | unix time when SBT was revoked, 0 if it was not       |
 | `content`    | `Maybe ^Cell` | SBT's content if `with_content` was true, null if not |
 
-#### get\_nft\_data()
+#### `get_nft_data()`
 
 Same as [NFT standard](/standard/tokens/nft/api#get_nft_data). No arguments. Outputs:
 
@@ -220,7 +220,7 @@ Same as [NFT standard](/standard/tokens/nft/api#get_nft_data). No arguments. Out
 | `owner_address`      | `MsgAddress` | SBT owner's address                                                       |
 | `individual_content` | `Cell`       | individual SBT content in any format                                      |
 
-#### get\_authority\_address()
+#### `get_authority_address()`
 
 No arguments. Outputs:
 
@@ -230,7 +230,7 @@ No arguments. Outputs:
 
 <Aside type="note">This method is mandatory for SBT. If there is no authority it should return `addr_none` (2 zero bits).</Aside>
 
-#### get\_revoked\_time()
+#### `get_revoked_time()`
 
 No arguments. Outputs:
 
diff --git a/standard/tokens/nft/metadata.mdx b/standard/tokens/nft/metadata.mdx
index a76030677..ce758e053 100644
--- a/standard/tokens/nft/metadata.mdx
+++ b/standard/tokens/nft/metadata.mdx
@@ -24,4 +24,4 @@ To get full NFT metadata manually:
 
 1. If it is not known, resolve the NFT item address by its index from the collection using [`get_nft_address_by_index(index)`](/standard/tokens/nft/api#get_nft_address_by_index).
 1. Get the individual content from the item contract using [`get_nft_data()`](/standard/tokens/nft/api#get_nft_data).
-1. Get the full metadata from the collection contract using [`get_nft_content(index, individual_content)`](/standard/tokens/nft/api#get-nft-content).
+1. Get the full metadata from the collection contract using [`get_nft_content(index, individual_content)`](/standard/tokens/nft/api#get_nft_content).
diff --git a/standard/vesting.mdx b/standard/vesting.mdx
index ce4a7863a..cb328417b 100644
--- a/standard/vesting.mdx
+++ b/standard/vesting.mdx
@@ -304,7 +304,7 @@ For detailed setup instructions, see [MyTonCtrl single nominator pool mode](/eco
   type="tip"
   title="Staking rewards"
 >
-  Staking rewards are distributed according to the pool's reward scheme. See [staking rewards distribution](/ecosystem/staking/overview#nominator-validator-rewards-distribution) for details on how rewards are calculated and split between validators and nominators.
+  Staking rewards are distributed according to the pool's reward scheme. See [staking reward calculation in nominator pools](/ecosystem/staking/nominator-pools) for details on how rewards are calculated and split between validators and nominators.
 </Aside>
 
 ### Liquid staking: Tonstakers
diff --git a/standard/wallets/highload/v2/specification.mdx b/standard/wallets/highload/v2/specification.mdx
index de089bff6..9c878a05c 100644
--- a/standard/wallets/highload/v2/specification.mdx
+++ b/standard/wallets/highload/v2/specification.mdx
@@ -62,8 +62,6 @@ Allows a single keypair to control multiple wallets with different addresses.
 **How it works:**\
 The `subwallet_id` is part of the contract's initial state. Changing it produces a different contract address. Each external message must include the correct `subwallet_id`; mismatches result in transaction failure.
 
----
-
 ### `last_cleaned` (64 bits)
 
 **Purpose:**\
@@ -86,8 +84,6 @@ Queries with `query_id < (now() - 64) << 32` are removed from storage.
   **Gas costs:** Cleanup operations consume gas proportional to the number of expired queries. With many expired queries, cleanup can exceed the 1,000,000 gas limit, causing the transaction to fail.
 </Aside>
 
----
-
 ### `public_key` (256 bits)
 
 **Purpose:**\
@@ -96,8 +92,6 @@ The Ed25519 public key is used to verify signatures on incoming external message
 **How it works:**\
 When the wallet receives an external message, it verifies that the 512-bit signature was created by the holder of the private key corresponding to this public key.
 
----
-
 ### `queries` (HashmapE 64 Cell)
 
 **Purpose:**\
@@ -147,8 +141,6 @@ throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
 
 The contract uses `slice_hash()` on the message body after loading the signature.
 
----
-
 ### `subwallet_id` (32 bits)
 
 **Purpose:**\
@@ -157,8 +149,6 @@ Identifies which subwallet this message targets.
 **Validation:**\
 Must match the `subwallet_id` stored in contract storage.
 
----
-
 ### `query_id` (64 bits)
 
 **Purpose:**\
@@ -176,8 +166,6 @@ The contract checks `query_id >= now() << 32`, ensuring the query ID is not from
 **Total unique IDs:**\
 Approximately **32,000** unique query IDs (limited by the cleanup mechanism and the bitmap structure).
 
----
-
 ### `messages` (HashmapE 16)
 
 **Purpose:**\
@@ -205,8 +193,6 @@ do {
 **Max batch size:**\
 Up to **255 messages** (limited by action list size, not dictionary structure).
 
----
-
 ## Replay protection mechanism
 
 ### Validation sequence
@@ -227,8 +213,6 @@ Up to **255 messages** (limited by action list size, not dictionary structure).
   Highload Wallet v3 solves this with `commit()` and a two-transaction pattern. See [Why internal messages to self?](/standard/wallets/highload/v3/specification#why-internal-messages-to-self) for details.
 </Aside>
 
----
-
 ## Exit codes
 
 | Exit code | Name                           | Description                                                     | How to fix                                                      |
@@ -238,8 +222,6 @@ Up to **255 messages** (limited by action list size, not dictionary structure).
 | `34`      | Subwallet ID mismatch          | The `subwallet_id` in the message does not match storage        | Verify you are using the correct `subwallet_id` for this wallet |
 | `35`      | Invalid signature or query\_id | Ed25519 signature verification failed, or `query_id` is too old | Check the private key and ensure `query_id >= now() << 32`      |
 
----
-
 ## Limitations and constraints
 
 ### Storage size limit
@@ -271,8 +253,6 @@ Queries older than **64 seconds** are removed from storage during cleanup.
 **Effective limit:**\
 With the 64-second expiration window and recommended limit of ≤1,000 queries per window, the effective query ID space is approximately **32,000** unique IDs before cleanup is required.
 
----
-
 ## Get methods
 
 | Method                 | Returns          | Description                                                                               |
@@ -288,8 +268,6 @@ With the 64-second expiration window and recommended limit of ≤1,000 queries p
 - `0` (false) — the `query_id` has not been processed yet
 - `1` (unknown) — the `query_id` is older than `last_cleaned` and was forgotten during cleanup
 
----
-
 ## Implementation
 
 **Source code:**\
@@ -302,9 +280,7 @@ With the 64-second expiration window and recommended limit of ≤1,000 queries p
 
 For new projects, consider using [Highload Wallet v3](/standard/wallets/highload/v3/specification) instead.
 
----
-
 ## See also
 
 - [Highload Wallet v3 specification](/standard/wallets/highload/v3/specification) — recommended version
-- [Version comparison](/standard/wallets/highload/overview#version-comparison) — v1 vs v2 vs v3
+- [Version comparison](/standard/wallets/highload/overview#highload-wallet-version-comparison) — v1 vs v2 vs v3
diff --git a/standard/wallets/highload/v3/send-batch-transfers.mdx b/standard/wallets/highload/v3/send-batch-transfers.mdx
index e4413b19b..70b6c1299 100644
--- a/standard/wallets/highload/v3/send-batch-transfers.mdx
+++ b/standard/wallets/highload/v3/send-batch-transfers.mdx
@@ -88,7 +88,7 @@ Each message in the batch:
 - **`outMsg`** — the internal message to send
 
 <Aside type="tip">
-  **Batch limit:** You can send up to **254 messages** per transaction. This limit exists because one action slot is reserved for [`set_code` protection](/standard/wallets/highload/v3/specification#protection-against-set-code).
+  **Batch limit:** You can send up to **254 messages** per transaction. This limit exists because one action slot is reserved for [`set_code` protection](/standard/wallets/highload/v3/specification#protection-against-set_code).
 </Aside>
 
 ## Step 3: Send the batch
diff --git a/standard/wallets/highload/v3/specification.mdx b/standard/wallets/highload/v3/specification.mdx
index 351852a12..6fccbc2bf 100644
--- a/standard/wallets/highload/v3/specification.mdx
+++ b/standard/wallets/highload/v3/specification.mdx
@@ -26,8 +26,6 @@ Unlike seqno-based wallets (v3, v4, v5) that require sequential transaction proc
 **Compared to Highload v2:**\
 v3 solves architectural issues that could lock funds in v2 and consumes less gas during operations.
 
----
-
 ## TL-B schema
 
 [TL-B (Type Language - Binary)](/languages/tl-b/overview) is a domain-specific language designed to describe data structures in TON. The schemas below define the binary layout of the contract's storage, external messages, and internal messages.
@@ -69,8 +67,6 @@ internal_transfer#ae42e5a4 {n:#} query_id:uint64 actions:^(OutList n) = Internal
 
 Below, each field is explained in detail.
 
----
-
 ## Storage structure
 
 The Highload Wallet v3 contract stores six persistent fields:
@@ -89,8 +85,6 @@ When the wallet receives an external message, it verifies that the 512-bit signa
   The public key is not the wallet address. The address is [derived](/foundations/addresses/derive) from the contract's [`StateInit`](/foundations/messages/deploy).
 </Aside>
 
----
-
 ### `subwallet_id` (32 bits)
 
 **Purpose:**\
@@ -105,8 +99,6 @@ One private key manages multiple "virtual" wallets for organizational or account
 **Recommendation:**\
 Use `subwallet_id: 0x10ad` (4269) to avoid conflicts with other wallet types (standard wallets or vesting wallets) derived from the same keypair. See [How to create Highload Wallet v3](/standard/wallets/highload/v3/create) for details.
 
----
-
 ### `old_queries` (HashmapE 13 ^Cell)
 
 **Purpose:**\
@@ -120,8 +112,6 @@ Provides a second layer of replay protection. During cleanup, `queries` → `old
 
 **Details:** See [Replay protection mechanism](#replay-protection-mechanism).
 
----
-
 ### `queries` (HashmapE 13 ^Cell)
 
 **Purpose:**\
@@ -135,8 +125,6 @@ When a message arrives, the contract checks if its `query_id` is already marked
 
 **Details:** See [Replay protection mechanism](#replay-protection-mechanism).
 
----
-
 ### `last_clean_time` (64 bits)
 
 **Purpose:**\
@@ -147,8 +135,6 @@ Tracks when the contract last rotated `queries` → `old_queries`. Cleanup trigg
 
 **Details:** See [Replay protection mechanism](#replay-protection-mechanism).
 
----
-
 ### `timeout` (22 bits)
 
 **Purpose:**\
@@ -166,8 +152,6 @@ Messages are valid if `created_at > now() - timeout` and `created_at <= now()`.
 - [Replay protection mechanism](#replay-protection-mechanism) — how timeout is used
 - [Timeout constraints](#timeout-constraints) — choosing the right value
 
----
-
 ## Replay protection mechanism
 
 Highload v3 uses a dual-hashmap system (`queries` and `old_queries`) combined with timestamps to prevent replay attacks.
@@ -191,7 +175,7 @@ The contract stores processed `query_id` values in two hashmaps:
 - Each value is a cell containing a bitmap of processed `bit_number` values
 - Stores recently processed query IDs
 
-### How query\_id is checked
+### How `query_id` is checked
 
 When an external message arrives, the contract:
 
@@ -286,8 +270,6 @@ Even if Transaction 2 fails in the action phase, Transaction 1 has already succe
 
 This architecture solves a fundamental problem present in all standard external message wallets, including seqno-based wallets and earlier highload designs.
 
----
-
 ## External message structure
 
 External messages sent to Highload v3 have a specific layout.
@@ -311,8 +293,6 @@ The signature is in the **root cell** (512 bits); all other parameters are in a
   **Gas optimization:** This structure saves \~500 gas units during signature verification. If the signature were in the same cell as the message body, the contract would need to use `slice_hash()` (which rebuilds the cell internally, costing extra gas) instead of simply taking `cell_hash()` of the reference.
 </Aside>
 
----
-
 ### `signature` (512 bits)
 
 **Type:**\
@@ -333,8 +313,6 @@ Exit code `33`.
 
 **Link:** [Ed25519 signature scheme](https://en.wikipedia.org/wiki/EdDSA#Ed25519)
 
----
-
 ### `subwallet_id` (32 bits)
 
 **Purpose:**\
@@ -346,8 +324,6 @@ Must match the `subwallet_id` stored in contract storage.
 **On mismatch:**\
 Exit code `34`.
 
----
-
 ### `query_id` (composite structure)
 
 The `query_id` follows the `QueryId` TL-B structure and is split into two parts:
@@ -370,8 +346,6 @@ The contract checks if bit `bit_number` is set in the cell stored at `hashmap[sh
 **Recommendation:**\
 Increment `query_id` sequentially using a counter-based strategy.
 
----
-
 ### `created_at` (64 bits)
 
 **Purpose:**\
@@ -391,8 +365,6 @@ Exit code `35`.
 **Why it matters:**\
 Prevents replay of expired messages. Even if a `query_id` is eventually forgotten, stale messages are rejected based on `created_at`. See [Timestamp validation](#timestamp-validation) for important time lag considerations.
 
----
-
 ### `timeout` (22 bits)
 
 **Purpose:**\
@@ -408,8 +380,6 @@ Exit code `38`.
   22 bits allows timeout values up to \~4.8 million seconds (\~55 days).
 </Aside>
 
----
-
 ### `send_mode` (8 bits)
 
 **Purpose:**\
@@ -417,8 +387,6 @@ Specifies the [send mode](/foundations/messages/modes) for the internal message.
 
 **Link:** [send\_raw\_message modes](/languages/func/stdlib#send_raw_message)
 
----
-
 ### `message_to_send` (reference cell)
 
 **Structure:**\
@@ -450,8 +418,6 @@ The contract validates `message_to_send` **after committing storage** to prevent
 **Critical limitation:**\
 Highload v3 can send **only ONE internal message** per external message. For batch transfers, use the [internal\_transfer pattern](#single-message-per-external) with an action list (up to 254 messages).
 
----
-
 ## Message sending flow
 
 Highload v3 uses a two-transaction pattern to safely send messages:
@@ -472,8 +438,6 @@ Highload v3 uses a two-transaction pattern to safely send messages:
 
 See [Single message per external](#single-message-per-external) for details on this limitation and the batch transfer workaround.
 
----
-
 ## Exit codes
 
 | Exit code | Name                   | Description                                                                | How to fix                                                                      |
@@ -486,8 +450,6 @@ See [Single message per external](#single-message-per-external) for details on t
 | `37`      | Invalid message        | The `message_to_send` structure is invalid or cannot be processed          | Verify the message cell structure and contents                                  |
 | `38`      | Invalid timeout        | The `timeout` in the message does not match storage timeout                | Verify you are using the correct `timeout` value for this wallet                |
 
----
-
 ## Limitations and constraints
 
 ### Single message per external
@@ -502,15 +464,13 @@ Manually validating message structure is expensive in gas costs. The contract va
 State-init validation is complex and gas-intensive, while deploying contracts from a highload wallet is rarely needed. The feature was intentionally excluded to reduce gas costs.
 
 **Workaround for batch transfers:**\
-Send an internal message to the wallet itself with opcode `0xae42e5a4` (`internal_transfer`) and an action list containing up to **254 outgoing messages** (not 255, because one action slot is reserved for [`set_code` protection](#protection-against-set-code)).
+Send an internal message to the wallet itself with opcode `0xae42e5a4` (`internal_transfer`) and an action list containing up to **254 outgoing messages** (not 255, because one action slot is reserved for [`set_code` protection](#protection-against-set_code)).
 
 **How to implement:** [Send batch transfers](/standard/wallets/highload/v3/send-batch-transfers)
 
----
-
 ### Query ID space limitations
 
-Highload v3 supports up to **8,380,416 unique query IDs** (see [`query_id` structure](#query-id-composite-structure) for details).
+Highload v3 supports up to **8,380,416 unique query IDs** (see [`query_id` structure](#query-id-structure) for details).
 
 **Impact on throughput:**\
 If you send messages faster than `timeout`, you may exhaust available query IDs. After `timeout`, old IDs can be reused.
@@ -518,8 +478,6 @@ If you send messages faster than `timeout`, you may exhaust available query IDs.
 **Recommended strategy:**\
 Use a counter-based approach, incrementing `query_id` for each message.
 
----
-
 ### Timeout constraints
 
 The `timeout` value affects message validity, storage costs, and operational behavior:
@@ -535,8 +493,6 @@ Processed `query_id` values remain in storage for up to `2 × timeout` (across `
 - Short timeout (seconds/minutes): Fast expiration certainty, but messages may expire during network congestion
 - Long timeout (hours): Messages survive congestion, but slow failure detection and higher storage costs
 
----
-
 ### Gas consumption
 
 Gas costs vary depending on the number of outgoing messages sent:
@@ -560,8 +516,6 @@ Forward fees scale with:
 - Number of outgoing messages
 - Size and complexity of message content
 
----
-
 ## Get methods
 
 Highload Wallet v3 provides several read-only methods for monitoring and verification.
@@ -591,8 +545,6 @@ Before sending a message, check if a `query_id` was already used to avoid replay
 
 **Link:** [How to verify if a message is processed](/standard/wallets/highload/v3/verify-is-processed)
 
----
-
 ## Protection against `set_code`
 
 **Why this protection is needed:**
@@ -614,8 +566,6 @@ This pattern **prevents any `set_code` action in the action list from taking eff
 **Action list limitation:**\
 Because the contract calls `set_code(old_code)` as a protection mechanism, one action slot is consumed. This is why the maximum number of outgoing messages in a batch is **254** (not 255) — one slot is reserved for the `set_code` protection.
 
----
-
 ## Implementation
 
 **Source code:** [`ton-blockchain/highload-wallet-contract-v3`](https://github.com/ton-blockchain/highload-wallet-contract-v3)
@@ -630,8 +580,6 @@ Because the contract calls `set_code(old_code)` as a protection mechanism, one a
 
 **Link:** [How-to guides](/standard/wallets/highload/v3/create)
 
----
-
 ## See also
 
 - [How to create Highload Wallet v3](/standard/wallets/highload/v3/create)
diff --git a/standard/wallets/highload/v3/verify-is-processed.mdx b/standard/wallets/highload/v3/verify-is-processed.mdx
index 29aa73032..2e0b7feac 100644
--- a/standard/wallets/highload/v3/verify-is-processed.mdx
+++ b/standard/wallets/highload/v3/verify-is-processed.mdx
@@ -291,7 +291,7 @@ if (messagesFailed > 0) {
 >
   **Partial failures:** Even if the action phase succeeds overall, some individual messages may fail. Check `skippedActions` to detect partial failures. If `skippedActions > 0`, some messages in the batch were not sent.
 
-  The `totalActions - 1` calculation accounts for the [`set_code` protection](/standard/wallets/highload/v3/specification#protection-against-set-code) action.
+  The `totalActions - 1` calculation accounts for the [`set_code` protection](/standard/wallets/highload/v3/specification#protection-against-set_code) action.
 </Aside>
 
 ## Expected outputs
diff --git a/standard/wallets/v5-api.mdx b/standard/wallets/v5-api.mdx
index 983aa96d0..3b3207445 100644
--- a/standard/wallets/v5-api.mdx
+++ b/standard/wallets/v5-api.mdx
@@ -189,7 +189,7 @@ graph LR
 
 Signed message is a message that was signed using owners private key from his dedicated keypair, method from asymmetric cryptography. Later this message will be verified on-chain using public key stored in wallet smart contract - [read more](/standard/wallets/how-it-works#how-ownership-verification-works) about how ownership verification works.
 
-Before V5 standard, there was only one way to deliver signed message to wallet contract - via external-in message. However, external messages has certain limitations, e.g. you can only send external-out messages from the smart contracts themselves. This means that it wasn't possible to deliver signed message from inside the blockchain, from another smart contract. V5 standard adds this functionality, partially enabling [gasless transaction](/standard/wallets/v5#preparing-for-gasless-transactions).
+Before V5 standard, there was only one way to deliver signed message to wallet contract - via external-in message. However, external messages has certain limitations, e.g. you can only send external-out messages from the smart contracts themselves. This means that it wasn't possible to deliver signed message from inside the blockchain, from another smart contract. V5 standard adds this functionality, partially enabling [gasless transaction](/standard/wallets/gasless).
 
 Besides `W5InnerRequest` field that contains actual actions that will be performed, `W5SignedRequest` structure contains usual wallet message fields that were in-place in previous versions, read more about them [here](/standard/wallets/how-it-works).
 
diff --git a/start-here.mdx b/start-here.mdx
index 08bb692ed..758f5438e 100644
--- a/start-here.mdx
+++ b/start-here.mdx
@@ -75,7 +75,7 @@ Over its lifetime, an account changes its [status](/foundations/status) among fo
 - `nonexist`: There wasn't a single operation with the account, or it was removed. It has neither a balance, nor code.
 - `uninit`: If some Toncoin is transferred to an account, it now exists, but there is still no smart contract code on it. It now has a balance.
 - `active`: After a deploy message (see below) with code and initial data is sent to an account, it becomes active and can process other messages. It now has a balance, code, and internal state.
-- `frozen`: If an account is overdue on its [storage fees](/foundations/fees#storage-fee), it will be frozen until the fees are paid. If the overdue amount reaches a maximum limit specified by the blockchain, the account goes completely bankrupt, is removed, and ceases to exist.
+- `frozen`: If an account is overdue on its [storage fees](/foundations/fees#storage-fees), it will be frozen until the fees are paid. If the overdue amount reaches a maximum limit specified by the blockchain, the account goes completely bankrupt, is removed, and ceases to exist.
 
 ### Smart contracts
 
diff --git a/tolk/features/message-handling.mdx b/tolk/features/message-handling.mdx
index 1986b12cd..d7e840d71 100644
--- a/tolk/features/message-handling.mdx
+++ b/tolk/features/message-handling.mdx
@@ -8,7 +8,7 @@ A contract file typically begins with a [`contract` declaration](/languages/tolk
 
 ## `onInternalMessage`
 
-Contracts primarily handle [internal messages](/foundations/messages/internal#internal-messages). Users interact with contracts through their wallets, which send internal messages to the contract. The entrypoint is declared as follows:
+Contracts primarily handle [internal messages](/foundations/messages/internal). Users interact with contracts through their wallets, which send internal messages to the contract. The entrypoint is declared as follows:
 
 ```tolk
 fun onInternalMessage(in: InMessage) {
diff --git a/tolk/features/message-sending.mdx b/tolk/features/message-sending.mdx
index 22df44577..41ada57c7 100644
--- a/tolk/features/message-sending.mdx
+++ b/tolk/features/message-sending.mdx
@@ -78,7 +78,7 @@ val walletInitialState: ContractState = {
 };
 ```
 
-When sending a message to the wallet, it may not yet exist on-chain. In this case, the message must include the wallet's code and initial data. The message destination is therefore defined by the wallet's [`StateInit`](/foundations/messages/deploy#deploy-message).
+When sending a message to the wallet, it may not yet exist on-chain. In this case, the message must include the wallet's code and initial data. The message destination is therefore defined by the wallet's [`StateInit`](/foundations/messages/deploy).
 
 ```tolk
 // address auto-calculated, code+data auto-attached
@@ -232,7 +232,7 @@ A struct is declared as `CreateMessageOptions<TBody = void>`. By convention, fie
 
 ## Sending modes
 
-A message created with `createMessage()` is typically sent using [`msg.send(mode)`](/foundations/messages/modes#sending-modes).
+A message created with `createMessage()` is typically sent using [`msg.send(mode)`](/foundations/messages/modes).
 
 ## `ContractState` and `StateInit`
 
diff --git a/tolk/types/tuples.mdx b/tolk/types/tuples.mdx
index 915e2ee3b..ff9de51ab 100644
--- a/tolk/types/tuples.mdx
+++ b/tolk/types/tuples.mdx
@@ -328,4 +328,4 @@ fun demo(p: Point3d) {
 
 Arrays can be [serialized to cells](/languages/tolk/types/overall-serialization) when `T` is serializable. The binary format uses snake references: a `uint8` length followed by chained cell references containing the elements.
 
-Raw tuples are not serializable to cells, because `unknown` is unserializable. But they can be returned from [get methods](/tvm/get-method#get-methods), since contract getters operate directly on the stack.
+Raw tuples are not serializable to cells, because `unknown` is unserializable. But they can be returned from [get methods](/tolk/features/contract-getters), since contract getters operate directly on the stack.
diff --git a/tvm/builders-and-slices.mdx b/tvm/builders-and-slices.mdx
index a14b87710..c2888a81c 100644
--- a/tvm/builders-and-slices.mdx
+++ b/tvm/builders-and-slices.mdx
@@ -28,7 +28,7 @@ Then, put a number on the stack:
 1 INT  // stack: x{} 1
 ```
 
-And call [`STU`](/tvm/instructions#cb-stu) ("STore Unsigned integer") to store integer into builder (swapping builder and value to meet `STU` input order):
+And call [`STU`](/tvm/instructions#cbcc-stu) ("STore Unsigned integer") to store integer into builder (swapping builder and value to meet `STU` input order):
 
 ```fift Fift
 SWAP  // stack: 1 x{}
@@ -60,7 +60,7 @@ Slice allows reading data back from a cell, field by field. For example, deseria
 CTOS  // x{0001001011111111}
 ```
 
-Then, call [`LDU`](/tvm/instructions#d3-ldu) ("LoaD Unsigned integer") to read first value (`uint4`).
+Then, call [`LDU`](/tvm/instructions#d3cc-ldu) ("LoaD Unsigned integer") to read first value (`uint4`).
 
 ```fift Fift
 4 LDU  // 1 x{001011111111}
diff --git a/tvm/exit-codes.mdx b/tvm/exit-codes.mdx
index b9a9a0960..e34e09f18 100644
--- a/tvm/exit-codes.mdx
+++ b/tvm/exit-codes.mdx
@@ -6,51 +6,51 @@ import { Aside } from '/snippets/aside.jsx';
 
 An exit code is a 32-bit signed integer that indicates whether the compute or action phase of the transaction was successful. If not, it holds the code of the exception that occurred.
 
-Each transaction on TON Blockchain consists of multiple phases. An _exit code_ is a 32-bit signed integer that indicates whether the [compute](#compute) or [action](#action) phase of the transaction was successful, and if not, holds the code of the exception that occurred. Each exit code represents its own exception or the resulting state of the transaction.
+Each transaction on TON Blockchain consists of multiple phases. An _exit code_ is a 32-bit signed integer that indicates whether the [compute](#compute-phase) or [action](#action-phase) phase of the transaction was successful, and if not, holds the code of the exception that occurred. Each exit code represents its own exception or the resulting state of the transaction.
 
-Exit codes 0 and 1 indicate normal (successful) execution of the [compute phase](#compute). Exit (or [result](#action)) code 0 indicates normal (successful) execution of the [action phase](#action). Any other exit code indicates that a certain exception has occurred and that the transaction was not successful in one way or another, i.e., the transaction was reverted or the inbound message has bounced back.
+Exit codes 0 and 1 indicate normal (successful) execution of the [compute phase](#compute-phase). Exit (or [result](#action-phase)) code 0 indicates normal (successful) execution of the [action phase](#action-phase). Any other exit code indicates that a certain exception has occurred and that the transaction was not successful in one way or another, i.e., the transaction was reverted or the inbound message has bounced back.
 
 TON Blockchain reserves exit code values from 0 to 127. The range from 256 to 65535 is free for developer-defined exit codes.
 
 <Aside>
-  While an exit (or [result](#action)) code is a 32-bit signed integer on TON Blockchain, an attempt to throw an exit code outside the bounds of a 16-bit unsigned integer ($0 - 65535$) will cause an error with [exit code 5](#5%3A-integer-out-of-expected-range). This is done intentionally to prevent some exit codes from being produced artificially, such as [exit code -14](#-14%3A-out-of-gas-error).
+  While an exit (or [result](#action-phase)) code is a 32-bit signed integer on TON Blockchain, an attempt to throw an exit code outside the bounds of a 16-bit unsigned integer ($0 - 65535$) will cause an error with [exit code 5](#5-integer-out-of-expected-range). This is done intentionally to prevent some exit codes from being produced artificially, such as [exit code -14](#14-out-of-gas-error).
 </Aside>
 
 ## Table of exit codes
 
 The following table lists exit codes with their origin (where they can occur) and a short description for each.
 
-| Exit code                                                    | Origin                              | Brief description                                                                                      |
-| :----------------------------------------------------------- | :---------------------------------- | :----------------------------------------------------------------------------------------------------- |
-| [0](#0%3A-normal-termination)                                | [Compute][c] and [action][a] phases | Standard successful execution exit code.                                                               |
-| [1](#1%3A-alternative-termination)                           | [Compute phase][c]                  | Alternative successful execution exit code. Reserved, but does not occur.                              |
-| [2](#2%3A-stack-underflow)                                   | [Compute phase][c]                  | Stack underflow.                                                                                       |
-| [3](#3%3A-stack-overflow)                                    | [Compute phase][c]                  | Stack overflow.                                                                                        |
-| [4](#4%3A-integer-overflow)                                  | [Compute phase][c]                  | Integer overflow.                                                                                      |
-| [5](#5%3A-integer-out-of-expected-range)                     | [Compute phase][c]                  | Range check error — an integer is out of its expected range.                                           |
-| [6](#6%3A-invalid-opcode)                                    | [Compute phase][c]                  | Invalid [TVM][tvm] opcode.                                                                             |
-| [7](#7%3A-type-check-error)                                  | [Compute phase][c]                  | Type check error.                                                                                      |
-| [8](#8%3A-cell-overflow)                                     | [Compute phase][c]                  | Cell overflow.                                                                                         |
-| [9](#9%3A-cell-underflow)                                    | [Compute phase][c]                  | Cell underflow.                                                                                        |
-| [10](#10%3A-dictionary-error)                                | [Compute phase][c]                  | Dictionary error.                                                                                      |
-| [11](#11%3A-%22unknown%22-error)                             | [Compute phase][c]                  | Described in [TVM][tvm] docs as "Unknown error, may be thrown by user programs."                       |
-| [12](#12%3A-fatal-error)                                     | [Compute phase][c]                  | Fatal error. Thrown by [TVM][tvm] in situations deemed impossible.                                     |
-| [13](#13%3A-out-of-gas-error)                                | [Compute phase][c]                  | Out of gas error.                                                                                      |
-| [-14](#-14%3A-out-of-gas-error)                              | [Compute phase][c]                  | Same as 13. Negative, so that it [cannot be faked](#13%3A-out-of-gas-error).                           |
-| [14](#14%3A-virtualization-error)                            | [Compute phase][c]                  | VM virtualization error. Reserved, but never thrown.                                                   |
-| [32](#32%3A-action-list-is-invalid)                          | [Action phase][a]                   | Action list is invalid.                                                                                |
-| [33](#33%3A-action-list-is-too-long)                         | [Action phase][a]                   | Action list is too long.                                                                               |
-| [34](#34%3A-invalid-or-unsupported-action)                   | [Action phase][a]                   | Action is invalid or not supported.                                                                    |
-| [35](#35%3A-invalid-source-address-in-outbound-message)      | [Action phase][a]                   | Invalid source address in outbound message.                                                            |
-| [36](#36%3A-invalid-destination-address-in-outbound-message) | [Action phase][a]                   | Invalid destination address in outbound message.                                                       |
-| [37](#37%3A-not-enough-toncoin)                              | [Action phase][a]                   | Not enough Toncoin.                                                                                    |
-| [38](#38%3A-not-enough-extra-currencies)                     | [Action phase][a]                   | Not enough extra currencies.                                                                           |
-| [39](#39%3A-outbound-message-does-not-fit-into-cell)         | [Action phase][a]                   | Outbound message does not fit into a cell after rewriting.                                             |
-| [40](#40%3A-cannot-process-message)                          | [Action phase][a]                   | Cannot process a message — not enough funds, the message is too large, or its Merkle depth is too big. |
-| [41](#41%3A-library-reference-is-null)                       | [Action phase][a]                   | Library reference is null during library change action.                                                |
-| [42](#42%3A-library-change-action-error)                     | [Action phase][a]                   | Library change action error.                                                                           |
-| [43](#43%3A-library-limits-exceeded)                         | [Action phase][a]                   | Exceeded the maximum number of cells in the library or the maximum depth of the Merkle tree.           |
-| [50](#50%3A-account-state-size-exceeded-limits)              | [Action phase][a]                   | Account state size exceeded limits.                                                                    |
+| Exit code                                                 | Origin                              | Brief description                                                                                      |
+| :-------------------------------------------------------- | :---------------------------------- | :----------------------------------------------------------------------------------------------------- |
+| [0](#0-normal-termination)                                | [Compute][c] and [action][a] phases | Standard successful execution exit code.                                                               |
+| [1](#1-alternative-termination)                           | [Compute phase][c]                  | Alternative successful execution exit code. Reserved, but does not occur.                              |
+| [2](#2-stack-underflow)                                   | [Compute phase][c]                  | Stack underflow.                                                                                       |
+| [3](#3-stack-overflow)                                    | [Compute phase][c]                  | Stack overflow.                                                                                        |
+| [4](#4-integer-overflow)                                  | [Compute phase][c]                  | Integer overflow.                                                                                      |
+| [5](#5-integer-out-of-expected-range)                     | [Compute phase][c]                  | Range check error — an integer is out of its expected range.                                           |
+| [6](#6-invalid-opcode)                                    | [Compute phase][c]                  | Invalid [TVM][tvm] opcode.                                                                             |
+| [7](#7-type-check-error)                                  | [Compute phase][c]                  | Type check error.                                                                                      |
+| [8](#8-cell-overflow)                                     | [Compute phase][c]                  | Cell overflow.                                                                                         |
+| [9](#9-cell-underflow)                                    | [Compute phase][c]                  | Cell underflow.                                                                                        |
+| [10](#10-dictionary-error)                                | [Compute phase][c]                  | Dictionary error.                                                                                      |
+| [11](#11-%22unknown%22-error)                             | [Compute phase][c]                  | Described in [TVM][tvm] docs as "Unknown error, may be thrown by user programs."                       |
+| [12](#12-fatal-error)                                     | [Compute phase][c]                  | Fatal error. Thrown by [TVM][tvm] in situations deemed impossible.                                     |
+| [13](#13-out-of-gas-error)                                | [Compute phase][c]                  | Out of gas error.                                                                                      |
+| [-14](#14-out-of-gas-error)                               | [Compute phase][c]                  | Same as 13. Negative, so that it [cannot be faked](#13-out-of-gas-error).                              |
+| [14](#14-virtualization-error)                            | [Compute phase][c]                  | VM virtualization error. Reserved, but never thrown.                                                   |
+| [32](#32-action-list-is-invalid)                          | [Action phase][a]                   | Action list is invalid.                                                                                |
+| [33](#33-action-list-is-too-long)                         | [Action phase][a]                   | Action list is too long.                                                                               |
+| [34](#34-invalid-or-unsupported-action)                   | [Action phase][a]                   | Action is invalid or not supported.                                                                    |
+| [35](#35-invalid-source-address-in-outbound-message)      | [Action phase][a]                   | Invalid source address in outbound message.                                                            |
+| [36](#36-invalid-destination-address-in-outbound-message) | [Action phase][a]                   | Invalid destination address in outbound message.                                                       |
+| [37](#37-not-enough-toncoin)                              | [Action phase][a]                   | Not enough Toncoin.                                                                                    |
+| [38](#38-not-enough-extra-currencies)                     | [Action phase][a]                   | Not enough extra currencies.                                                                           |
+| [39](#39-outbound-message-does-not-fit-into-cell)         | [Action phase][a]                   | Outbound message does not fit into a cell after rewriting.                                             |
+| [40](#40-cannot-process-message)                          | [Action phase][a]                   | Cannot process a message — not enough funds, the message is too large, or its Merkle depth is too big. |
+| [41](#41-library-reference-is-null)                       | [Action phase][a]                   | Library reference is null during library change action.                                                |
+| [42](#42-library-change-action-error)                     | [Action phase][a]                   | Library change action error.                                                                           |
+| [43](#43-library-limits-exceeded)                         | [Action phase][a]                   | Exceeded the maximum number of cells in the library or the maximum depth of the Merkle tree.           |
+| [50](#50-account-state-size-exceeded-limits)              | [Action phase][a]                   | Account state size exceeded limits.                                                                    |
 
 {/* NOTE: Some might depend on a phase; in such cases, the table entry might be:
 
@@ -59,7 +59,7 @@ The following table lists exit codes with their origin (where they can occur) an
   */}
 
 <Aside>
-  Often enough, you might encounter the exit code 65535 (or `0xffff`), which usually means the same as the [exit code 130](#130%3A-) — the received opcode is unknown to the contract, as no receivers were expecting it. When writing contracts, the exit code 65535 is set by the developers and not by [TVM][tvm] or the Tolk compiler.
+  Often enough, you might encounter the exit code 65535 (or `0xffff`), which usually means that the received opcode is unknown to the contract, as no handlers were expecting it. The exit code 65535 is set in the smart contract code and not by [TVM][tvm] or the Tolk compiler.
 </Aside>
 
 [c]: /tvm/overview#compute-phase
@@ -67,17 +67,13 @@ The following table lists exit codes with their origin (where they can occur) an
 
 ## Exit codes in Blueprint projects
 
-In [Blueprint][bp] tests, exit codes from the [compute phase](#compute) are specified in the `exitCode` field of the object argument for the `toHaveTransaction()` method of the `expect()` matcher. The field for the [result](#action) codes (exit codes from the [action phase](#action)) in the same `toHaveTransaction()` method is called `actionResultCode`.
+In [Blueprint][bp] tests, exit codes from the [compute phase](#compute-phase) are specified in the `exitCode` field of the object argument for the `toHaveTransaction()` method of the `expect()` matcher. The field for the [result](#action-phase) codes (exit codes from the [action phase](#action-phase)) in the same `toHaveTransaction()` method is called `actionResultCode`.
 
-{/*
-  <Aside>
-
-  Read more about expecting specific exit codes: [Transactions with intentional errors](/book/debug#tests-errors).
-
-  </Aside>
-  */}
+<Aside type="note">
+  Read more about expecting specific exit codes: [Explore TVM logs](/contract-dev/blueprint/debug#explore-tvm-logs).
+</Aside>
 
-Additionally, one can examine the result of sending a message to a contract and discover the phases of each transaction and their values, including exit (or result) codes for the [compute phase](#compute) (or [action phase](#action)).
+Additionally, one can examine the result of sending a message to a contract and discover the phases of each transaction and their values, including exit (or result) codes for the [compute phase](#compute-phase) (or [action phase](#action-phase)).
 
 Note that to do so, you'll have to perform a couple of type checks first:
 
@@ -105,17 +101,17 @@ it('tests something, you name it', async () => {
 
 ### 0: Normal termination
 
-This exit (or [result](#action)) code indicates the successful completion of the [compute phase](#compute) (or [action phase](#action)) of the transaction.
+This exit (or [result](#action-phase)) code indicates the successful completion of the [compute phase](#compute-phase) (or [action phase](#action-phase)) of the transaction.
 
 ## Compute phase
 
 [TVM][tvm] initialization and all computations occur in the [compute phase][c].
 
-If the compute phase fails (the resulting exit code is neither [0](#0%3A-normal-termination) nor [1](#1%3A-alternative-termination)), the transaction skips the [action phase](#action) and proceeds to the bounce phase. In this phase, a bounce message is formed for transactions initiated by the inbound message.
+If the compute phase fails (the resulting exit code is neither [0](#0-normal-termination) nor [1](#1-alternative-termination)), the transaction skips the [action phase](#action-phase) and proceeds to the bounce phase. In this phase, a bounce message is formed for transactions initiated by the inbound message.
 
 ### 1: Alternative termination
 
-This is an alternative exit code for the successful execution of the [compute phase](#compute). It is reserved but never occurs.
+This is an alternative exit code for the successful execution of the [compute phase](#compute-phase). It is reserved but never occurs.
 
 ### 2: Stack underflow
 
@@ -301,7 +297,7 @@ fun onInternalMessage() {
 
 ### 7: Type check error
 
-If an argument to a primitive is of an incorrect value type or there is any other mismatch in types during the [compute phase](#compute), an error with exit code 7 is thrown: `Type check error`.
+If an argument to a primitive is of an incorrect value type or there is any other mismatch in types during the [compute phase](#compute-phase), an error with exit code 7 is thrown: `Type check error`.
 
 ```tolk title="Tolk"
 fun touch<T>(y: T): void asm "NOP" // so that the compiler doesn't remove instructions
@@ -448,7 +444,7 @@ Fatal error. Thrown by TVM in situations deemed impossible.
 
 ### 13: Out of gas error
 
-If there isn't enough gas to complete computations in the [compute phase](#compute), an error with exit code 13 is thrown: `Out of gas error`.
+If there isn't enough gas to complete computations in the [compute phase](#compute-phase), an error with exit code 13 is thrown: `Out of gas error`.
 
 However, this code isn't immediately shown as is — instead, the bitwise NOT operation is applied, changing the value from 13 to -14. Only then is the code displayed.
 
@@ -464,7 +460,7 @@ fun onInternalMessage() {
 
 ### -14: Out of gas error
 
-See [exit code 13](#13%3A-out-of-gas-error).
+See [exit code 13](#13-out-of-gas-error).
 
 ### 14: Virtualization error
 
@@ -472,21 +468,21 @@ Virtualization error related to pruned branch cells. Reserved but never thrown.
 
 ## Action phase
 
-The [action phase][a] is processed after the successful execution of the [compute phase](#compute). It attempts to perform the actions stored in the action list by [TVM][tvm] during the compute phase.
+The [action phase][a] is processed after the successful execution of the [compute phase](#compute-phase). It attempts to perform the actions stored in the action list by [TVM][tvm] during the compute phase.
 
-Some actions may fail during processing, in which case those actions may be skipped or the whole transaction may revert, depending on the mode of actions. The code indicating the resulting state of the [action phase][a] is called a _result code_. Since it is also a 32-bit signed integer that essentially serves the same purpose as the _exit code_ of the [compute phase](#compute), it is common to call the result code an exit code as well.
+Some actions may fail during processing, in which case those actions may be skipped or the whole transaction may revert, depending on the mode of actions. The code indicating the resulting state of the [action phase][a] is called a _result code_. Since it is also a 32-bit signed integer that essentially serves the same purpose as the _exit code_ of the [compute phase](#compute-phase), it is common to call the result code an exit code as well.
 
 ### 32: Action list is invalid
 
 If the list of actions contains exotic cells, an action entry cell does not have references, or some action entry cell cannot be parsed, an error with exit code 32 is thrown: `Action list is invalid`.
 
 <Aside>
-  Aside from this exit code, there is a boolean flag `valid`, which you can find under `description.actionPhase.valid` in the transaction results when working with [Sandbox and Blueprint](#blueprint). A transaction can set this flag to `false` even when there is some other exit code thrown from the action phase.
+  Aside from this exit code, there is a boolean flag `valid`, which you can find under `description.actionPhase.valid` in the transaction results when working with [Sandbox and Blueprint](#exit-codes-in-blueprint-projects). A transaction can set this flag to `false` even when there is some other exit code thrown from the action phase.
 </Aside>
 
 ### 33: Action list is too long
 
-If there are more than 255 actions queued for execution, the [action phase](#action) will throw an error with an exit code 33: `Action list is too long`.
+If there are more than 255 actions queued for execution, the [action phase](#action-phase) will throw an error with an exit code 33: `Action list is too long`.
 
 ```tolk title="Tolk"
 import "@stdlib/gas-payments";
@@ -568,7 +564,7 @@ If the maximum number of cells in the library is exceeded or the maximum depth o
 
 ### 50: Account state size exceeded limits
 
-If the account state (contract storage, essentially) exceeds any of the limits specified in [config param 43 of TON Blockchain](/foundations/config#param-43-account-and-message-limits) by the end of the [action phase](#action), an error with exit code 50 is thrown: `Account state size exceeded limits`.
+If the account state (contract storage, essentially) exceeds any of the limits specified in [config param 43 of TON Blockchain](/foundations/config#param-43-account-and-message-limits) by the end of the [action phase](#action-phase), an error with exit code 50 is thrown: `Account state size exceeded limits`.
 
 If the configuration is absent, the default values are:
 
@@ -583,12 +579,14 @@ If the configuration is absent, the default values are:
 - `max_acc_public_libraries` is equal to $2^{8}$ — maximum number of library reference cells that an account state can use on the masterchain.
 - `defer_out_queue_size_limit` is equal to $2^{8}$ — maximum number of outbound messages to be queued (regarding validators and collators).
 
-{/* NOTE: Reserved a section until Tolk introduces any custom exit codes.
+## Tolk compiler
 
-  ## Tolk compiler
+Tolk utilizes exit codes below 128. Note that exit codes used by Tolk indicate contract errors which can occur when using Tolk-generated code and are therefore thrown in the transaction's [compute phase](#compute-phase), not during compilation.
 
-  Tolk utilizes exit codes from 128 to 255. Note that exit codes used by Tolk indicate contract errors which can occur when using Tolk-generated code and are therefore thrown in the transaction's [compute phase](#compute), not during compilation.
-  */}
+- **0:** When the `onBouncedMessage()` handler is not defined, all bounced messages are rejected with an [exit code 0](#0-normal-termination), which is considered a normal termination.
+- **5:** If there is an exhaustive enum `match` fallthrough or an enum deserialization range or membership check, an [exit code 5: integer out of expected range](#5-integer-out-of-expected-range) is thrown.
+- **9:** If there is a slice or array deserialization invalidation, an [exit code 9: cell underflow](#9-cell-underflow) is thrown.
+- **63:** If there is an opcode (or prefix) mismatch when unpacking a struct, a Tolk-specific exit code 63 is thrown. Additionally, it is the default exit code for `throwIfOpcodeDoesNotMatch()` function, which can be overridden.
 
 [tlb]: /languages/tl-b/overview
 [tvm]: /tvm/overview
diff --git a/tvm/gas.mdx b/tvm/gas.mdx
index c3a591598..179bf7289 100644
--- a/tvm/gas.mdx
+++ b/tvm/gas.mdx
@@ -10,12 +10,12 @@ Each instruction consumes a fixed amount of `10` gas and `1` gas for each bit of
 
 Examples:
 
-| Instruction                                             | TL-B                                                                                             | Gas  | Notes                                                                                                                                              |
-| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
-| [`NEWC`](/tvm/instructions#c8-newc)                     | `#C8`                                                                                            | `18` | 8-bit prefix without operands                                                                                                                      |
-| [`STU`](/tvm/instructions#cb-stu)                       | `#CB` <br />`cc:uint8`                                                                           | `26` | 8-bit prefix, 8-bit operand                                                                                                                        |
-| [`PUSHINT_LONG`](/tvm/instructions#82-pushint_long)     | `#82` <br />`l:(## 5)` <br />`xxx:(int (8 * l + 19))`                                            | `23` | 8-bit prefix, 5-bit operand, length of `xxx` depends on `l`, so it is not included                                                                 |
-| [`STSLICE_CONST`](/tvm/instructions#cfc0_-stsliceconst) | `#CFC0_` <br />`x:(## 2)` <br />`y:(## 3)` <br />`c:(x * ^Cell)` <br />`sss:((8 * y + 2) * Bit)` | `24` | 9-bit prefix (`CF` is 8 bits, `C0_` is `C_`, which is just bit `1`), 2-bit and 3-bit operands, refs `c` and variable-length `sss` are not included |
+| Instruction                                                 | TL-B                                                                                             | Gas  | Notes                                                                                                                                              |
+| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [`NEWC`](/tvm/instructions#c8-newc)                         | `#C8`                                                                                            | `18` | 8-bit prefix without operands                                                                                                                      |
+| [`STU`](/tvm/instructions#cbcc-stu)                         | `#CB` <br />`cc:uint8`                                                                           | `26` | 8-bit prefix, 8-bit operand                                                                                                                        |
+| [`PUSHINT_LONG`](/tvm/instructions#82lxxx-pushint_long)     | `#82` <br />`l:(## 5)` <br />`xxx:(int (8 * l + 19))`                                            | `23` | 8-bit prefix, 5-bit operand, length of `xxx` depends on `l`, so it is not included                                                                 |
+| [`STSLICE_CONST`](/tvm/instructions#cfc_xysss-stsliceconst) | `#CFC0_` <br />`x:(## 2)` <br />`y:(## 3)` <br />`c:(x * ^Cell)` <br />`sss:((8 * y + 2) * Bit)` | `24` | 9-bit prefix (`CF` is 8 bits, `C0_` is `C_`, which is just bit `1`), 2-bit and 3-bit operands, refs `c` and variable-length `sss` are not included |
 
 ## Cell operations
 
@@ -28,7 +28,7 @@ This applies to all instructions that internally operate with cells (including d
 
 ## Exceptions
 
-TVM consumes `50` gas when any exception is thrown, both explicitly by [`THROW`](/tvm/instructions#f2c4_-throw)-like instructions or implicitly during execution of other instructions. This happens before the jump to the exception handler `c2`.
+TVM consumes `50` gas when any exception is thrown, both explicitly by [`THROW`](/tvm/instructions#f2c4_n-throw)-like instructions or implicitly during execution of other instructions. This happens before the jump to the exception handler `c2`.
 
 ## Implicit jumps and returns
 
@@ -40,11 +40,11 @@ Calling more than `8` extraordinary continuations in a chain consumes `1` gas fo
 
 ## Tuple operations
 
-[`TUPLE`](/tvm/instructions#6f0-tuple), [`TUPLEVAR`](/tvm/instructions#6f80-tuplevar), [`UNTUPLE`](/tvm/instructions#6f2-untuple), [`UNTUPLEVAR`](/tvm/instructions#6f82-untuplevar), [`UNPACKFIRST`](/tvm/instructions#6f3-unpackfirst), [`UNPACKFIRSTVAR`](/tvm/instructions#6f83-unpackfirstvar), [`EXPLODE`](/tvm/instructions#6f4-explode), [`EXPLODEVAR`](/tvm/instructions#6f84-explodevar) consumes `1` gas for each entry been pushed or popped into a tuple. [`TPUSH`](/tvm/instructions#6f8c-tpush), [`TPOP`](/tvm/instructions#6f8d-tpop), [`SETINDEX`](/tvm/instructions#6f5-setindex), [`SETINDEXVAR`](/tvm/instructions#6f85-setindexvar), [`SETINDEXQ`](/tvm/instructions#6f7-setindexq)/[`SETINDEXVARQ`](/tvm/instructions#6f87-setindexvarq) consumes `len(tuple)` gas for the resulting tuple size after push/pop/set. Same applies to instructions operating with `c7`: [`SETGLOB`](/tvm/instructions#f87_-setglob)/[`SETGLOBVAR`](/tvm/instructions#f860-setglobvar), [`RANDU256`](/tvm/instructions#f810-randu256)/[`RAND`](/tvm/instructions#f811-rand), [`SETRAND`](/tvm/instructions#f814-setrand), [`ADDRAND`](/tvm/instructions#f815-addrand).
+[`TUPLE`](/tvm/instructions#6f0n-tuple), [`TUPLEVAR`](/tvm/instructions#6f80-tuplevar), [`UNTUPLE`](/tvm/instructions#6f2n-untuple), [`UNTUPLEVAR`](/tvm/instructions#6f82-untuplevar), [`UNPACKFIRST`](/tvm/instructions#6f3k-unpackfirst), [`UNPACKFIRSTVAR`](/tvm/instructions#6f83-unpackfirstvar), [`EXPLODE`](/tvm/instructions#6f4n-explode), [`EXPLODEVAR`](/tvm/instructions#6f84-explodevar) consumes `1` gas for each entry been pushed or popped into a tuple. [`TPUSH`](/tvm/instructions#6f8c-tpush), [`TPOP`](/tvm/instructions#6f8d-tpop), [`SETINDEX`](/tvm/instructions#6f5k-setindex), [`SETINDEXVAR`](/tvm/instructions#6f85-setindexvar), [`SETINDEXQ`](/tvm/instructions#6f7k-setindexq)/[`SETINDEXVARQ`](/tvm/instructions#6f87-setindexvarq) consumes `len(tuple)` gas for the resulting tuple size after push/pop/set. Same applies to instructions operating with `c7`: [`SETGLOB`](/tvm/instructions#f87_k-setglob)/[`SETGLOBVAR`](/tvm/instructions#f860-setglobvar), [`RANDU256`](/tvm/instructions#f810-randu256)/[`RAND`](/tvm/instructions#f811-rand), [`SETRAND`](/tvm/instructions#f814-setrand), [`ADDRAND`](/tvm/instructions#f815-addrand).
 
 ## Stack operations
 
-TVM consumes 1 gas for each stack element deeper than 32 elements inside the resulting new stack each time stack gets copied: when calling or jumping to a continuation with a non-empty argument number, an initial stack, or both, when extending a continuation stack using [`SETCONTARGS`](/tvm/instructions#ec-setcontargs_n) and similar instructions, when using [`RUNVM`](/tvm/instructions#db4-runvm) (both for initial and resulting stacks of the vm).
+TVM consumes 1 gas for each stack element deeper than 32 elements inside the resulting new stack each time stack gets copied: when calling or jumping to a continuation with a non-empty argument number, an initial stack, or both, when extending a continuation stack using [`SETCONTARGS`](/tvm/instructions#ecrn-setcontargs_n) and similar instructions, when using [`RUNVM`](/tvm/instructions#db4fff-runvm) (both for initial and resulting stacks of the vm).
 
 ## Extra currency
 
@@ -52,7 +52,7 @@ The first `5` executions of `GETEXTRABALANCE` consume at most `26 + 200` gas eac
 
 ## RUNVM
 
-[`RUNVM`](/tvm/instructions#db4-runvm) and [`RUNVMX`](/tvm/instructions#db50-runvmx) consume `40` extra gas before starting a VM.
+[`RUNVM`](/tvm/instructions#db4fff-runvm) and [`RUNVMX`](/tvm/instructions#db50-runvmx) consume `40` extra gas before starting a VM.
 
 ## Cryptography
 
diff --git a/tvm/overview.mdx b/tvm/overview.mdx
index e2f668e50..975926969 100644
--- a/tvm/overview.mdx
+++ b/tvm/overview.mdx
@@ -32,7 +32,7 @@ The total state of TVM consists of the following components:
 - [**Control registers**](/tvm/registers). A small fixed set of special registers, denoted as `c0`, `c1`, ..., `c5`, and `c7` (`c6` does not exist).
 - [**Gas counter**](/tvm/gas). Tracks remaining computation budget. Each instruction decrements gas. When counter hits zero/negative value, an exception is raised, and the run aborts.
 - **Current continuation (`cc`)**. A special register that stores a list of the next instructions to execute. Similar to the instruction pointer in traditional architectures.
-- **Current codepage (`cp`)**. Determines how to decode the next instruction in `cc`. Different codepages may implement different instruction sets, allowing for adding new features to TVM without affecting old smart contracts. Currently, only codepage `0` (`cp0`) is implemented. Smart contract runs [`SETCP0`](/tvm/instructions#ff-setcp) instruction to explicitly use codepage `0`.
+- **Current codepage (`cp`)**. Determines how to decode the next instruction in `cc`. Different codepages may implement different instruction sets, allowing for adding new features to TVM without affecting old smart contracts. Currently, only codepage `0` (`cp0`) is implemented. Smart contract runs [`SETCP0`](/tvm/instructions#ffnn-setcp) instruction to explicitly use codepage `0`.
 
 ## TVM data types
 
diff --git a/tvm/registers.mdx b/tvm/registers.mdx
index fa94b21f3..edeee52f4 100644
--- a/tvm/registers.mdx
+++ b/tvm/registers.mdx
@@ -29,7 +29,7 @@ Same as `c0`, but invoked only in special control flow instructions, such as [`R
 
 **Initial value**: `ExcQuit` — extraordinary continuation which terminates TVM with an exception. In this case, the exit code is an exception number.
 
-Invoked implicitly on any exception that occurs during TVM execution. Can be invoked explicitly by [`THROW`](/tvm/instructions#f2c4_-throw)-like instructions. To set a custom exception handler, use [TRY](/tvm/instructions#f2ff-try).
+Invoked implicitly on any exception that occurs during TVM execution. Can be invoked explicitly by [`THROW`](/tvm/instructions#f2c4_n-throw)-like instructions. To set a custom exception handler, use [TRY](/tvm/instructions#f2ff-try).
 
 ## `c3` — function selector
 
@@ -37,7 +37,7 @@ Invoked implicitly on any exception that occurs during TVM execution. Can be inv
 
 **Initial value**: Root cell of code currently executing in TVM.
 
-Invoked by [`CALLDICT`](/tvm/instructions#f0-calldict) instruction with a function ID (integer) passed on the stack. The function selector should jump to a function with that ID.
+Invoked by [`CALLDICT`](/tvm/instructions#f0nn-calldict) instruction with a function ID (integer) passed on the stack. The function selector should jump to a function with that ID.
 
 Fift-ASM assembler constructs following function selector ([`Asm.fif`:1624](https://github.com/ton-blockchain/ton/blob/4ebd7412c52248360464c2df5f434c8aaa3edfe1/crypto/fift/lib/Asm.fif#L1624)):
 
@@ -89,7 +89,7 @@ The previous action is always the first reference of the next one. If action its
 
 **Initial value**: `Tuple[Tuple[0x076ef1ea, 0, 0, ...]]`.
 
-The zero element of the `c7` tuple is an environment information (which itself is also a tuple). The remaining 255 slots are used for global variables. [`[i] SETGLOB`](/tvm/instructions#f87_-setglob) modifies `c7`, inserting an element with index `i`, [`[i] GETGLOB`](/tvm/instructions#f85_-getglob) reads `i`-th element from `c7`.
+The zero element of the `c7` tuple is an environment information (which itself is also a tuple). The remaining 255 slots are used for global variables. [`[i] SETGLOB`](/tvm/instructions#f87_k-setglob) modifies `c7`, inserting an element with index `i`, [`[i] GETGLOB`](/tvm/instructions#f85_k-getglob) reads `i`-th element from `c7`.
 
 ### Structure of environment information tuple