@@ -135,7 +137,9 @@ Not specified by NFT standard in /ton-blockchain/token-contract
## Batch mint NFT
:::info
+
Not specified by NFT standard in /ton-blockchain/token-contract
+
:::
diff --git a/docs/v3/documentation/smart-contracts/message-management/external-messages.mdx b/docs/v3/documentation/smart-contracts/message-management/external-messages.mdx
index 6e43a856c28..adf3ec3aa94 100644
--- a/docs/v3/documentation/smart-contracts/message-management/external-messages.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/external-messages.mdx
@@ -96,7 +96,9 @@ created_lt:uint64 created_at:uint32 = CommonMsgInfo;
## Replay protection
:::caution
+
Stay vigilant and check replay protection in contracts for external-in messages.
+
:::
Notice that all external messages must be protected against replay attacks. The validators normally remove an external message from the pool of suggested external messages (received from the network); however, in some situations another validator could process the same external message twice (thus creating a second transaction for the same external message, leading to the duplication of the original action). Even worse, a `malicious actor could extract` the external message from the block containing the processing transaction and re-send it later. This could force a wallet smart contract to repeat a payment.
@@ -106,7 +108,9 @@ The simplest way to protect smart contracts from replay attacks related to exter
And one could also include an `expire-at` field in the external message, and accept an external message only if the current Unix time is less than the value of this field. This approach can be used in conjunction with `seqno`; alternatively, the receiving smart contract could store the set of (the hashes of) all recent (not expired) accepted external messages in its persistent data, and reject a new external message if it is a duplicate of one of the stored messages. Some garbage collection of expired messages in this set should also be performed to avoid bloating the persistent data.
:::note
-In general, an external message begins with a 256-bit signature (if needed), a 32-bit `req-seqno` (if needed), a 32-bit `expire-at` (if needed), and possibly a 32-bit `op` and other required parameters depending on `op`. The layout of external messages does not need to be as standardized as that of internal messages because external messages are not used for interaction between different smart contracts (written by different developers and managed by different owners).
+
+In general, an external message begins with a 256-bit signature (if needed), a 32-bit `req-seqno` (if needed), a 32-bit `expire-at` (if needed), and possibly a 32-bit `op` and other required parameters depending on `op`. The layout of external messages does not need to be as standardized as that of internal messages because external messages are not used for interaction between different smart contracts (written by different developers and managed by different owners).
+
:::
### See also
diff --git a/docs/v3/documentation/smart-contracts/message-management/internal-messages.mdx b/docs/v3/documentation/smart-contracts/message-management/internal-messages.mdx
index f724b71a7dc..5c0dca9527d 100644
--- a/docs/v3/documentation/smart-contracts/message-management/internal-messages.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/internal-messages.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
Smart contracts interact with each other by sending so-called **internal messages**. When an internal message reaches its intended destination, an ordinary transaction is created on behalf of the destination account, and the internal message is processed as specified by the code and the persistent data of this account (smart contract).
:::info
+
In particular, the processing transaction can create one or several outbound internal messages, some of which may be addressed to the source address of the internal message being processed. This can be used to create simple "client-server applications" when a query is encapsulated in an internal message and sent to another smart contract, which processes the query and sends back a response again as an internal message.
+
:::
This approach requires distinguishing whether an internal message is a:
@@ -87,11 +89,13 @@ Input:
Comments for NFT and jetton transfers follow the same format. Note that the public key of the sender and receiver addresses (not jetton-wallet addresses) should be used.
:::info
+
Learn from examples of the message encryption algorithm:
- [encryption.js](https://github.com/toncenter/ton-wallet/blob/master/src/js/util/encryption.js)
- [SimpleEncryption.cpp](https://github.com/ton-blockchain/ton/blob/master/tonlib/tonlib/keys/SimpleEncryption.cpp)
- :::
+
+:::
### Simple transfer messages without comments
@@ -114,7 +118,9 @@ Notice that unknown "responses" (with an `op` in the range `2^31 .. 2^32-1`) sho
## Known op codes
:::info
+
Also op-code, op::code and operational code
+
:::
| Contract type | Hex code | OP::code |
@@ -167,9 +173,11 @@ Also op-code, op::code and operational code
| StonFi | 0x45078540 | Swap success ref |
:::info
+
[DeDust docs](https://docs.dedust.io/docs/swaps)
[StonFi docs](https://docs.ston.fi/docs/developer-section/architecture#calls-descriptions)
+
:::
### See also
diff --git a/docs/v3/documentation/smart-contracts/message-management/message-modes-cookbook.mdx b/docs/v3/documentation/smart-contracts/message-management/message-modes-cookbook.mdx
index 922bd2e3075..aea04f1d5f6 100644
--- a/docs/v3/documentation/smart-contracts/message-management/message-modes-cookbook.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/message-modes-cookbook.mdx
@@ -8,7 +8,9 @@ import ThemedImage from "@theme/ThemedImage";
Understanding the modes and flags for sending messages ensures your smart contracts behave as intended. This section illustrates their practical application through specific examples.
:::info IMPORTANT
+
You can check [this example](https://testnet.tonviewer.com/transaction/42ed45726e4fe994b7fd6dbf953a2ac24ecd77753858abeda9d6755c664a537a) as a real-world validation.
+
:::
#### Message value and account balance
@@ -76,9 +78,11 @@ Storage → Credit → Compute → Action → Bounce
| [IHR fee](/v3/documentation/smart-contracts/transaction-fees/fees-low-level#ihr) (each msg) | 0.0006 | cost of ihr fwd of in_msg |
:::info IMPORTANT
+
The table is populated using [this example transaction](https://tonviewer.com/transaction/b5e14a9c4a4e982fda42d6079c3f84fa48e76497a8f3fca872f9a3737f1f6262).
For live calculations, refer to the [**fee calculator**](/v3/documentation/smart-contracts/transaction-fees/fees#basic-fees-formula).
+
:::
The transaction fees used in these examples are hypothetical and for illustrative purposes only. Any fees other than message forwarding are outside the scope of this article.
@@ -108,7 +112,9 @@ State after the transaction: Account A has 0.9 TON, Account B has 1.096 TON
## 2. (Mode 0, flag 2) error‐silent message \{#mode2}
:::info
+
Please note that omitting the `+2` flag may be unsafe. For more information, refer to [this section](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
State before transaction: Account A has 1 TON, Account B has 1 TON
@@ -119,7 +125,9 @@ In case of an error during [action phase](/v3/documentation/smart-contracts/mess
State after the transaction: Account A has 0.9 TON, Account B has 1.096 TON
:::info tip
+
If no errors occur, the result is the same as [mode = 0](#mode0).
+
:::
@@ -158,13 +166,15 @@ State after the transaction with error: Account A has 1 - ([total_fee](/v3/docum
:::info tip
+
If no errors occur, the result is the same as [mode = 0](#mode0).
The key difference is that `flag 16` creates bounces for [action phase errors](/v3/documentation/tvm/tvm-exit-codes#standard-exit-codes). In contrast, the message's [built‐in bounce flag](/v3/guidelines/smart-contracts/howto/wallet#internal-message-creation) handles protocol‐level failures like:
- The destination contract does not exist.
- The destination contract throws an unhandled exception.
- :::
+
+:::
@@ -182,7 +192,9 @@ The key difference is that `flag 16` creates bounces for [action phase errors](/
## 4. (Mode 0, flag 1) separate fees \{#mode1}
:::info
+
Please note that using only this flag is unsafe, for more information refer to [this section](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
State before the transaction: Account A has 1 TON, Account B has 1 TON
@@ -227,7 +239,9 @@ State after the transaction with an error: Account A has 1 - ([total_fee](/v3/do
:::info tip
+
If no errors occur, the result is the same as [mode = 0, flag = 1](#mode1).
+
:::
@@ -252,14 +266,18 @@ State before the transaction: Account A has 1 TON, Account B has 1 TON, Account
State after the transaction: Account A has 0.896 TON, Account B has 0.5 TON, Account C has 1.6 - (total_fee + `fwd_fee`) TON
:::info
+
You might check [this example](https://testnet.tonviewer.com/transaction/f63ab35f34e342cdd249f13018d5034ce3d80c488628d5a4db0a43163fa50adb).
Please note that `storage_fee` is included in `total_fee` but is always paid from the contract `balance`.
+
:::
:::warning
+
Please note that `SENDRAWMSG` doesn't update the balance.
If you try to send multiple messages (e.g., mode 0 **and** mode 64), you'll get exit code 37.
+
:::
@@ -284,8 +302,10 @@ State before the transaction: Account A has 1 TON, Account B has 1 TON, Account
State after the transaction: Account A has 0.896 TON, Account B has 0.5 - (total_fee + `fwd_fee`) TON, Account C has 1.6 TON
:::info
+
You might check [this example](https://testnet.tonviewer.com/transaction/ad93e784453b573d737d9d928b4377ff3779177753e05629e54f6629556568ad).
Please note that `storage_fee` is included in `total_fee` but is always paid from the contract `balance`.
+
:::
@@ -324,7 +344,9 @@ State after the transaction with an error: Account A has 1 - (total_fee + `fwd_f
:::info tip
+
If no errors occur, the result is the same as [mode = 64, flag 0](#mode64). This mode is widely used in TON for jetton transfers. You can [check it in the C5 action list](https://retracer.ton.org/?tx=6489d60d9197c0be7ee64b0812139d82221e8f94c6e378c356acc10f9067310c) of the jetton wallet.
+
:::
@@ -363,7 +385,9 @@ State after the transaction with an error: Account A has 1 - (total_fee + `fwd_f
:::info tip
+
If no errors occur, the result is the same as [mode = 65](#mode65).
+
:::
@@ -422,7 +446,9 @@ State after the transaction with an error: Account A has 1 - (total_fee + `fwd_f
:::info tip
+
If no errors occur, the result is the same as [mode = 128](#mode128). This mode is widely used in TON for jetton transfers. You can [check it in the C5 action list](https://retracer.ton.org/?tx=e4f31e37eec74a8cfcecdad9246a6bbf3da20c4edb3635150cb0fa54b9def558) of the jetton wallet.
+
:::
diff --git a/docs/v3/documentation/smart-contracts/message-management/messages-and-transactions.mdx b/docs/v3/documentation/smart-contracts/message-management/messages-and-transactions.mdx
index 8475b311764..46a7f4d6cba 100644
--- a/docs/v3/documentation/smart-contracts/message-management/messages-and-transactions.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/messages-and-transactions.mdx
@@ -29,9 +29,9 @@ Working with this type of communication is reminiscent of launching a satellite
A transaction in TON is the **result** of a smart contract successfully processing an incoming message. It consists of:
-* the **incoming message** that triggered the contract
-* the **state changes** performed by the contract during message processing (e.g. storage or balance updates)
-* any **outgoing messages** sent to other contracts (if applicable)
+- the **incoming message** that triggered the contract
+- the **state changes** performed by the contract during message processing (e.g. storage or balance updates)
+- any **outgoing messages** sent to other contracts (if applicable)
> Technically, a contract can be triggered through special functions such as [Tick-tock](/v3/documentation/data-formats/tlb/transaction-layout#tick-tock). Still, this function is more used for internal TON Blockchain core contracts.
@@ -55,7 +55,9 @@ In an asynchronous system, you can't get a response from the destination smart c
Achieving the infinite sharding paradigm requires full parallelization, ensuring that each transaction executes independently of others. Therefore, instead of transactions that affect and change the state of many contracts simultaneously, each transaction in TON is only executed on a single smart contract, and smart contracts communicate through messages. That way, smart contracts can only interact with each other by calling their functions with special messages and getting a response to them via other messages later.
:::info
+
See [transaction layout](/v3/documentation/data-formats/tlb/transaction-layout) for complete transaction details.
+
:::
### Transaction outcome
@@ -64,7 +66,9 @@ There is a [TVM exit code](/v3/documentation/tvm/tvm-exit-codes) for a transacti
Also, TVM [compute phase may be skipped](/v3/documentation/tvm/tvm-overview#when-the-compute-phase-is-skipped) for reasons like lack of funds or state.
:::info for toncenter api v3
+
One should use `tx.description.action` to determine a successful `transaction.success && tx.description.compute_ph.success`:
+
:::
```json
@@ -92,7 +96,9 @@ The transaction may have one of three results:
- Fail, [exit code](/v3/documentation/tvm/tvm-exit-codes), `aborted: true`
:::info for toncenter api v3
+
`aborted: true` is a TON Center field. Transaction has no such field.
+
:::
## What is a logical time?
diff --git a/docs/v3/documentation/smart-contracts/message-management/non-bounceable-messages.mdx b/docs/v3/documentation/smart-contracts/message-management/non-bounceable-messages.mdx
index 3b0cace3bf3..cc6b588be35 100644
--- a/docs/v3/documentation/smart-contracts/message-management/non-bounceable-messages.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/non-bounceable-messages.mdx
@@ -34,7 +34,9 @@ Most internal messages between contracts should be bounceable (with the "bounce"
- Never execute the bounced message's original query
:::info
+
The query contained in the body of a bounced message
should never be executed .
+
:::
Non-bounceable messages are essential for account initialization. A new account cannot be created without receiving at least one non-bounceable internal message containing its `StateInit` (with contract code and initial data).
diff --git a/docs/v3/documentation/smart-contracts/message-management/sending-messages.mdx b/docs/v3/documentation/smart-contracts/message-management/sending-messages.mdx
index 5ba29e65d6d..22f5647b4d1 100644
--- a/docs/v3/documentation/smart-contracts/message-management/sending-messages.mdx
+++ b/docs/v3/documentation/smart-contracts/message-management/sending-messages.mdx
@@ -163,7 +163,9 @@ The entire scheme of the message layout and the layout of all constituting field
## Message size
:::info cell size
+
Note that any [Cell](/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage) may contain up to `1023` bits. If you need to store more data, you should split it into chunks and store it in reference cells.
+
:::
For example, if your message body is 900 bits long, you can't store it in the same cell as the message header. Including the message header fields would make the total cell size exceed 1023 bits, triggering a `cell overflow` exception during serialization.
@@ -192,16 +194,20 @@ That way:
(where `0b1000` specifies 8 bytes length followed by the 8-byte value)
:::info message size
+
Note that the message has general size limits and cell count limits, too,
e.g., the maximum message size must not exceed `max_msg_bits`, and the number of cells per message must not exceed `max_msg_cells`.
More configuration parameters and their values can be found [here](/v3/documentation/network/configs/blockchain-configs#param-43).
+
:::
## Message modes
:::info
+
For the latest information, refer to the [message modes cookbook](/v3/documentation/smart-contracts/message-management/message-modes-cookbook).
+
:::
As you may have noticed, we send messages using `send_raw_message`, which also accepts a mode parameter and consumes the message. This mode determines how the message is sent, including whether to pay for gas separately and how to handle errors. The TON Virtual Machine (TVM) processes messages differently depending on the mode value. It’s important to note that the mode parameter consists of two components, **mode** and **flag**, which serve different purposes:
@@ -225,9 +231,11 @@ When using the `send_raw_message` function, choosing the appropriate combination
| `+32` | Destroy the current account if its resulting balance is zero (often used with Mode 128) |
:::info +16 Flag
+
If a contract receives a bounceable message, it processes the `storage` phase **before** the `credit` phase. Otherwise, it processes the `credit` phase **before** the `storage` phase.
For more details, check the [source code with checks for the `bounce-enable` flag](https://github.com/ton-blockchain/ton/blob/master/validator/impl/collator.cpp#L2810).
+
:::
:::warning
diff --git a/docs/v3/documentation/smart-contracts/overview.mdx b/docs/v3/documentation/smart-contracts/overview.mdx
index cb51f54c08a..c24caaf0358 100644
--- a/docs/v3/documentation/smart-contracts/overview.mdx
+++ b/docs/v3/documentation/smart-contracts/overview.mdx
@@ -45,7 +45,9 @@ Kickstart your journey with our beginner-friendly guides:
### TON course
:::tip
+
Before starting the course, make sure you have a solid understanding of the basics of blockchain technology. If you have gaps in your knowledge, we recommend taking the [**Blockchain Basics with TON**](https://stepik.org/course/201294/promo) ([RU version](https://stepik.org/course/202221/), [CHN version](https://stepik.org/course/200976/)) course.
+
:::
We are proud to present the **TON Blockchain Course**, a comprehensive guide to TON Blockchain. The course is designed for developers who want to learn how to create smart contracts and decentralized applications on TON Blockchain.
@@ -75,7 +77,9 @@ For those who prefer detail and nuance, visit:
Explore ready-made smart contract examples and tools provided by the TON community.
:::tip
+
Prefer smart contracts written in FunC (.fc) over lower‑level Fift (.fif).
+
:::
Standard examples of smart contracts on TON include wallets, electors (which manage validation on TON), and multi-signature wallets, which can serve as references when studying.
@@ -138,7 +142,9 @@ View some of the selected projects: [Tact in production](https://github.com/tact
Tolk is a new language for writing smart contracts in TON. Think of Tolk as the "**next‑generation FunC**".
:::caution
+
Under active development.
+
:::
@@ -148,7 +154,9 @@ Under active development.
### 📕 Fift (advanced)
:::caution advanced level
+
Only for the brave!
+
:::
diff --git a/docs/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm.mdx b/docs/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm.mdx
index a1bb9f08f68..ef58ac99dad 100644
--- a/docs/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm.mdx
+++ b/docs/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm.mdx
@@ -111,6 +111,7 @@ An efficient messaging system between ShardChains is essential for the operation
### Current Status of IHR
:::info Important Clarification
+
**Instant Hypercube Routing (IHR) is an alternative mechanism for message delivery without intermediate hops.** However, it is important to understand that:
- **IHR is not implemented** and is not yet fully specified
@@ -118,6 +119,7 @@ An efficient messaging system between ShardChains is essential for the operation
- **Current network settings forbid splitting deeper than 16 shards**, so IHR is not relevant in any practical sense today
Currently, TON uses standard **Hypercube Routing (HR)** for message delivery between shards, which routes messages through intermediate shards when necessary. IHR would provide a more direct routing mechanism, but only becomes necessary in much larger shard configurations than are currently possible.
+
:::
### Message Routing Mechanisms
diff --git a/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/in-detail.mdx b/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/in-detail.mdx
index 5ee9ee28d7d..e5b0104c80b 100644
--- a/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/in-detail.mdx
+++ b/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/in-detail.mdx
@@ -5,7 +5,9 @@ import Feedback from '@site/src/components/Feedback';
A huge list is below. Will anyone have enough patience to read it up to the end?..
:::tip There is a compact version
+
Here: [Tolk vs FunC: in short](/v3/documentation/smart-contracts/tolk/tolk-vs-func/in-short)
+
:::
### Traditional comments
diff --git a/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/mutability.mdx b/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/mutability.mdx
index 2951246f3a5..a22fc57cb95 100644
--- a/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/mutability.mdx
+++ b/docs/v3/documentation/smart-contracts/tolk/tolk-vs-func/mutability.mdx
@@ -7,6 +7,7 @@ import Feedback from '@site/src/components/Feedback';
# Mutability in Tolk vs tilda functions in FunC
:::tip TLDR
+
- no `~` tilda methods
- `cs.loadInt(32)` modifies a slice and returns an integer
- `b.storeInt(x, 32)` modifies a builder
@@ -16,6 +17,7 @@ import Feedback from '@site/src/components/Feedback';
- no runtime overhead, the same Fift instructions
- custom methods are created with ease
- tilda `~` does not exist in Tolk at all
+
:::
This is a drastic change. If FunC has `.methods()` and `~methods()`, Tolk has only a dot, and the only way to call a method is `.method()`. The method may or may not *mutate* an object. Also, there is a behavioral and semantic difference between FunC and the list.
diff --git a/docs/v3/documentation/smart-contracts/transaction-fees/accept-message-effects.mdx b/docs/v3/documentation/smart-contracts/transaction-fees/accept-message-effects.mdx
index ecbba0919fe..d05395e6b18 100644
--- a/docs/v3/documentation/smart-contracts/transaction-fees/accept-message-effects.mdx
+++ b/docs/v3/documentation/smart-contracts/transaction-fees/accept-message-effects.mdx
@@ -38,11 +38,13 @@ When a contract receives an internal message from another contract:
Note that manual settings of gas limits do not interfere with bouncing behavior; messages will be bounced if sent in bounceable mode and contain enough money to pay for their processing and the creation of bounce messages.
:::info example
+
**Case 1:**
If you send a bounceable message with 0.1 TON in the basechain that is accepted by a contract with a 1 TON balance, and the computation costs 0.005 TON, with a message fee of 0.001 TON, then the bounce message will contain `0.1 - 0.005 - 0.001` = `0.094` TON.
**Case 2:**
If in the same example, the computation cost is 0.5 (instead of 0.005), there will be no bounce (the message balance would be `0.1 - 0.5 - 0.001 = -0.401`, thus no bounce), and the contract balance will be `1 + 0.1 - 0.5` = `0.6` TON.
+
:::
diff --git a/docs/v3/documentation/smart-contracts/transaction-fees/fees-low-level.mdx b/docs/v3/documentation/smart-contracts/transaction-fees/fees-low-level.mdx
index 3111fa37a4c..61e389c5e30 100644
--- a/docs/v3/documentation/smart-contracts/transaction-fees/fees-low-level.mdx
+++ b/docs/v3/documentation/smart-contracts/transaction-fees/fees-low-level.mdx
@@ -3,10 +3,12 @@ import Feedback from '@site/src/components/Feedback';
# Low-level fees overview
:::caution
+
This section describes instructions and manuals for interacting with TON at a low level.
Here you will find the **raw formulas** for calculating commissions and fees on TON.
However, most of them are **already implemented through opcodes**!
So, you **use them instead of manual calculations**.
+
:::
This document provides a general idea of transaction fees on TON and particularly computation fees for the FunC code. There is also a [detailed specification in the TVM whitepaper](https://ton.org/tvm.pdf).
@@ -26,7 +28,9 @@ It's important to keep in mind that on TON you pay for both the execution of a s
If you have not used your TON Wallet for a significant period of time (1 year), _you will have to pay a significantly larger commission than usual because the wallet pays commission on sending and receiving transactions_.
:::info **Note**:
+
When a message is bounced from the contract, the contract will pay its current `storage_fee`
+
:::
### Formula
@@ -221,6 +225,7 @@ Internal messages define an `ihr_fee` in Toncoins, which is subtracted from the
### IHR
:::info What is IHR?
+
[**Instant Hypercube Routing (IHR)**](/v3/documentation/smart-contracts/shards/infinity-sharding-paradigm#messages-and-instant-hypercube-routing-instant-hypercube-routing) is an alternative mechanism for message delivery without intermediate hops between shards. To understand why IHR is not currently relevant:
- **IHR is not implemented** and is not yet fully specified
@@ -230,6 +235,7 @@ Internal messages define an `ihr_fee` in Toncoins, which is subtracted from the
In the current TON network configuration, all message routing uses standard **Hypercube Routing (HR)**, which can handle message delivery efficiently with the current shard topology. The `ihr_fee` field exists in the message structure for future compatibility, but serves no functional purpose today.
If you set the `ihr_fee` to a non-zero value, it will always be added to the message value upon receipt. For now, there are no practical reasons to do this.
+
:::
### Formula
@@ -251,9 +257,11 @@ total_fwd_fees = msg_fwd_fees + ihr_fwd_fees; // ihr_fwd_fees - is 0 for externa
```
:::info IMPORTANT
+
Please note that `msg_fwd_fees` above includes `action_fee` below. For a basic message this fee = lump_price = 400000 nanotons, action_fee = (400000 \* 21845) / 65536 = 133331. Or approximately a third of the `msg_fwd_fees`.
`fwd_fee` = `msg_fwd_fees` - `action_fee` = 266669 nanotons = 0,000266669 TON
+
:::
## Action fee
@@ -269,6 +277,7 @@ action_fee = msg_fwd_fees; //external
[`first_frac`](/v3/documentation/network/configs/blockchain-configs#param-24-and-25) is part of the 24 and 25 parameters (for master chain and work chain) of the TON Blockchain. Currently, both are set to a value of 21845, which means that the `action_fee` is approximately a third of the `msg_fwd_fees`. In the case of an external message action, `SENDRAWMSG`, the `action_fee` is equal to the `msg_fwd_fees`.
:::tip
+
Remember that an action register can contain up to 255 actions, which means that all formulas related to `fwd_fee` and `action_fee` will be computed for each `SENDRAWMSG` action, resulting in the following sum:
```cpp
@@ -298,9 +307,11 @@ All fees are nominated in nanotons or nanotons multiplied by 2^16 to [maintain a
- out_fwd_fees = [p24](https://tonviewer.com/config#24), [p25](https://tonviewer.com/config#25)
:::info
+
[A direct link to the mainnet live config file](https://tonviewer.com/config).
For educational purposes [example of the old one](https://explorer.toncoin.org/config?workchain=-1&shard=8000000000000000&seqno=22185244&roothash=165D55B3CFFC4043BFC43F81C1A3F2C41B69B33D6615D46FBFD2036256756382&filehash=69C43394D872B02C334B75F59464B2848CD4E23031C03CA7F3B1F98E8A13EE05).
+
:::
## References
diff --git a/docs/v3/documentation/smart-contracts/transaction-fees/fees.mdx b/docs/v3/documentation/smart-contracts/transaction-fees/fees.mdx
index 04507a9839f..127af0e1d21 100644
--- a/docs/v3/documentation/smart-contracts/transaction-fees/fees.mdx
+++ b/docs/v3/documentation/smart-contracts/transaction-fees/fees.mdx
@@ -29,7 +29,9 @@ Current settings in masterchain are as follows: 1 unit of gas costs 10000 nanoto
Even if Toncoin price increases 100 times, transactions will remain ultra-cheap — about $0.01. Moreover, validators may lower this value if they see commissions have become expensive [read why they're interested](#gas-price-voting-process).
:::info
+
The current gas price is defined in the Network Config [param 20](https://tonviewer.com/config#20) and [param 21](https://tonviewer.com/config#21) for the masterchain and basechain, respectively.
+
:::
### Gas price voting process
@@ -53,9 +55,11 @@ Fees on TON are difficult to calculate in advance, as their amount depends on tr
That is why NFT marketplaces typically require an extra amount of TON (~1 TON) and refund the remaining amount (1 - transaction_fee) after the transaction.
:::info
+
Each contract should check incoming messages for the amount of TON attached to ensure it is enough to cover the fees.
Check the [low-level fees overview](/v3/documentation/smart-contracts/transaction-fees/fees-low-level) to learn more about the formulas for calculating commissions and [fees calculation](/v3/guidelines/smart-contracts/fee-calculation) to learn how to calculate fees in FunC contracts using the new TVM opcodes.
+
:::
However, let's read more about how fees are supposed to function on TON.
diff --git a/docs/v3/documentation/smart-contracts/transaction-fees/forward-fees.mdx b/docs/v3/documentation/smart-contracts/transaction-fees/forward-fees.mdx
index 682bf67b959..7b81f3238b9 100644
--- a/docs/v3/documentation/smart-contracts/transaction-fees/forward-fees.mdx
+++ b/docs/v3/documentation/smart-contracts/transaction-fees/forward-fees.mdx
@@ -14,11 +14,13 @@ When a smart contract sends a query to another smart contract, it must pay for:
## Standard message handling
:::note
+
In most cases, the sender:
1. Attaches a small amount of Toncoin (typically one Toncoin) to the internal message
2. Sets the "bounce" flag (sends a bounceable internal message)
The receiver then returns the unused portion of the received value with the answer, deducting message forwarding fees. This is typically done using `SENDRAWMSG` with `mode = 64`.
+
:::
## Message bouncing
@@ -40,7 +42,9 @@ If the "bounced" flag is set:
- Alternatively, terminate with zero exit code to ignore bounced messages
:::note
+
The "bounced" flag cannot be forged because it's rewritten during sending. If a message has the "bounced" flag set, it's definitely a result of a bounced message from the receiver.
+
:::
## Error handling
diff --git a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2023-07.mdx b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2023-07.mdx
index c0ddc11771c..b214d3f7aa2 100644
--- a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2023-07.mdx
+++ b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2023-07.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# TVM upgrade Jul 2023
:::tip
+
This upgrade was [launched](https://t.me/tonblockchain/223) on the Mainnet in Dec 2023.
+
:::
## `c7`
diff --git a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2024-04.mdx b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2024-04.mdx
index d22d932fded..eb8f7cbafbf 100644
--- a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2024-04.mdx
+++ b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2024-04.mdx
@@ -5,7 +5,9 @@ import Feedback from '@site/src/components/Feedback';
## Introduction of new instructions for low fees calculation
:::tip
+
This upgrade is active on the Mainnet since Mar 16, 2024. See the details [here](https://t.me/tonstatus/101). A preview of the update for blueprints is available in the following packages: `@ton/sandbox@0.16.0-tvmbeta.3`, `@ton-community/func-js@0.6.3-tvmbeta.3`, and `@ton-community/func-js-bin@0.4.5-tvmbeta.3`.
+
:::
This update is enabled with Config8 `version >= 6`.
diff --git a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2025-02.mdx b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2025-02.mdx
index e1d20d76764..a2fd4e9e601 100644
--- a/docs/v3/documentation/tvm/changelog/tvm-upgrade-2025-02.mdx
+++ b/docs/v3/documentation/tvm/changelog/tvm-upgrade-2025-02.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# TVM upgrade Feb 2025
:::tip
+
This upgrade is active on the Mainnet since February 13, 2025. See details [here](https://t.me/tonstatus/153).
+
:::
This update is enabled with Config8 `version >= 9`.
diff --git a/docs/v3/documentation/tvm/tvm-exit-codes.mdx b/docs/v3/documentation/tvm/tvm-exit-codes.mdx
index 456e17c79dc..c999d4ae447 100644
--- a/docs/v3/documentation/tvm/tvm-exit-codes.mdx
+++ b/docs/v3/documentation/tvm/tvm-exit-codes.mdx
@@ -14,7 +14,9 @@ Exit code 0 indicates standard successful execution of the [compute phase](#comp
The range from 256 to 65535 is free for developer-defined exit codes.
:::note
+
While exit codes are 32-bit signed integers in TON, attempting to throw an exit code outside the 16-bit unsigned integer range (0-65535) will trigger an error with [exit code 5](#5). This intentionally prevents the artificial generation of specific exit codes like [-14](#-14).
+
:::
## Table of exit codes \{#standard-exit-codes}
@@ -65,7 +67,9 @@ The following table lists exit codes with an origin (where it can occur) and a s
| 138 | Tact compiler ([Compute phase][c]) | Not a BaseChain address. |
:::note
+
The exit code 65535 (`0xffff`) typically indicates the same issue as exit code `130`: an unrecognized message opcode. It is assigned manually when developing contracts rather than generated by [TVM][tvm] or the Tact compiler.
+
:::
## Exit codes in Blueprint projects \{#blueprint}
@@ -418,7 +422,9 @@ If the source address in the outbound message isn't equal to [`addr_none`](/v3/d
Suppose the destination address in the outbound message is invalid. In that case, e.g., it doesn't conform to the relevant [TL-B][tlb] schemas, contains an unknown workchain ID, or has an invalid length for the given workchain, an error with exit code 36 is thrown: `Invalid destination address in the outbound message`.
:::note
+
If the [optional flag +2][flag2] is set, this error will not be thrown, and the given message will not be sent.
+
:::
### 37: Not enough Toncoin \{#37}
@@ -426,7 +432,9 @@ If the [optional flag +2][flag2] is set, this error will not be thrown, and the
If all funds of the inbound message with [mode 64](/v3/documentation/smart-contracts/message-management/message-modes-cookbook#mode64) had been already consumed and there's not enough funds to pay for the failed action, or the [TL-B][tlb] layout of the provided value ([`CurrencyCollection`](/v3/documentation/data-formats/tlb/msg-tlb#currencycollection)) is invalid, or there are not enough funds to pay forward fees or not enough funds after deducting fees, an error with exit code 37 is thrown: `Not enough Toncoin`.
:::note
+
If the [optional flag +2][flag2] is set, this error will not be thrown, and the given message will not be sent.
+
:::
### 38: Not enough extra currencies \{#38}
@@ -436,9 +444,11 @@ Besides the native currency, Toncoin, TON Blockchain supports up to 232
:::tip
+
For more examples, read the [TON cookbook](/v3/guidelines/dapps/cookbook#tep-74-jettons-standard).
+
:::
### Retrieving data for a specific jetton wallet
@@ -254,7 +270,9 @@ This method returns the following data:
## Message layouts
:::tip Messages
+
Read more about messages [here](/v3/documentation/smart-contracts/message-management/messages-and-transactions).
+
:::
Communication between jetton wallets and TON wallets follows this sequence:
@@ -307,7 +325,9 @@ In this case, the `sender` address refers to Alice's `jetton wallet`.
| `query_id` | uint64 |
:::tip jettons standard
+
A detailed description of the jetton wallet contract fields is available in the [TEP-74](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md) `jetton standard`.
+
:::
## How to send jetton transfers with comments and notifications
@@ -317,7 +337,9 @@ This transfer requires some Toncoin for **fees** and a **transfer notification m
To send a **comment** you need to set up `forward_payload`. Set **first 32 bits to 0x0** and add **custom text**; `forward_payload` is sent in the internal `jetton notify 0x7362d09c` message. It will only be generated if `forward_ton_amount` > 0.
:::info
+
Recommended `forward_ton_amount` for a jetton transfer with a comment: 1 nanoton.
+
:::
Finally, to retrieve `Excess 0xd53276db` message you must set up `response destination`.
@@ -328,13 +350,17 @@ It is recommended to add a supply of Toncoin to the message and set your address
You may also encounter the error [`cskip_no_gas`](/v3/documentation/tvm/tvm-overview#when-the-compute-phase-is-skipped), which indicates that the tokens were successfully transferred, but no other computations were performed. This is a common situation when the `forward_ton_amount` value is 1 nanoton.
:::tip
+
Check [best practices](/v3/guidelines/dapps/asset-processing/jettons#best-practices) for the _"send jettons with comments"_ example.
+
:::
## Jetton off-chain processing
:::info Transaction confirmation
+
TON transactions are irreversible after just one confirmation. To provide the best user experience, avoid waiting on additional blocks once transactions are finalized on the TON Blockchain. Read more in [Catchain.pdf](https://docs.ton.org/catchain.pdf#page=3).
+
:::
There are two ways to accept jettons:
@@ -368,11 +394,15 @@ This should not be confused with the `sender` field in the [body](/v3/guidelines
### Accepting jettons from users through a centralized wallet
:::info
+
To prevent transaction bottlenecks in a single wallet, distribute deposits across multiple wallets and expand as needed.
+
:::
:::warning Transaction notification
+
Each service in the ecosystem is expected to set `forward_ton_amount` to 0.000000001 TON (1 nanoton) when withdrawing a token, in order to send a token notification upon [a successful transfer](https://testnet.tonviewer.com/transaction/a0eede398d554318326b6e13081c2441f8b9a814bf9704e2e2f44f24adb3d407), otherwise the transfer will not be compliant and will not be processed by other CEXs and services.
+
:::
In this scenario, the payment service creates a unique memo identifier for each sender, revealing the
@@ -446,7 +476,9 @@ const wallet = new WalletClass(tonweb.provider, {
#### Processing transactions
:::info Transaction confirmation
+
TON transactions are irreversible after one confirmation. To enhance user experience, avoid waiting for additional blocks once transactions are finalized on TON Blockchain. Read more in [Catchain.pdf](https://docs.ton.org/catchain.pdf#page=3).
+
:::
It is not always possible to determine the exact amount of jettons received from a message, as `transfer notification` messages depend on the `forward_ton_amount`. `excesses` and `internal transfer` messages are not standardized and may not be decodable.
@@ -495,9 +527,11 @@ By default, jetton deposit wallets are uninitialized since storage fees are not
### Jetton withdrawals
:::info Important
+
**It is recommended that you** read and **understand** the [how jetton transfer works](/v3/guidelines/dapps/asset-processing/jettons#overview) and [how to send jetton transfers with comments and notifications](/v3/guidelines/dapps/asset-processing/jettons#how-to-send-jetton-transfers-with-comments-and-notifications) articles before reading this section.
Below, you will find a step-by-step guide on how to process jetton withdrawals.
+
:::
To withdraw jettons, the wallet sends messages with a `transfer` body to the corresponding jetton wallet.
@@ -558,7 +592,9 @@ The `jetton` parameter is required (which is actually the address of the primary
Generally, to accept and process jettons, a message handler responsible for internal messages uses the `op=0x7362d09c` op code.
:::info Transaction Confirmation
+
TON transactions are irreversible after one confirmation. For the best user experience, it is recommended to avoid waiting for additional blocks after completing transactions on the TON blockchain. Read more in the [Catchain.pdf](https://docs.ton.org/catchain.pdf#page=3).
+
:::
### On-chain processing recommendations
@@ -631,9 +667,13 @@ For ready-to-test examples, check [SDKs](/v3/guidelines/dapps/asset-processing/j
}).send()
```
+
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [Message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
+
diff --git a/docs/v3/guidelines/dapps/asset-processing/mass-mint-tools.mdx b/docs/v3/guidelines/dapps/asset-processing/mass-mint-tools.mdx
index 9938da76a09..05be94369cf 100644
--- a/docs/v3/guidelines/dapps/asset-processing/mass-mint-tools.mdx
+++ b/docs/v3/guidelines/dapps/asset-processing/mass-mint-tools.mdx
@@ -9,6 +9,7 @@ To prevent these issues and ensure a smooth launch, we recommend using the high-
### Mass sender
:::info
+
Recommended for token airdrops. Battle-tested on Notcoin and DOGS in September.
:::
@@ -25,7 +26,9 @@ Specification:
Access: [Mintless jettons](/v3/guidelines/dapps/asset-processing/mintless-jettons)
:::info
+
battle-tested on HAMSTER
+
:::
Specification:
@@ -37,7 +40,9 @@ Specification:
### TokenTable v4
:::info
+
battle-tested on Avacoin, DOGS
+
:::
Access: [www.tokentable.xyz](https://www.tokentable.xyz/)
@@ -50,7 +55,9 @@ Access: [www.tokentable.xyz](https://www.tokentable.xyz/)
### Gigadrop
:::info
+
battle-tested on HAMSTER
+
:::
Access: [gigadrop.io](https://gigadrop.io/)
diff --git a/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx b/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
index 5f510c90833..548b922a6b7 100644
--- a/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
+++ b/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
@@ -5,7 +5,9 @@ import Feedback from '@site/src/components/Feedback';
## Introduction
:::info
+
To understand this document, you should be familiar with the basic principles of asset processing outlined in [payments processing section](/v3/guidelines/dapps/asset-processing/payments-processing) and [jetton processing](/v3/guidelines/dapps/asset-processing/jettons).
+
:::
TON has introduced [mintless jettons](https://github.com/ton-community/mintless-jetton?tab=readme-ov-file), an innovative extension of the Jetton standard.
@@ -49,7 +51,9 @@ Using a custom API:
- Make the parsed result available via API.
:::info
+
Wallets are not required to support mintless claims, including indexing airdrop trees. Wallet applications may charge the jetton issuer for this service.
+
:::
## Supporting mintless jettons in dApps (DEX/Lending platforms)
diff --git a/docs/v3/guidelines/dapps/asset-processing/payments-processing.mdx b/docs/v3/guidelines/dapps/asset-processing/payments-processing.mdx
index 801cce52379..2675bc621b4 100644
--- a/docs/v3/guidelines/dapps/asset-processing/payments-processing.mdx
+++ b/docs/v3/guidelines/dapps/asset-processing/payments-processing.mdx
@@ -9,7 +9,9 @@ import TabItem from '@theme/TabItem';
This page **explains how to process** (send and accept) digital assets on TON Blockchain. While it primarily focuses on handling Toncoin, the **theoretical concepts** are also relevant for processing `jettons`.
:::tip
+
It's recommended to review the [Asset processing overview](/v3/documentation/dapps/assets/overview) before reading this tutorial.
+
:::
## Wallet smart contract
@@ -44,7 +46,9 @@ To deploy a wallet via TonLib, follow these steps:
6. Check the contract’s status after a few seconds using the [getAccountState](https://github.com/ton-blockchain/ton/blob/master/tl/generate/scheme/tonlib_api.tl#L288) method.
:::tip
+
Read more on the [Wallet tutorial](/v3/guidelines/smart-contracts/howto/wallet#-deploying-a-wallet).
+
:::
### Checking wallet address validity
@@ -96,7 +100,9 @@ Most SDKs automatically verify a wallet address during creation or transaction p
:::tip
+
Full Address description on the [Smart contract addresses](/v3/documentation/smart-contracts/addresses) page.
+
:::
## Working with transfers
@@ -176,7 +182,9 @@ It is possible to track message flows during transaction processing. Since the m
### Send payments
:::tip
+
Learn the basics of payment processing from the [TMA USDT Payments demo](https://github.com/ton-community/tma-usdt-payments-demo).
+
:::
1. The service must deploy a `wallet` and keep it funded to prevent contract destruction due to storage fees. Storage fees are typically less than 1 Toncoin per year.
@@ -189,7 +197,9 @@ Learn the basics of payment processing from the [TMA USDT Payments demo](https:/
8. Requests sent to `v3` of `high-load` have a 60-second expiration time by default. After expiration, unprocessed requests can be safely resent following steps 3-6.
:::caution
+
If the attached `value` is too small, the transaction may fail with the error `cskip_no_gas`. In this case, Toncoin will be transferred, but no logic will be executed on the recipient's side (the TVM will not launch). Read more [here](/v3/documentation/network/configs/blockchain-configs#param-20-and-21).
+
:::
### Get the transaction ID
@@ -235,7 +245,9 @@ Best for dApps that require multiple transactions within a session or a persiste
### Invoices with ton:// link
:::warning
+
The TON link is deprecated. Avoid using it.
+
:::
If you need an easy integration for a simple user flow, it is suitable to use the ton:// link.
diff --git a/docs/v3/guidelines/dapps/cookbook.mdx b/docs/v3/guidelines/dapps/cookbook.mdx
index 07535d28ae8..a6fbc94d80a 100644
--- a/docs/v3/guidelines/dapps/cookbook.mdx
+++ b/docs/v3/guidelines/dapps/cookbook.mdx
@@ -117,7 +117,9 @@ There are two flags in user-friendly addresses: **bounceable**/**non-bounceable*
| 0... | 110100.01 | no | yes |
:::tip
+
The Testnet-only flag does not appear in the blockchain. The non-bounceable flag only affects message transfers: when used as a destination, it prevents the message from being bounced.
+
:::
Also, in some libraries, you may notice a serialization parameter called `urlSafe`. The base64 format is not URL safe, which means that some characters (namely, `+` and `/`) can cause issues when transmitting an address in a link. When `urlSafe = true`, all `+` symbols are replaced with `-`, and all `/` symbols are replaced with `_`. You can obtain these address formats using the following code:
@@ -370,8 +372,11 @@ Most SDKs follow a similar process for sending messages from your wallet:
```
:::info
+
`sendMode: SendMode.PAY_GAS_SEPARATELY + SendMode.IGNORE_ERRORS` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
+
@@ -486,7 +491,9 @@ Don't forget that the comment message in a snake cell has 32 zero bits (i.e., it
To calculate a user's jetton wallet address, use the `get_wallet_address` method from the jetton master contract with the user's address. You can also call the master contract directly or use the `getWalletAddress` method provided in the JettonMaster SDK.
:::info
+
The `JettonMaster` in `@ton/ton` provides this functionality, although it lacks other features.
+
:::
@@ -916,9 +923,11 @@ When constructing a message for a jetton transfer, refer to [TEP-74](https://git
:::warning
+
When displaying token amounts, they are usually divided by `10^decimals` (often `9 decimals`). This allows for the use of the `toNano` function. If the number of decimals is different (e.g., 6), you will need to adjust accordingly.
Of course, one can always do calculation in indivisible units.
+
:::
@@ -1023,8 +1032,11 @@ Of course, one can always do calculation in indivisible units.
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
+
@@ -1073,18 +1085,25 @@ Of course, one can always do calculation in indivisible units.
If the `forward_amount` is nonzero, a notification about the Jetton reception will be sent to the destination contract. Additionally, if the `response_destination` address is non-null, excess Toncoin (called "excesses") will be sent to that address.
:::tip
+
Explorers support comments in Jetton notifications, similar to regular TON transfers. Comments are formatted as 32 zero bits followed by UTF-8 text.
+
:::
:::tip
+
Be careful when calculating fees and amounts for jetton transfer messages. For instance, transferring 0.2 TON with no excess may prevent you from receiving 0.1 TON in a response.
+
:::
## TEP-62 (NFT standard)
NFT collections on TON are highly customizable. The NFT contract can be defined as any contract that provides a valid get-method to return metadata. The transfer operation is standardized similarly to [Jettons](/v3/guidelines/dapps/cookbook#how-to-construct-a-message-for-a-jetton-transfer-with-a-comment).
+
:::warning
+
Reminder: all methods about NFT below are not bound by TEP-62 to work. Before trying them, check if your NFT or collection process those messages in an expected way. The wallet app emulation may be useful in this case.
+
:::
### How to use NFT batch deployment?
@@ -1094,7 +1113,9 @@ NFT collection smart contracts allow batch deployment of up to 250 NFTs in a sin
#### Batch mint NFT
:::info
+
Not specified by the NFT standard (ton-blockchain/token-contract).
+
:::
@@ -1277,7 +1298,9 @@ Changing the owner of a collection is simple. Specify the `opcode = 3`, any `que
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
@@ -1407,7 +1430,9 @@ Often, the collection's metadata is stored in a format similar to `0.json` and c
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
@@ -1768,7 +1793,9 @@ swap#e3a0d482 _:SwapStep swap_params:^SwapParams = ForwardPayload;
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
## Basics of message processing
@@ -2048,8 +2075,11 @@ This topic is explored in depth in the [Payments processing](/v3/guidelines/dapp
### How to find a transaction for a certain TON Connect result?
TON Connect 2 only returns the cell sent to the blockchain, not the transaction hash itself, as the transaction may not be confirmed. To track a transaction from TON Connect, you can search for it in your account history using an indexer.
+
:::tip
+
You can use an indexer to make the search easier. The provided implementation is for `TonClient` connected to an RPC.
+
:::
Prepare `retry` function for attempts on listening blockchain:
@@ -2138,7 +2168,9 @@ Create a listener function that will assert specific transaction on certain acco
### How to find a transaction or message hash?
:::info
+
Be careful with the hash definition. It can be either a transaction hash or a message hash.
+
:::
To get transaction hash you need to use a `hash` method of a transaction. To get external message hash you need
diff --git a/docs/v3/guidelines/dapps/overview.mdx b/docs/v3/guidelines/dapps/overview.mdx
index 3087eeb0ffd..904aca97497 100644
--- a/docs/v3/guidelines/dapps/overview.mdx
+++ b/docs/v3/guidelines/dapps/overview.mdx
@@ -27,8 +27,10 @@ Choose an SDK
## TON course: DApps
:::tip
+
Before starting the course, make sure you have a solid understanding of blockchain basics. If you need a refresher, we recommend taking the [Blockchain basics with TON](https://stepik.org/course/201294/promo) ([RU version](https://stepik.org/course/202221/), [CHN version](https://stepik.org/course/200976/)) course.
Module 3 covers core dApp concepts.
+
:::
The [TON Blockchain course](https://stepik.org/course/176754/) is a comprehensive guide to TON Blockchain development.
diff --git a/docs/v3/guidelines/dapps/tma/guidelines/monetization.mdx b/docs/v3/guidelines/dapps/tma/guidelines/monetization.mdx
index 53939f7bf63..43f3ec8a4fd 100644
--- a/docs/v3/guidelines/dapps/tma/guidelines/monetization.mdx
+++ b/docs/v3/guidelines/dapps/tma/guidelines/monetization.mdx
@@ -19,7 +19,9 @@ Useful links:
- [Demo Store Bot](https://t.me/PineAppleDemoWPStoreBot) is a Telegram bot for demonstrating Wallet Pay functionality.
:::note
+
All payments are processed using real assets
+
:::
- [Merchant Community](https://t.me/+6TReWBEyZxI5Njli) is a Telegram group for members to share experiences and solutions.
diff --git a/docs/v3/guidelines/dapps/tma/guidelines/tips-and-tricks.mdx b/docs/v3/guidelines/dapps/tma/guidelines/tips-and-tricks.mdx
index 607f2f09c27..a08348caecc 100644
--- a/docs/v3/guidelines/dapps/tma/guidelines/tips-and-tricks.mdx
+++ b/docs/v3/guidelines/dapps/tma/guidelines/tips-and-tricks.mdx
@@ -7,12 +7,15 @@ On this page, you'll find a list of frequently asked questions about issues in T
### How to solve the cache overflow issue in TMA?
:::tip
+
Reinstalling the Telegram application is the only effective solution.
+
:::
### Are there any recommendations on caching headers for HTML files?
:::tip
+
It’s best to disable caching in HTML files. To ensure caching is turned off, specify the following headers in your request:
```curl
@@ -50,6 +53,7 @@ window.Telegram.WebApp.enableClosingConfirmation()
## How to specify a description for a certain language in the TMA?
:::tip
+
Use the following methods to configure descriptions in different languages:
- [https://core.telegram.org/bots/api#setmydescription](https://core.telegram.org/bots/api#setmydescription)
diff --git a/docs/v3/guidelines/dapps/tma/overview.mdx b/docs/v3/guidelines/dapps/tma/overview.mdx
index 9ea4729aabf..6e7decd5167 100644
--- a/docs/v3/guidelines/dapps/tma/overview.mdx
+++ b/docs/v3/guidelines/dapps/tma/overview.mdx
@@ -61,7 +61,9 @@ Join chat
| [ton-defi-org/tonstarter-twa](https://github.com/ton-defi-org/tonstarter-twa) | a template for a new TMA interacting with TON |
:::tip
+
Since TMAs are web pages and use JavaScript, you need to choose [JS/TS-based SDK](/v3/guidelines/dapps/apis-sdks/sdk#typescript--javascript).
+
:::
diff --git a/docs/v3/guidelines/dapps/tma/tutorials/design-guidelines.mdx b/docs/v3/guidelines/dapps/tma/tutorials/design-guidelines.mdx
index 24bbba39537..17bc668402f 100644
--- a/docs/v3/guidelines/dapps/tma/tutorials/design-guidelines.mdx
+++ b/docs/v3/guidelines/dapps/tma/tutorials/design-guidelines.mdx
@@ -3,6 +3,7 @@ import Feedback from '@site/src/components/Feedback';
# TMA design guidelines
:::info
+
Starting with version **6.10**, Telegram updated the Mini App color palette by fixing some old colors and adding new ones.
:::
diff --git a/docs/v3/guidelines/dapps/tma/tutorials/step-by-step-guide.mdx b/docs/v3/guidelines/dapps/tma/tutorials/step-by-step-guide.mdx
index ea0ab9c9a54..89b2005a878 100644
--- a/docs/v3/guidelines/dapps/tma/tutorials/step-by-step-guide.mdx
+++ b/docs/v3/guidelines/dapps/tma/tutorials/step-by-step-guide.mdx
@@ -12,6 +12,7 @@ Telegram Mini Apps (TMA) are web applications that run inside the Telegram messe
```
:::tip
+
It's best to disable caching using HTTP response headers. To ensure caching is turned off, configure these headers in your server responses:
```text
@@ -19,6 +20,7 @@ Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0
```
+
:::
2. Once the script is connected, the **[window.Telegram.WebApp](https://core.telegram.org/bots/webapps#initializing-web-apps)** object becomes available. Learn more about creating a Mini App using [`telegram-web-app.js`](/v3/guidelines/dapps/tma/tutorials/app-examples#basic-tma-example) here.
diff --git a/docs/v3/guidelines/dapps/transactions/api-based-retrieval.mdx b/docs/v3/guidelines/dapps/transactions/api-based-retrieval.mdx
index 74bb7a25450..df7e537f166 100644
--- a/docs/v3/guidelines/dapps/transactions/api-based-retrieval.mdx
+++ b/docs/v3/guidelines/dapps/transactions/api-based-retrieval.mdx
@@ -117,8 +117,10 @@ This approach is beneficial when tracking a small number of accounts (up to \~10
It works well for wallet-v4 and wallet-v5 transfers and is primarily used to find transactions triggered by external messages.
:::note
+
There may be a delay of up to 10 seconds due to the time required to finalize the block.
For better performance in real-time scenarios, consider also monitoring the pending pool.
+
:::
---
diff --git a/docs/v3/guidelines/dapps/transactions/explore-transactions.mdx b/docs/v3/guidelines/dapps/transactions/explore-transactions.mdx
index 9cf4d4ff99f..27abd489cf0 100644
--- a/docs/v3/guidelines/dapps/transactions/explore-transactions.mdx
+++ b/docs/v3/guidelines/dapps/transactions/explore-transactions.mdx
@@ -67,6 +67,7 @@ According to the TL-B schema, a transaction consists of the following fields:
Other types of transactions—such as [trans_storage](https://github.com/ton-blockchain/ton/blob/26761a1d139402ef343081810677d2582c3eff51/crypto/block/block.tlb#L352-L353), [trans_tick_tock](https://github.com/ton-blockchain/ton/blob/26761a1d139402ef343081810677d2582c3eff51/crypto/block/block.tlb#L355-L357), [trans_split_prepare](https://github.com/ton-blockchain/ton/blob/26761a1d139402ef343081810677d2582c3eff51/crypto/block/block.tlb#L362-L366), and others—are used for internal events that are invisible to end users. These include shard splitting and merging, tick-tock transactions, etc.
Since they are not relevant to DApp development, we will not cover them in this tutorial.
+
:::
### Credit phase
@@ -160,7 +161,9 @@ To start, note that the compute phase can be **skipped** entirely. In that case,
| `cskip_suspended` | The account is frozen, so execution is disabled. This was used to freeze early miner accounts during the stabilization of TON’s tokenomics. |
:::tip
+
The `fixed_prefix_length` field can be used to specify a fixed prefix for the account address, ensuring that the account resides in a specific shard. This topic is outside the scope of this guide, but more information is available [here](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#anycast-addresses-and-address-rewrite).
+
:::
Now that we've covered the reasons why the compute phase might be skipped, let's examine what happens when the smart contract code is **executed**. The following fields are used to describe the result:
@@ -177,7 +180,9 @@ Now that we've covered the reasons why the compute phase might be skipped, let's
| `vm_steps` | `uint32` | The number of steps executed by the virtual machine during code execution. |
:::tip
+
The `commit` instruction is used to persist any changes made before it is called, even if an error occurs later in the same phase. These changes will only be rolled back if the **Action phase** fails.
+
:::
### Action phase
@@ -243,7 +248,9 @@ The action phase includes the following fields:
If the **Compute phase** or **Action phase** ends with an error, and the incoming message has the `bounce` flag set, the system triggers the **Bounce phase**.
:::note
+
For the bounce phase to trigger due to an error in the action phase, the failed action must have **flag 16** set, which enables bounce on error.
+
:::
```tlb
@@ -378,10 +385,12 @@ Among the supported open-source APIs, we can use TON Center [APIv2](https://tonc
The recommended approach is to use **JSON-RPC**, as it integrates with existing SDKs, where all fields are predefined and typed correctly. This removes the need to interpret each field manually.
:::note
+
When retrieving transactions, you might encounter the following error:
`LITE_SERVER_UNKNOWN: cannot compute block with specified transaction: cannot find block (0,ca6e321c7cce9ece) lt=57674065000003: lt not in db.`
This means the account’s transactions are old, and the blocks containing them are no longer stored on the LiteServer. In this case, you can use the option `archival: true` to fetch data from an archival node.
+
:::
### How to retrieve a transaction using api/v3
@@ -512,10 +521,12 @@ Earlier, we discussed **actions** from a technical perspective. However, many AP
For example, transferring Jettons from one wallet to another typically involves at least three separate transactions. Different services refer to these sequences using terms like **action**, **event**, or **operation**. To avoid confusion with the previously defined technical term **action**, we use the term **Event** here.
:::tip
+
Note that not every Jetton transfer qualifies as a `Jetton Transfer Event`. For instance, sending Jettons to a DEX to receive other tokens is classified as a `Swap Event`.
The classification depends heavily on how Jettons are used. API services typically parse the `forward_payload` and check additional parameters to determine the exact type of operation, then present it in a user-friendly format.
This approach applies not only to Jettons but also to NFTs and other on-chain operations.
+
:::
### Ordinary TON transfer: determining event success
@@ -593,11 +604,13 @@ After retrieving the transactions, we need to perform the following checks:
If all these conditions are met, we can consider the deposit successfully credited to the wallet.
:::danger
+
Please note that the provided code is a simplified example and does not constitute a complete deposit tracking solution.
In real applications, you should not limit the check to just the latest 10 transactions.
Instead, you must process all transactions that occurred since the last check.
Additionally, note that field values for fake deposits may vary depending on the API service used. This example only reflects the APIv3 response from the TON Center `transactions` endpoint.
+
:::
If we run this code, the expected output is:
@@ -609,9 +622,11 @@ Fake deposit detected: 4vXGhdvtfgFx8tkkaL17POhOwrUZq3sQDVSdNpW+Duk=
By inspecting this transaction in the [explorer](https://tonviewer.com/transaction/e2f5c685dbed7e0171f2d92468bd7b3ce84ec2b519ab7b100d549d3695be0ee9), we see that the funds return to the sender.
:::note
+
If we query this account’s transactions using APIv2, we don’t see any transactions. This happens because the transaction data exists only in the block, and only the APIv3 indexer captures it.
Since the account has no state at all—not even a single balance top-up—there are no transactions formally associated with it. If there is at least one deposit, the state changes from `nonexist` to `uninit`, and APIv2 then returns the transaction.
+
:::
### Jetton transfer: determining event success
@@ -787,9 +802,11 @@ internal_transfer query_id:uint64 amount:(VarUInteger 16) from:MsgAddress
```
:::note
+
Note that this is a highly simplified example.
Real applications may implement different logic for handling deposits.
For more details on how to process such events, refer to the [dedicated article](/v3/guidelines/dapps/asset-processing/jettons).
+
:::
### NFT transfer: determining event success
@@ -858,7 +875,9 @@ We call the method and check the owner's address.
:::note
+
As with the previous two examples, please note that this is a simplified scenario. In real-world applications, the system is more complex overall. For more detailed information, refer to the [dedicated article](/v3/guidelines/dapps/asset-processing/nft-processing/nfts).
+
:::
### How to determine event success from contract code and TL‑B
diff --git a/docs/v3/guidelines/dapps/transactions/foundations-of-blockchain.mdx b/docs/v3/guidelines/dapps/transactions/foundations-of-blockchain.mdx
index fc90afe1001..319dda3819d 100644
--- a/docs/v3/guidelines/dapps/transactions/foundations-of-blockchain.mdx
+++ b/docs/v3/guidelines/dapps/transactions/foundations-of-blockchain.mdx
@@ -226,7 +226,9 @@ In technical terms, a smart contract in TON is an `Account` in the active state
- an initialized `data` field in `StateInit` — storing the persistent contract state
:::note
+
An account may be in the `active` state with `state_init.code = None`. For example, immediately after a `SetCode` action in the VM. This is an edge case: such a state is not valid for execution but is technically possible.
+
:::
### Address
@@ -239,8 +241,10 @@ It consists of the following components:
- **Account ID** — a 256-bit hash of the `StateInit` structure, which includes the contract’s initialized `code`, `data`, and, optionally, a `library`. It is stored as an arbitrary `SliceData` and may not exactly match the hash of `StateInit`.
:::important
+
`StateInit` (short for _state initialized_) can change as the contract evolves.
The `account_id` never changes, as it’s based on the very first `StateInit` recorded at deployment.
+
:::
The address is defined as:
diff --git a/docs/v3/guidelines/dapps/transactions/hash-based-tracking.mdx b/docs/v3/guidelines/dapps/transactions/hash-based-tracking.mdx
index c66bcdb60f0..9dd95f8a3a1 100644
--- a/docs/v3/guidelines/dapps/transactions/hash-based-tracking.mdx
+++ b/docs/v3/guidelines/dapps/transactions/hash-based-tracking.mdx
@@ -37,17 +37,21 @@ it involves serialization and internal formatting steps, and in some cases, may
Each cell, message, or transaction has its unique hash, which acts as a digital signature.
:::info Important
+
Hashes in TON are irreversible — the original data cannot be reconstructed from the hash.
However, they are deterministic — the same input always produces the same hash.
+
:::
TON uses the _Merkle–Damgård construction_ for hashing, a method of building collision-resistant hash functions from one-way compression functions.
This design makes it vulnerable to **length extension attacks**.
:::warning
+
If you use hashes for authentication or message integrity, be aware that the Merkle–Damgård construction is susceptible to length extension attacks.
Avoid relying solely on raw hashes in security-critical contexts.
+
:::
## Hashes of structures
@@ -186,7 +190,9 @@ For details on how a hash is computed from the structure above, see:
- The practical section on retrieving hashes in the [DApp cookbook](/v3/guidelines/dapps/cookbook#how-to-find-transaction-or-message-hash).
:::info
+
A transaction hash is the representation hash (SHA‑256) of the root `Transaction` cell serialized per TL‑B, precisely as it appears in the block. Any change to messages, fees, or the state update alters the hash.
+
:::
**Obtaining a transaction hash:**
@@ -303,7 +309,9 @@ Normalized message hash: ce70ed4db0fd40aee2bd62b7d92707e8860762737872245687cc238
```
:::info
+
This example shows a low-level construction of the message. For a higher-level, SDK-based approach, see the example in [TON Connect](/v3/guidelines/ton-connect/guidelines/transaction-by-external-message#message-normalization).
+
:::
**Practical example of calculating a non-normalized hash:**
diff --git a/docs/v3/guidelines/dapps/transactions/message-driven-execution.mdx b/docs/v3/guidelines/dapps/transactions/message-driven-execution.mdx
index 762545a6f5c..a4529386c27 100644
--- a/docs/v3/guidelines/dapps/transactions/message-driven-execution.mdx
+++ b/docs/v3/guidelines/dapps/transactions/message-driven-execution.mdx
@@ -413,7 +413,9 @@ npx blueprint run sendBounceableMessages --testnet --mnemonic
:::important
+
Bounce messages are regular internal messages marked with the `bounced = true` flag. By convention, they signal errors, but a smart contract chooses to process them or ignore them, depending on its logic.
+
:::
## Custom message structure
diff --git a/docs/v3/guidelines/dapps/tutorials/mint-your-first-token.mdx b/docs/v3/guidelines/dapps/tutorials/mint-your-first-token.mdx
index 69d72e5efee..b5c95da00ea 100644
--- a/docs/v3/guidelines/dapps/tutorials/mint-your-first-token.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/mint-your-first-token.mdx
@@ -24,7 +24,9 @@ Before you start, make sure you have the following:
At least 0.25 Toncoin in your wallet (plus extra for blockchain fees)
:::tip Starter tip
+
\~0.5 TON should be enough for this tutorial.
+
:::
## 🚀 Let's get started!
@@ -59,12 +61,14 @@ If you want your token to stand out, you’ll need to host an attractive logo on
- [https://bitcoincash-example.github.io/website/logo.png](https://bitcoincash-example.github.io/website/logo.png)
:::info
+
You can easily find out about the URL placement of the logo in the [repository](https://github.com/ton-blockchain/minter-contract#jetton-metadata-field-best-practices) in the 'Where is this metadata stored' paragraph.
- On-chain.
- Off-chain IPFS.
- Off-chain website.
- :::
+
+:::
#### How to create your logo URL?
@@ -84,9 +88,11 @@ On the right side of the screen, you can **send tokens** to multi-currency walle

:::info
+
You also can **burn** your tokens to reduce their amount.

+
:::
### 📱 Send tokens from your phone using Tonkeeper
@@ -107,9 +113,11 @@ Then, go to **your token**, set the **amount** to send, and enter the **recipien
You can manage your token by entering its address in the **search bar** at the top of the TON Minter site.
:::info
+
The address can be found on the right side if you are already in the owner panel, or you can find the token address when receiving an airdrop.

+
:::
## ✏️ Jetton (token) customization
@@ -141,7 +149,9 @@ npm run build
The result will describe the process of creating the necessary files and the search for smart contracts.
:::info
+
Read the console, there are a lot of tips!
+
:::
6. You can test your changes using:
diff --git a/docs/v3/guidelines/dapps/tutorials/nft-minting-guide.mdx b/docs/v3/guidelines/dapps/tutorials/nft-minting-guide.mdx
index fef064a4be4..562ba25ff66 100644
--- a/docs/v3/guidelines/dapps/tutorials/nft-minting-guide.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/nft-minting-guide.mdx
@@ -27,7 +27,8 @@ You must already have a testnet wallet with at least 2 TON. You can get testnet
1. Open Wallets list.
2. Create a new Testnet wallet: Add wallet → Add Testnet Account.
- :::
+
+:::
We will use Pinata as our IPFS storage system, so you also need to create an account on [pinata.cloud](https://pinata.cloud) and get api_key and api_secret. The official Pinata [documentation](https://docs.pinata.cloud/account-management/api-keys) can help with that. Once you have these API tokens, I'll be waiting for you here!
@@ -59,7 +60,9 @@ On TON, there is one master contract—the collection's smart contract—which s

:::info
+
You can check out the article on [NFT processing on TON](/v3/guidelines/dapps/asset-processing/nft-processing/nfts) or read the [NFT standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md) for a deeper understanding.
+
:::
## ⚙ Setup development environment
@@ -229,7 +232,9 @@ export function sleep(ms: number): Promise {
```
:::info What is it - seqno?
+
Simply put, seqno is a counter that tracks outgoing transactions from a wallet. It helps prevent Replay Attacks. hen a transaction is sent to a wallet smart contract, it compares the seqno field in the transaction with the one stored in the wallet. If they match, the transaction is accepted, and the stored seqno increments by one. If they don't match, the transaction is discarded. This is why we need to wait a bit after every outgoing transaction.
+
:::
## 🖼 Prepare metadata
@@ -641,7 +646,9 @@ public async deploy(wallet: OpenedWallet) {
```
:::info
+
`sendMode: SendMode.PAY_GAS_SEPARATELY + SendMode.IGNORE_ERRORS` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
Deploying a new smart contract in our case means sending a message from our wallet to the collection address, which we can calculate if we have `StateInit`, along with its `StateInit`.
@@ -793,7 +800,9 @@ export class NftItem {
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
At the end, we write a short method to retrieve an NFT's address by its index:
@@ -1123,7 +1132,9 @@ Finally, let's send our message:
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
Once the sale contract is deployed, the only step left is to transfer ownership of the NFT item to the sale contract's address.
diff --git a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-2.mdx b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-2.mdx
index d4bf7631dd8..02b0a37fc3d 100644
--- a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-2.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-2.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
# Bot with own balance
:::caution
+
The integration method described in this guide is one of the available approaches. With ongoing developments, Telegram Mini Apps provide additional capabilities that better suit modern security and functionality requirements.
+
:::
In this article, we'll create a simple Telegram bot for accepting payments in TON.
diff --git a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-js.mdx b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-js.mdx
index 98522dc3159..4fe378879eb 100644
--- a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-js.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot-js.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
# Bot for selling dumplings
:::caution
+
The integration method described in this guide is one of the available approaches. With ongoing developments, Telegram Mini Apps provide additional capabilities that better suit modern security and functionality requirements.
+
:::
In this article, we'll create a simple Telegram bot for accepting payments in TON.
diff --git a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot.mdx b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot.mdx
index 74a08583fc1..8078f64961f 100644
--- a/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/telegram-bot-examples/accept-payments-in-a-telegram-bot.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
# Storefront bot with payments in TON
:::caution
+
The integration method described in this guide is one of the available approaches. With ongoing developments, Telegram Mini Apps provide additional capabilities that better suit modern security and functionality requirements.
+
:::
In this article, we'll guide you through the process of accepting payments in a Telegram bot.
diff --git a/docs/v3/guidelines/dapps/tutorials/zero-knowledge-proofs.mdx b/docs/v3/guidelines/dapps/tutorials/zero-knowledge-proofs.mdx
index 7dd3318ac92..81b5ecda1da 100644
--- a/docs/v3/guidelines/dapps/tutorials/zero-knowledge-proofs.mdx
+++ b/docs/v3/guidelines/dapps/tutorials/zero-knowledge-proofs.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
**Zero-knowledge (ZK)** proofs are a fundamental cryptographic concept that allows **the prover** to prove to **the verifier** that a statement is true without revealing any additional information. ZK proofs are a powerful tool for building privacy-preserving systems and are widely used in applications such as anonymous payments, private messaging, and trustless bridges.
:::tip TVM upgrade 2023.07
+
Before June 2023, verifying cryptographic proofs on TON was not possible. Due to the complex computations required for the pairing algorithm, the TON Virtual Machine (TVM) needed to be upgraded with new opcodes to support proof verification. This functionality was added in the [June 2023 update](https://docs.ton.org/learn/tvm-instructions/tvm-upgrade#bls12-381).
+
:::
## 🦄 This tutorial will cover
@@ -132,6 +134,7 @@ node ../../../snarkjs/build/cli.cjs powersoftau verify pot14_final.ptau
Once the process is complete, a file named pot14_final.ptau will be created inside the build/circuits folder. This file can be reused for generating future circuits.
:::caution Constraint size
+
If you plan to write a more complex circuit with additional constraints, you’ll need to generate a Powers of Tau (PTAU) setup using a larger parameter.
You can remove the unnecessary files:
@@ -151,7 +154,9 @@ circom ../../circuits/test.circom --r1cs circuit.r1cs --wasm circuit.wasm --prim
After running this command, the compiled circuit will be available in `build/circuits/circuit.sym`, `build/circuits/circuit.r1cs`, and `build/circuits/circuit.wasm`.
:::info altbn-128 and bls12-381 curves
+
The altbn-128 and bls12-381 elliptic curves are currently supported by snarkjs. However, the [altbn-128](https://eips.ethereum.org/EIPS/eip-197) curve is only supported on Ethereum, whereas TON exclusively supports the bls12-381 curve.
+
:::
To check the constraint size of the circuit, run:
diff --git a/docs/v3/guidelines/get-started-with-ton.mdx b/docs/v3/guidelines/get-started-with-ton.mdx
index 1f68c0d1d4a..101d46520c4 100644
--- a/docs/v3/guidelines/get-started-with-ton.mdx
+++ b/docs/v3/guidelines/get-started-with-ton.mdx
@@ -9,7 +9,9 @@ import Player from '@site/src/components/player'
Discover the speed, reliability, and core principles of asynchronous thinking by building your first application on TON Blockchain — from scratch.
:::tip newcomer-friendly guide
+
This is the perfect place to start if you're entirely new to programming.
+
:::
This learning path is split into **5** beginner-friendly modules and takes approximately **45 minutes**.
@@ -81,7 +83,9 @@ First, you need a non-custodial wallet to receive and store your Toncoin. For th
You need to enable Testnet mode within the wallet to receive Testnet Toncoin. These tokens will be used later to send a final minting transaction to the smart contract.
:::info
+
With a non-custodial wallet, the user owns the wallet and holds the private key themselves.
+
:::
To download and create a TON wallet, follow these simple steps:
@@ -96,7 +100,9 @@ Let's start development now.
We use a boilerplate to simplify your life and skip routine low-level tasks.
:::tip
+
Note that you need to [sign in](https://github.com/login) to GitHub for further work.
+
:::
Please use the [ton-onboarding-challenge](https://github.com/ton-community/ton-onboarding-challenge) template to create your project by clicking the “Use this template” button and selecting the “Create a new repository” tab as shown below:
@@ -120,7 +126,9 @@ After completing this step, you'll have access to a highly performant repository
The next step is to choose which developer environment best suits your needs, experience level, and overall skill set. As you can see, this process can be carried out using either a cloud-based or local environment. Developing on the cloud is often considered simpler and easier to get started. Below, we’ll outline the steps required for both approaches.
:::tip
+
Ensure you have opened the repository in your GitHub profile generated from the template in the previous step.
+
:::
@@ -288,7 +296,9 @@ const client = new TonClient({ endpoint });
```
:::info what to do in production?
+
Using an RPC node provider or running your own ton-http-api instance is better for that. Read more at the [TON HTTP-based APIs page](/v3/guidelines/dapps/apis-sdks/ton-http-apis).
+
:::
### Receiving mining data from TON Blockchain
@@ -330,7 +340,9 @@ npm run start:script
```
:::tip
+
To avoid unexpected issues, ensure you have finalized all previous steps, including inputting contract addresses.
+
:::
Good! As long as the above processes are executed correctly, a successful connection to the API will be achieved, and the necessary data will be displayed in the console. The correct console output should be initiated as follows:
@@ -357,12 +369,14 @@ The output above shows data on executing a process with a collection of numerica
We need to convert the stack output into a more _useful form_.
:::info GAS PARAMETERS ON TON
+
**Warning**: Though this information is highly complex and **not necessary for this tutorial** if you're interested in understanding the complex technical aspects of TON, consider using these resources:
1. To better understand how TON Virtual Machine (TVM) operates and _how TON processes transactions_, check out [TVM overview section](/v3/documentation/tvm/tvm-overview).
2. Secondly, if you want to learn more about how transaction and gas fees work on TON, consider diving into [this section](/v3/documentation/smart-contracts/transaction-fees/fees) of our documentation.
3. Finally, to better understand the exact gas values needed to carry out TVM instructions, see [this section](/v3/documentation/tvm/instructions#gas-prices) of our documentation.
- :::
+
+:::
Now, let's return to the tutorial!
@@ -434,7 +448,9 @@ First, we must prepare a mining message by ensuring the correct parameters to en
Thankfully, the [README file](https://github.com/ton-community/ton-onboarding-challenge#mining-process-deep-dive) allows us to retrieve the correct guidelines to achieve this goal. As you can see, the above README file comprises a table with specific fields and cell types (titled "Layout of proof of work cell') to help achieve our desired result.
:::info What are cells?
+
Cells are data storage structures on TON that fulfill numerous purposes, including increasing network scalability and smart contract transaction speeds. We won't get into specifics here, but if you're interested in understanding the complexity of cells and how they work, consider diving into [this](/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage) section of our documentation.
+
:::
Fortunately, all the data structures used in this tutorial are already written in TypeScript. Use the `MineMessageParams` object from _NftGiver.ts_ to build a transaction with _Queries_:
@@ -461,7 +477,9 @@ Probably you have a question: where are the _op_ and _data2_ from the [table](ht
- Because the `op` classification is always constant, it is already implemented in transaction builder _Queries_ and in _OpCodes_. You can find the opcode by going to the source code of the `mine()` method.
:::tip
+
Though it may be interesting to check out the source code (`../wrappers/NftGiver.ts`), but it is unnecessary.
+
:::
### Creating TON NFT miners
@@ -642,7 +660,9 @@ To successfully mine an NFT rocket on Testnet, it is necessary to follow these s
6. _Confirm_ the transaction in your Tonkeeper wallet.
:::tip final tip
+
Because other developers may be carrying out the same process in an attempt to mine their own NFT, you may need to try the process a couple of times to succeed, as another user could mine the next NFT available right before you.
+
:::
Soon after initiating this process, you will have successfully mined your first NFT on TON, and it should appear in your Tonkeeper wallet.
@@ -677,7 +697,9 @@ As we outlined in the Testnet NFT rocket mining process, to successfully mine an
6. _Confirm_ the transaction in your Tonkeeper wallet.
:::tip final tip
+
Because other developers may be carrying out the same process to mine their own NFT, you may have to try the process a couple of times to be successful (as another user could mine the next NFT available right before you).
+
:::
After some time, you will have **mined your NFT** and become a TON Developer in TON Blockchain. The ritual is complete. Look at your NFT in Tonkeeper.
@@ -712,7 +734,9 @@ After finishing the TON onboarding challenge, where we successfully mined an NFT
- [How to run TON Site](/v3/guidelines/web3/ton-proxy-sites/how-to-run-ton-site)
:::info have some feedback?
+
You are one of the first explorers here. If you find any mistakes or feel stacked, please send feedback to [@SwiftAdviser](https://t.me/SwiftAdviser). I will fix it ASAP! :)
+
:::
diff --git a/docs/v3/guidelines/nodes/custom-overlays.mdx b/docs/v3/guidelines/nodes/custom-overlays.mdx
index 0dcc66c21c1..84192c3df4b 100644
--- a/docs/v3/guidelines/nodes/custom-overlays.mdx
+++ b/docs/v3/guidelines/nodes/custom-overlays.mdx
@@ -55,7 +55,9 @@ Create a config file in the following format:
`msg_sender_priority` determines the order of external message inclusion in blocks: messages from higher-priority sources are first processed. Messages from the public overlay and local LS have priority 0.
:::caution
+
All nodes listed in the configuration **must** participate in the overlay; if they do not add an overlay with the exact same configuration, connectivity will be poor and broadcasts may fail.
+
:::
There is a special word `@validators` to create a dynamic custom overlay that MyTonCtrl will generate automatically each round adding all current validators.
@@ -69,7 +71,9 @@ MyTonCtrl> add_custom_overlay
```
:::caution
+
The name and config file **must** be the same on all overlay members. Check that the overlay has been created using MyTonCtrl's `list_custom_overlays` command.
+
:::
### Debug
diff --git a/docs/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-prometheus.mdx b/docs/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-prometheus.mdx
index 4be386cb457..77ac9e62416 100644
--- a/docs/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-prometheus.mdx
+++ b/docs/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-prometheus.mdx
@@ -13,7 +13,9 @@ So it should be used with the [Prometheus Pushgateway](https://github.com/promet
## Setup
:::caution
+
For validators it's highly recommended to run Prometheus and Pushgateway on a separate server.
+
:::
1. Install Pushgateway
@@ -74,8 +76,11 @@ For validators it's highly recommended to run Prometheus and Pushgateway on a se
```bash
MyTonCtrl> set prometheus_url http://:9091/metrics/job/
```
+
:::warning
+
Note that it is very important to use different job names for different nodes in case you want to monitor multiple nodes with the same Prometheus instance.
+
:::
5. Check the metrics
diff --git a/docs/v3/guidelines/nodes/monitoring/performance-monitoring.mdx b/docs/v3/guidelines/nodes/monitoring/performance-monitoring.mdx
index b06356f6c15..118e6369437 100644
--- a/docs/v3/guidelines/nodes/monitoring/performance-monitoring.mdx
+++ b/docs/v3/guidelines/nodes/monitoring/performance-monitoring.mdx
@@ -9,7 +9,9 @@ Tools such as `htop`, `iotop`, `iftop`, `dstat`, and `nmon` are effective for me
This guide recommends using the Linux SAR (System Activity Report) utility for monitoring the performance of TON servers, and it provides an explanation of how to use it effectively.
:::tip
+
This guideline helps to identify whether your server experiences a resource shortage, not whether the validator engine performs badly.
+
:::
### Installation
@@ -124,7 +126,9 @@ cat /sys/class/net//speed
```
:::info
+
The speed you're experiencing is not what your provider promised you.
+
:::
Consider upgrading your link speed if `%ifutil` shows above 70% usage or columns `rxkB/s` and `txkB/s` reporting values close to a bandwidth provided by your provider.
diff --git a/docs/v3/guidelines/nodes/node-maintenance-and-security.mdx b/docs/v3/guidelines/nodes/node-maintenance-and-security.mdx
index 057cc302e71..a73606e77ac 100644
--- a/docs/v3/guidelines/nodes/node-maintenance-and-security.mdx
+++ b/docs/v3/guidelines/nodes/node-maintenance-and-security.mdx
@@ -167,7 +167,9 @@ sudo ufw allow proto udp from any to any port `sudo jq -r '.addrs[0].p
#### Doublecheck your management networks
:::caution important
+
**Before enabling a firewall, double-check that you added the correct management addresses!**
+
:::
#### Enable ufw firewall
@@ -214,7 +216,9 @@ See this excellent **[ufw tutorial](https://www.digitalocean.com/community/tutor
If you suspect that your node is under attack, consider changing your IP address. The method for switching will depend on your hosting provider. You may need to pre-order a second IP address, clone your **stopped** virtual machine (VM) to create a new instance or set up a fresh instance through a [disaster recovery](#disaster-recovery) process.
:::warning
+
Regardless of the approach you choose, be sure to [update your new IP address](#set-node-ip-address) in the node configuration file!
+
:::
diff --git a/docs/v3/guidelines/nodes/nodes-troubleshooting.mdx b/docs/v3/guidelines/nodes/nodes-troubleshooting.mdx
index 68c904cd04d..f6fb3c7d819 100644
--- a/docs/v3/guidelines/nodes/nodes-troubleshooting.mdx
+++ b/docs/v3/guidelines/nodes/nodes-troubleshooting.mdx
@@ -59,9 +59,11 @@ For wallet contracts:
This process can sometimes take up to 24 hours. However, if you've been receiving this error for several days, that means that your node cannot synchronize via a current network connection.
:::tip Solution
+
You need to check the firewall settings, including any NAT settings if they exist.
It should allow incoming connections on one specific port and outgoing connections from any port.
+
:::
## Validator console is not settings
@@ -69,6 +71,7 @@ It should allow incoming connections on one specific port and outgoing connectio
If you encounter the `Validator console is not settings` error, it indicates that you are running `MyTonCtrl` from a user other than the one you used for the installation.
:::tip Solution
+
Run `MyTonCtrl` from [the user you've installed](/v3/guidelines/nodes/running-nodes/full-node#switch-to-non-root-user) it (non-root sudo user).
```bash
@@ -106,7 +109,9 @@ In such cases, you should repeat the request after a short delay.
If you encounter an issue where the `out of sync` equals the timestamp after downloading `MyTonCtrl` with the `-d` flag, it's possible that the dump wasn't installed correctly (or it's already outdated).
:::tip Solution
+
The recommended solution is to reinstall `MyTonCtrl` again with the new dump.
+
:::
If synchronization takes an unusually long time, there may be issues with the dump. Please [contact us](https://t.me/SwiftAdviser) for assistance.
@@ -118,7 +123,9 @@ Execute the `mytonctrl` command using the user account under which it was instal
This error indicates that the local node is not yet synchronized, has been out of sync for less than 20 seconds, and that public nodes are being utilized. Public nodes do not always respond, which can result in a timeout error.
:::tip Solution
+
The solution to the problem is to wait for the local node to synchronize or to execute the same command multiple times before proceeding.
+
:::
## Status command displays without local node section
@@ -144,7 +151,9 @@ MyTonCtrl> set validatorWalletName validator_wallet_001
## Transfer a validator on the new server
:::info
+
Transfer all keys and configs from the old to the working node and start it. In case something goes wrong on the new one, the source where everything is set up is still available.
+
:::
The best way (while the penalty for temporary non-validation is small, it can be done without interruption):
diff --git a/docs/v3/guidelines/nodes/running-nodes/archive-node.mdx b/docs/v3/guidelines/nodes/running-nodes/archive-node.mdx
index 1800d5217e2..66b638781bf 100644
--- a/docs/v3/guidelines/nodes/running-nodes/archive-node.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/archive-node.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# Archive node
:::info
+
Before this article, read about [Full node](/v3/guidelines/nodes/running-nodes/full-node).
+
:::
## Overview
@@ -29,7 +31,9 @@ We highly recommend installing mytonctrl using the supported operating systems:
- A public IP address (fixed IP address)
:::info Data compression
+
Uncompressed data requires 12 TB of storage. A ZFS volume with compression reduces this to 11 TB. As of February 2025, the data volume is growing by approximately 0.1 to 1 TB per month, depending on the load.
+
:::
## Installation
@@ -147,17 +151,21 @@ nano /etc/systemd/system/validator.service
```
:::info
+
Please remain patient after starting the node and monitor the logs closely.
The dump files lack DHT caches, requiring your node to discover other nodes and synchronize with them.
Depending on the snapshot's age and your network bandwidth,
your node might need **anywhere from several hours to multiple days** to synchronize with the network.
**The synchronization process typically takes up to 5 days when using minimum hardware specifications.**
This is expected behavior.
+
:::
:::caution
+
If the node sync process has already taken 5 days, but the node is still out of sync, you should check the
[troubleshooting section](/v3/guidelines/nodes/nodes-troubleshooting#archive-node-is-out-of-sync-even-after-5-days-of-the-syncing-process).
+
:::
#### Start the node
@@ -225,13 +233,17 @@ zfs rollback data/ton-work@dumpstate
If your node operates properly, you may remove this snapshot to reclaim storage space. However, we recommend creating regular filesystem snapshots for rollback capability since the validator node may occasionally corrupt data and `config.json`. For automated snapshot management, [zfsnap](https://www.zfsnap.org/docs.html) handles rotation effectively.
:::tip Need help?
+
Have a question or need help? Please ask in the [TON dev chat](https://t.me/tondev_eng) to get help from the community. MyTonCtrl developers also hang out there.
+
:::
## Tips & tricks
:::info
+
Basic info about archival dumps is present at https://archival-dump.ton.org/
+
:::
### Remove dump snapshot
diff --git a/docs/v3/guidelines/nodes/running-nodes/collators-validators.mdx b/docs/v3/guidelines/nodes/running-nodes/collators-validators.mdx
index 560e4018f57..b3c19259cae 100644
--- a/docs/v3/guidelines/nodes/running-nodes/collators-validators.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/collators-validators.mdx
@@ -2,7 +2,9 @@
:::caution
+
Please be aware that collator nodes used by validators should be treated as mission-critical assets, especially if more than one validator utilizes a collator machine. Great care should be taken to ensure the flawless operation and failover of these nodes. Any configuration changes to collators must be thoroughly tested and reviewed before being implemented.
+
:::
## Collators
@@ -42,9 +44,11 @@ setup_collator --adnl 5889072E81219A0E656F31E8784EA09C93A562AA74308E1B25364EE87E
```
:::caution
+
Adding new shards to monitor on an existing node that is already monitoring other shards is not recommended, as it may cause performance issues or unexpected behavior.
When using `setup_collator`, MyTonCtrl checks if the provided shards are already included in the nodes already monitored and raises an error if they are not.
However, it's entirely ok to add new ADNL addresses to the collator to collate blocks for already monitored shards and broadcast them with a different ADNL address.
+
:::
### Collator actions
@@ -68,7 +72,9 @@ add_validator_to_collation_wl [adnl2] ...
```
:::note
+
The `adnl` argument here is the ADNL address of the remote validator, in line with the output of the `status` command on the validator that shows the address in the `ADNL address of local validator` field.
+
:::
This will enable collation wl and add specified validators to it.
@@ -103,9 +109,11 @@ This command displays the current state of the collation whitelist, showing all
### Stopping collator
:::caution
+
It is highly not recommended to reuse a collator node as a validator after it was used as a collator, as it may
not sync the whole blockchain and miss the creation of blocks for some shards. So it is recommended to uninstall MyTonCtrl
and then install it again in `validator` mode.
+
:::
To stop the collator, you can use the command:
@@ -154,8 +162,10 @@ Where:
- `round_robin` - Cycle through collators sequentially
:::note
+
The `--self-collate` and `--select-mode` options apply to all collators for the specified shard.
If these options are already configured for that shard, they will be overridden.
+
:::
### Managing validator collators
diff --git a/docs/v3/guidelines/nodes/running-nodes/full-node.mdx b/docs/v3/guidelines/nodes/running-nodes/full-node.mdx
index fd4080eb311..6f1a53242e3 100644
--- a/docs/v3/guidelines/nodes/running-nodes/full-node.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/full-node.mdx
@@ -16,7 +16,9 @@ We highly recommend installing MyTonCtrl on the following supported operating sy
## Hardware requirements
:::caution Node usage on personal local machine
+
You shouldn't run any type of node on your personal local machine for extended periods, even if it meets the requirements. Nodes actively use disks, which can lead to rapid wear and potential damage.
+
:::
### With validator
@@ -29,7 +31,9 @@ You shouldn't run any type of node on your personal local machine for extended p
- 64 TB/month traffic (100 TB/month at a peak load)
:::info Be ready for peak loads
+
To reliably handle peak loads, a connection of at least 1 Gbit/s is typically required, while the average load is expected to be around 100 Mbit/s.
+
:::
### Port forwarding
@@ -39,7 +43,9 @@ All types of nodes require a static external IP address, one UDP port forwarded
You can accomplish this by contacting your network provider or [renting a server](/v3/guidelines/nodes/running-nodes/full-node#recommended-providers) to run a node.
:::info
+
You can find out which UDP ports are open using the `netstat -tulpn` command.
+
:::
### Recommended providers
@@ -57,7 +63,9 @@ The TON Foundation recommends the following providers for running a validator:
| AWS | `i4i.8xlarge` | `32 vCPUs` | `256GB` | `2 x 3,750 AWS Nitro SSD (fixed)` | `Up to 25 Gbps` | Bind an Elastic IP | `64 TB/month` |
:::info
+
**Note:** Prices, configurations, and availability can change. It is recommended to always refer to the official documentation and pricing pages of the respective cloud provider before making any decisions.
+
:::
## Run a node (video)
@@ -83,7 +91,9 @@ Please check this step-by-step video tutorial to get started quickly:
### Switch to non-root user
:::warning
+
This step is required to successfully install and use MyTonCtrl—don't ignore non-root user creation. Without this step, there will be no errors during installation, but MyTonCtrl will not work properly.
+
:::
If you don't have a non-root user, you can create one with the following steps (otherwise, skip the first two steps and go to the third).
@@ -167,8 +177,10 @@ Example of the **status** command output:

:::caution Make sure you have the same output for status
+
For all nodes type **Local Validator status** section should appear.
Otherwise, [check troubleshooting section](/v3/guidelines/nodes/nodes-troubleshooting#status-command-displays-without-local-node-section) and [check node logs](/v3/guidelines/nodes/running-nodes/full-node#check-the-node-logs).
+
:::
Please wait until the `Local validator out of sync` status is less than 20 seconds.
diff --git a/docs/v3/guidelines/nodes/running-nodes/liteserver-node.mdx b/docs/v3/guidelines/nodes/running-nodes/liteserver-node.mdx
index 12544eee1b4..231b3705b93 100644
--- a/docs/v3/guidelines/nodes/running-nodes/liteserver-node.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/liteserver-node.mdx
@@ -6,7 +6,9 @@ import TabItem from '@theme/TabItem';
# Liteserver node
:::info
+
Before reading this article, please refer to the section on [Full node](/v3/guidelines/nodes/running-nodes/full-node) for more information.
+
:::
When an endpoint is activated in a full node, that node becomes a **liteserver**. This type of node can handle and respond to requests from the lite-client, facilitating smooth interaction with the TON Blockchain.
diff --git a/docs/v3/guidelines/nodes/running-nodes/run-mytonctrl-docker.mdx b/docs/v3/guidelines/nodes/running-nodes/run-mytonctrl-docker.mdx
index f0031c9affc..22b4e25f74e 100644
--- a/docs/v3/guidelines/nodes/running-nodes/run-mytonctrl-docker.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/run-mytonctrl-docker.mdx
@@ -16,7 +16,9 @@ To ensure an optimal experience while running MyTonCtrl, here are the recommende
- 16 TB/month traffic on peak load
:::warning
+
This setup is primarily intended for testing purposes, so it may not be suitable for production environments. If you’d like to bypass hardware checks for any reason, you can easily do this by setting the variable ``IGNORE_MINIMAL_REQS=true``.
+
:::
## Software requirements
diff --git a/docs/v3/guidelines/nodes/running-nodes/running-a-local-ton.mdx b/docs/v3/guidelines/nodes/running-nodes/running-a-local-ton.mdx
index 396a62b77e7..f753379b5f8 100644
--- a/docs/v3/guidelines/nodes/running-nodes/running-a-local-ton.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/running-a-local-ton.mdx
@@ -176,7 +176,9 @@ Track MyLocalTon's operation through these log files:
### Important notice
:::caution
+
Developers currently classify MyLocalTon as alpha software, making it unsuitable for production environments. For containerized deployment, developers recommend using the [dedicated Docker repository](https://github.com/neodix42/mylocalton-docker).
+
:::
### Resources
diff --git a/docs/v3/guidelines/nodes/running-nodes/secure-guidelines.mdx b/docs/v3/guidelines/nodes/running-nodes/secure-guidelines.mdx
index e127a4c690a..43873057f46 100644
--- a/docs/v3/guidelines/nodes/running-nodes/secure-guidelines.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/secure-guidelines.mdx
@@ -101,7 +101,9 @@ Ensuring the security of nodes, particularly in decentralized networks such as b
- Utilize **AIDE (Advanced Intrusion Detection Environment)** to monitor file integrity and identify any unauthorized changes.
:::caution
+
Please remain vigilant and ensure that your node is secure at all times.
+
:::
diff --git a/docs/v3/guidelines/nodes/running-nodes/staking-with-nominator-pools.mdx b/docs/v3/guidelines/nodes/running-nodes/staking-with-nominator-pools.mdx
index edd4613b3ce..4b37221c066 100644
--- a/docs/v3/guidelines/nodes/running-nodes/staking-with-nominator-pools.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/staking-with-nominator-pools.mdx
@@ -23,7 +23,9 @@ To become a validator, you must meet two requirements: have a high-performance s
## Nominator
:::info
+
New version of [nominator pool](/v3/documentation/smart-contracts/contracts-specs/nominator-pool/) available, read more in the [Single nominator pool](/v3/documentation/smart-contracts/contracts-specs/single-nominator-pool/) and [Vesting contract](/v3/documentation/smart-contracts/contracts-specs/vesting-contract/) pages.
+
:::
It's evident that not everyone can afford to have 100,000s of Toncoin on their balance – here's where nominators come into play. Simply put, the nominator is a user who lends his TON to validators. Every time the validator earns a reward by validating blocks, it is distributed between the involved participants.
@@ -47,7 +49,9 @@ Since validation round lasts ~18 hours, takes about 5 TON per validation round a
- [Nominator pool smart contract source code](https://github.com/ton-blockchain/nominator-pool)
:::info
+
The theory of nominators is described in [TON Whitepaper](https://docs.ton.org/ton.pdf), chapters 2.6.3, 2.6.25.
+
:::
## See also
diff --git a/docs/v3/guidelines/nodes/running-nodes/validator-node.mdx b/docs/v3/guidelines/nodes/running-nodes/validator-node.mdx
index 9f096d201ef..50e5241588f 100644
--- a/docs/v3/guidelines/nodes/running-nodes/validator-node.mdx
+++ b/docs/v3/guidelines/nodes/running-nodes/validator-node.mdx
@@ -24,7 +24,9 @@ All types of nodes require a static external IP address, one UDP port forwarded
You can work with your network provider or [rent a server](/v3/guidelines/nodes/running-nodes/full-node#recommended-providers) to run a node.
:::info
+
To determine which UDP ports are open, use the `netstat -tulpn` command.
+
:::
## Prerequisites
@@ -90,7 +92,9 @@ The command above sets the stake size to 50k Toncoins. If the bet is accepted an
## Adhere to rules
:::caution Slashing policy for underperforming validators
+
If a validator processes less than 90% of the expected number of blocks during a validation round, that validator will incur a fine of 101 TON. For more information, read about the [slashing policy](/v3/documentation/infra/nodes/validation/staking-incentives#decentralized-system-of-penalties).
+
:::
As a TON validator, make sure you follow these crucial steps to ensure network stability and avoid slashing penalties in the future.
@@ -114,17 +118,23 @@ As a TON validator, make sure you follow these crucial steps to ensure network s
- Check [Build dashboard with APIs](/v3/guidelines/nodes/running-nodes/validator-node#validation-effectiveness-apis).
:::info
+
`MyTonCtrl` enables you to evaluate the performance of validators using the command `check_ef`. This command provides efficiency data for both the last round and the current round. The data is retrieved by calling the `checkloadall` utility. Make sure that your efficiency is above 90% for the entire round period.
+
:::
:::info
+
If you encounter low efficiency, take action to resolve the issue. If necessary, contact technical support at [@mytonctrl_help_bot](https://t.me/mytonctrl_help_bot).
+
:::
## Validation effectiveness APIs
:::info
+
Please set up dashboards to monitor your validators using the APIs provided below.
+
:::
### Penalized validators tracker
diff --git a/docs/v3/guidelines/quick-start/blockchain-interaction/reading-from-network.mdx b/docs/v3/guidelines/quick-start/blockchain-interaction/reading-from-network.mdx
index 1089bb48310..595a53263da 100644
--- a/docs/v3/guidelines/quick-start/blockchain-interaction/reading-from-network.mdx
+++ b/docs/v3/guidelines/quick-start/blockchain-interaction/reading-from-network.mdx
@@ -259,9 +259,9 @@ Interaction within an account on the blockchain happens due to [messages and tra
A transaction in TON is the **result** of a smart contract successfully processing an incoming message. It consists of:
-* the **incoming message** that triggered the contract
-* the **state changes** performed by the contract during message processing (e.g. storage or balance updates)
-* any **outgoing messages** sent to other contracts (if applicable)
+- the **incoming message** that triggered the contract
+- the **state changes** performed by the contract during message processing (e.g. storage or balance updates)
+- any **outgoing messages** sent to other contracts (if applicable)
:::caution
+
Unlike in the [Reading from network](/v3/guidelines/quick-start/blockchain-interaction/reading-from-network) section, a Toncenter API key is mandatory in the following examples. It may be retrieved using [the following guide](/v3/guidelines/dapps/apis-sdks/api-keys).
+
:::
#### Implementation
@@ -120,7 +122,9 @@ main();
Using `API_KEY` in this case, allows you to access TON functionality through the `endpoint`. By running this script, we authenticate to our wallet through a `public/private key` pair generated from the `mnemonic phrase`. After preparing a transaction, we send it to TON, resulting in a message that the wallet sends to itself with the *'Hello from wallet!'* message.
:::caution Advanced Level
+
In most scenarios, `SendMode.PAY_GAS_SEPARATELY | SendMode.IGNORE_ERRORS` will work, but if you want a deeper understanding, continue reading in the [message modes cookbook](/v3/documentation/smart-contracts/message-management/message-modes-cookbook/).
+
:::
@@ -204,7 +208,9 @@ main();
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
Run this example using the following command:
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview.mdx
index cab8e751179..59446bbc060 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/blueprint-sdk-overview.mdx
@@ -12,7 +12,9 @@ Before we proceed to actual smart contract development, let's briefly describe t
## Project structure
:::warning
+
If you didn't choose the proposed names in the previous steps, source code file names and some of the in-code entities may differ.
+
:::
@@ -94,7 +96,9 @@ npx blueprint run
```
:::tip
+
All examples in this guide follow the sequence of these **1-3 steps** with corresponding code samples. **Step 5**, the deployment process, is covered in the last section of the guide: [Deploying to network](/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network/).
+
:::
Also, you can always generate the same structure for another smart contract if, for example, you want to create multiple contracts interacting with each other by using the following command:
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network.mdx
index eacc5a83ab0..508bcdac4dd 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/deploying-to-network.mdx
@@ -45,7 +45,9 @@ init(id: Int, owner: Address) {
If we remove the `id` field from its initial storage, we can ensure that **only one** `CounterInternal` smart contract can exist for a particular owner.
:::info Tokens
+
This mechanism plays a crucial role in [Jetton Processing](/v3/guidelines/dapps/asset-processing/jettons/). Each non-native (jetton) token requires its own `Jetton Wallet` for a particular owner and, therefore, provides a calculable address for it, creating a **star scheme** with the basic wallet in the center.
+
:::
*/}
## Implementation
@@ -102,7 +104,9 @@ After that, you will see an interactive menu allowing you to choose a network:
```
:::danger
+
Before deployment to the `Mainnet`, ensure that your smart contracts correspond to [Security measures](/v3/guidelines/smart-contracts/security/overview/). As we said before, the `HelloWorld` smart contract **doesn't**.
+
:::
### Step 4: choose wallet app
@@ -138,7 +142,9 @@ You can view it at https://testnet.tonscan.org/address/EQBrFHgzSwxVYBXjIYAM6g2RH
:::tip
+
Using `Blueprint` and wallet apps is not the only option. You can create a message with [state_init](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout) by yourself. Moreover, you can do it even through a smart contract's [internal message](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout).
+
:::
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/processing-messages.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/processing-messages.mdx
index 894a0238790..a07c5aa3528 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/processing-messages.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/processing-messages.mdx
@@ -10,7 +10,9 @@ import Button from '@site/src/components/button'
Now, we are ready to move on to the main functionality of smart contracts — **sending and receiving messages**. In TON, messages are used not only for sending currency but also as a data-exchange mechanism between smart contracts, making them crucial for smart contract development.
:::tip
+
If you are stuck on some of the examples, you can find the original template project with all modifications performed during this guide [here](https://github.com/ton-community/onboarding-sandbox/tree/main/quick-start/smart-contracts/Example/contracts).
+
:::
---
@@ -50,7 +52,9 @@ fun onInternalMessage(myBalance: int, msgValue: int, msgFull: cell, msgBody: sli
:::info
+
You can find a comprehensive description of sending messages in this [section](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout).
+
:::
What we are specifically interested in is the source address of the message, which we can extract from the `msg_full` cell. By obtaining that address and comparing it to a stored one — we can conditionally allow access to crucial parts of our smart contract functionality. A common approach looks like this:
@@ -186,7 +190,9 @@ By combining both of these patterns, you can achieve a comprehensive description
Developing external endpoints includes several standard [approaches](/v3/documentation/smart-contracts/message-management/external-messages) and [security measures](/v3/guidelines/smart-contracts/security/overview) that might be overwhelming at this point. Therefore, in this guide, we will implement incrementing the previously added `ctx_counter_ext` number.
:::danger
+
This implementation is **unsafe** and may lead to losing your contract funds. Don't deploy it to `Mainnet`, especially with a high smart contract balance.
+
:::
## Implementation
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/storage-and-get-methods.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/storage-and-get-methods.mdx
index b48cb40fe58..4d5581cbd48 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/storage-and-get-methods.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/func-tolk-folder/storage-and-get-methods.mdx
@@ -8,7 +8,9 @@ import Button from '@site/src/components/button'
> **Summary:** In the previous steps, we learned how to use the `Blueprint` and its project structure.
:::tip
+
If you're stuck on any of the examples, you can find the original template project with all modifications made during this guide [here](https://github.com/ton-community/onboarding-sandbox/tree/main/quick-start/smart-contracts/Example/contracts).
+
:::
Almost all smart contracts need to store their `data` between transactions. This guide explains standard ways to manage `storage` for smart contracts and how to use `get methods` to access it outside the blockchain.
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/setup-environment.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/setup-environment.mdx
index 51c6c774f93..e4df9dd0699 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/setup-environment.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/setup-environment.mdx
@@ -17,9 +17,11 @@ This guide covers the basic steps of setting up your smart contract development
For this guide, we will rely on the [Blueprint](https://github.com/ton-org/blueprint/) and [Node.js](https://nodejs.org/en)/TypeScript stack for writing wrappers, tests, and deployment scripts for your smart contract, as it provides the easiest, ready-to-use environment for smart contract development.
:::info
+
Using native tools and language-dependent SDKs for smart contract development is covered in more advanced sections here:
- [Compile and build smart contracts on TON](/v3/documentation/archive/compile#ton-compiler).
- [Creating state init for deployment](/v3/guidelines/smart-contracts/howto/wallet#creating-the-state-init-for-deployment).
+
:::
### Step 1: install Node.js
@@ -38,7 +40,9 @@ node -v
During the guide, we provide examples in `FunC`, `Tolk`, and `Tact`. You can choose any of them and even combine smart contracts in different languages. To proceed through the guide, there is no need for a deep understanding of the chosen language—basic programming skills will be enough.
:::info
+
You can find a brief overview of the languages here: [Programming languages](/v3/documentation/smart-contracts/overview#programming-languages).
+
:::
### Step 3: set up Blueprint
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-blueprint-sdk-overview.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-blueprint-sdk-overview.mdx
index 65edd3a207d..92342956275 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-blueprint-sdk-overview.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-blueprint-sdk-overview.mdx
@@ -8,7 +8,9 @@ import Button from '@site/src/components/button'
> **Summary:** In the previous steps, we installed and configured all the tools required for TON smart contract development and created our first project template.
:::info
+
We recommend installing the [Tact extension for VS Code](https://marketplace.visualstudio.com/items?itemName=tonstudio.vscode-tact). It offers syntax highlighting, error hints, and a smoother development experience.
+
:::
Before we proceed to actual smart contract development, let's briefly describe the project structure and explain how to use the **`Blueprint`**.
@@ -16,7 +18,9 @@ Before we proceed to actual smart contract development, let's briefly describe t
## Project structure
:::warning
+
If you didn't choose the proposed names in the previous steps, source code file names and some of the in-code entities may differ.
+
:::
@@ -82,7 +86,9 @@ npx blueprint run
```
:::tip
+
All examples in this guide follow the sequence of these **1-3 steps** with corresponding code samples. **Step 5**, the deployment process, is covered in the last section of the guide: [Deploying to network](/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-deploying-to-network/).
+
:::
Also, you can always generate the same structure for another smart contract if, for example, you want to create multiple contracts interacting with each other by using the following command:
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-deploying-to-network.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-deploying-to-network.mdx
index 236bd4dee24..d33fc5e38f9 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-deploying-to-network.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-deploying-to-network.mdx
@@ -45,7 +45,9 @@ init(id: Int, owner: Address) {
If we remove the `id` field from its initial storage, we can ensure that **only one** `HelloWorld` smart contract can exist for a particular owner.
:::info Tokens
+
This mechanism plays a crucial role in [Jetton processing](/v3/guidelines/dapps/asset-processing/jettons). Each non-native (jetton) token requires its own `Jetton Wallet` for a particular owner and, therefore, provides a calculable address for it, creating a **star scheme** with the basic wallet in the center.
+
:::
## Implementation
@@ -104,7 +106,9 @@ After that, you will see an interactive menu allowing you to choose a network:
```
:::danger
+
Before deployment to the `Mainnet`, ensure that your smart contracts correspond to [Security measures](/v3/guidelines/smart-contracts/security/overview). As we said before, the `HelloWorld` smart contract **doesn't**.
+
:::
### Step 4: choose wallet app
@@ -139,7 +143,9 @@ You can view it at https://testnet.tonscan.org/address/EQBrFHgzSwxVYBXjIYAM6g2RH
**Congratulations!** Your custom `smart contract` is ready to execute `get methods` the same way as your wallet in the [Getting started](/v3/guidelines/quick-start/getting-started#navigation-tabs) section and execute `transactions` the same as in the [Blockchain interaction](/v3/guidelines/quick-start/blockchain-interaction/reading-from-network) section — consider reading it to understand how to interact with `smart contracts` off-chain if you haven't already.
:::tip
+
Using `Blueprint` and wallet apps is not the only option. You can create a message with [state_init](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout) by yourself. Moreover, you can do it even through a smart contract's [internal message](/v3/documentation/smart-contracts/message-management/sending-messages#message-layout).
+
:::
diff --git a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-storage-and-get-methods.mdx b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-storage-and-get-methods.mdx
index 7b45451260f..f7d10ca2e7a 100644
--- a/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-storage-and-get-methods.mdx
+++ b/docs/v3/guidelines/quick-start/developing-smart-contracts/tact-folder/tact-storage-and-get-methods.mdx
@@ -8,7 +8,9 @@ import Button from '@site/src/components/button'
> **Summary:** In the previous steps, we learned how to use the `Blueprint SDK` and its project structure.
:::info
+
For more details, refer to the [Tact documentation](https://docs.tact-lang.org/#start/) and [Tact By Example](https://tact-by-example.org/00-hello-world/).
+
:::
@@ -120,7 +122,9 @@ receive() {
Tact supports [getter functions](https://docs.tact-lang.org/book/functions/#getter-functions) for retrieving contract state off-chain:
:::note
+
Get function cannot be called from another contract.
+
:::
```tact title="/contracts/hello_world.tact"
diff --git a/docs/v3/guidelines/quick-start/getting-started.mdx b/docs/v3/guidelines/quick-start/getting-started.mdx
index 8fbbbc3bc0a..956cc1cb406 100644
--- a/docs/v3/guidelines/quick-start/getting-started.mdx
+++ b/docs/v3/guidelines/quick-start/getting-started.mdx
@@ -13,7 +13,9 @@ Welcome to the TON Quick Start guide! This guide will give you a starting point
- Around __30 minutes__ of your time.
:::note
+
We will provide a short explanation of core concepts during the guide, but if you prefer a more theoretical approach, you can check out the core concepts of [TON Blockchain](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains) first.
+
:::
## What you'll learn
@@ -36,7 +38,9 @@ Each successfully processed message results in a **transaction**, which may incl
- changing its balance
:::info
+
In contrast to other blockchains, where you can call other contract code synchronously, a smart contract in TON is a standalone entity that communicates equally with other smart contracts. Smart contracts interact by sending messages to each other, and the processing of these messages happens asynchronously due to the asynchronous nature of transactions in TON.
+
:::
The available interfaces of a smart contract are:
@@ -47,7 +51,9 @@ The available interfaces of a smart contract are:
Unlike internal or external messages, **get methods** do not result in transactions. They are special functions of the smart contract that cannot change the contract's internal state or perform any other action except querying specific data from the contract's state.
:::info
+
Contrary to what might seem intuitive, invoking `get methods` from other contracts **is not possible**.
+
:::
## Interacting with the TON ecosystem
@@ -73,7 +79,9 @@ TON basic transactions are very cheap—about 1 cent per transaction. Getting th
- For **Mainnet**, you can get Toncoin by simply pressing the buy button in the user interface or asking someone to send them to your **address**. You can copy the address from the wallet app, which is usually located near your balance.
:::info
+
Don't worry, sharing your address is **totally safe**, unless you don't want it to be associated with you.
+
:::
- For the **Testnet** version, you can request funds from the [Testgiver Ton Bot](https://t.me/testgiver_ton_bot/) **completely for free**! After a short wait, you will receive 2 Toncoin that will appear in your wallet app.
@@ -114,7 +122,9 @@ Congratulations! We’ve created our first wallet and received some funds in it.
An **explorer** is a tool that allows you to query data from the chain, investigate TON **smart contracts**, and view transactions. For our examples, we are going to use [Tonviewer](https://tonviewer.com/).
:::tip
+
Note that when using the **Testnet**, you should manually change the explorer mode to the **Testnet** version. Don't forget that these are different networks that do not share any transactions or smart contracts. Therefore, your **Testnet** wallet will not be visible in **Mainnet** mode and vice versa.
+
:::
Let's take a look at our newly created wallet using the `explorer`: copy your wallet address from the app and insert it into the search bar of the explorer like this:
@@ -140,10 +150,12 @@ First, let's examine the common [address state](/v3/documentation/smart-contract
:::info
+
This might seem unintuitive: why is your wallet in the `uninit` state when you’ve already created it? There is a small difference between the `wallet app` and the `wallet smart contract`:
- The `wallet app` is your off-chain client for the `wallet smart contract`.
- The `wallet smart contract` is the contract itself. Since its deployment requires some fees, most `wallet apps` don’t actually deploy the wallet `smart contract` until you receive funds to your address and try to make your first transaction.
+
:::
- `Active`: the state of a _deployed_ smart contract that contains code, data, and balance.
@@ -155,7 +167,9 @@ To deploy our wallet, let's send the first transaction to someone special—**ou
:::info
+
There is also a fourth state called [frozen](/v3/documentation/smart-contracts/addresses/address-states), which stands for a smart contract with a [storage charge](/v3/documentation/smart-contracts/transaction-fees/fees-low-level#storage-fee) that exceeds its balance. In this state, the smart contract cannot perform any operations.
+
:::
And here we are — our wallet contract is deployed and ready to use. Let's examine the provided user interface:
diff --git a/docs/v3/guidelines/smart-contracts/fee-calculation.mdx b/docs/v3/guidelines/smart-contracts/fee-calculation.mdx
index f6d22c0a594..69955da8fe4 100644
--- a/docs/v3/guidelines/smart-contracts/fee-calculation.mdx
+++ b/docs/v3/guidelines/smart-contracts/fee-calculation.mdx
@@ -9,7 +9,9 @@ When your contract begins processing an incoming message, you should verify the
This document explains how to calculate fees in FunC contracts using the latest TVM opcodes.
:::info opcodes
+
For a comprehensive list of TVM opcodes, including those mentioned below, refer to the [TVM instruction page](/v3/documentation/tvm/instructions).
+
:::
## Storage fee
@@ -27,7 +29,9 @@ Use the `GETSTORAGEFEE` opcode with the following parameters:
| is_mc | True if the source or destination is in the MasterChain |
:::info
-The system counts only unique hash cells for storage and forward fees. For example, it counts three identical hash cells as one. This mechanism deduplicates data by storing the content of multiple equivalent sub-cells only once, even if they are referenced across different branches. [Read more about deduplication](/v3/documentation/data-formats/tlb/library-cells).
+
+The system counts only unique hash cells for storage and forward fees. For example, it counts three identical hash cells as one. This mechanism deduplicates data by storing the content of multiple equivalent sub-cells only once, even if they are referenced across different branches. [Read more about deduplication](/v3/documentation/data-formats/tlb/library-cells).
+
:::
### Calculation flow
@@ -189,7 +193,9 @@ If the message structure is deterministic, use the `GETFORWARDFEE` opcode with t
| is_mc | True if the source or destination is in the MasterChain |
:::info
-The system counts only unique hash cells for storage and forward fees. For example, it counts three identical hash cells as one. This mechanism deduplicates data by storing the content of multiple equivalent sub-cells only once, even if they are referenced across different branches. [Read more about deduplication](/v3/documentation/data-formats/tlb/library-cells).
+
+The system counts only unique hash cells for storage and forward fees. For example, it counts three identical hash cells as one. This mechanism deduplicates data by storing the content of multiple equivalent sub-cells only once, even if they are referenced across different branches. [Read more about deduplication](/v3/documentation/data-formats/tlb/library-cells).
+
:::
However, if the outgoing message depends significantly on the incoming structure, you may not be able to fully predict the fee. In such cases, try using the `GETORIGINALFWDFEE` opcode with the following parameters:
@@ -200,7 +206,9 @@ However, if the outgoing message depends significantly on the incoming structure
| is_mc | True if the source or destination is in the MasterChain |
:::caution
+
Be careful with the `SENDMSG` opcode, as it uses an **unpredictable amount** of gas. Avoid using it unless necessary.
+
:::
The `SENDMSG` opcode is the least optimal way to calculate fees, but it is better than not checking.
diff --git a/docs/v3/guidelines/smart-contracts/get-methods.mdx b/docs/v3/guidelines/smart-contracts/get-methods.mdx
index 52fafeda151..5ad353236ba 100644
--- a/docs/v3/guidelines/smart-contracts/get-methods.mdx
+++ b/docs/v3/guidelines/smart-contracts/get-methods.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# Get methods
:::note
+
To fully benefit from this content, readers must understand the [FunC programming language](/v3/documentation/smart-contracts/func/overview/) on the TON Blockchain. This knowledge is crucial for grasping the information presented here.
+
:::
## Introduction
diff --git a/docs/v3/guidelines/smart-contracts/howto/airdrop-claim-best-practice.mdx b/docs/v3/guidelines/smart-contracts/howto/airdrop-claim-best-practice.mdx
index 7902513b9eb..759b670a2d1 100644
--- a/docs/v3/guidelines/smart-contracts/howto/airdrop-claim-best-practice.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/airdrop-claim-best-practice.mdx
@@ -7,7 +7,9 @@ In this article, we'll explore an imaginary claim solution, identify its perform
## Claim machine
:::info
+
How does a typical claim solution work? Let's break it down.
+
:::
The user submits some form of proof to demonstrate eligibility for the claim. The solution verifies the proof and sends jettons to the user. In this case, `proof` refers to a [merkle proof](/v3/documentation/data-formats/tlb/exotic-cells#merkle-proof), but it could also be signed data or any other authorization method. To send jettons, we'll need a jetton wallet and minter. Additionally, we must prevent users from claiming twice—this requires a double-spend protection contract. And, of course, we'd like to monetize this, right? So, we'll need at least one claim wallet. Let's summarize:
diff --git a/docs/v3/guidelines/smart-contracts/howto/compile/compilation-instructions.mdx b/docs/v3/guidelines/smart-contracts/howto/compile/compilation-instructions.mdx
index 546b21cc174..050553a54d3 100644
--- a/docs/v3/guidelines/smart-contracts/howto/compile/compilation-instructions.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/compile/compilation-instructions.mdx
@@ -7,9 +7,11 @@ You can download prebuilt binaries [here](/v3/documentation/archive/precompiled-
If you still want to compile sources yourself, follow the instructions below.
:::caution
+
This is a simplified quick build guide.
If you are building for production and not for home use, it's better to use [autobuild scripts](https://github.com/ton-blockchain/ton/tree/master/.github/workflows).
+
:::
## Common
@@ -113,7 +115,9 @@ cmake -GNinja -DCMAKE_BUILD_TYPE=Release .. \
:::tip
+
If you are compiling on a computer with low memory (e.g., 1 Gb), don't forget to [create a swap partitions](/v3/guidelines/smart-contracts/howto/compile/instructions-low-memory).
+
:::
## Download global config
diff --git a/docs/v3/guidelines/smart-contracts/howto/compile/instructions-low-memory.mdx b/docs/v3/guidelines/smart-contracts/howto/compile/instructions-low-memory.mdx
index 0993f75e97c..359ca0ba22d 100644
--- a/docs/v3/guidelines/smart-contracts/howto/compile/instructions-low-memory.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/compile/instructions-low-memory.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# Compile TON on low-memory machines
:::caution
+
This section provides low-level instructions for working with TON.
+
:::
To compile TON on systems with limited memory (< 1 GB), you need to create swap partitions.
diff --git a/docs/v3/guidelines/smart-contracts/howto/multisig-js.mdx b/docs/v3/guidelines/smart-contracts/howto/multisig-js.mdx
index 361f87b4387..d8f4bfebc78 100644
--- a/docs/v3/guidelines/smart-contracts/howto/multisig-js.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/multisig-js.mdx
@@ -6,9 +6,11 @@ import Feedback from '@site/src/components/Feedback';
# Interact with multisig wallets using TypeScript
:::warning
-This page is heavily outdated and will be updated soon.
+
+This page is heavily outdated and will be updated soon.
Refer to the [multisig-contract-v2](https://github.com/ton-blockchain/multisig-contract-v2), the most up-to-date multisignature contract on TON.
Use npm and avoid updating this guide.
+
:::
## Introduction
diff --git a/docs/v3/guidelines/smart-contracts/howto/multisig.mdx b/docs/v3/guidelines/smart-contracts/howto/multisig.mdx
index eeae9ec7c28..c5ce8e0f62d 100644
--- a/docs/v3/guidelines/smart-contracts/howto/multisig.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/multisig.mdx
@@ -7,7 +7,9 @@ import Feedback from '@site/src/components/Feedback';
# Make a simple multisig contract with fift
:::caution advanced level
+
This information is **very low-level**. It could be hard for newcomers and designed for advanced people who want to understand [fift](/v3/documentation/smart-contracts/fift/overview). The use of fift is not required in everyday tasks.
+
:::
## 💡 Overview
@@ -21,7 +23,9 @@ Based on the original multisig contract code and updates by akifoq:
- [akifoq/multisig](https://github.com/akifoq/multisig) with fift libraries to work with multisig.
:::tip starter tip
+
For anyone new to multisig: [What is Multisig Technology? (video)](https://www.youtube.com/watch?v=yeLqe_gg2u0)
+
:::
## 📖 What you'll learn
@@ -112,7 +116,9 @@ fift -s new-multisig.fif 0 $WALLET_ID$ wallet $KEYS_COUNT$ ./keys.txt
- `$KEYS_COUNT$` - the number of keys needed for confirmation, usually equal to the number of public keys.
:::info wallet_id explained
+
It is possible to create many wallets with the same keys (Alice key, Bob key). What should we do if Alice and Bob already have a treasure? That's why `$WALLET_ID$` is crucial here.
+
:::
The script will output something like:
@@ -130,11 +136,15 @@ Bounceable address (for later access): kQBLuyZgCX21xy3V6QhhFQEPD4yFAeC4_vH-MY2d5
```
:::info
+
If you have a "public key must be 48 characters long" error, please make sure your `keys.txt` has a Unix-type word wrap - LF. For example, word wrap can be changed via the Sublime text editor.
+
:::
:::tip
+
A bounceable address is better to keep - this is the wallet's address.
+
:::
#### Activate your contract
@@ -148,7 +158,9 @@ lite-client -C global.config.json
```
:::info Where to get `global.config.json`?
+
You can get a fresh config file `global.config.json` for [mainnet](https://ton.org/global-config.json) or [testnet](https://ton.org/testnet-global.config.json).
+
:::
After starting lite-client, it's best to run the `time` command in the lite-client console to make sure the connection was successful:
@@ -188,7 +200,9 @@ fift -s create-msg.fif EQApAj3rEnJJSxEjEHVKrH3QZgto_MQMOmk8l72azaXlY1zB 0.1 mess
```
:::tip
+
Use the `-C comment` attribute to add a comment for your transaction. To get more information, run the _create-msg.fif_ file without parameters.
+
:::
#### Choose a wallet
@@ -206,7 +220,9 @@ Where
- `$MESSAGE$` — here is the name of the message boc-file created in the previous step.
:::info
+
The request expires if the time equals `$AWAIT_TIME$` passed before the request signs. As usual, `$AWAIT_TIME$` equals a couple of hours (7200 seconds).
+
:::
For example:
@@ -218,7 +234,9 @@ fift -s create-order.fif 0 message -t 7200
The ready file will be saved in `order.boc`.
:::info
+
`order.boc` must be shared with key holders; they must sign it.
+
:::
#### Sign your part
diff --git a/docs/v3/guidelines/smart-contracts/howto/nominator-pool.mdx b/docs/v3/guidelines/smart-contracts/howto/nominator-pool.mdx
index ffb944a2a67..bb8dcd20d48 100644
--- a/docs/v3/guidelines/smart-contracts/howto/nominator-pool.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/nominator-pool.mdx
@@ -3,7 +3,9 @@ import Feedback from '@site/src/components/Feedback';
# How to use the nominator pool
:::tip
+
Before reading this tutorial, you should familiarize yourself with [nominator pool specification](/v3/documentation/smart-contracts/contracts-specs/nominator-pool).
+
:::
## Running the validator in nominator pool mode \{#validator-pool-mode}
diff --git a/docs/v3/guidelines/smart-contracts/howto/single-nominator-pool.mdx b/docs/v3/guidelines/smart-contracts/howto/single-nominator-pool.mdx
index f3b70dcfb3c..10f2965658d 100644
--- a/docs/v3/guidelines/smart-contracts/howto/single-nominator-pool.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/single-nominator-pool.mdx
@@ -6,13 +6,17 @@ import TabItem from '@theme/TabItem';
# How to use a single nominator pool
:::tip
+
Before proceeding with this tutorial, we recommend familiarizing yourself with the [single nominator pool specification](/v3/documentation/smart-contracts/contracts-specs/single-nominator-pool).
+
:::
### Set up single nominator mode
:::caution
+
Before starting, ensure you have topped up and [activated](/v3/guidelines/nodes/running-nodes/validator-node#activate-the-wallets) the validator's wallet.
+
:::
1. Enable single nominator mode:
@@ -66,7 +70,9 @@ test-pool active 0.99389 spool_r2 kf_JcC5pn3etTAdwOnc16_tyMmKE8-ftNUnf0OnUjA
You can manage this pool via MyTonCtrl like a standard nominator pool.
:::info
+
If the pool's balance is sufficient to participate in both rounds (`balance > min_stake_amount * 2`), MyTonCtrl will automatically participate in both rounds using `stake = balance / 2`, unless you manually set the stake using the `set stake` command. This behavior differs from using a nominator pool but resembles staking with a validator wallet.
+
:::
## Start without MyTonCtrl
@@ -421,7 +427,9 @@ Initially, the owner of the vesting contract manages it with their wallet contra
- `owner_wallet` – The TON wallet that owns the `vesting`.
:::caution
+
Ensure you have backed up the vesting `owner_wallet` recovery phrase. If you lose access to the `owner_wallet`, you will also lose access to managing the `vesting` funds, and recovery will be impossible.
+
:::
1. Run a full node and wait for it to sync.
diff --git a/docs/v3/guidelines/smart-contracts/howto/wallet.mdx b/docs/v3/guidelines/smart-contracts/howto/wallet.mdx
index 74367a3989c..e58478367c6 100644
--- a/docs/v3/guidelines/smart-contracts/howto/wallet.mdx
+++ b/docs/v3/guidelines/smart-contracts/howto/wallet.mdx
@@ -13,7 +13,9 @@ import TabItem from '@theme/TabItem';
Learning how wallets and transactions work on TON before beginning smart contracts development is essential. This knowledge will help developers understand the interaction between wallets, messages, and smart contracts to implement specific development tasks.
:::tip
+
Before starting this tutorial, we recommend reviewing the [Wallet contracts](/v3/documentation/smart-contracts/contracts-specs/wallet-contracts) article.
+
:::
This section will teach us to create operations without using pre-configured functions to understand development workflows. The references chapter contains all the necessary references for analyzing this tutorial.
@@ -23,7 +25,9 @@ This section will teach us to create operations without using pre-configured fun
This tutorial requires basic knowledge of JavaScript and TypeScript or Golang. It is also necessary to hold at least 3 TON (which can be stored in an exchange account, a non-custodial wallet, or the Telegram bot wallet). It is necessary to have a basic understanding of [cell](/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage), [addresses in TON](/v3/documentation/smart-contracts/addresses/address), [blockchain of blockchains](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains) to understand this tutorial.
:::info MAINNET DEVELOPMENT IS ESSENTIAL
+
Working with the TON Testnet often leads to deployment errors, difficulty tracking transactions, and unstable network functionality. Completing most of the development on the TON Mainnet could help avoid potential issues. This may reduce the number of transactions and minimize fees.
+
:::
## 💿 Source code
@@ -71,8 +75,10 @@ npx tsc --init --rootDir src --outDir build \ --esModuleInterop --target es2020
```
:::info
+
To help us carry out the following process, a `ts-node` executes TypeScript code directly without precompiling. `nodemon` restarts the node application automatically when file changes in the directory are detected.
-:::
+
+:::
4. Next, remove these lines from `tsconfig.json`:
@@ -122,7 +128,9 @@ npm run start:dev

:::tip Blueprint
+
The TON Community created an excellent tool for automating all development processes (deployment, contract writing, testing) called [Blueprint](https://github.com/ton-org/blueprint). However, we will not need such a powerful tool, so the instructions above should be followed.
+
:::
**OPTIONAL:** When using Golang, follow these instructions:
@@ -160,13 +168,17 @@ func main() {
6. Run the code above until the output in the terminal is displayed.
:::info
+
It is also possible to use another IDE since GoLand isn’t free, but it is preferred.
+
:::
:::warning IMPORTANT
+
Add all coding components to the `main` function created in the [⚙ Set your environment](/v3/guidelines/smart-contracts/howto/wallet#-set-your-environment) section.
Only the imports required for that specific code section are specified in each new section. Combine new imports with the existing ones as needed.
+
:::
## 🚀 Let's get started!
@@ -176,9 +188,11 @@ In this tutorial, we’ll learn which wallets (versions 3 and 4) are most often
Our main task is to build messages using various objects and functions for @ton/ton, @ton/core, and @ton/crypto (ExternalMessage, InternalMessage, Signing, etc.) to understand what messages look like on a bigger scale. To carry out this process, we'll use two main wallet versions (v3 and v4) because exchanges, non-custodial wallets, and most users only use these specific versions.
:::note
+
This tutorial may not explain particular details on occasion. In these cases, more details will be provided later.
**IMPORTANT:** Throughout this tutorial, the [wallet v3 code](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet3-code.fc) is used to understand the wallet development process better. Version v3 has two sub-versions: r1 and r2. Currently, only the second version is being used, which means that when we refer to v3 in this document, it implies v3r2.
+
:::
## 💎 TON Blockchain wallets
@@ -246,7 +260,9 @@ throw_unless(33, msg_seqno == stored_seqno);
The code above compares the `seqno` from the incoming message with the `seqno` stored in the smart contract. If the values do not match, the contract returns an error with the `33 exit code`. This ensures that if the sender provides an invalid `seqno`, indicating a mistake in the message sequence, the contract prevents further processing and safeguards against such errors.
:::note
+
It's also essential to consider that anyone can send external messages. If you send 1 TON to someone, someone else can repeat this message. However, when the seqno increases, the previous external message becomes invalid, and no one will be able to repeat it, thus preventing the possibility of stealing your funds.
+
:::
### Signature
@@ -269,7 +285,9 @@ accept_message();
```
:::info accept_message()
+
Since external messages do not include the Toncoin required to pay transaction fees, the `accept_message()` function applies a `gas_credit` (currently valued at 10,000 gas units). This allows the contract to perform necessary calculations for free, provided the gas usage does not exceed the `gas_credit` limit. After invoking `accept_message()`, the smart contract deducts all gas costs (in TON) from its balance. You can read more about this process [here](/v3/documentation/smart-contracts/transaction-fees/accept-message-effects).
+
:::
### Transaction expiration
@@ -302,7 +320,9 @@ while (cs.slice_refs()) {
```
:::tip touch()
+
On TON, all smart contracts run on the stack-based TON Virtual Machine (TVM). ~ touch() places the variable `cs` on top of the stack to optimize code running for less gas.
+
:::
Since a single cell can store **a maximum of 4 references**, we can send up to 4 internal messages per external message.
@@ -329,7 +349,9 @@ To simplify this process, we’ll use a pre-built wallet. Here’s how to procee
This way, the Tonkeeper wallet app will deploy the wallet contract, which we can use for the following steps.
:::note
+
At the time of writing, most wallet apps on TON default to wallet v4. However, since plugins are not required for this tutorial, we’ll use the functionality provided by wallet v3. Tonkeeper allows users to select their preferred wallet version, so it’s recommended to deploy wallet v3.
+
:::
### TL-B
@@ -339,7 +361,9 @@ As mentioned earlier, everything in the TON Blockchain is a smart contract compo
This section will explore [block.tlb](https://github.com/ton-blockchain/ton/blob/master/crypto/block/block.tlb). This file will be invaluable for future development as it outlines how to assemble different types of cells. Specifically for our purposes, it provides detailed information about the structure and behavior of internal and external messages.
:::info
+
This guide provides basic information. For further details, please refer to our TL-B [documentation](/v3/documentation/data-formats/tlb/tl-b-language) to learn more about TL-B.
+
:::
### CommonMsgInfo
@@ -353,7 +377,9 @@ When examining [TL-B](https://github.com/ton-blockchain/ton/blob/24dc184a2ea67f9
However, the `CommonMsgInfo` structure only supports the `MsgAddress` specification. Since the sender’s address is typically unknown, it’s necessary to use `addr_none` (represented by two zero bits `00`). The `CommonMsgInfoRelaxed` structure is used in such cases, as it supports the `addr_none` address. For `ext_in_msg_info` (used for incoming external messages), the `CommonMsgInfo` structure is sufficient because these messages don’t require a sender and always use the [MsgAddressExt](https://hub.com/ton/ton.blockchain/ton/blob/24dc184a2ea67f9c47042b4104bbb4d82289fac1/crypto/block/block.tlb#L100) structure (represented by `addr_none$00`, meaning two zero bits). This eliminates the need to overwrite the data.
:::note
+
The numbers after the `$` symbol are the bits that must be stored at the beginning of a specific structure for further identification of these structures during reading (deserialization).
+
:::
### Internal message creation
@@ -431,7 +457,9 @@ Finally, let’s look at the remaining lines of code:
Validators rewrite the above values (including src), excluding the State Init and the Message Body bits.
:::note
+
If the number value fits within fewer bits than is specified, then the missing zeros are added to the left side of the value. For example, 0x18 fits within 5 bits -> `11000`. However, since 6 bits were specified, the result becomes `011000`.
+
:::
Next, we’ll prepare a message to send Toncoins to another wallet v3. For example, let’s say a user wants to send 0.5 TON to themselves with the comment "**Hello, TON!**". To learn how to send a message with a comment, refer to this documentation section: [How to send a simple message](/v3/documentation/smart-contracts/func/cookbook#how-to-send-a-simple-message).
@@ -655,7 +683,9 @@ body := cell.BeginCell().
Note that no `.endCell()` was used in defining the `toSign` here. In this case, it is necessary **to transfer toSign content directly to the message body**. If writing a cell was required, it would have to be stored as a reference.
:::tip Wallet V4
+
In addition to the basic verification process we learned above for the Wallet V3, Wallet V4 smart contracts [extract the opcode to determine whether a simple translation or a message associated with the plugin](https://github.com/ton-blockchain/wallet-contract/blob/4111fd9e3313ec17d99ca9b5b1656445b5b49d8f/func/wallet-v4-code.fc#L94-L100) is required. To match this version, it is necessary to add the `storeUint(0, 8).` (JS/TS), `MustStoreUInt(0, 8).` (Golang) functions after writing the **sequence number (seqno)** and before specifying the transaction mode.
+
:::
### External message creation
@@ -703,7 +733,9 @@ externalMessage := cell.BeginCell().
| Message Body | The message must be sent to the contract for processing. |
:::tip 0b10
+
0b10 (b - binary) denotes a binary record. Two bits are stored in this process: `1` and `0`. Thus, we specify that it's `ext_in_msg_info$10`.
+
:::
Now that we have a completed message ready to send to our contract, the next step is to serialize it into a `BoC` ([bag of cells](/v3/documentation/data-formats/tlb/cell-boc#bag-of-cells)). Once serialized, we can send it using the following code:
@@ -805,7 +837,9 @@ log.Println(mnemonic) // if we want, we can print our mnemonic
The private key is needed to sign messages, and the public key is stored in the wallet’s smart contract.
:::danger IMPORTANT
+
Make sure to output the generated mnemonic seed phrase to the console, save it, and use it (as detailed in the previous section) to ensure the same key pair is used each time the wallet’s code is run.
+
:::
### Subwallet IDs
@@ -878,7 +912,9 @@ Now, we have the following structure for the project we are creating:
```
:::info
+
It’s OK if your IDE plugin conflicts with the `() set_seed(int) impure asm "SETRAND";` in the `stdlib.fc` file.
+
:::
Remember to add the following line to the beginning of the `wallet_v3.fc` file to indicate that the functions from the stdlib will be used below:
@@ -1048,7 +1084,9 @@ log.Println("Contract address:", contractAddress.String()) // Output contract ad
We can build and send the message to the blockchain using the State Init.
:::warning
+
Keep in mind this concept for your services
+
:::
To carry out this process, **a minimum wallet balance of 0.1 TON** is required (the balance can be less, but this amount is guaranteed sufficient). To accomplish this, we’ll need to run the code mentioned earlier in the tutorial, obtain the correct wallet address, and send 0.1 TON to this address. Alternatively, you can send this sum manually via your wallet app before sending the deployment message.
@@ -1225,7 +1263,9 @@ Note that we sent an internal message using mode `3`. If you must redeploy the s
Remember that for each new transaction, the `seqno` must be incremented by one.
:::info
+
The contract code we used is [verified](https://tonscan.org/tx/BL9T1i5DjX1JRLUn4z9JOgOWRKWQ80pSNevis26hGvc=), so you can see an example [here](https://tonscan.org/address/EQDBjzo_iQCZh3bZSxFnK9ue4hLTOKgsCNKfC8LOUM4SlSCX#source).
+
:::
## 💸 Working with wallet smart contracts
@@ -1560,7 +1600,9 @@ if err != nil {
:::info Connection error
+
If an error related to the lite-server connection (in Golang) occurs, you may need to run the code repeatedly until the message is successfully sent. This happens because the `tonutils-go` library uses multiple lite-servers from the global configuration specified in the code. However, not all lite-servers may accept the connection.
+
:::
After completing this process, you can use a TON blockchain explorer to verify that the wallet sent four messages to the specified addresses.
@@ -2004,7 +2046,9 @@ internalMessage := cell.BeginCell().
:::info
+
Note that the bits have been specified above and that the stateInit and internalMessageBody have been saved as references.
+
:::
Since the links are stored separately, we could write:
@@ -2157,7 +2201,9 @@ You’ll need a specialized wallet called a **High-Load Wallet** to handle many
[With the introduction of High-Load Wallet V3](https://github.com/ton-blockchain/highload-wallet-contract-v3), this issue has been resolved at the contract architecture level, and it consumes less gas. This chapter will cover the basics of High-Load Wallet V3 and highlight important nuances to keep in mind.
:::note
+
We will work [with a slightly modified version of wrapper](https://github.com/aSpite/highload-wallet-contract-v3/blob/main/wrappers/HighloadWalletV3.ts) for the contract, as it protects against some non-obvious mistakes.
+
:::
### Storage structure
@@ -2171,7 +2217,9 @@ storage$_ public_key:bits256 subwallet_id:uint32 old_queries:(HashmapE 14 ^Cell)
```
:::tip TL-B
+
You can read more about TL-B [here](/v3/documentation/data-formats/tlb/tl-b-language).
+
:::
In the contract storage, we can find the following fields:
@@ -2235,9 +2283,11 @@ if (found) {
```
:::note
+
If you [familiarize yourself](/v3/documentation/tvm/instructions) with the operation of the `LDSLICEX` opcode (used by the `load_bits` function), you’ll notice that the read data is returned first (head), followed by the remaining data (tail). However, in the contract code, they appear in reverse order.
This happens because, in the stdlib function signature, the returned data [is ordered differently](https://github.com/ton-blockchain/highload-wallet-contract-v3/blob/d58c31e82315c34b4db55942851dd8d4153975c5/contracts/imports/stdlib.fc#L321): `(slice, slice) load_bits(slice s, int len) asm(s len -> 1 0) "LDSLICEX";`. Here, `-> 1 0` indicates that the argument with index `1` (tail) is returned first, followed by the argument with index `0` (head).
+
:::
In practice, we’re working with a matrix where `shift` represents the row index and `bit_number` represents the column index. This structure allows us to store up to 1023 queries in a single cell, meaning gas consumption only increases every 1023 queries when a new cell is added to the dictionary. However, this efficiency depends on the sequential growth of values, not random ones. Therefore, it’s crucial to increment the Query ID properly [using a dedicated class for this purpose](https://github.com/aSpite/highload-wallet-contract-v3/blob/main/wrappers/HighloadQueryId.ts).
@@ -2247,7 +2297,9 @@ This approach allows storing massive requests per timeout (1023 \* 8192 = 8,380,
For every cell that can hold 1023 requests, 2 cells in the dictionary are spent (one to store the key, the other for the value). If we take the current maximum shift value, the theoretical maximum is 8192 \* 2 \* 2 (we have two dictionaries: queries and old_queries) = 32,768 cells. If you increase the key size by a bit, it will no longer fit within the current limits.
:::info
+
In High-Load V2, each Query ID (64-bit) was stored in a separate cell within the dictionary, combining two 32-bit fields: `expire_at` and `query_id`. This approach caused gas consumption to grow rapidly when clearing old queries.
+
:::
### Replay protection
@@ -2361,7 +2413,9 @@ As a result, the contract marks the request as processed, even though it wasn’
High-Load Wallet V3 can send more than 254 messages, [putting the remaining messages into the 254th message](https://github.com/aSpite/highload-wallet-contract-v3/blob/d4c1752d00b5303782f121a87eb0620d403d9544/wrappers/HighloadWalletV3.ts#L169-L176). This way `internal_transfer` will be processed several times. The wrapper automatically does this, and we won't have to worry about it, but **recommended to take no more than 150 messages at a time** to ensure that even complex messages will fit into an external message.
:::info
+
Although the external message limit is 64KB, the larger the external message, the more likely it is to be lost in delivery, so 150 messages is the optimal solution.
+
:::
### GET methods
@@ -2377,7 +2431,9 @@ High-Load Wallet V3 supports the 5 GET methods:
| int processed?(int query_id, int need_clean) | Returns whether the query_id has been processed. If need_clean is set to 1, we will first do the cleanup based on `last_clean_time` and `timeout` and then check for query_id in `old_queries` and `queries`. |
:::tip
+
It’s recommended to pass `true` for `need_clean` unless the situation requires explicitly otherwise. This ensures the most current dictionary states are returned.
+
:::
Thanks to how the Query ID is structured in High-Load Wallet V3, we can safely resend a message with the same Query ID if it doesn’t arrive initially without worrying about the request being processed twice.
@@ -2577,7 +2633,9 @@ await wallet.sendBatch(
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
@@ -2598,7 +2656,9 @@ queryHandler.getNext();
## 🔥 High-load wallet v2
:::warning
+
High-load wallet v2 is outdated. Do not use this for new projects.
+
:::
In some situations, sending a large number of messages per transaction may be necessary. As previously mentioned, ordinary wallets support sending up to 4 messages simultaneously by storing [a maximum of 4 references](/v3/documentation/data-formats/tlb/cell-boc#cell) in a single cell. High-load wallets only allow 255 messages to be sent at once. This restriction exists because the maximum number of outgoing messages (actions) in the blockchain’s config settings is set to 255.
@@ -2922,7 +2982,9 @@ log.Println("Contract address:", contractAddress.String()) // Output contract
:::caution
+
Everything we have detailed above follows the same steps as the contract [deployment via wallet](/v3/guidelines/smart-contracts/howto/wallet#contract-deployment-via-wallet) section. To better understand, read the entire [GitHub source code](https://github.com/aSpite/wallet-tutorial).
+
:::
### Sending high-load wallet v2 messages
@@ -2930,7 +2992,9 @@ Everything we have detailed above follows the same steps as the contract [deploy
Now, let’s program a high-load wallet to send several messages simultaneously. For example, let's take 12 messages per transaction so that the gas fees are small.
:::info High-load balance
+
The contract balance must be at least 0.5 TON to complete the transaction.
+
:::
Each message carries its own comment with code, and the destination address will be the wallet from which we deployed:
@@ -3111,7 +3175,9 @@ signature := ed25519.Sign(highloadPrivateKey, toSign.EndCell().Hash())
:::note IMPORTANT
+
Note that when using JavaScript and TypeScript, our messages are saved into an array without a send mode. This happens because, when using the `@ton/ton` library, developers are expected to handle the serialization and deserialization process manually. As a result, the method first saves the message mode and then the message itself. Using the `Dictionary.Values.Cell()` specification for the value method saves the entire message as a cell reference without storing the mode separately.
+
:::
Next, we’ll create an external message and send it to the blockchain using the following code:
diff --git a/docs/v3/guidelines/smart-contracts/security/common-vulnerabilities.mdx b/docs/v3/guidelines/smart-contracts/security/common-vulnerabilities.mdx
index d37462c9c7c..41cb18e264b 100644
--- a/docs/v3/guidelines/smart-contracts/security/common-vulnerabilities.mdx
+++ b/docs/v3/guidelines/smart-contracts/security/common-vulnerabilities.mdx
@@ -7,7 +7,9 @@ import Button from '@site/src/components/button'
This comprehensive guide covers the most critical security vulnerabilities found in TON smart contracts, based on real-world audits and security research. Understanding these pitfalls is essential for developing secure smart contracts on TON Blockchain.
:::caution Critical
+
Many of these vulnerabilities can lead to complete loss of funds. Always conduct thorough security audits before deploying contracts to mainnet.
+
:::
## Critical
@@ -33,7 +35,9 @@ The absence of the `impure` modifier allows the compiler to skip function calls
```
:::tip Best practice
+
Always add the `impure` modifier to functions that perform state changes or critical validations.
+
:::
### Incorrect use of modifying/non-modifying methods
@@ -56,8 +60,10 @@ if(found?) {
```
:::info Key difference
+
- **Non-modifying (`.`)**: Returns modified copy, original unchanged
- **Modifying (`~`)**: Modifies the original variable in place
+
:::
### Signed/unsigned integer vulnerabilities
@@ -119,7 +125,9 @@ if(rand(10000) == 7777) {
```
:::warning
+
Never rely on on-chain randomness for critical operations. Validators can influence or predict random values. Consider using commit-reveal schemes or external oracles for true randomness.
+
:::
### Missing bounced message handling
@@ -169,7 +177,9 @@ cell private_data = begin_cell()
```
:::warning
+
Everything on blockchain is public. Transaction history, contract storage, and message contents are permanently visible to everyone.
+
:::
### Account destruction race conditions
@@ -430,11 +440,13 @@ receiver_balance += received_amount;
Not understanding TON's 5-phase transaction model can lead to unexpected behavior.
:::info Transaction phases
+
1. **Storage phase**: Account state loading
2. **Credit phase**: Value crediting
3. **Compute phase**: Contract execution
4. **Action phase**: Message sending
5. **Bounce phase**: Error handling
+
:::
### Cross-contract data access
@@ -499,10 +511,12 @@ Before deploying your smart contract, ensure you've addressed:
## Testing and auditing
:::tip Security first
+
- Use [Blueprint testing framework](/v3/guidelines/smart-contracts/testing/overview/) for comprehensive testing
- Conduct formal security audits before mainnet deployment
- Test edge cases and failure scenarios
- Verify bounced message handling
+
:::
## See also
diff --git a/docs/v3/guidelines/smart-contracts/security/overview.mdx b/docs/v3/guidelines/smart-contracts/security/overview.mdx
index 6c56e34035d..4ccc94a5ffe 100644
--- a/docs/v3/guidelines/smart-contracts/security/overview.mdx
+++ b/docs/v3/guidelines/smart-contracts/security/overview.mdx
@@ -5,7 +5,9 @@ import Button from '@site/src/components/button'
# Overview
:::info
+
This article needs an update. Please help us improve it.
+
:::
This section provides comprehensive recommendations to help secure your smart contracts on TON Blockchain.
@@ -32,7 +34,9 @@ Learn from actual security incidents:
## TON course: security
:::tip
-Before diving into developer-level security topics, ensure you understand security at the user level. To achieve this, take the [Blockchain Basics with TON](https://stepik.org/course/201294/promo) course ([RU version](https://stepik.org/course/202221/), [CHN version](https://stepik.org/course/200976/)). Module 5 covers the basics of user-level security.
+
+Before diving into developer-level security topics, ensure you understand security at the user level. To achieve this, take the [Blockchain Basics with TON](https://stepik.org/course/201294/promo) course ([RU version](https://stepik.org/course/202221/), [CHN version](https://stepik.org/course/200976/)). Module 5 covers the basics of user-level security.
+
:::
The [TON Blockchain course](https://stepik.org/course/176754/) is a comprehensive guide to TON Blockchain development.
diff --git a/docs/v3/guidelines/smart-contracts/security/random-number-generation.mdx b/docs/v3/guidelines/smart-contracts/security/random-number-generation.mdx
index 887c3f12a3b..5648d2d946f 100644
--- a/docs/v3/guidelines/smart-contracts/security/random-number-generation.mdx
+++ b/docs/v3/guidelines/smart-contracts/security/random-number-generation.mdx
@@ -85,6 +85,7 @@ Below we outline three fundamental approaches:
---
:::caution
+
No method is universally perfect – choose based on:
- Value-at-risk in your application
diff --git a/docs/v3/guidelines/smart-contracts/security/random.mdx b/docs/v3/guidelines/smart-contracts/security/random.mdx
index d2d41491fa4..a27a74454cf 100644
--- a/docs/v3/guidelines/smart-contracts/security/random.mdx
+++ b/docs/v3/guidelines/smart-contracts/security/random.mdx
@@ -3,8 +3,10 @@ import Feedback from '@site/src/components/Feedback';
# Generation of block random seed
:::caution
-This information is accurate at the time of writing. It may change during any network upgrade.
-:::
+
+This information is accurate at the time of writing. It may change during any network upgrade.
+
+:::
Lottery contracts occasionally appear on TON. These contracts often use unsafe methods to handle randomness, making the generated values predictable and allowing the lottery to be exploited.
diff --git a/docs/v3/guidelines/smart-contracts/security/ton-hack-challenge-1.mdx b/docs/v3/guidelines/smart-contracts/security/ton-hack-challenge-1.mdx
index b5f28ba39b4..fb4e23ff097 100644
--- a/docs/v3/guidelines/smart-contracts/security/ton-hack-challenge-1.mdx
+++ b/docs/v3/guidelines/smart-contracts/security/ton-hack-challenge-1.mdx
@@ -12,7 +12,9 @@ Source code and contest rules were hosted on GitHub [here](https://github.com/to
### 1. Mutual fund
:::note SECURITY RULE
+
Always check functions for [`impure`](/v3/documentation/smart-contracts/func/docs/functions#impure-specifier) modifier.
+
:::
The first task was very simple. The attacker could find that `authorize` function was not `impure`. The absence of this modifier allows a compiler to skip calls to that function if it returns nothing or the return value is unused.
@@ -26,7 +28,9 @@ The first task was very simple. The attacker could find that `authorize` functio
### 2. Bank
:::note SECURITY RULE
+
Always check for [modifying/non-modifying](/v3/documentation/smart-contracts/func/docs/statements#methods-calls) methods.
+
:::
`udict_delete_get?` was called with `.` instead `~`, so the real dict was untouched.
@@ -38,7 +42,9 @@ Always check for [modifying/non-modifying](/v3/documentation/smart-contracts/fun
### 3. DAO
:::note SECURITY RULE
+
Use signed integers if you really need it.
+
:::
Voting power was stored in message as an integer. So the attacker could send a negative value during power transfer and get infinite voting power.
@@ -63,7 +69,9 @@ Voting power was stored in message as an integer. So the attacker could send a n
### 4. Lottery
:::note SECURITY RULE
+
Always randomize seed before doing [`rand()`](/v3/documentation/smart-contracts/func/docs/stdlib#rand)
+
:::
Seed was brought from logical time of the transaction, and a hacker can win by bruteforcing the logical time in the current block (cause lt is sequential in the borders of one block).
@@ -87,7 +95,9 @@ if(rand(10000) == 7777) { ...send reward... }
### 5. Wallet
:::note SECURITY RULE
+
Remember that everything is stored in the blockchain.
+
:::
The wallet was protected with password, it's hash was stored in contract data. However, the blockchain remembers everything—the password was in the transaction history.
@@ -95,9 +105,11 @@ The wallet was protected with password, it's hash was stored in contract data. H
### 6. Vault
:::note SECURITY RULE
+
Always check for [bounced](/v3/documentation/smart-contracts/message-management/non-bounceable-messages) messages.
Don't forget about errors caused by [standard](/v3/documentation/smart-contracts/func/docs/stdlib) functions.
Make your conditions as strict as possible.
+
:::
The vault has the following code in the database message handler:
@@ -118,10 +130,12 @@ Vault does not have a bounce handler or proxy message to the database if the use
### 7. Better bank
:::note SECURITY RULE
+
Never destroy account for fun.
Make [`raw_reserve`](/v3/documentation/smart-contracts/func/docs/stdlib#raw_reserve) instead of sending money to yourself.
Think about possible race conditions.
Be careful with hashmap gas consumption.
+
:::
There were race conditions in the contract: you could deposit money, then try to withdraw it twice in concurrent messages. There is no guarantee that a message with reserved money will be processed, so the bank can shut down after a second withdrawal. After that, the contract could be redeployed and anybody could withdraw unclaimed money.
@@ -129,7 +143,9 @@ There were race conditions in the contract: you could deposit money, then try to
### 8. Dehasher
:::note SECURITY RULE
+
Avoid executing third-party code in your contract.
+
:::
```func
diff --git a/docs/v3/guidelines/smart-contracts/testing/collect-contract-gas-metric.mdx b/docs/v3/guidelines/smart-contracts/testing/collect-contract-gas-metric.mdx
index 434993f4ad8..5f271034a94 100644
--- a/docs/v3/guidelines/smart-contracts/testing/collect-contract-gas-metric.mdx
+++ b/docs/v3/guidelines/smart-contracts/testing/collect-contract-gas-metric.mdx
@@ -11,12 +11,14 @@ Unlike many other blockchains, TON also requires you to pay for storing contract
As you develop and iterate on a contract, even small changes to its logic can affect both gas usage and data size. Monitoring these changes helps ensure that your contract remains efficient and cost-effective.
:::tip
+
For a deeper breakdown of how fees work in TON, refer to:
- [Transaction fees](/v3/documentation/smart-contracts/transaction-fees/fees)
- [Storage fees](/v3/documentation/smart-contracts/transaction-fees/fees-low-level#storage-fee)
- [Forward fees](/v3/documentation/smart-contracts/transaction-fees/forward-fees)
- :::
+
+:::
## Gas metrics reporting
@@ -212,7 +214,9 @@ Report write in '.snapshot/1749821319408.json'
Let’s try a simple optimization — adding the `inline` specifier to some functions.
:::note
+
An [inline function](/v3/documentation/smart-contracts/func/docs/functions#inline-specifier) is directly substituted into the code wherever it’s called, which can help reduce gas usage by eliminating the overhead of a function call.
+
:::
Update your contract like this:
@@ -284,7 +288,9 @@ export default config;
```
:::tip
+
See the full list of options in the [Sandbox jest config docs](https://github.com/ton-org/sandbox?tab=readme-ov-file#setup-in-jestconfigts).
+
:::
#### Option 2: create a separate config `gas-report.config.ts`
diff --git a/docs/v3/guidelines/smart-contracts/testing/overview.mdx b/docs/v3/guidelines/smart-contracts/testing/overview.mdx
index b58f9f0de3e..58bbabc7c77 100644
--- a/docs/v3/guidelines/smart-contracts/testing/overview.mdx
+++ b/docs/v3/guidelines/smart-contracts/testing/overview.mdx
@@ -80,7 +80,9 @@ The `toHaveTransaction` matcher expects an object with any combination of fields
You can omit fields you’re not interested in and pass functions that accept the types and return booleans (`true` meaning good) to check, for example, number ranges, message opcodes, etc. Note that if a field is optional (like `from?: Address`), the function must also accept the optional type.
:::tip
-The complete list of matcher fields is in the [Sandbox documentation](https://github.com/ton-org/sandbox#test-a-transaction-with-matcher).
+
+The complete list of matcher fields is in the [Sandbox documentation](https://github.com/ton-org/sandbox#test-a-transaction-with-matcher).
+
:::
### Specific test suite
diff --git a/docs/v3/guidelines/smart-contracts/testing/writing-test-examples.mdx b/docs/v3/guidelines/smart-contracts/testing/writing-test-examples.mdx
index b19b3fe32a4..840b60d47a5 100644
--- a/docs/v3/guidelines/smart-contracts/testing/writing-test-examples.mdx
+++ b/docs/v3/guidelines/smart-contracts/testing/writing-test-examples.mdx
@@ -633,7 +633,9 @@ This error may occur if the maximum number of cells in the library is exceeded o
A library is a cell stored in [MasterChain](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains#masterchain-blockchain-of-blockchains) and can be used by all smart contracts if it is [public](https://github.com/ton-blockchain/ton/blob/9728bc65b75defe4f9dcaaea0f62a22f198abe96/crypto/block/transaction.cpp#L1844).
:::info
-Since the order of lines may change when updating the code, some links may become outdated. Therefore, all links reference the code base at commit [9728bc65b75defe4f9dcaaea0f62a22f198abe96](https://github.com/ton-blockchain/ton/tree/9728bc65b75defe4f9dcaaea0f62a22f198abe96).
+
+Since the order of lines may change when updating the code, some links may become outdated. Therefore, all links reference the code base at commit [9728bc65b75defe4f9dcaaea0f62a22f198abe96](https://github.com/ton-blockchain/ton/tree/9728bc65b75defe4f9dcaaea0f62a22f198abe96).
+
:::
diff --git a/docs/v3/guidelines/ton-connect/cookbook/cells.mdx b/docs/v3/guidelines/ton-connect/cookbook/cells.mdx
index c3b84967865..ca11ae360c3 100644
--- a/docs/v3/guidelines/ton-connect/cookbook/cells.mdx
+++ b/docs/v3/guidelines/ton-connect/cookbook/cells.mdx
@@ -47,8 +47,10 @@ const cell = beginCell()
```
:::info
+
These examples use the `@ton/ton` library only.
However, every [TON SDK](/v3/guidelines/dapps/apis-sdks/sdk) offers equivalent helper functions.
+
:::
### Parsing a cell
diff --git a/docs/v3/guidelines/ton-connect/cookbook/jetton-transfer.mdx b/docs/v3/guidelines/ton-connect/cookbook/jetton-transfer.mdx
index dba5eac1b2b..fe7ab5658a0 100644
--- a/docs/v3/guidelines/ton-connect/cookbook/jetton-transfer.mdx
+++ b/docs/v3/guidelines/ton-connect/cookbook/jetton-transfer.mdx
@@ -21,7 +21,9 @@ import TabItem from '@theme/TabItem';
The `body` for jetton transfers is based on the ([TEP-74](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md#1-transfer)) standard. Please note that the number of decimals can vary between different tokens: for example, USDT uses 6 decimals (1 USDT = 1 × 10
6 ), while typically jettons and Toncoin uses 9 decimals (1 TON = 1 × 10
9 ).
:::info
+
The `assets-sdk` library works out of the box with `ton-connect`.
+
:::
@@ -153,7 +155,9 @@ The `assets-sdk` library works out of the box with `ton-connect`.
:::tip
+
Note: For the browser, you must set a polyfill for `Buffer`.
+
:::
For more examples, check [documentation](https://github.com/ton-community/assets-sdk)
@@ -367,7 +371,9 @@ The `assets-sdk` library works out of the box with `ton-connect`.
:::tip
+
Note: For the browser, you must set a polyfill for `Buffer`.
+
:::
For more examples, check [documentation](https://github.com/ton-community/assets-sdk)
@@ -495,7 +501,9 @@ The `assets-sdk` library works out of the box with `ton-connect`.
:::tip
+
Note: For the browser, you must set a polyfill for `Buffer`.
+
:::
For more examples, check [documentation](https://github.com/ton-community/assets-sdk)
diff --git a/docs/v3/guidelines/ton-connect/cookbook/nft-transfer.mdx b/docs/v3/guidelines/ton-connect/cookbook/nft-transfer.mdx
index d49bcb2024b..b568a4036b6 100644
--- a/docs/v3/guidelines/ton-connect/cookbook/nft-transfer.mdx
+++ b/docs/v3/guidelines/ton-connect/cookbook/nft-transfer.mdx
@@ -106,7 +106,9 @@ import TabItem from '@theme/TabItem';
:::tip
+
Note: For the browser, you must set a polyfill for `Buffer`.
+
:::
For more examples, check [documentation](https://github.com/ton-community/assets-sdk)
@@ -403,7 +405,9 @@ The prepared `transferNftBody` should be sent to the NFT Item contract with at l
:::tip
+
Note: For the browser, you must set a polyfill for `Buffer`.
+
:::
For more examples, check [documentation](https://github.com/ton-community/assets-sdk)
diff --git a/docs/v3/guidelines/ton-connect/cookbook/ton-transfer.mdx b/docs/v3/guidelines/ton-connect/cookbook/ton-transfer.mdx
index a7a25024ce3..2a6f2db8123 100644
--- a/docs/v3/guidelines/ton-connect/cookbook/ton-transfer.mdx
+++ b/docs/v3/guidelines/ton-connect/cookbook/ton-transfer.mdx
@@ -160,7 +160,9 @@ A regular TON transfer using the TON Connect JS SDKs can be executed as follows:
:::tip
+
Learn more about [TON smart contract addresses](/v3/documentation/smart-contracts/addresses).
+
:::
### Getting the result
diff --git a/docs/v3/guidelines/ton-connect/creating-manifest.mdx b/docs/v3/guidelines/ton-connect/creating-manifest.mdx
index b241af1d40f..aec4d25d1e0 100644
--- a/docs/v3/guidelines/ton-connect/creating-manifest.mdx
+++ b/docs/v3/guidelines/ton-connect/creating-manifest.mdx
@@ -63,7 +63,9 @@ The manifest is a JSON file named `tonconnect-manifest.json`, and it must follow
:::info
+
For reference, see the [TON Connect specification](https://github.com/ton-blockchain/ton-connect/blob/main/requests-responses.md#app-manifest).
+
:::
### Example
diff --git a/docs/v3/guidelines/ton-connect/frameworks/python.mdx b/docs/v3/guidelines/ton-connect/frameworks/python.mdx
index 679cdd0a7d7..cb87d0b7b4c 100644
--- a/docs/v3/guidelines/ton-connect/frameworks/python.mdx
+++ b/docs/v3/guidelines/ton-connect/frameworks/python.mdx
@@ -475,16 +475,16 @@ TON Connect emits two categories of events:
These events are triggered when an action completes successfully:
-* `Event.CONNECT` — emitted when a wallet is successfully connected.
+- `Event.CONNECT` — emitted when a wallet is successfully connected.
**Parameters:** `user_id: int`, `wallet: WalletInfo`
-* `Event.DISCONNECT` — emitted when a wallet is disconnected.
+- `Event.DISCONNECT` — emitted when a wallet is disconnected.
**Parameters:** `user_id: int`, `wallet: WalletInfo`
-* `Event.TRANSACTION` — emitted when a transaction is confirmed by the user.
+- `Event.TRANSACTION` — emitted when a transaction is confirmed by the user.
**Parameters:** `user_id: int`, `transaction: SendTransactionResponse`, `rpc_request_id: int`
-* `Event.SIGN_DATA` — emitted when a sign data request is approved.
+- `Event.SIGN_DATA` — emitted when a sign data request is approved.
**Parameters:** `user_id: int`, `sign_data: SignDataResponse`, `rpc_request_id: int`
#### Error Events
diff --git a/docs/v3/guidelines/ton-connect/frameworks/react.mdx b/docs/v3/guidelines/ton-connect/frameworks/react.mdx
index d8fa907c3e9..8ad47b9d8f9 100644
--- a/docs/v3/guidelines/ton-connect/frameworks/react.mdx
+++ b/docs/v3/guidelines/ton-connect/frameworks/react.mdx
@@ -283,7 +283,9 @@ Check out the [Transaction lookup](/v3/guidelines/ton-connect/guidelines/transac
### Optional check on the backend: ton_proof
:::tip
+
Understand how to sign and verify messages: [Signing and verification](/v3/guidelines/ton-connect/verifying-signed-in-users)
+
:::
To ensure that the user truly owns the declared address, you can use `ton_proof`.
@@ -440,7 +442,9 @@ Wrappers are classes that simplify interaction with the contract, allowing you t
- When using the [Tact language](https://docs.tact-lang.org), wrappers are automatically generated for you.
:::tip
+
Check out the [Blueprint](https://github.com/ton-org/blueprint) documentation on how to develop and deploy contracts.
+
:::
Let's take a look at the default `Blueprint` counter wrapper example and how we can use it:
@@ -523,7 +527,9 @@ Let's take a look at the default `Blueprint` counter wrapper example and how we
```
:::info
+
`sendMode: 3` is a combination of `SendMode.PAY_GAS_SEPARATELY` (`+1`) and `SendMode.IGNORE_ERRORS` (`+2`) flags. Please note that it may be unsafe **not to use** the `+2` flag. For more information, please refer to the [message sending modes documentation](/v3/documentation/smart-contracts/message-management/sending-messages#mode3).
+
:::
Then you can use this class in your react component:
diff --git a/docs/v3/guidelines/ton-connect/frameworks/web.mdx b/docs/v3/guidelines/ton-connect/frameworks/web.mdx
index 8ac4c066738..95021af803b 100644
--- a/docs/v3/guidelines/ton-connect/frameworks/web.mdx
+++ b/docs/v3/guidelines/ton-connect/frameworks/web.mdx
@@ -136,7 +136,9 @@ const result = await tonConnectUI.sendTransaction(transaction)
```
:::tip
+
Get more examples on the [Sending messages](/v3/guidelines/ton-connect/cookbook/ton-transfer) page.
+
:::
### Understanding transaction status by hash
diff --git a/docs/v3/guidelines/ton-connect/guidelines/developers.mdx b/docs/v3/guidelines/ton-connect/guidelines/developers.mdx
index 72fb3941b92..1797ed0753e 100644
--- a/docs/v3/guidelines/ton-connect/guidelines/developers.mdx
+++ b/docs/v3/guidelines/ton-connect/guidelines/developers.mdx
@@ -5,7 +5,9 @@ import Feedback from '@site/src/components/Feedback';
## SDK List
:::info
+
We recommend using the [@tonconnect/ui-react](https://github.com/ton-connect/sdk/tree/main/packages/ui-react) kit for your DApps. Only switch to lower‑level packages (such as `@tonconnect/ui` or `@tonconnect/sdk`) or implement the protocol yourself if your product requires it.
+
:::
This page contains the list of useful libraries for TON Connect.
diff --git a/docs/v3/guidelines/ton-connect/overview.mdx b/docs/v3/guidelines/ton-connect/overview.mdx
index 9ed1f4e4aad..236a1d64f68 100644
--- a/docs/v3/guidelines/ton-connect/overview.mdx
+++ b/docs/v3/guidelines/ton-connect/overview.mdx
@@ -30,8 +30,8 @@ TON Connect enables communication between **wallets** and **DApps** (Decentraliz
### Interaction model
-* **Wallets** provide user interfaces for approving transactions and securely store cryptographic keys on users’ devices.
-* **DApps** built on TON offer rich functionality and secure user funds through the use of smart contracts.
+- **Wallets** provide user interfaces for approving transactions and securely store cryptographic keys on users’ devices.
+- **DApps** built on TON offer rich functionality and secure user funds through the use of smart contracts.
This separation of responsibilities enables rapid innovation and enhances security: _wallets are not tied to closed ecosystems, and DApps do not hold users’ accounts_.
@@ -89,9 +89,9 @@ See how to [integrate TON Connect into your wallet](/v3/guidelines/ton-connect/w
To integrate your service with the TON ecosystem, complete the following steps:
-* **Implement TON Connect**: integrate the TON Connect protocol into your application.
-* **Make a transfer**: use TON libraries to create and send messages. See [Sending messages](/v3/guidelines/ton-connect/cookbook/ton-transfer) for implementation details.
-* **Enable payments**: process payments using [TonAPI](https://tonapi.io/) or a custom indexer (e.g., [gobicycle](https://github.com/gobicycle/bicycle)). See the [Payments processing guide](/v3/guidelines/DApps/asset-processing/payments-processing) for more details.
+- **Implement TON Connect**: integrate the TON Connect protocol into your application.
+- **Make a transfer**: use TON libraries to create and send messages. See [Sending messages](/v3/guidelines/ton-connect/cookbook/ton-transfer) for implementation details.
+- **Enable payments**: process payments using [TonAPI](https://tonapi.io/) or a custom indexer (e.g., [gobicycle](https://github.com/gobicycle/bicycle)). See the [Payments processing guide](/v3/guidelines/DApps/asset-processing/payments-processing) for more details.
### Start with a template
diff --git a/docs/v3/guidelines/ton-connect/quick-start.mdx b/docs/v3/guidelines/ton-connect/quick-start.mdx
index e8f4c1b53b2..fe55b4e6734 100644
--- a/docs/v3/guidelines/ton-connect/quick-start.mdx
+++ b/docs/v3/guidelines/ton-connect/quick-start.mdx
@@ -70,8 +70,10 @@ await tonConnectUI.sendTransaction({
## Run the demo locally (optional)
:::caution Testnet vs Mainnet
+
The demo below sends **real TON** from the connected wallet.
Try it with a testnet wallet first or send 0.01 TON to avoid surprises.
+
:::
Clone the minimal **`react-ui-example`** repository:
diff --git a/docs/v3/guidelines/web3/ton-dns/subresolvers.mdx b/docs/v3/guidelines/web3/ton-dns/subresolvers.mdx
index 00482890f3f..19757a05599 100644
--- a/docs/v3/guidelines/web3/ton-dns/subresolvers.mdx
+++ b/docs/v3/guidelines/web3/ton-dns/subresolvers.mdx
@@ -21,9 +21,11 @@ Subdomains provide helpful functionality. For example, most blockchain explorers
:::info
-The example contract is deployed at [EQDkAbAZNb4uk-6pzTPDO2s0tXZweN-2R08T2Wy6Z3qzH_Zp](https://tonscan.org/address/EQDkAbAZNb4uk-6pzTPDO2s0tXZweN-2R08T2Wy6Z3qzH_Zp#source) and is associated with `resolve-contract.ton`. To test it, enter `
.resolve-contract.ton` in the address bar of your preferred TON explorer. This resolves to the corresponding TON DNS domain contract page. Subdomains and `.t.me` domains are supported.
+
+The example contract is deployed at [EQDkAbAZNb4uk-6pzTPDO2s0tXZweN-2R08T2Wy6Z3qzH_Zp](https://tonscan.org/address/EQDkAbAZNb4uk-6pzTPDO2s0tXZweN-2R08T2Wy6Z3qzH_Zp#source) and is associated with `resolve-contract.ton`. To test it, enter `.resolve-contract.ton` in the address bar of your preferred TON explorer. This resolves to the corresponding TON DNS domain contract page. Subdomains and `.t.me` domains are supported.
To view the resolver’s code, navigate to `resolve-contract.ton.resolve-contract.ton`. Note that this does not show the subresolver contract; it is a separate smart contract. Instead, it displays the domain contract itself.
+
:::
### dnsresolve() code
@@ -154,7 +156,9 @@ The `dnsresolve()` function can:
- Return a "domain not found" result if the subdomain is unknown.
:::warning
+
Base64 address parsing is currently not functional. Suppose you attempt to resolve a domain like `.address.resolve-contract.ton`, you will receive an error indicating that the domain is misconfigured or does not exist. This issue arises because domain names are case-insensitive—a behavior inherited from traditional DNS, which results in the lowercase. Consequently, the resolver may attempt to query a non-existent or invalid WorkChain address.
+
:::
### Binding the resolver
diff --git a/docs/v3/guidelines/web3/ton-proxy-sites/running-your-own-ton-proxy.mdx b/docs/v3/guidelines/web3/ton-proxy-sites/running-your-own-ton-proxy.mdx
index 1b56a159efb..1390b5bc314 100644
--- a/docs/v3/guidelines/web3/ton-proxy-sites/running-your-own-ton-proxy.mdx
+++ b/docs/v3/guidelines/web3/ton-proxy-sites/running-your-own-ton-proxy.mdx
@@ -144,7 +144,9 @@ You can interact with these TON Sites just like regular websites.
## Running TON Site
:::tip tutorial found!
-Want to create your own TON Site? This is a [beginner-friendly guide](/v3/guidelines/web3/ton-proxy-sites/how-to-run-ton-site).
+
+Want to create your own TON Site? This is a [beginner-friendly guide](/v3/guidelines/web3/ton-proxy-sites/how-to-run-ton-site).
+
:::
diff --git a/docs/v3/guidelines/web3/ton-proxy-sites/ton-sites-for-applications.mdx b/docs/v3/guidelines/web3/ton-proxy-sites/ton-sites-for-applications.mdx
index 36ebca7b9af..a56d3827e0f 100644
--- a/docs/v3/guidelines/web3/ton-proxy-sites/ton-sites-for-applications.mdx
+++ b/docs/v3/guidelines/web3/ton-proxy-sites/ton-sites-for-applications.mdx
@@ -11,7 +11,9 @@ Libraries and example integrations are available for popular platforms:
- [iOS](https://github.com/ton-blockchain/ton-proxy-swift)
:::caution
+
Public entry proxies are intended only for demonstration and testing purposes. Please do not use them in production.
+
:::
## See also
diff --git a/docs/v3/guidelines/web3/ton-storage/storage-daemon.mdx b/docs/v3/guidelines/web3/ton-storage/storage-daemon.mdx
index edbe2e10b03..f33d9110d92 100644
--- a/docs/v3/guidelines/web3/ton-storage/storage-daemon.mdx
+++ b/docs/v3/guidelines/web3/ton-storage/storage-daemon.mdx
@@ -114,7 +114,9 @@ add-by-meta -d directory
The bag will be downloaded to the specified directory. It will be saved to the default storage daemon directory if not specified.
:::info
+
The hash must be provided in hexadecimal format with a length of 64 characters.
+
:::
When adding a bag via a metafile, information such as size, description, and file list becomes available immediately. When adding by hash, this information may take time to load.
@@ -138,7 +140,9 @@ In the following commands, `` can be either a bag's hexadecimal hash or i
## Partial download, priorities
:::info
+
When adding a bag, you can specify which files to download:
+
:::
```
diff --git a/docs/v3/guidelines/web3/ton-storage/storage-provider.mdx b/docs/v3/guidelines/web3/ton-storage/storage-provider.mdx
index 7a65c34a72d..bff153a35b9 100644
--- a/docs/v3/guidelines/web3/ton-storage/storage-provider.mdx
+++ b/docs/v3/guidelines/web3/ton-storage/storage-provider.mdx
@@ -34,7 +34,9 @@ The process works as follows:
6. If the contract's funds are depleted, it becomes inactive, and the provider is no longer obligated to store the bag. The client can either refill the contract or retrieve their files.
:::info
+
Clients can retrieve their files anytime by providing proof of ownership to the storage contract. Once validated, the contract releases the files and deactivates itself.
+
:::
## Smart contract
@@ -94,7 +96,9 @@ The storage contract maintains a client balance, which consists of the funds tra
### Contract closure
:::info
+
If the storage contract is closed, the client receives a message with the remaining balance and [`op=0xb6236d63`](https://github.com/ton-blockchain/ton/tree/testnet/storage/storage-daemon/smartcont/constants.fc#L6).
+
:::
A storage contract may be closed under the following conditions:
@@ -117,7 +121,9 @@ deploy-provider
```
:::info IMPORTANT!
+
During deployment, you’ll be prompted to send a non-bounceable message with 1 TON to the specified address to initialize the provider. You can verify successful deployment with the `get-provider-info` command.
+
:::
By default, the contract does not accept new storage contracts. Before activating it, you must configure the provider configuration, which is stored in `storage-daemon`, and contract parameters stored on-chain.
@@ -205,7 +211,9 @@ send-coins --message "Some message"
```
:::info
+
All _bags_ stored by the provider are available with the command `list` and can be used as usual. To prevent disrupting the provider's operations, do not delete them or use this storage daemon to work with any other _bags_.
+
:::
diff --git a/package-lock.json b/package-lock.json
index ad718044d91..b3c7d7614a7 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -53,6 +53,7 @@
"remark-frontmatter": "^5.0.0",
"remark-gfm": "^4.0.1",
"remark-lint": "^10.0.1",
+ "remark-lint-docusaurus-empty-lines-around-admonition-content": "^0.2.0",
"remark-lint-rule-style": "^4.0.1",
"remark-lint-unordered-list-marker-style": "^4.0.1",
"typescript": "^5.8.3"
@@ -13659,8 +13660,6 @@
}
],
"license": "MIT",
- "optional": true,
- "peer": true,
"engines": {
"node": ">=4"
}
@@ -20299,6 +20298,167 @@
"url": "https://opencollective.com/unified"
}
},
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content": {
+ "version": "0.2.0",
+ "resolved": "https://registry.npmjs.org/remark-lint-docusaurus-empty-lines-around-admonition-content/-/remark-lint-docusaurus-empty-lines-around-admonition-content-0.2.0.tgz",
+ "integrity": "sha512-IhSVKCetkqEP7rLVqc2qwjs8MKfmm8waBtVLKWTHzcmr7MaQkDKTyw3QglvF0qsd0VMjAcvXsRPAQ2s2pBIsGw==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/mdast": "^3.0.0",
+ "@types/node": "^18.15.5",
+ "@types/unist": "^2.0.6",
+ "unified": "^10.0.0",
+ "unified-lint-rule": "^2.0.0",
+ "unist-util-generated": "^2.0.0",
+ "unist-util-visit": "^4.0.0"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/@types/mdast": {
+ "version": "3.0.15",
+ "resolved": "https://registry.npmjs.org/@types/mdast/-/mdast-3.0.15.tgz",
+ "integrity": "sha512-LnwD+mUEfxWMa1QpDraczIn6k0Ee3SMicuYSSzS6ZYl2gKS09EClnJYGd8Du6rfc5r/GZEk5o1mRb8TaTj03sQ==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/@types/node": {
+ "version": "18.19.123",
+ "resolved": "https://registry.npmjs.org/@types/node/-/node-18.19.123.tgz",
+ "integrity": "sha512-K7DIaHnh0mzVxreCR9qwgNxp3MH9dltPNIEddW9MYUlcKAzm+3grKNSTe2vCJHI1FaLpvpL5JGJrz1UZDKYvDg==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "undici-types": "~5.26.4"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/@types/unist": {
+ "version": "2.0.11",
+ "resolved": "https://registry.npmjs.org/@types/unist/-/unist-2.0.11.tgz",
+ "integrity": "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==",
+ "dev": true,
+ "license": "MIT"
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/undici-types": {
+ "version": "5.26.5",
+ "resolved": "https://registry.npmjs.org/undici-types/-/undici-types-5.26.5.tgz",
+ "integrity": "sha512-JlCMO+ehdEIKqlFxk6IfVoAUVmgz7cU7zD/h9XZ0qzeosSHmUJVOzSQvvYSYWXkFXC+IfLKSIffhv0sVZup6pA==",
+ "dev": true,
+ "license": "MIT"
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/unified": {
+ "version": "10.1.2",
+ "resolved": "https://registry.npmjs.org/unified/-/unified-10.1.2.tgz",
+ "integrity": "sha512-pUSWAi/RAnVy1Pif2kAoeWNBa3JVrx0MId2LASj8G+7AiHWoKZNTomq6LG326T68U7/e263X6fTdcXIy7XnF7Q==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0",
+ "bail": "^2.0.0",
+ "extend": "^3.0.0",
+ "is-buffer": "^2.0.0",
+ "is-plain-obj": "^4.0.0",
+ "trough": "^2.0.0",
+ "vfile": "^5.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/unist-util-is": {
+ "version": "5.2.1",
+ "resolved": "https://registry.npmjs.org/unist-util-is/-/unist-util-is-5.2.1.tgz",
+ "integrity": "sha512-u9njyyfEh43npf1M+yGKDGVPbY/JWEemg5nH05ncKPfi+kBbKBJoTdsogMu33uhytuLlv9y0O7GH7fEdwLdLQw==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/unist-util-stringify-position": {
+ "version": "3.0.3",
+ "resolved": "https://registry.npmjs.org/unist-util-stringify-position/-/unist-util-stringify-position-3.0.3.tgz",
+ "integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/unist-util-visit": {
+ "version": "4.1.2",
+ "resolved": "https://registry.npmjs.org/unist-util-visit/-/unist-util-visit-4.1.2.tgz",
+ "integrity": "sha512-MSd8OUGISqHdVvfY9TPhyK2VdUrPgxkUtWSuMHF6XAAFuL4LokseigBnZtPnJMu+FbynTkFNnFlyjxpVKujMRg==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0",
+ "unist-util-is": "^5.0.0",
+ "unist-util-visit-parents": "^5.1.1"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/unist-util-visit-parents": {
+ "version": "5.1.3",
+ "resolved": "https://registry.npmjs.org/unist-util-visit-parents/-/unist-util-visit-parents-5.1.3.tgz",
+ "integrity": "sha512-x6+y8g7wWMyQhL1iZfhIPhDAs7Xwbn9nRosDXl7qoPTSCy0yNxnKc+hWokFifWQIDGi154rdUqKvbCa4+1kLhg==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0",
+ "unist-util-is": "^5.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/vfile": {
+ "version": "5.3.7",
+ "resolved": "https://registry.npmjs.org/vfile/-/vfile-5.3.7.tgz",
+ "integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0",
+ "is-buffer": "^2.0.0",
+ "unist-util-stringify-position": "^3.0.0",
+ "vfile-message": "^3.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
+ "node_modules/remark-lint-docusaurus-empty-lines-around-admonition-content/node_modules/vfile-message": {
+ "version": "3.1.4",
+ "resolved": "https://registry.npmjs.org/vfile-message/-/vfile-message-3.1.4.tgz",
+ "integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==",
+ "dev": true,
+ "license": "MIT",
+ "dependencies": {
+ "@types/unist": "^2.0.0",
+ "unist-util-stringify-position": "^3.0.0"
+ },
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
"node_modules/remark-lint-file-extension": {
"version": "2.1.2",
"resolved": "https://registry.npmjs.org/remark-lint-file-extension/-/remark-lint-file-extension-2.1.2.tgz",
@@ -22517,8 +22677,6 @@
"integrity": "sha512-JWudPtRN7TLFHVLEVZ+Rm8FUb6kCAtHxEXFgBGDxRSdNMnGyTU5zyYvduHSF/liExlFB3vdFvsAHnNVE/UjAwA==",
"dev": true,
"license": "MIT",
- "optional": true,
- "peer": true,
"dependencies": {
"@types/unist": "^2.0.0",
"trough": "^2.0.0",
@@ -22535,9 +22693,7 @@
"resolved": "https://registry.npmjs.org/@types/unist/-/unist-2.0.11.tgz",
"integrity": "sha512-CmBKiL6NNo/OqgmMn95Fk9Whlp2mtvIv+KNpQKN2F4SjvrEesubTRWGYSg+BnWZOnlCaSTU1sMpsBOzgbYhnsA==",
"dev": true,
- "license": "MIT",
- "optional": true,
- "peer": true
+ "license": "MIT"
},
"node_modules/unified-lint-rule/node_modules/unified": {
"version": "10.1.2",
@@ -22545,8 +22701,6 @@
"integrity": "sha512-pUSWAi/RAnVy1Pif2kAoeWNBa3JVrx0MId2LASj8G+7AiHWoKZNTomq6LG326T68U7/e263X6fTdcXIy7XnF7Q==",
"dev": true,
"license": "MIT",
- "optional": true,
- "peer": true,
"dependencies": {
"@types/unist": "^2.0.0",
"bail": "^2.0.0",
@@ -22567,8 +22721,6 @@
"integrity": "sha512-k5GzIBZ/QatR8N5X2y+drfpWG8IDBzdnVj6OInRNWm1oXrzydiaAT2OQiA8DPRRZyAKb9b6I2a6PxYklZD0gKg==",
"dev": true,
"license": "MIT",
- "optional": true,
- "peer": true,
"dependencies": {
"@types/unist": "^2.0.0"
},
@@ -22583,8 +22735,6 @@
"integrity": "sha512-r7qlzkgErKjobAmyNIkkSpizsFPYiUPuJb5pNW1RB4JcYVZhs4lIbVqk8XPk033CV/1z8ss5pkax8SuhGpcG8g==",
"dev": true,
"license": "MIT",
- "optional": true,
- "peer": true,
"dependencies": {
"@types/unist": "^2.0.0",
"is-buffer": "^2.0.0",
@@ -22602,8 +22752,6 @@
"integrity": "sha512-fa0Z6P8HUrQN4BZaX05SIVXic+7kE3b05PWAtPuYP9QLHsLKYR7/AlLW3NtOrpXRLeawpDLMsVkmk5DG0NXgWw==",
"dev": true,
"license": "MIT",
- "optional": true,
- "peer": true,
"dependencies": {
"@types/unist": "^2.0.0",
"unist-util-stringify-position": "^3.0.0"
@@ -22648,6 +22796,17 @@
"url": "https://github.com/sponsors/sindresorhus"
}
},
+ "node_modules/unist-util-generated": {
+ "version": "2.0.1",
+ "resolved": "https://registry.npmjs.org/unist-util-generated/-/unist-util-generated-2.0.1.tgz",
+ "integrity": "sha512-qF72kLmPxAw0oN2fwpWIqbXAVyEqUzDHMsbtPvOudIlUzXYFIeQIuxXQCRCFh22B7cixvU0MG7m3MW8FTq/S+A==",
+ "dev": true,
+ "license": "MIT",
+ "funding": {
+ "type": "opencollective",
+ "url": "https://opencollective.com/unified"
+ }
+ },
"node_modules/unist-util-inspect": {
"version": "8.1.0",
"resolved": "https://registry.npmjs.org/unist-util-inspect/-/unist-util-inspect-8.1.0.tgz",
diff --git a/package.json b/package.json
index 818393066d6..d4926bb38ae 100644
--- a/package.json
+++ b/package.json
@@ -68,6 +68,7 @@
"remark-frontmatter": "^5.0.0",
"remark-gfm": "^4.0.1",
"remark-lint": "^10.0.1",
+ "remark-lint-docusaurus-empty-lines-around-admonition-content": "^0.2.0",
"remark-lint-rule-style": "^4.0.1",
"remark-lint-unordered-list-marker-style": "^4.0.1",
"typescript": "^5.8.3"
diff --git a/src/pages/v3/documentation/tvm/instructions.mdx b/src/pages/v3/documentation/tvm/instructions.mdx
index 4cf77947f85..5857ade0104 100644
--- a/src/pages/v3/documentation/tvm/instructions.mdx
+++ b/src/pages/v3/documentation/tvm/instructions.mdx
@@ -9,8 +9,10 @@ import { cp0 } from '@site/src/data/opcodes';
# TVM instructions
:::caution advanced level
+
This information is **very low-level** and could be hard to understand for newcomers.
So feel free to read about it later.
+
:::
- [TVM instructions overview](/v3/documentation/tvm/tvm-overview)
@@ -23,7 +25,8 @@ This document provides a list of TVM instructions along with their opcodes and m
- [**TVM.pdf**](https://ton.org/tvm.pdf) concept document for TON Virtual Machine (may include outdated information).
- [TVM Retracer](https://retracer.ton.org/)
- :::
+
+:::
Fift is a stack-based programming language designed to manage TON smart contracts. The Fift assembler is a Fift library that converts mnemonics of TVM instructions into their binary representation.
@@ -51,7 +54,9 @@ The gas price of each instruction is specified in this document. The basic gas p
### Quick search
:::info
+
A full machine-readable list of TVM instructions is available [here](https://github.com/ton-community/tvm-spec/blob/dev/match-report.json).
+
:::
Each section of TVM Instructions includes a built-in search component for finding opcodes specific to that section as well.