tact-lang · anton-trunov · Oct 9, 2025 · Oct 7, 2025 · Oct 8, 2025 · Oct 9, 2025
diff --git a/.vale/config/vocabularies/Custom/accept.txt b/.vale/config/vocabularies/Custom/accept.txt
@@ -30,6 +30,7 @@ Brodie
 Brujn
 Buildx
 Burnosov
+Buterin
 CEX(s|es)?
 CLion
 CMake
@@ -99,6 +100,7 @@ Interchain
 Jetbrains
 Jettons
 Kademlia
+Kelmer
 Kiayas
 Kol
 Kolya
@@ -115,6 +117,7 @@ MTProto
 MTon
 Mainnet
 Masterchain
+Maymounkov
 Memoizing
 Merkle
 Metaverse
@@ -144,6 +147,7 @@ PRNGs
 Pavel
 Pease
 Permissionless
+Peyton
 Phaser
 Precompiled
 Preloads
@@ -171,13 +175,15 @@ Schnorr
 Sedov
 Serializable
 Sharding
+Shokrollahi
 Shostak
 Singlechain
 Snarkjs
 Solana
 Soulbound
 Spellbook
 Stablecoins?
+Syverson
 TEPs
 TMAs
 TVM('s|s)?
@@ -207,6 +213,7 @@ Unary
 Underload
 Uninit
 Universa
+Upgradability
 VMs
 VPNs
 VSCodium
@@ -371,6 +378,7 @@ codepages?
 codepoints?
 codespaces?
 codomain
+cofactors?
 combinator('s|s)?
 componentwise
 composable
@@ -481,6 +489,7 @@ Gigatons
 Gilmanova
 Gitpod
 globals
+Goldschlag
 Golev
 Grafana
 globals
@@ -538,7 +547,9 @@ Kol
 Kol
 Kolya
 kTon
+Larimer
 Latinisms
+Luby
 leaderboard
 leaderboard
 linkability
@@ -601,6 +612,7 @@ multisignature
 mytoncore
 mytonctrl
 namespace
+Nakamoto
 Namespace
 namespace
 namespaces?
@@ -773,6 +785,7 @@ stdlib
 STON.fi
 styleguide
 subarrays
+subcases?
 subcell
 subcolumn
 subcolumnTblkch

diff --git a/language/fift/whitepaper.mdx b/language/fift/whitepaper.mdx
@@ -7,7 +7,9 @@ noindex: "true"
 
 import { Aside } from '/snippets/aside.jsx';
 
-> Nikolai Durov. July 4, 2019
+**Author**: Nikolai Durov <br />
+**Date**: July 4, 2019 <br />
+<Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/fiftbase.pdf)
 
 ## Introduction
 

diff --git a/ton/catchain.mdx b/ton/catchain.mdx
@@ -1,11 +1,12 @@
 ---
 title: "Catchain consensus: an outline"
-sidebarTitle: "Catchain Consensus"
+sidebarTitle: "Catchain consensus"
 description: "Whitepaper by Dr. Nikolai Durov"
 ---
 
-**Nikolai Durov**
-_February 19, 2020_
+**Authors**: Nikolai Durov <br />
+**Date**: February 19, 2020 <br />
+<Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/catchain.pdf)
 
 ## Abstract
 
