diff --git a/ton/tvm.mdx b/ton/tvm.mdx
index 925c0d94..09fae850 100644
--- a/ton/tvm.mdx
+++ b/ton/tvm.mdx
@@ -4,6 +4,8 @@ sidebarTitle: "TVM"
 description: "Whitepaper by Dr. Nikolai Durov"
 ---
 
+import { Aside } from '/snippets/aside.jsx';
+
 **Author**: Nikolai Durov <br />
 **Date**: March 23, 2020 <br />
 <Icon icon="file-pdf" size={16} />: [Original whitepaper, PDF](/resources/pdfs/tvm.pdf)
@@ -12,6 +14,11 @@ description: "Whitepaper by Dr. Nikolai Durov"
 
 The aim of this text is to provide a description of the Telegram Open Network Virtual Machine (TON VM or TVM), used to execute smart contracts in the TON Blockchain.
 
+<Aside type="caution" title="Reference Update Notice">
+ The original PDF referred to an earlier version of the [Telegram Open Network](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf).  
+ We have redirected links **[1.x.x]** to the updated [The Open Network](/ton/ton) and the [TON Blockchain](/ton/tblkch) documents.
+</Aside>
+
 ## 1 Introduction
 
 The primary purpose of the Telegram Open Network Virtual Machine (TON VM or TVM) is to execute smart-contract code in the TON Blockchain.
@@ -108,7 +115,7 @@ All type tags attached to values processed by TVM will always have expected valu
 A preliminary list of value types supported by TVM is as follows:
 
 - **Integer** — Signed 257-bit integers, representing integer numbers in the range `−2²⁵⁶ … 2²⁵⁶ − 1`, as well as a special “not-a-number” value `NaN`.
-- **Cell** — A TVM cell consists of at most 1023 bits of data, and of at most four references to other cells. All persistent data (including TVM code) in the TON Blockchain is represented as a collection of TVM cells (cf. [1](#reference-1) 2.5.14]).
+- **Cell** — A TVM cell consists of at most 1023 bits of data, and of at most four references to other cells. All persistent data (including TVM code) in the TON Blockchain is represented as a collection of TVM cells (cf. [[1, 1.1.1](/ton/tblkch#1-1-1-tvm-cells)]).
 - **Tuple** — An ordered collection of up to 255 components, having arbitrary value types, possibly distinct. May be used to represent nonpersistent values of arbitrary algebraic data types.
 - **Null** — A type with exactly one value `⊥`, used for representing empty lists, empty branches of binary trees, absence of return value in some situations, and so on.
 - **Slice** — A TVM cell slice, or slice for short, is a contiguous “sub-cell” of an existing cell, containing some of its bits of data and some of its references. Essentially, a slice is a read-only view for a subcell of a cell. Slices are used for unpacking data previously stored (or serialized) in a cell or a tree of cells.
@@ -565,7 +572,7 @@ The exact way in which the TVM code (e.g., TVM assembly code) is transformed int
 
 ### 3.1.10 “Everything is a bag of cells” paradigm
 
-As described in [1](#reference-1), all the data used by the TON Blockchain, including the blocks themselves and the blockchain state, can be represented—and are represented—as collections, or “bags”, of cells.
+As described in [[1, 1.1](/ton/tblkch#1-1-everything-is-a-bag-of-cells)], all the data used by the TON Blockchain, including the blocks themselves and the blockchain state, can be represented—and are represented—as collections, or “bags”, of cells.
 
 We see that TVM’s structure of data (cf. [3.1.8](#3-1-8-all-values-of-algebraic-data-types-are-trees-of-cells)) and code (cf. [3.1.9](#3-1-9-tvm-code-is-a-tree-of-cells)) nicely fits into this “everything is a bag of cells” paradigm.
 
@@ -1020,7 +1027,7 @@ Similarly to `JMPX` and `RET`, `CALLX` also has special (rarely used) forms, whi
 
 This means that the caller is willing to pass exactly `n''` arguments to the called subroutine, and is willing to accept exactly `n'''` results in their stead.
 
-Such forms of `CALLX` and `RET` are mostly intended for library functions that accept functional arguments and want to invoke them safely. Another application is related to the “virtualization support” of TVM, which enables TVM code to run other TVM code inside a “virtual TVM machine”. Such virtualization techniques might be useful for implementing sophisticated payment channels in the TON Blockchain (cf. [1, 5](#reference-1)).
+Such forms of `CALLX` and `RET` are mostly intended for library functions that accept functional arguments and want to invoke them safely. Another application is related to the “virtualization support” of TVM, which enables TVM code to run other TVM code inside a “virtual TVM machine”. Such virtualization techniques might be useful for implementing sophisticated payment channels in the TON Blockchain (cf. [[1, 5](/ton/ton#5-ton-payments)]).
 
 ### 4.1.11 CALLCC: call with current continuation
 
@@ -4516,10 +4523,9 @@ An interesting point is that the stack machine code in our samples might have be
 
 By contrast, the heavily optimized (with respect to size) code for register machines shown in [C.3.2](#c-3-2-three-address-and-two-address-register-machines%2C-m-%3D-0-preserved-registers) and [C.3.3](#c-3-3-three-address-and-two-address-register-machines%2C-m-%3D-8-preserved-registers) is unlikely to be produced automatically by an optimizing compiler. Therefore, if we had compared compiler-generated code instead of manually-generated code, the advantages of stack machines with respect to code density would have been even more striking.
 
-
 ## References
 
-<a id="reference-1"></a> [1] N. Durov, *Telegram Open Network*, 2017.
+<a id="reference-1"></a> [1] N. Durov, [Telegram Open Network, 2017](https://www.editionmultimedia.fr/wp-content/uploads/2019/10/Telegram-Open-Network-2017.pdf).
 
 ## Footnotes