Proofread

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
 

docs/v3/concepts/dive-into-ton/ton-blockchain/cells-as-data-storage.md

@@ -5,36 +5,36 @@ 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:
 
-![Directed Acylic Graph](/img/docs/dag.png)
+![Directed Acyclic Graph](/img/docs/dag.png)
 
 ## 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
 * Merkle proof cell
 * 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
 
 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
 

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 <a href="https://bridge.ton.org" target="_blank">bridge.ton.org</a>. But on [18.04.2023](https://t.me/toncoin/824) the public launch of **native** USD₮ token issued by the company <a href="https://tether.to/en/" target="_blank">Tether</a> 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 <a href="https://bridge.ton.org" target="_blank">bridge.ton.org</a>. But on [18.04.2023](https://t.me/toncoin/824) the public launch of **native** USD₮ token issued by the company <a href="https://tether.to/en/" target="_blank">Tether</a> 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).
 :::

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
 

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)

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`).
 

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
 

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: