nodes_documentation_fine_update (#762)

* nodes_documentation_fine_update

* added_wallet_deployment_for_each_shard

* added_mintless_jettons

* beauty_fixes

* beauty_fixes_2

docs/develop/dapps/asset-processing/README.md

@@ -3,7 +3,7 @@ import Button from '@site/src/components/button'
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-# Payments processing
+# Payments Processing
 
 This page **explains how to process** (send and accept) `digital assets` on the TON blockchain.
 It **mostly** describes how to work with `TON coins`, but **theoretical part** is **important** even if you want to process only `jettons`.
@@ -169,6 +169,10 @@ main();
 
 ### Send payments
 
+:::tip
+Learn on basic example of payments processing from [TMA USDT Payments demo](https://github.com/ton-community/tma-usdt-payments-demo)
+:::
+
 1. Service should deploy a `wallet` and keep it funded to prevent contract destruction due to storage fees. Note that storage fees are generally less than 1 Toncoin per year.
 2. Service should get from the user `destination_address` and optional `comment`. Note that for the meantime, we recommend either prohibiting unfinished outgoing payments with the same (`destination_address`, `value`, `comment`) set or proper scheduling of those payments; that way, the next payment is initiated only after the previous one is confirmed.
 3. Form [msg.dataText](https://github.com/ton-blockchain/ton/blob/master/tl/generate/scheme/tonlib_api.tl#L103) with `comment` as text.
@@ -200,6 +204,8 @@ To calculate the **incoming message value** that the message brings to the contr
 
 Anyway, in general, the amount that a message brings to the contract can be calculated as the value of the incoming message minus the sum of the values of the outgoing messages minus the fee: `value_{in_msg} - SUM(value_{out_msg}) - fee`. Technically, transaction representation contains three different fields with `fee` in name: `fee`, `storage_fee`, and `other_fee`, that is, a total fee, a part of the fee related to storage costs, and a part of the fee related to transaction processing. Only the first one should be used.
 
+
+
 ### Invoices with TON Connect
 
 Best suited for dApps that need to sign multiple payments/transactions within a session or need to maintain a connection to the wallet for some time.
@@ -266,7 +272,7 @@ More about transactions and messages hashes [here](/develop/dapps/cookbook#how-t
 
 ## Best Practices
 
-### Wallet creation
+### Wallet Creation
 
 <Tabs groupId="example-create_wallet">
 <TabItem value="JS" label="JS">
@@ -317,6 +323,60 @@ if __name__ == "__main__":
 
 </Tabs>
 
+
+### Wallet Creation for Different Shards
+
+When under heavy load, the TON blockchain may split into [shards](/develop/blockchain/shards). A simple analogy for a shard in the Web3 world would be a network segment.
+
+Just as we distribute service infrastructure in the Web2 world to be as close as possible to the end user, in TON, we can deploy contracts to be in the same shard as the user's wallet or any other contract that interacts with it.
+
+For instance, a DApp that collects fees from users for a future airdrop service might prepare separate wallets for each shard to enhance the user experience on peak load days. To achieve the highest processing speed, you will need to deploy one collector wallet per shard.
+
+Shard prefix `SHARD_INDEX` of a contract is defined by the first 4 bits of it's address hash.
+In order to deploy wallet into specific shard, one may use logic based on the following code snippet:
+
+```javascript
+
+import { NetworkProvider, sleep } from '@ton/blueprint';
+import { Address, toNano } from "@ton/core";
+import {mnemonicNew, mnemonicToPrivateKey} from '@ton/crypto';
+import { WalletContractV3R2 } from '@ton/ton';
+
+export async function run(provider?: NetworkProvider) {
+  if(!process.env.SHARD_INDEX) {
+    throw new Error("Shard index is not specified");
+  }
+
+    const shardIdx = Number(process.env.SHARD_INDEX);
+    let testWallet: WalletContractV3R2;
+    let mnemonic:  string[];
+    do {
+        mnemonic   = await mnemonicNew(24);
+        const keyPair = await mnemonicToPrivateKey(mnemonic);
+        testWallet = WalletContractV3R2.create({workchain: 0, publicKey: keyPair.publicKey});
+    } while(testWallet.address.hash[0] >> 4 !== shardIdx);
+
+    console.log("Mnemonic for shard found:", mnemonic);
+    console.log("Wallet address:",testWallet.address.toRawString());
+}
+
+if(require.main === module) {
+run();
+}
+
+```
+In case of wallet contract, one may use `subwalletId` instead of mnemonic, however `subwalletId` is not supported by [wallet applications](https://ton.org/wallets).
+
+Once deployment have completed, you can process with the following algorithm:
+
+1. User arrives at DApp page and requests action.
+2. DApp picks the closest wallet to the user(matching by 4 bit prefix)
+3. DApp provides user payload sending his fee to the picked wallet.
+
+That way you will be able to provide the best possible user experience regardless current network load.
+
+
+
 ### Toncoin Deposits (Get toncoins)
 
 <Tabs groupId="example-toncoin_deposit">
@@ -510,9 +570,6 @@ if __name__ == "__main__":
 
 <TabItem value="Python" label="Python">
 
-- **psylopunk/pythonlib:**
-  - [Withdraw Toncoins from a wallet](https://github.com/psylopunk/pytonlib/blob/main/examples/transactions.py)
-
 - **yungwine/pytoniq:**
 
 ```python
@@ -565,9 +622,6 @@ if __name__ == "__main__":
 
 <TabItem value="Python" label="Python">
 
-- **psylopunk/pythonlib:**
-  - [Get transactions](https://github.com/psylopunk/pytonlib/blob/main/examples/transactions.py)
-  
 - **yungwine/pytoniq:**
   - [Get transactions](https://github.com/yungwine/pytoniq/blob/master/examples/transactions.py)
 

docs/develop/dapps/asset-processing/jettons.md

@@ -2,13 +2,13 @@ import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 import Button from '@site/src/components/button';
 
-# TON Jetton processing
+# Jetton Processing
 
 :::info
 For clear understanding, the reader should be familiar with the basic principles of asset processing described in [payments processing section](/develop/dapps/asset-processing/) of our documentation.
 :::
 
-Jettons are tokens on TON Blockchain - one can consider them similarly to ERC-20 tokens on Ethereum.
+Jettons are tokens on TON Blockchain - one can consider them similarly to ERC-20 tokens on Ethereum was set in TON with [TEP-74](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md).
 
 In this analysis, we take a deeper dive into the formal standards detailing jetton [behavior](https://github.com/ton-blockchain/TEPs/blob/master/text/0074-jettons-standard.md) and [metadata](https://github.com/ton-blockchain/TEPs/blob/master/text/0064-token-data-standard.md).
 A less formal sharding-focused overview of jetton architecture can be found in our

docs/develop/dapps/asset-processing/mass-mint-tools.mdx

@@ -0,0 +1,46 @@
+# Mass Minting Tools
+
+In an era of launching major on-chain projects with millions of users, peak loads can lead to issues in user experience across the entire TON Ecosystem.
+
+To prevent this situation and ensure a smooth launch, we suggest using a provided on this page high-load distribution system.
+
+## Mass Sender
+
+:::info
+Recommended approach for token airdrops in September
+battle-tested on Notcoin, DOGS
+:::
+
+Access: [Masse Sender](https://docs.tonconsole.com/tonconsole/jettons/mass-sending)
+
+Specification:
+- Direct distribution of tokens, the project spends money on gas during claims
+- Low network load (latest versions are optimized)
+- Self-regulation of load (slows down distribution if there's too much activity on the network)
+
+## Mintless Jettons
+
+Access: [Mintless Jettons](/develop/dapps/asset-processing/mintless-jettons)
+
+:::caution
+  Currently being tested on HAMSTER
+  Work In Progress
+:::
+
+Specification:
+- Users claim airdrop tokens without transactions
+- Projects don't earn from claims
+- Minimal network load
+
+
+### TokenTable v4
+
+:::info
+  battle-tested on Avacoin, DOGS
+:::
+
+Access: [www.tokentable.xyz](https://www.tokentable.xyz/)
+
+- Higher network load than mass sender, users make transactions when claiming
+- Projects can also earn from user claims
+- Projects pay TokenTable for setup

docs/develop/dapps/asset-processing/mintless-jettons.mdx

@@ -0,0 +1,171 @@
+# Mintless Jettons Processing
+
+## Introduction
+
+:::info
+For clear understanding, the reader should be familiar with the basic principles of asset processing described in [payments processing section](/develop/dapps/asset-processing/) and [jetton processing](/develop/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).
+
+This extension enables decentralized, [Merkle-proof](/develop/data-formats/exotic-cells#merkle-proof) airdrops without the need for traditional minting processes.
+
+## Overview
+
+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.
+
+### 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!
+
+## Supporting Mintless Jettons in On-Chain Protocols
+
+Since Mintless Jettons are an extension of Standard Jettons, no additional steps are needed. Just interact with them as you would with USDT, NOT, Scale, or STON.
+
+## Supporting Mintless Jettons in Wallet Applications
+
+Wallet applications play a crucial role in enhancing user experience with Mintless Jettons:
+
+- **Display Unclaimed Jettons**: Wallets should show users the jettons they are eligible to claim based on the Merkle tree data.
+- **Automated Claim Process**: On initiating an outgoing transfer, the wallet should automatically include the necessary Merkle proof in the `transfer` message's custom payload.
+
+This can be done by either:
+
+- Integration with the Off-Chain API Specified in the [Custom Payload API](https://github.com/ton-blockchain/TEPs/blob/master/text/0000-jetton-offchain-payloads.md)**:
+  - For each jetton, check whether it is mintless.
+  - If it is mintless, check whether the owner of the wallet has claimed it.
+  - If not claimed, retrieve data from the Custom Payload API and add the off-chain balance to the on-chain one.
+  - On outgoing transfers, if the user has not yet claimed the airdrop, retrieve the custom payload and init state from the Custom Payload API and include it in the `transfer` message to the jetton wallet.
+
+- Custom API:
+  - Download the tree of airdrops from `mintless_merkle_dump_uri` in the jetton metadata.
+  - Parse it (see section 6 below) and make the parsed result available via API.
+
+:::info
+Supporting Mintless claims (in particular, indexing of airdrop trees) is not mandatory for wallets. It is expected that wallet applications may charge the jetton issuer for this service.
+:::
+## Supporting Mintless Jettons in dApps (DEX/Lending Platforms)
+
+Since the claim happens automatically in wallet applications, dApps don't need any specific logic. They may use APIs (like Tonapi or Toncenter) that show unclaimed balances.
+
+To enhance the user experience, dApps can check whether the wallet application that the user used to connect to the dApp supports the specific mintless jetton. If it is not supported, the dApp can retrieve the airdrop proof and initialization data from the jetton API and add it to the `transfer` message on the dApp side.
+
+## Deploy a Mintless Jetton
+
+Deploying a Mintless Jetton involves several steps:
+
+1. Prepare the Merkle Tree:
+  - Generate a Merkle tree containing all the airdrop recipients and their respective amounts.
+  - Compute the root `merkle_hash`.
+
+2. Deploy the Jetton Master Contract:
+  - Include the `merkle_hash` in the contract's storage.
+  - Ensure the contract complies with the extended Jetton standard; you may use the [Mintless Jetton Standard Implementation](https://github.com/ton-community/mintless-jetton) as an example.
+
+3. Provide the Merkle Proofs:
+  - Host the Merkle tree data off-chain.
+  - Implement the Custom Payload API to allow wallets to fetch the necessary proofs.
+
+4. Update Metadata:
+  - Add the `mintless_merkle_dump_uri` and `custom_payload_api_uri` to the token's metadata as per the [Metadata Standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0064-token-data-standard.md).
+
+5. Request Support from Wallets:
+  - Ask desired wallet applications to support (index) your Mintless Jetton.
+
+By following these steps, you can deploy a Mintless Jetton that users can seamlessly claim during usual operations.
+
+## Retrieving Airdrop Information
+
+Auditing the airdrop and verifying the total supply consists of a few steps.
+
+### Accessing the Merkle Dump
+- Start by downloading the Merkle tree data from the `mintless_merkle_dump_uri` provided in the metadata. It can be stored in TON Storage, IPFS, a web 2.0 resource, or other ways. This file contains `HashMap{address -> airdrop_data}` as a BoC file. The `airdrop_data` includes the amount, Unix timestamp from which the claim is available (`start_from`), and Unix timestamp when the claim is closed (`expired_at`).
+
+### Checking Integrity
+- This can be done by comparing the mintless Merkle dump cell hash with the hash stored in the jetton minter (the latter can be retrieved on-chain via the `get_mintless_airdrop_hashmap_root` get-method of the minter contract).
+
+### Verifying Balances
+- Use the Merkle tree to verify individual balances and ensure they sum up to the expected total supply.
+
+## Tooling
+
+There are a few utilities that can be used for the steps described above.
+
+### mintless-proof-generator (from Core)
+
+1. **Compile the Utility**:
+
+```bash
+git clone https://github.com/ton-blockchain/ton
+```
+
+```bash
+cd ton
+```
+
+```bash
+git checkout testnet
+```
+
+```bash
+mkdir build && cd build
+```
+
+```bash
+cmake ../
+```
+
+```bash
+make mintless-proof-generator
+```
+
+- The compiled file is stored as `build/crypto/mintless-proof-generator`.
+
+2. **Run a Check**:
+
+```bash
+build/crypto/mintless-proof-generator parse <input-boc> <output-file>
+```
+This utility will print the mintless Merkle dump cell hash and store to `<output-file>` the list of all airdrops in `<address> <amount> <start_from> <expired_at>` format (one airdrop per line).
+
+You can additionally generate all Merkle proofs (needed for `custom_payload_api_uri`) via the `mintless-proof-generator make_all_proofs <input-boc> <output-file>` command.
+
+### mintless-toolbox (from Tonkeeper)
+
+1. **Compile the Utility**:
+```bash
+git clone https://github.com/tonkeeper/mintless-toolbox.git
+```
+
+```bash
+cd mintless-toolbox
+```
+
+```bash
+make
+```
+
+2. **Run a Check**:
+
+```bash
+./bin/mintless-cli dump <airdrop-filename>
+```
+- This utility reads an airdrop file and dumps it to the console in the format `address,amount,start_from,expire_at`.
+
+By auditing the Merkle tree and contract data, stakeholders can verify the integrity of the airdrop and token supply.
+
+## Conclusion
+
+Mintless Jettons offer an efficient and scalable solution for large-scale token airdrops on the TON blockchain. By extending the standard Jetton implementation, they reduce costs and blockchain load while maintaining security and decentralization. Supporting Mintless Jettons across smart contracts, wallet applications, and dApps ensures a seamless experience for users and fosters wider adoption. Deploying and auditing Mintless Jettons involves careful implementation of Merkle trees and adherence to the extended standards, contributing to a robust and transparent token ecosystem.
+
+
+## See Also
+
+- [Understanding Mintless Jettons: A Comprehensive Guide](https://gist.github.com/EmelyanenkoK/bfe633bdf8e22ca92a5138e59134988f) - original post.
+- [Mintless Jetton Standard Implementation](https://github.com/ton-community/mintless-jetton)
+- [Jetton Offchain Payloads TEP](https://github.com/ton-blockchain/TEPs/blob/master/text/0000-jetton-offchain-payloads.md)
+- [Jetton Metadata Standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0064-token-data-standard.md)

docs/participate/network-maintenance/nominator-pool.mdx

@@ -2,7 +2,7 @@
 
 ## Running the Validator in Nominator Pool Mode
 
-1. Set up the hardware for the validator - you will need 8 vCPUs, 64GB memory, 1TB SSD, a fixed IP address, and 1Gb/s internet speed.
+1. Set up the hardware for the validator - you will need 8 vCPUs, 128GB memory, 1TB SSD, a fixed IP address, and 1Gb/s internet speed.
 
    For maintaining network stability, it's recommended to distribute validator nodes in different geographical locations worldwide rather than concentrating them in a single data center. You can use [this site](https://status.toncenter.com/) to assess the load of various locations. The map indicates high data center utilization in Europe, especially in Finland, Germany, and Paris. Therefore, using providers such as Hetzner and OVH is not recommended.