feat: improve wording in addresses/overview

foundations/addresses/overview.mdx

@@ -5,22 +5,17 @@ sidebarTitle: "Overview"
 
 import { Aside } from '/snippets/aside.jsx';
 
-TON implements **Actor model**, where all entities, including wallets, are smart contracts. Each actor:
+TON implements an [actor model](https://en.wikipedia.org/wiki/Actor_model), where entities, including wallets, are _smart contracts_ that exchange messages. Each smart contract is hosted on a distinct _account_ that manages its balance and persistent storage. These accounts have identifiable _addresses_, used for sending and receiving messages on the blockchain.
 
-- processes incoming messages;
-- updates its internal state;
-- generates outgoing messages.
+Each actor (account) processes incoming messages on its address one at a time, updating its internal state and generating outgoing messages. While multiple accounts can share the same code, each maintains its own storage and balance. To uphold this separation, each account address is unique.
 
-As a result, every actor must have a unique address to ensure the correct message routing. This section explains how these addresses are structured and why they are fundamental to the TON architecture.
-
-There are several types of addresses used in the TON blockchain. Here, we will focus on the two most important ones for developers: **internal** and **external**.
-Every account in the TON blockchain has an internal address. External addresses are intended to be used by off-chain software.
+On the TON blockchain, there are several types of addresses. The two most relevant ones for developers are [_internal_](#internal-addresses) and [_external_](#external-addresses). Every account has an internal address, while external addresses are intended for use by off-chain software.
 
 ## Internal addresses
 
-Each smart contract deployed on TON blockchain has this type of the address. Let's look at the corresponding TL-B schemes:
+Each smart contract deployed on TON has an internal address. The corresponding TL-B schemes are:
 
-```
+```tlb
 addr_std$10 anycast:(Maybe Anycast)
    workchain_id:int8 address:bits256 = MsgAddressInt;
 addr_var$11 anycast:(Maybe Anycast) addr_len:(## 9)
@@ -35,7 +30,7 @@ There are two constructors:
 And four components:
 
 - `workchain_id`: the workchain ID — a signed 8-bit integer in case of `addr_std` and a 32-bit integer in case of `addr_var`.
-- `address`: an address of the account — from 64 to 512 bits, depending on the workchain. To avoid confusion with a full address, this field is usually called `account_id`.
+- `address`: an address of the account — from 64 to 512 bits, depending on the workchain. To avoid confusion with a full address, this field is usually called `account_id` or a **hash** part of address.
 - `addr_len`: a length of the non-standardized address.
 - `anycast`: not currently used in the blockchain and is always replaced with a zero bit. It was designed to implement shard splitting for _global_ (or _large_) accounts, but was later deprecated in [TVM 10](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#anycast-addresses-and-address-rewrite).
 
@@ -52,19 +47,21 @@ Both use **256-bit addresses** for accounts.
 
 ### Account ID
 
-In the currently used workchains, an account ID is defined as the result of applying a hash function to a [`StateInit`](/foundations/messages/deploy) structure that stores initial code and data of a smart contract.
+In the currently used workchains, the account ID is defined as the hash of the contract's initial state ([`StateInit`](/foundations/messages/deploy)) structure, which holds its code and data:
 
-```
+```text
 account_id = hash(initial_code, initial_data)
 ```
 
-So, for each pair (`initial_code`, `initial_data`), there exists a unique account ID to which a smart contract with such code and data can be deployed (this logic may become more complex when [TVM 11](https://github.com/ton-blockchain/ton/blob/master/doc/GlobalVersions.md#version-11) is deployed on the main network.).
+Uninitialized account can only become active by providing a `StateInit` that matches its account ID (hash) in the incoming message. If the [`fixed_prefix_length` is set](/foundations/messages/deploy#deploying-to-specific-shard), the first respective bits of the destination account ID are not compared with the `StateInit` hash — only the remaining bits must match. That short prefix is used to [deploy a contract in the specific shard](/foundations/messages/deploy#deploying-to-specific-shard).
+
+As such, for each pair of `initial_code` and `initial_data`, there exists a specific set of account IDs to which a smart contract with such code and data can be deployed. Account IDs are crucial for sharding and for delivering messages between shards during [Hypercube Routing](/foundations/shards).
 
-<Aside type="tip">
-  Although the deployed smart contract code and data may change during its lifetime, the address where it's deployed does not change.
+<Aside type="note">
+  Although the deployed smart contract code and data may change during its lifetime, the address where it is deployed does **not** change.
 </Aside>
 
-Additionally, a 64-bit prefix of an account ID is crucial for the sharding process and delivering messages from one shard to another during [Hypercube Routing](/foundations/shards).
+Some contracts can transform into another contract with specified code and data as their first action. They are called [vanity](/contract-dev/techniques/vanity) contracts because they allow for a wider range of account IDs, helping to find a subjectively prettier address for the new contract. Their off-chain generation parts try different `StateInit` values, often by changing a salt, until the resulting account ID has a desired prefix or suffix. After deployment, the contract can set its runtime code and data to the intended contract state, retaining the address obtained with the initial `StateInit`.
 
 ## External addresses
 
@@ -88,10 +85,10 @@ addr_extern$01 len:(## 9) external_address:(bits len)
 - **Every actor is a smart contract**, each with a unique address for message routing.
 - **Main internal address fields**:
   - `workchain_id` (8- or 32-bit): identifies the workchain.
-  - `account_id` (256-bit): a hash of the contract’s initial code and data.
-- **Active workchains**: masterchain and basechain, both using 256-bit ids.
-- **Flexibility**: TON supports up to `2^32` workchains, allowing future chains to customize address lengths (64–512 bits).
-- **External addresses**: may be used by external software for its own purposes but are ignored by the TON Blockchain software.
+  - `account_id` (256-bit in active workchains): a hash of the contract's initial code and data.
+- **Active workchains**: masterchain and basechain, both using 256-bit IDs.
+- **Flexibility**: TON supports up to `2^32` workchains, allowing future chains to customize address lengths from 64 to 512 bits.
+- **External addresses**: may be used by external software but are ignored on-chain.
 
 ## Next steps
 

foundations/whitepapers/ton.mdx

@@ -1315,7 +1315,7 @@ We conclude our brief discussion of the TON Blockchain and its most important an
 
 **Table 1:** A summary of some notable blockchain projects. The columns are: *Project* — project name; *Year* — year announced and year deployed; *G.* — generation (cf. [2.8.15](#2-8-15-simplified-classification-generations-of-blockchain-projects)); *Cons.* — consensus algorithm (cf. [2.8.3](#2-8-3-creating-and-validating-blocks-proof-of-work-vs-proof-of-stake) and [2.8.4](#2-8-4-variants-of-proof-of-stake-dpos-vs-bft)); *Sm.* — support for arbitrary code (smart contracts; cf. [2.8.6](#2-8-6-support-for-turing-complete-code-in-transactions%2C-i-e-%2C-essentially-arbitrary-smart-contracts)); *Ch.* — single/multiple blockchain system (cf. [2.8.2](#2-8-2-single-blockchain-vs-multi-blockchain-projects)); *R.* — heterogeneous/homogeneous multichain systems (cf. [2.8.8](#2-8-8-blockchain-types-homogeneous-and-heterogeneous-systems)); *Sh.* — sharding support (cf. [2.8.12](#2-8-12-sharding-support)); *Int.* — interaction between blockchains, (L)oose or (T)ight (cf. [2.8.14](#2-8-14-interaction-between-blockchains-loosely-coupled-and-tightly-coupled-systems)).
 
-#### 2.9.1. Bitcoin [[12]](#ref-12); https://bitcoin.org/ 
+#### 2.9.1. Bitcoin [[12]](#ref-12); https://bitcoin.org/
 
 *Bitcoin* (2009) is the first and the most famous blockchain project. It is a typical *first-generation* blockchain project: it is single-chain, it uses Proof-of-Work with a "longest-fork-wins" fork selection algorithm, and it does not have a Turing-complete scripting language (however, simple scripts without loops are supported). The Bitcoin blockchain has no notion of an account; it uses the UTXO (Unspent Transaction Output) model instead.
 
@@ -1372,7 +1372,7 @@ In this way, Plasma might become a platform for distributed computations bound t
 #### 2.9.11. Specialized blockchain projects
 
 There are also some specialized blockchain projects, such as FileCoin (a system that incentivizes users to offer their disk space for storing the files of other users who are willing to pay for it), Golem (a blockchain-based platform for renting and lending computing power for specialized applications such as 3D-rendering) or SONM (another similar computing power-lending project). Such projects do not introduce anything conceptually new on the level of blockchain organization; rather, they are particular blockchain applications, which could be implemented by smart contracts running in a general-purpose blockchain, provided it can deliver the required performance. As such, projects of this kind are likely to use one of the existing or planned blockchain projects as their base, such as EOS, PolkaDot or TON. If a project needs "true" scalability (based on sharding), it would better use TON; if it is content to work in a "confederated" context by defining a family of workchains of its own, explicitly optimized for its purpose, it might opt for EOS or PolkaDot.
- 
+
 #### 2.9.12. The TON Blockchain
 
 The TON (Telegram Open Network) Blockchain (planned 2018) is the project we are describing in this document. It is designed to be the first fifth-generation blockchain project—that is, a BFT PoS-multichain project, mixed homogeneous/heterogeneous, with support for (shardable) custom workchains, with native sharding support, and tightly-coupled (in particular, capable of forwarding messages between shards almost instantly while preserving a consistent state of all shardchains). As such, it will be a truly scalable general-purpose blockchain project, capable of accommodating essentially any applications that can be implemented in a blockchain at all. When augmented by the other components of the TON Project (cf. [1](#1-brief-description-of-ton-components)), its possibilities expand even further.
@@ -1844,7 +1844,7 @@ Subdomains are registered on a "first-come, first-served" basis.
 
 In principle, any full node for the masterchain or shardchain containing a DNS smart contract might be able to look up any subdomain in the database of that smart contract, if the structure and the location of the hashmap inside the persistent storage of the smart contract are known.
 
-However, this approach would work only for certain DNS smart contracts. It would fail miserably if a non-standard DNS smart contract were used. 
+However, this approach would work only for certain DNS smart contracts. It would fail miserably if a non-standard DNS smart contract were used.
 
 Instead, an approach based on *general smart contract interfaces and get methods* ([cf. 4.3.11](#4-3-11-get-methods-of-smart-contracts)) is used. Any DNS smart contract must define a get method with a known signature, which is invoked to look up a key. Since this approach makes sense for other smart contracts as well, especially those providing on-chain and mixed services, we explain it in some detail in [4.3.11](#4-3-11-get-methods-of-smart-contracts).