diff --git a/docs/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains.md b/docs/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains.md
index e552267656..6200bc0346 100644
--- a/docs/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains.md
+++ b/docs/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains.md
@@ -2,14 +2,14 @@
:::tip
-Terms '**smart contract**', '**account**' and '**actor**' are used interchangeably in this document to describe a blockchain entity.
+Terms '**smart contract**', '**account**', and '**actor**' are used interchangeably in this document to describe a blockchain entity.
:::
## Single actor
Let's consider one smart contract.
-In TON, it is a _thing_ with properties like `address`, `code`, `data`, `balance` and others. In other words, it is an object which has some _storage_ and _behavior_.
+In TON, it is a _thing_ with properties like `address`, `code`, `data`, `balance` and others. In other words, it is an object that has some _storage_ and _behavior_.
That behavior has the following pattern:
* something happens (the most common situation is that a contract gets a message)
* contract handles that event according to its own properties by executing its `code` in TON Virtual Machine.
@@ -29,7 +29,7 @@ Now, since nodes that process transactions need from time to time to coordinate
`[Tx1 -> Tx2] -> [Tx3 -> Tx4 -> Tx5] -> [] -> [Tx6]`.
Batching does not intervene in sequencing, each transaction still has only one 'prev tx' and at most one 'next tx', but now this sequence is cut into the **blocks**.
-It is also expedient to include queues of incoming and outgoing messages to _blocks_. In that case, a _block_ will contain a full set of information which determines and describes what happened to the smart contract during that block.
+It is also expedient to include queues of incoming and outgoing messages in _blocks_. In that case, a _block_ will contain a full set of information that determines and describes what happened to the smart contract during that block.
## Many AccountChains: Shards
diff --git a/docs/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage.md b/docs/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage.md
index 06cbd7e383..dbf4622868 100644
--- a/docs/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage.md
+++ b/docs/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage.md
@@ -5,15 +5,15 @@ Everything in TON is stored in cells. A cell is a data structure containing:
- up to **1023 bits** of data (not bytes!)
- up to **4 references** to other cells
-Bits and references are not intermixed (they are stored separately). Circular references are forbidden: for any cell, none of its descendant cells can have this original cell as reference.
+Bits and references are not intermixed (they are stored separately). Circular references are forbidden: for any cell, none of its descendant cells can have this original cell as a reference.
Thus, all cells constitute a directed acyclic graph (DAG). Here is a good picture to illustrate:
-
+
## Cell types
-Currently, there are 5 types of cell: _ordinary_ and 4 _exotic_.
+Currently, there are 5 types of cells: _ordinary_ and 4 _exotic_.
The exotic types are the following:
* Pruned branch cell
* Library reference cell
@@ -21,7 +21,7 @@ The exotic types are the following:
* Merkle update cell
:::tip
-For more on exotic cells see: [**TVM Whitepaper, Section 3**](https://ton.org/tvm.pdf).
+For more on exotic cells, see: [**TVM Whitepaper, Section 3**](https://ton.org/tvm.pdf).
:::
## Cell flavors
@@ -29,12 +29,12 @@ For more on exotic cells see: [**TVM Whitepaper, Section 3**](https://ton.org/tv
A cell is an opaque object optimized for compact storage.
In particular, it deduplicates data: if there are several equivalent sub-cells referenced in different branches, their content is only stored once. However, opaqueness means that a cell cannot be modified or read directly. Thus, there are 2 additional flavors of the cells:
-* _Builder_ for partially constructed cells, for which fast operations for appending bitstrings, integers, other cells and references to other cells can be defined.
+* _Builder_ for partially constructed cells, for which fast operations for appending bitstrings, integers, other cells and, references to other cells can be defined.
* _Slice_ for 'dissected' cells representing either the remainder of a partially parsed cell or a value (subcell) residing inside such a cell and extracted from it via a parsing instruction.
Another special cell flavor is used in TVM:
-* _Continuation_ for cells containing op-codes (instructions) for TON Virtual Machine, see [TVM bird's-eye overview](/v3/documentation/tvm/tvm-overview).
+* _Continuation_ for cells containing opcodes (instructions) for TON Virtual Machine, see [TVM bird's-eye overview](/v3/documentation/tvm/tvm-overview).
## Serialization of data to cells
diff --git a/docs/v3/documentation/dapps/assets/usdt.md b/docs/v3/documentation/dapps/assets/usdt.md
index 41fe3b2a07..cae0ddeb06 100644
--- a/docs/v3/documentation/dapps/assets/usdt.md
+++ b/docs/v3/documentation/dapps/assets/usdt.md
@@ -4,7 +4,7 @@ import Button from '@site/src/components/button'
## Tether
-Stablecoins are a type of cryptocurrency whose value is 1:1 pegged to another asset, such as a fiat currency or gold, to maintain a stable price. Until recently, there was a jUSDT token, which is a wrapped ERC-20 from the Ethereum token bridged with bridge.ton.org. But on [18.04.2023](https://t.me/toncoin/824) the public launch of **native** USD₮ token issued by the company Tether was happened. After launching USD₮, the jUSDT has moved to the second priority token but is still used in services as an alternative or addition to USD₮.
+Stablecoins are a type of cryptocurrency whose value is 1:1 pegged to another asset, such as a fiat currency or gold, to maintain a stable price. Until recently, there was a jUSDT token, which is a wrapped ERC-20 Ethereum token bridged with bridge.ton.org. But on [18.04.2023](https://t.me/toncoin/824) the public launch of **native** USD₮ token issued by the company Tether was happened. After the launch of USD₮, jUSDT moved to second-priority status but remains in use as an alternative or addition to USD₮ in various services.
In TON Blockchain USD₮ supported as a [Jetton Asset](/v3/guidelines/dapps/asset-processing/jettons).
@@ -26,16 +26,16 @@ To integrate Tether’s USD₮ Token on TON Blockchain use the contract address:
### Lower transaction fees
-Fee consumed by Ethereum USD₮ transfer is calculated dynamically depending on the network load. That's why transaction can cost a lot.
+Fees for Ethereum USD₮ transfers are calculated dynamically depending on network load. This is why transactions can become expensive.
```cpp
transaction_fee = gas_used * gas_price
```
-* `gas_used` is the amount of gas was used during transaction execution.
-* `gas_price` price on 1 unit of gas in Gwei, calculated dynamically
+* `gas_used` is the amount of gas used during transaction execution.
+* `gas_price` is the cost of one unit of gas in Gwei, calculated dynamically.
-On the other hand average fee for sending any amount of USD₮ in TON Blockchain is about 0.0145 TON nowadays. Even if TON price increases 100 times, transactions will [remain ultra-cheap](/v3/documentation/smart-contracts/transaction-fees/fees#average-transaction-cost). The core TON development team has optimized Tether’s smart contract to make it three times cheaper than any other Jetton.
+On the other hand average fee for sending any amount of USD₮ in TON Blockchain is about 0.0145 TON nowadays. Even if the price of TON increases 100 times, transactions will [remain ultra-cheap](/v3/documentation/smart-contracts/transaction-fees/fees#average-transaction-cost). The core TON development team has optimized Tether’s smart contract to make it three times cheaper than any other Jetton.
### Faster and scalable
@@ -44,7 +44,7 @@ TON’s high throughput and rapid confirmation times enable USD₮ transactions
## Advanced Details
:::caution IMPORTANT
-In TON Blockchain Jettons can be created with duplicate names. Technically, it will not differ in any way from the real USD₮ but it will have no value because of no security. You can check it for fraud only by checking Jetton Master address.
+In TON Blockchain Jettons can be created with duplicate names. Technically, it will not differ in any way from the real USD₮ but it will have no value because of no security. You can verify legitimacy and check for fraud only by confirming the Jetton Master address.
See important [recommendations](/v3/guidelines/dapps/asset-processing/jettons).
:::
diff --git a/docs/v3/documentation/dapps/defi/tokens.mdx b/docs/v3/documentation/dapps/defi/tokens.mdx
index 117320f0ea..f50f4a259e 100644
--- a/docs/v3/documentation/dapps/defi/tokens.mdx
+++ b/docs/v3/documentation/dapps/defi/tokens.mdx
@@ -4,13 +4,13 @@ import Button from '@site/src/components/button'
[Distributed TON tokens overview](https://telegra.ph/Scalable-DeFi-in-TON-03-30)
-> TON-powered tokens and NFTs do not have a single center and do not create bottlenecks.
+> TON-powered tokens and NFTs are decentralized, avoiding single points of failure and bottlenecks.
>
> Each NFT in a given collection is a separate smart contract. The token balance for each user is stored in a separate user wallet.
>
-> Smart contracts interact with one another directly, spreading the load on the whole network.
+> Smart contracts interact directly with one another, distributing the load across the entire network.
>
-> With the growth in user and transaction count, the load will still be even, allowing the network to scale.
+> As the number of users and transactions grows, the network maintains an even load, enabling seamless scalability.
## TON Course: Jettons & NFTs
diff --git a/docs/v3/documentation/infra/crosschain/overview.md b/docs/v3/documentation/infra/crosschain/overview.md
index 474af83ebb..76075bc938 100644
--- a/docs/v3/documentation/infra/crosschain/overview.md
+++ b/docs/v3/documentation/infra/crosschain/overview.md
@@ -8,9 +8,9 @@ The Toncoin bridge allows you to transfer Toncoin between TON Blockchain and the
The bridge is managed by [decentralized oracles](/v3/documentation/infra/crosschain/bridge-addresses).
-### How to use it?
+### How to use it:
-Bridge frontend is hosted on https://ton.org/bridge.
+The bridge frontend is hosted on https://ton.org/bridge.
:::info
[Bridge frontend source code](https://github.com/ton-blockchain/bridge)
diff --git a/docs/v3/documentation/infra/nodes/validation/staking-incentives.md b/docs/v3/documentation/infra/nodes/validation/staking-incentives.md
index 90a98f5f4d..38e22430e0 100644
--- a/docs/v3/documentation/infra/nodes/validation/staking-incentives.md
+++ b/docs/v3/documentation/infra/nodes/validation/staking-incentives.md
@@ -3,16 +3,16 @@
## Election and Staking
-TON Blockchain makes use of the Proof of Stake (PoS) consensus algorithm which means, like all PoS networks, that the network’s security and stability is maintained by a set of network validators. In particular, validators propose candidates for new blocks (made up of transaction batches), while other validators _validate_ and approve them via digital signatures.
+TON Blockchain uses the Proof of Stake (PoS) consensus algorithm, meaning that, like all PoS networks, the network's security and stability are maintained by a set of network validators. In particular, validators propose candidates for new blocks (made up of transaction batches), while other validators _validate_ and approve them via digital signatures.
-Validators are chosen using special [Elector governance contract](/v3/documentation/smart-contracts/contracts-specs/governance#elector). During each consensus round, validator candidates send an application for election along with their stake and desired _max_factor_ (a parameter which regulates the amount of maintenance the validator performs per consensus round).
+Validators are chosen using a special [Elector governance contract](/v3/documentation/smart-contracts/contracts-specs/governance#elector). During each consensus round, validator candidates send an application for election along with their stake and desired _max_factor_ (a parameter which regulates the amount of maintenance the validator performs per consensus round).
During the validator election process, the governance smart contract chooses the next round of validators and assigns a voting weight to each validator to maximize their total stake, while also taking into consideration the validator’s stake and _max_factor_. In this respect, the higher the stake and _max_factor_, the higher the voting weight of the validator and vice versa.
-Validators that are elected are chosen to secure the network by participating in the next consensus round. However, unlike many other blockchains, to achieve horizontal scalability, each validator validates only a portion of the network:
+Elected validators are chosen to secure the network by participating in the next consensus round. However, unlike many other blockchains, to achieve horizontal scalability, each validator validates only a portion of the network:
-For each shardchain and masterchain a dedicated set of validators exists. Sets of masterchain validators consist of up to 100 validators that exhibit the highest voting weight (defined as Network Parameter `Config16:max_main_validators`).
+A dedicated set of validators exists for each shardchain and masterchain. Sets of masterchain validators consist of up to 100 validators that exhibit the highest voting weight (defined as Network Parameter `Config16:max_main_validators`).
In contrast, each shardchain is validated by a set of 23 validators (defined as Network Parameter `Config28:shard_validators_num`) and rotated randomly every 1000 seconds (Network Parameter `Config28:shard_validators_lifetime`).
diff --git a/docs/v3/documentation/smart-contracts/func/cookbook.md b/docs/v3/documentation/smart-contracts/func/cookbook.md
index 9cf1655bbf..ffecc97125 100644
--- a/docs/v3/documentation/smart-contracts/func/cookbook.md
+++ b/docs/v3/documentation/smart-contracts/func/cookbook.md
@@ -2,7 +2,7 @@
The core reason for creating the FunC Cookbook is to collect all the experience from FunC developers in one place so that future developers will use it!
-Compared to the [FunC Documentation](/v3/documentation/smart-contracts/func/docs/types), this article is more focused on everyday tasks every FunC developer resolve during the development of smart contracts.
+Compared to the [FunC Documentation](/v3/documentation/smart-contracts/func/docs/types), this article is more focused on the everyday tasks of every FunC developer to resolve during the development of smart contracts.
## Basics
diff --git a/docs/v3/documentation/smart-contracts/message-management/internal-messages.md b/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
index 819cb55d2c..6b6a832f92 100644
--- a/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
+++ b/docs/v3/documentation/smart-contracts/message-management/internal-messages.md
@@ -5,22 +5,22 @@
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 could 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.
+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 leads to the necessity of distinguishing whether an internal message is intended as a "query", "response", or doesn't require any additional processing (like a "simple money transfer"). Furthermore, when a response is received, there must be a means to understand to which query it corresponds.
+This approach leads to the necessity of distinguishing whether an internal message is intended as a "query", "response", or doesn't require any additional processing (like a "simple money transfer"). Furthermore, when a response is received, there must be a way to determine which query it corresponds to.
-In order to achieve this goal, the following approaches for the internal message layout can be used (notice that TON Blockchain does not enforce any restrictions on the message body, so these are indeed just recommendations).
+To achieve this goal, the following approaches for the internal message layout can be used (note that TON Blockchain does not enforce any restrictions on the message body, so these are indeed just recommendations).
### Internal Message Structure
-The body of the message can be embedded into the message itself, or be stored in a separate cell referred to from the message, as indicated by the TL-B scheme fragment:
+The body of the message can be embedded into the message itself or stored in a separate cell referenced by the message, as indicated by the TL-B scheme fragment:
```tlb
message$_ {X:Type} ... body:(Either X ^X) = Message X;
```
-The receiving smart contract should accept at least internal messages with embedded message bodies (whenever they fit into the cell containing the message). If it accepts message bodies in separate cells (using the `right` constructor of `(Either X ^X)`), the processing of the inbound message should not depend on the specific embedding option chosen for the message body. On the other hand, it is perfectly valid not to support message bodies in separate cells at all for simpler queries and responses.
+The receiving smart contract should accept at least internal messages with embedded message bodies (whenever they fit into the cell containing the message). If it accepts message bodies in separate cells (using the `right` constructor of `(Either X ^X)`), the processing of the inbound message should not depend on the specific embedding option chosen for the message body. On the other hand, it is perfectly valid not to support message bodies in separate cells for simpler queries and responses.
### Internal Message Body
The message body typically begins with the following fields:
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 f1daa82fb3..f46730c8d6 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
@@ -7,7 +7,7 @@ TON is an asynchronous blockchain with a complex structure very different from o
## What is a message?
-A message is a packet of data sent between actors (users, applications, smart contracts). It typically contains information instructing the receiver on what action to perform, such as updating storage or sending a new message.
+A message is a packet of data exchanged between actors (users, applications, or smart contracts). It typically contains information instructing the receiver on what action to perform, such as updating storage or sending a new message.
@@ -21,7 +21,7 @@ A message is a packet of data sent between actors (users, applications, smart co
-Working with this type of communication is reminiscent of launching a satellite into space. We know the message we've formed, but after its launch, it is necessary to conduct separate observation to find out what results we will obtain.
+Working with this type of communication is reminiscent of launching a satellite into space. While we know the message we've created, observation after launch is required to determine the outcome.
@@ -30,9 +30,9 @@ Working with this type of communication is reminiscent of launching a satellite
A transaction in TON consists of the following:
- the incoming message that initially triggers the contract (special ways to trigger exist)
- contract actions caused by the incoming message, such as an update to the contract's storage (optional)
-- outgoing generated messages that are sent to other actors (optional)
+- outgoing messages generated and sent to other actors (optional)
->Technically, a contract can be triggered through special functions such as [Tick-Tock](/v3/documentation/data-formats/tlb/transaction-layout#tick-tock), but this function more used for internal TON Blockchain core contracts.
+>Technically, a contract can be triggered through special functions such as [Tick-Tock](/v3/documentation/data-formats/tlb/transaction-layout#tick-tock), but this function is more used for internal TON Blockchain core contracts.
>Not every transaction results in outgoing messages or updates to the contract's storage — this depends on the actions defined by the contract's code.
@@ -52,7 +52,7 @@ If we look at Ethereum or almost any other synchronous blockchain, each transact
In an asynchronous system you can't get a response from the destination smart contract in the same transaction. A contract call may take a few blocks to be processed, depending on the length of the route between source and destination.
-To achieve the infinite sharding paradigm, it is necessary to ensure full parallelization, which means that the execution of each transactions is independent of every other. Therefore, instead of transactions which affect and change the state of many contracts at one time, 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.
+Achieving the infinite sharding paradigm requires full parallelization, ensuring that each transaction executes independently of others. Therefore, instead of transactions which affect and change the state of many contracts at one time, 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
More detailed and accurate description on the [Transaction Layout](/v3/documentation/data-formats/tlb/transaction-layout) page.
diff --git a/docs/v3/documentation/smart-contracts/message-management/sending-messages.md b/docs/v3/documentation/smart-contracts/message-management/sending-messages.md
index 95c7d9a387..9037bdf957 100644
--- a/docs/v3/documentation/smart-contracts/message-management/sending-messages.md
+++ b/docs/v3/documentation/smart-contracts/message-management/sending-messages.md
@@ -1,10 +1,11 @@
# Sending messages
-Composition, parsing, and sending messages lie at the intersection of [TL-B schemas](/v3/documentation/data-formats/tlb/tl-b-language), [transaction phases and TVM](/v3/documentation/tvm/tvm-overview).
+Composition, parsing, and sending messages lie at the intersection of [TL-B schemas](/v3/documentation/data-formats/tlb/tl-b-language), [transaction phases, and TVM](/v3/documentation/tvm/tvm-overview).
-Indeed, FunC exposes [send_raw_message](/v3/documentation/smart-contracts/func/docs/stdlib#send_raw_message) function which expects a serialized message as an argument.
+Indeed, FunC exposes the [send_raw_message](/v3/documentation/smart-contracts/func/docs/stdlib#send_raw_message) function which expects a serialized message as an argument.
+
+Since TON is a comprehensive system with wide functionality, messages that need to support all of this functionality may appear quite complicated. However, most of that functionality is not used in common scenarios, and message serialization, in most cases, can be simplified to:
-Since TON is a comprehensive system with wide functionality, messages which need to be able to support all of this functionality may look quite complicated. Still, most of that functionality is not used in common scenarios, and message serialization in most cases may be reduced to:
```func
cell msg = begin_cell()
.store_uint(0x18, 6)
@@ -15,17 +16,17 @@ Since TON is a comprehensive system with wide functionality, messages which need
.end_cell();
```
-Therefore, the developer should not be afraid, and if something in this document seems incomprehensible on first reading, it's okay. Just grasp the general idea.
+Therefore, the developer should not worry; if something in this document seems incomprehensible on first reading, that's okay. Just grasp the general idea.
-Sometimes the word **'gram'** may be mentioned in the documentation, mostly in code examples, it's just an outdated name for **toncoin**.
+Sometimes the word **'gram'** may appear in the documentation, primarily in code examples; it is simply an outdated name for **toncoin**.
Let's dive in!
## Types of messages
There are three types of messages:
- * external—messages that are sent from outside of the blockchain to a smart contract inside the blockchain. Such messages should be explicitly accepted by smart contracts during so called `credit_gas`. If the message is not accepted, the node should not accept it into a block or relay it to other nodes.
- * internal—messages that are sent from one blockchain entity to another. Such messages (in contrast to external) may carry some TON and pay for themselves. Thus, smart contracts that receive such messages may not accept it. In this case, gas will be deducted from the message value.
- * logs—messages that are sent from a blockchain entity to the outer world. Generally speaking, there is no mechanism for sending such messages out of the blockchain. In fact, while all nodes in the network have consensus on whether a message was created or not, there are no rules on how to process them. Logs may be directly sent to `/dev/null`, logged to disk, saved an indexed database, or even sent by non-blockchain means (email/telegram/sms), all of these are at the sole discretion of the given node.
+ * external—messages sent from outside of the blockchain to a smart contract inside the blockchain. Such messages should be explicitly accepted by smart contracts during the so-called `credit_gas`. If the message is not accepted, the node should not accept it into a block or relay it to other nodes.
+ * internal—messages sent from one blockchain entity to another. Such messages, in contrast to external ones, may carry some TON and pay for themselves. Thus, smart contracts that receive such messages may not accept it. In this case, gas will be deducted from the message value.
+ * logs—messages sent from a blockchain entity to the outer world. Generally, there is no mechanism for sending such messages out of the blockchain. In fact, while all nodes in the network have consensus on whether a message was created or not, there are no rules on how to process them. Logs may be directly sent to `/dev/null`, logged to disk, saved an indexed database, or even sent by non-blockchain means (email/telegram/sms), all of these are at the sole discretion of the given node.
## Message layout
diff --git a/docs/v3/documentation/whitepapers/overview.md b/docs/v3/documentation/whitepapers/overview.md
index 2a59c8c71b..537b1b3c94 100644
--- a/docs/v3/documentation/whitepapers/overview.md
+++ b/docs/v3/documentation/whitepapers/overview.md
@@ -1,6 +1,6 @@
# Whitepapers
-This section presents the original documentation written by Dr. Nikolai Durov, which fully describes all parts of TON.
+This section presents the original documentation written by Dr. Nikolai Durov, which comprehensively describes all parts of TON.
## Original documentation
@@ -14,7 +14,7 @@ Please note that here and later the code, comments and/or documentation may cont
* [TON Virtual Machine](https://docs.ton.org/tvm.pdf)
- TON Virtual Machine description(may include outdated information on OP Codes, actual list in [TVM Instruction](/v3/documentation/tvm/tvm-overview) section).
+ TON Virtual Machine description (may include outdated information on OP Codes, actual list in [TVM Instruction](/v3/documentation/tvm/tvm-overview) section).
* [TON Blockchain](https://docs.ton.org/tblkch.pdf)
@@ -26,7 +26,7 @@ Please note that here and later the code, comments and/or documentation may cont
* [Fift Documentation](https://docs.ton.org/fiftbase.pdf)
- Description of Fift language and how to use it in TON.
+ Description of the Fift language and how to use it in TON.
## Translations
diff --git a/docs/v3/guidelines/dapps/apis-sdks/sdk.mdx b/docs/v3/guidelines/dapps/apis-sdks/sdk.mdx
index 20c9880868..295372ba58 100644
--- a/docs/v3/guidelines/dapps/apis-sdks/sdk.mdx
+++ b/docs/v3/guidelines/dapps/apis-sdks/sdk.mdx
@@ -1,6 +1,6 @@
# SDKs
-Instant navigate on preferred language with right sidebar.
+Instantly navigate to your preferred language using the right sidebar.
## Overview
@@ -8,7 +8,7 @@ There are different ways to connect to blockchain:
1. RPC data provider or other API: in most cases, you have to *rely* on its stability and security.
2. ADNL connection: you're connecting to a [liteserver](/v3/guidelines/nodes/running-nodes/liteserver-node). They might be inaccessible, but with a certain level of validation (implemented in the library), cannot lie.
3. Tonlib binary: you're connecting to liteserver as well, so all benefits and downsides apply. However, your application also contains a dynamic-loading library compiled outside.
-4. Offchain-only. Such SDKs allow to create and serialize cells, which you can then send to APIs.
+4. Offchain-only. These SDKs enable the creation and serialization of cells, which can be transmitted to APIs.
### TypeScript / JavaScript
@@ -36,7 +36,7 @@ There are different ways to connect to blockchain:
|[pytoniq](https://github.com/yungwine/pytoniq) |Native ADNL| Python SDK with native LiteClient and other ADNL-based protocols implementations. |
|[pytoniq-core](https://github.com/yungwine/pytoniq-core) | *offchain-only* | Python powerful transport-free SDK |
|[tonutils](https://github.com/nessshon/tonutils) | via RPC ([TONAPI](https://tonapi.io/api-v2) / [Toncenter](https://toncenter.com/api/v3/)) / Native ADNL ([pytoniq](https://github.com/yungwine/pytoniq))| Tonutils is a high-level object-oriented library for Python designed to facilitate interactions with the TON blockchain |
-|[pytonlib](https://github.com/toncenter/pytonlib)|Tonlib binary| This is standalone Python library based on libtonlibjson, brought as a binary dependency from TON monorepo. |
+|[pytonlib](https://github.com/toncenter/pytonlib)|Tonlib binary| This is a standalone Python library based on libtonlibjson, brought as a binary dependency from TON monorepo. |
|[mytonlib](https://github.com/igroman787/mytonlib)|Native ADNL| Native Python SDK library for working with The Open Network |
|[TonTools](https://github.com/yungwine/TonTools)|via RPC ([Orbs](https://www.orbs.com/ton-access/) / [Toncenter](https://toncenter.com/api/v2/) / etc)|TonTools is a high-level OOP library for Python, which can be used to interact with TON Blockchain.|
|[tonpy](https://github.com/disintar/tonpy)|Native ADNL| Python package that provides data structures and API to interact with TON blockchain. |
diff --git a/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx b/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
index e33fe9fbb5..762e2f760e 100644
--- a/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
+++ b/docs/v3/guidelines/dapps/asset-processing/mintless-jettons.mdx
@@ -3,7 +3,7 @@
## Introduction
:::info
-For clear understanding, the reader should be familiar with the basic principles of asset processing described in [payments processing section](/v3/guidelines/dapps/asset-processing/payments-processing) and [jetton processing](/v3/guidelines/dapps/asset-processing/jettons).
+For a clear understanding, the reader should be familiar with the basic principles of asset processing described in [payments processing section](/v3/guidelines/dapps/asset-processing/payments-processing) and [jetton processing](/v3/guidelines/dapps/asset-processing/jettons).
:::
The TON blockchain ecosystem has introduced an innovative extension to the Jetton standard called [Mintless Jettons](https://github.com/ton-community/mintless-jetton?tab=readme-ov-file).
@@ -14,13 +14,13 @@ This extension enables decentralized, [Merkle-proof](/v3/documentation/data-form
Mintless Jettons - are an extension ([TEP-177](https://github.com/ton-blockchain/TEPs/pull/177) and [TEP-176](https://github.com/ton-blockchain/TEPs/pull/176)) of the standard Jetton implementation ([TEP-74](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md)) on the TON blockchain.
-This implementation allows for large-scale, decentralized airdrops to millions of users without incurring significant costs or adding excessive load to the blockchain.
+This implementation enables large-scale, decentralized airdrops to millions of users without incurring significant costs or adding excessive load to the blockchain.
### Basic Features
- **Scalability**: Traditional minting processes can be resource-intensive and costly when distributing tokens to a vast number of users.
- **Efficiency**: By utilizing Merkle trees, Mintless Jettons store a single hash representing all airdropped amounts, reducing storage requirements.
-- **User-Friendly Airdrops**: Users immediately have their jettons ready to use—send, swap, and so on—without any preparatory steps like withdrawal or claim. It just works!
+- **User-Friendly Airdrops**: Users have their jettons ready to use immediately—send, swap, and more—without any preparatory steps like withdrawal or claim!
## Supporting Mintless Jettons in On-Chain Protocols
diff --git a/docs/v3/guidelines/dapps/tutorials/web3-game-example.md b/docs/v3/guidelines/dapps/tutorials/web3-game-example.md
index 1ea0a1c677..387f13cf98 100644
--- a/docs/v3/guidelines/dapps/tutorials/web3-game-example.md
+++ b/docs/v3/guidelines/dapps/tutorials/web3-game-example.md
@@ -77,7 +77,7 @@ Image | You can download [the image](https://raw.githubusercontent.com/ton-commu
We are fully prepared. So, let’s go to the logic implementation.
## Connecting wallet
-Everything starts from a user connects his wallet. So, let’s add wallet connect integration. To work with the blockchain from the client side we need to install GameFi SDK for Phaser:
+The process begins with the user connecting their wallet. So, let’s add wallet connect integration. To work with the blockchain from the client side we need to install GameFi SDK for Phaser:
```sh
npm install --save @ton/phaser-sdk@beta
```
diff --git a/docs/v3/guidelines/nodes/nodes-troubleshooting.md b/docs/v3/guidelines/nodes/nodes-troubleshooting.md
index 22eb9f627e..1f21cc27de 100644
--- a/docs/v3/guidelines/nodes/nodes-troubleshooting.md
+++ b/docs/v3/guidelines/nodes/nodes-troubleshooting.md
@@ -9,8 +9,8 @@ This section contains answers to the most frequently asked questions about runni
Failed to get account state
```
-This error means that there are issues during search for this account in shard state.
-Most probably it means that liteserver node is syncing too slow, in particular the Masterchain synchronisation overtook shardchains (Basechain) synchronisation. In this case node knows the recent Masterchain block but can not check account state in recent shardchain block and returns Failed to get account state.
+This error indicates that there are issues during the search for this account in the shard state.
+It most likely means that the liteserver node is syncing too slowly, with the Masterchain synchronization overtaking the shardchain (Basechain) synchronization. In this case, the node knows the recent Masterchain block but cannot check the account state in the recent shardchain block, resulting in the "Failed to get account state" error.
## Failed to unpack account state
@@ -23,10 +23,10 @@ This error means that requested account doesn't exist in current state. That mea
## About no progress in node synchronization within 3 hours
-Try to perform following checks:
+Try to perform the following checks:
-1. Is process running without crashes? (Check systemd process status)
-2. Is there a firewall between node and internet, if so, will it pass incoming UDP traffic to port specified in field `addrs[0].port` of `/var/ton-work/db/config.json` file?
+1. Is the process running without crashes? (Check systemd process status)
+2. Is there a firewall between the node and internet, if so, will it pass incoming UDP traffic to port specified in field `addrs[0].port` of `/var/ton-work/db/config.json` file?
3. Is there NAT between the machine and the internet? If so, ensure that the IP address defined in the `addrs[0].ip` field of the `/var/ton-work/db/config.json` file corresponds to the real public IP of the machine. Note that the value of this field is specified as a signed INT. The `ip2dec` and `dec2ip` scripts located in [ton-tools/node](https://github.com/sonofmom/ton-tools/tree/master/node) can be used to perform conversions.
diff --git a/docs/v3/guidelines/smart-contracts/get-methods.md b/docs/v3/guidelines/smart-contracts/get-methods.md
index 7c33d68d0e..594b08290e 100644
--- a/docs/v3/guidelines/smart-contracts/get-methods.md
+++ b/docs/v3/guidelines/smart-contracts/get-methods.md
@@ -8,7 +8,7 @@ Before proceeding, it is recommended that readers have a basic understanding of
Get methods are special functions in smart contracts that are made for querying specific data from them. Their execution doesn't cost any fees and happens outside of the blockchain.
-These functions are very common for most smart contracts. For example, the default [Wallet contract](/v3/documentation/smart-contracts/contracts-specs/wallet-contracts) has several get methods, such as `seqno()`, `get_subwallet_id()` and `get_public_key()`. They are used by wallets, SDKs and APIs to fetch data about wallets.
+These functions are very common in most smart contracts. For example, the default [Wallet contract](/v3/documentation/smart-contracts/contracts-specs/wallet-contracts) has several get methods, such as `seqno()`, `get_subwallet_id()` and `get_public_key()`. They are used by wallets, SDKs, and APIs to fetch data about wallets.
## Design patterns for get methods
@@ -47,7 +47,7 @@ These functions are very common for most smart contracts. For example, the defau
}
```
-2. **Conditional data retrieval**: Sometimes, the data that needs to be retrieved depends on certain conditions, such as current time.
+2. **Conditional data retrieval**: Sometimes, the data that needs to be retrieved depends on certain conditions, such as the current time.
Example:
@@ -262,7 +262,7 @@ This code will result `Total: 123` output. The number can be different, this is
For testing smart contracts created we can use the [Sandbox](https://github.com/ton-community/sandbox) which is installed by default in new Blueprint projects.
-At first, you need to add a special method in contract wrapper that will execute the get method and return the typed result. Let's say your contract is called _Counter_ and you have already implemented the method that updates the stored number. Open `wrappers/Counter.ts` and add the following method:
+First, you need to add a special method in the contract wrapper that will execute the get method and return the typed result. Let's say your contract is called _Counter_ and you have already implemented the method that updates the stored number. Open `wrappers/Counter.ts` and add the following method:
```ts
async getTotal(provider: ContractProvider) {
@@ -355,7 +355,7 @@ In this example, the contract receives and processes internal messages by interp
- Op-code `2` signifies a request to query the number from the contract's data.
- Op-code `3` is used in the response message, which the calling smart contract must handle in order to receive the result.
-For the simplicity, we used just simple little numbers 1, 2 and 3 for the operation codes. But for real projects, consider setting them according to the standard:
+For simplicity, we used just simple little numbers 1, 2, and 3 for the operation codes. But for real projects, consider setting them according to the standard:
- [CRC32 Hashes for op-codes](/v3/documentation/data-formats/tlb/crc32)
diff --git a/docs/v3/guidelines/ton-connect/guidelines/integration-with-javascript-sdk.md b/docs/v3/guidelines/ton-connect/guidelines/integration-with-javascript-sdk.md
index bf5a2ade78..bd2b027ff0 100644
--- a/docs/v3/guidelines/ton-connect/guidelines/integration-with-javascript-sdk.md
+++ b/docs/v3/guidelines/ton-connect/guidelines/integration-with-javascript-sdk.md
@@ -1,6 +1,6 @@
# Integration manual with the JavaScript SDK
-In this tutorial, we’ll create a sample web app that supports TON Connect 2.0 authentication. It will allow for signature verification to eliminate the possibility of fraudulent identity impersonation without agreement establishment between parties.
+In this tutorial, we’ll create a sample web app that supports TON Connect 2.0 authentication. It will allow for signature verification to eliminate the possibility of fraudulent identity impersonation without the need for agreement establishment between parties.
## Documentation links
@@ -10,11 +10,11 @@ In this tutorial, we’ll create a sample web app that supports TON Connect 2.0
## Prerequisites
-In order for connectivity to be fluent between apps and wallets, the web app must make use of manifest that is accessible via wallet applications. The prerequisite to accomplish this is typically a host for static files. For example, say if a developer wants to make use of GitHub pages, or deploy their website using TON Sites hosted on their computer. This would therefore mean their web app site is publicly accessible.
+In order for connectivity to be fluent between apps and wallets, the web app must make use of manifest that is accessible via wallet applications. The prerequisite to accomplish this is typically a host for static files. For example, if a developer wants to make use of GitHub pages, or deploy their website using TON Sites hosted on their computer. This would mean their web app site is publicly accessible.
## Getting wallets support list
-To increase the overall adoption of TON Blockchain, it is necessary that TON Connect 2.0 is able to facilitate a vast number of application and wallet connectivity integrations. Of late and of significant importance, the ongoing development of TON Connect 2.0 has allowed for the connection of the Tonkeeper, TonHub, MyTonWallet and other wallets with various TON Ecosystem Apps. It is our mission to eventually allow for the exchange of data between applications and all wallet types built on TON via the TON Connect protocol. For now, this is realized by providing the ability for TON Connect to load an extensive list of available wallets currently operating within the TON Ecosystem.
+To increase the overall adoption of TON Blockchain, it is necessary that TON Connect 2.0 is able to facilitate a vast number of application and wallet connectivity integrations. Of late and of significant importance, the ongoing development of TON Connect 2.0 has allowed for the connection of the Tonkeeper, TonHub, MyTonWallet and other wallets with various TON Ecosystem Apps. It is our mission to eventually allow for the exchange of data between applications and all wallet types built on TON via the TON Connect protocol. For now, this is achieved by enabling TON Connect to load an extensive list of available wallets currently operating within the TON Ecosystem.
At the moment our sample web app enables the following:
@@ -44,7 +44,7 @@ For learning purposes, let's take a looks at the HTML page described by the foll