@@ -295,7 +296,7 @@

 • After that, the value of $\sigma_{D_m^+}$ is computed by an application of $f$: $\sigma_{D_m^+} = f(\sigma_{D_m}, m)$. This value is memorized for future use.

 • Finally, when a new message $m$ is delivered to the current process $i$, thus updating $C_i$ to $C'_i := C_i \cup \{m\}$, the algorithm uses the computed value $\sigma_{D_m^+}$ to update the current state

 ```math
 \sigma_{C'_i} = g(\sigma_{C_i}, \sigma_{D_m^+})
@@ -359,7 +360,7 @@

 ### 3.3. State recovery after restart or crashes

 A catchain is typically used by the BCP for several minutes; during this period, the program (the validator software) running the Catchain protocol may be terminated and restarted, either deliberately (e.g., because of a scheduled software update) or unintentionally (the program might crash because of a bug in this or some other subsystem, and be restarted afterwards). One way of dealing with this situation would be to ignore all catchains not created after the last restart. However, this would lead to some validators not participating in creating any blocks for several minutes (until the next catchain instances are created), which is undesirable. Therefore, a catchain state recovery protocol is run instead after every restart, so that the validator can continue participating in the same catchain.

 #### 3.3.1. Database of all delivered messages


diff --git a/ton/tblkch.mdx b/ton/tblkch.mdx
@@ -4,8 +4,9 @@
 description: "Whitepaper by Dr. Nikolai Durov"
 ---
 
-**Nikolai Durov**
-*February 8, 2020*
+**Authors**: Nikolai Durov <br />
+**Date**: February 8, 2020 <br />
+<Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/tblkch.pdf)
 
 ## Abstract
 
@@ -260,7 +261,7 @@
 There are several kinds of consistency conditions imposed on the TON Blockchain:

 - **Global conditions** — Express the invariants throughout the entire TON Blockchain. For instance, the message delivery guarantees, which assert that each message generated must be delivered to its destination account and delivered exactly once, are part of the global conditions.
 - **Internal (local) conditions** — Express the conditions imposed on the data kept inside one block. For example, each transaction included in the block (i.e., present in the transaction list of some account) processes exactly one inbound message; this inbound message must be listed in the `InMsgDescr` structure of the block as well.
 - **External (local) conditions** — Express the conditions imposed on the data of different blocks, usually belonging to the same or to neighboring shardchains (with respect to Hypercube Routing). Therefore, the external conditions come in several flavors:
  - **Antecessor/successor conditions** — Express the conditions imposed on the data of some block and of its immediate antecessor or (in the case of a preceding shardchain merge event) two immediate antecessors. The most important of these conditions is the one stating that the initial state for a shardchain block must coincide with final shardchain state of the immediate antecessor block, provided no shardchain split/merge event happened in between.
  - **Masterchain/shardchain conditions** — Express the conditions imposed on a shardchain block and on the masterchain block that refers to it in its `ShardHashes` list or is referred to in the header of the shardchain block.
@@ -285,7 +286,7 @@

 ### 1.3.7. Constructive elimination of existence quantifiers

 The local conditions one might want to impose sometimes are non-constructible, meaning that they do not necessarily contain an explanation of why they are true.

 A typical example of such a condition `C` is given by

@@ -1463,7 +1464,7 @@
 The state of an account is represented by an instance of type `Account`, described by the following TL-B scheme:[³⁰](#footnote-30)

 ```c
 account_none$0 = Account;
 account$1 addr:MsgAddressInt storage_stat:StorageInfo
 storage:AccountStorage = Account;


diff --git a/ton/ton.mdx b/ton/ton.mdx
@@ -4,9 +4,9 @@
 description: "Whitepaper by Dr. Nikolai Durov"
 ---
 
-based on the work of Dr. Nikolai Durov
-
-**July 26, 2021**
+**Authors**: Nikolai Durov, TON Core <br />
+**Date**: July 26, 2021 <br />
+<Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/ton.pdf)
 
 ## Abstract
 
@@ -1204,7 +1204,7 @@

 ### 2.7.9. Performing merge operations

 After that, when the validators from the union of the two original task groups are ready to become validators for the merged shardchain (this might involve a state transfer from the sibling shardchain and a state merge operation), they commit a merge commit flag in the headers of blocks of their shardchain (this event is propagated to the next masterchain blocks), and stop creating new blocks in separate shardchains (once the merge commit ag appears, creating blocks in separate shardchains is forbidden). Instead, a merged shardchain block is created (by the union of the two original task groups), referring to both of its preceding blocks in its header. This is reflected in the next masterchain block, which will contain the hash of the newly created block of the merged shardchain. After that, the merged task group continues creating blocks in the merged shardchain.

 ---

@@ -1405,7 +1405,7 @@
 | EOS       | 2016, (2018)| 4| DPoS      | yes| m   | ht.  | no   | L    |
 | PolkaDot  | 2016, (2019)| 4| PoS BFT   | yes| m   | ht.  | no   | L    |
 | Cosmos    | 2017, ?   | 4  | PoS BFT   | yes| m   | ht.  | no   | L    |
 | **TON**   | 2017, (2018)| 5| PoS BFT   | yes| m   | mix  | dyn. | T    |

 **Table Legend**: Project – project name; Year – year announced and year deployed; G. – generation (cf. [2.8.15](#2-8-15-simplified-classification-generations-of-blockchain-projects)); Cons. – consensus algorithm (cf. [2.8.3](#2-8-3-creating-and-validating-blocks%3A-proof-of-work-vs-proof-of-stake) and [2.8.4](#2-8-4-variants-of-proof-of-stake-dpos-vs-bft)); Sm. – support for arbitrary code (smart contracts; cf. [2.8.6](#2-8-6-support-for-turing-complete-code-in-transactions%2C-i-e-%2C-essentially-arbitrary-smart-contracts)); Ch. – single/multiple blockchain system (cf. [2.8.2](#2-8-2-single-blockchain-vs-multi-blockchain-projects)); R. – heterogeneous/homogeneous multichain systems (cf. [2.8.8](#2-8-8-blockchain-types%3A-homogeneous-and-heterogeneous-systems)); Sh. – sharding support (cf. [2.8.12](#2-8-12-sharding-support)); Int. – interaction between blockchains, (L)oose or (T)ight (cf. [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems)).

@@ -1443,7 +1443,7 @@

 ### 2.9.7. EOS [5]; https://eos.io

 EOS (2018 or later) is a proposed heterogeneous multi-blockchain DPoS system with smart contract support and with some minimal support for messaging (still loosely-coupled in the sense described in [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems)). It is an attempt by the same team that has previously successfully created the BitShares and SteemIt projects, demonstrating the strong points of the DPoS consensus algorithm. Scalability will be achieved by creating specialized workchains for projects that need it (e.g., a distributed exchange might use a workchain supporting a special set of optimized transactions, similarly to what BitShares did) and by creating multiple workchains with the same rules (confederations in the sense described in [2.8.10](#2-8-10-heterogeneous-systems-with-several-workchains-having-the-same-rules%2C-or-confederations)). The drawbacks and limitations of this approach to scalability have been discussed in _loc._, _cit._ Cf. also [2.8.5](#2-8-5-comparison-of-dpos-and-bft-pos), [2.8.12](#2-8-12-sharding-support), and [2.8.14](#2-8-14-interaction-between-blockchains%3A-loosely-coupled-and-tightly-coupled-systems) for a more detailed discussion of DPoS, sharding, interaction between workchains and their implications for the scalability of a blockchain system.

 At the same time, even if one will not be able to create a Facebook inside a blockchain (cf. [2.9.13](#2-9-13-is-it-possible-to-upload-facebook-into-a-blockchain%3F)), EOS or otherwise, we think that EOS might become a convenient platform for some highly-specialized weakly interacting distributed applications, similar to BitShares (decentralized exchange) and SteemIt (decentralized blog platform).


diff --git a/ton/tvm.mdx b/ton/tvm.mdx
@@ -4,8 +4,9 @@
 description: "Whitepaper by Dr. Nikolai Durov"
 ---
 
-*Nikolai Durov*
-*March 23, 2020*
+**Author**: Nikolai Durov <br />
+**Date**: March 23, 2020 <br />
+<Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/tvm.pdf)
 
 ## Abstract
 
@@ -643,7 +644,7 @@
 
 In addition to the cell serialization primitives for certain built-in value types described above, there are simple primitives that create a new empty Builder and push it into the stack (`NEWC`), or transform a Builder into a Cell (`ENDC`), thus finishing the cell creation process. An `ENDC` can be combined with a `STREF` into a single instruction `ENDCST`, which finishes the creation of a cell and immediately stores a reference to it in an “outer” Builder. There are also primitives that obtain the quantity of data bits or references already stored in a Builder, and check how many data bits or references can be stored.
 
-### 3.2.11 Taxonomy of cell deserialisation primitives
+### 3.2.11 Taxonomy of cell deserialization primitives
 
 Cell parsing, or deserialization, primitives can be classified as described in [3.2.6](#3-2-6-taxonomy-of-cell-creation-serialization-primitives), with the following modifications:
 
@@ -658,7 +659,7 @@
 
 ### 3.2.12 Other cell slice primitives
 
-In addition to the cell deserialisation primitives outlined above, TVM provides some obvious primitives for initializing and completing the cell deserialization process. For instance, one can convert a Cell into a Slice (`CTOS`), so that its deserialisation might begin; or check whether a Slice is empty, and generate an exception if it is not (`ENDS`); or deserialize a cell reference and immediately convert it into a Slice (`LDREFTOS`, equivalent to two instructions `LDREF` and `CTOS`).
+In addition to the cell deserialization primitives outlined above, TVM provides some obvious primitives for initializing and completing the cell deserialization process. For instance, one can convert a Cell into a Slice (`CTOS`), so that its deserialization might begin; or check whether a Slice is empty, and generate an exception if it is not (`ENDS`); or deserialize a cell reference and immediately convert it into a Slice (`LDREFTOS`, equivalent to two instructions `LDREF` and `CTOS`).
 
 ### 3.2.13 Modifying a serialized value in a cell
 
@@ -967,7 +968,7 @@
 
 TVM usually performs the following operations:
 
-If the current continuation `cc` is an ordinary one, it decodes the first instruction from the Slice `code`, similarly to the way other cells are deserialized by TVM `LD*` primitives (cf. [3.2](#3-2-data-manipulation-instructions-and-cells) and [3.2.11](#3-2-11-taxonomy-of-cell-deserialisation-primitives)): it decodes the opcode first, and then the parameters of the instruction (e.g., 4-bit fields indicating “stack registers” involved for stack manipulation primitives, or constant values for “push constant” or “literal” primitives). The remainder of the Slice is then put into the code of the new `cc`, and the decoded operation is executed on the current stack. This entire process is repeated until there are no operations left in `cc.code`.
+If the current continuation `cc` is an ordinary one, it decodes the first instruction from the Slice `code`, similarly to the way other cells are deserialized by TVM `LD*` primitives (cf. [3.2](#3-2-data-manipulation-instructions-and-cells) and [3.2.11](#3-2-11-taxonomy-of-cell-deserialization-primitives)): it decodes the opcode first, and then the parameters of the instruction (e.g., 4-bit fields indicating “stack registers” involved for stack manipulation primitives, or constant values for “push constant” or “literal” primitives). The remainder of the Slice is then put into the code of the new `cc`, and the decoded operation is executed on the current stack. This entire process is repeated until there are no operations left in `cc.code`.
 
 If the code is empty (i.e., contains no bits of data and no references), or if a (rarely needed) explicit subroutine return (`RET`) instruction is encountered, the current continuation is discarded, and the “return continuation” from control register `c0` is loaded into `cc` instead (this process is discussed in more detail starting in [4.1.6](#4-1-6-switching-to-another-continuation%3A-jmp-and-ret)).<sup id="ref-20">[20](#footnote-20)</sup> Then the execution continues by parsing operations from the new current continuation.
 
@@ -1248,7 +1249,7 @@

 This roughly corresponds to defining an auxiliary function `body` with three arguments `n`, `x`, and `f`, such that `body(n, x, f)` equals `x` if `n < 2` and `f(n − 1, nx, f)` otherwise, then invoking `body(n, 1, body)` to compute the factorial of `n`. The recursion is then implemented with the aid of the `DUP; EXECUTE` construction, or `DUP; JMPX` in the case of tail recursion. This trick is equivalent to applying Y-combinator to a function body.

 ### 4.6.3 A variant of Y-combinator solution
 Another way of recursively computing the factorial, more closely following the classical recursive definition:

 ```math
@@ -1445,7 +1446,7 @@
 If a (generic) instruction uses a simple encoding with an `ℓ`-bit opcode, then the instruction will utilize `2⁻ℓ` portion of the opcode space. This observation might be useful for considerations described in [5.2.9](#5-2-9-almost-optimal-encodings) and [5.2.10](#5-2-10-example-stack-manipulation-primitives).
 
 ### 5.2.12 Optimizing code density further: Huffman codes
-One might construct optimally dense binary code for the set of all complete instructions, provided their probabilities or frequences in real code are known. This is the well-known Huffman code (for the given probability distribution). However, such code would be highly unsystematic and hard to decode.
+One might construct optimally dense binary code for the set of all complete instructions, provided their probabilities or frequencies in real code are known. This is the well-known Huffman code (for the given probability distribution). However, such code would be highly unsystematic and hard to decode.
 
 ### 5.2.13 Practical instruction encodings
 In practice, instruction encodings used in TVM and other virtual machines offer a compromise between code density and ease of encoding and decoding. Such a compromise may be achieved by selecting simple encodings (cf. [5.2.11](#5-2-11-simple-encodings-of-instructions)) for all instructions (maybe with separate simple encodings for some often used variants, such as `XCHG s0,s(i)` among all `XCHG s(i),s(j)`), and allocating opcode space for such simple encodings using the heuristics outlined in [5.2.9](#5-2-9-almost-optimal-encodings) and [5.2.10](#5-2-10-example-stack-manipulation-primitives); this is the approach currently used in TVM.
@@ -2412,7 +2413,7 @@
   returns 0 on failure.
 
 * `D741` — `SCHKBITS (sl– )`, checks whether there are at least `l` data bits
-  in Slice s. If this is not the case, throws a cell deserialisation (i.e., cell
+  in Slice s. If this is not the case, throws a cell deserialization (i.e., cell
   underflow) exception.
 
 * `D742` — `SCHKREFS (sr–)`, checks whether there are at least `r` references

diff --git a/ton/whitepapers.mdx b/ton/whitepapers.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Whitepapers"
-sidebar: "Overview"
+sidebarTitle: "Overview"
 ---
 
 import { Aside } from '/snippets/aside.jsx';

diff --git a/tvm/instructions.mdx b/tvm/instructions.mdx
@@ -2280,7 +2280,7 @@ Category: cell_parse Cell Parse
 
 #### `D741` SCHKBITS
 Fift: SCHKBITS
-Description: Checks whether there are at least `l` data bits in _Slice_ `s`. If this is not the case, throws a cell deserialisation (i.e., cell underflow) exception.
+Description: Checks whether there are at least `l` data bits in _Slice_ `s`. If this is not the case, throws a cell deserialization (i.e., cell underflow) exception.
 Category: cell_parse Cell Parse
 
 #### `D742` SCHKREFS