diff --git a/docs/develop/dapps/asset-processing/README.md b/docs/develop/dapps/asset-processing/README.md index 81db35a1fd..bb9f108911 100644 --- a/docs/develop/dapps/asset-processing/README.md +++ b/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 @@ -317,6 +323,60 @@ if __name__ == "__main__": + +### 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) @@ -510,9 +570,6 @@ if __name__ == "__main__": -- **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__": -- **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) diff --git a/docs/develop/dapps/asset-processing/jettons.md b/docs/develop/dapps/asset-processing/jettons.md index 711cb52c91..1864b2044c 100644 --- a/docs/develop/dapps/asset-processing/jettons.md +++ b/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 diff --git a/docs/develop/dapps/asset-processing/mass-mint-tools.mdx b/docs/develop/dapps/asset-processing/mass-mint-tools.mdx new file mode 100644 index 0000000000..a32be3be05 --- /dev/null +++ b/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 diff --git a/docs/develop/dapps/asset-processing/mintless-jettons.mdx b/docs/develop/dapps/asset-processing/mintless-jettons.mdx new file mode 100644 index 0000000000..254102dc44 --- /dev/null +++ b/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 +``` +This utility will print the mintless Merkle dump cell hash and store to `` the list of all airdrops in `
` 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 ` 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 +``` +- 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) \ No newline at end of file diff --git a/docs/participate/network-maintenance/nominator-pool.mdx b/docs/participate/network-maintenance/nominator-pool.mdx index 48b3a65a3f..fe2b4d5724 100644 --- a/docs/participate/network-maintenance/nominator-pool.mdx +++ b/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. diff --git a/docs/participate/network-maintenance/staking-incentives.md b/docs/participate/network-maintenance/staking-incentives.md index a1ed4cd65d..43870f437e 100644 --- a/docs/participate/network-maintenance/staking-incentives.md +++ b/docs/participate/network-maintenance/staking-incentives.md @@ -90,8 +90,61 @@ On TON, slashing penalties (fines given to validators) allow any network partici Upon reaching 66% validator approval (measured by an equal voting weight), a slashing penalty is deducted from the validator and withdrawn from the validator’s total stake. The validation process for penalization and complaint resolution is typically conducted automatically using the MyTonCtrl. +## Decentralized System of Penalties + +:::info +The following system of penalising poorly performing validators fully operational September 9, 2024. +::: + +### Determination of Poor Work + +The TON is supplied with the [lite-client](https://github.com/newton-blockchain/ton/tree/master/lite-client) utility. In lite-client there is a `checkloadall` command. +This command analyses how many blocks the validator should have processed, and how many it actually processed in a given period of time. + +If the validator processed less than 90% of the expected number of blocks during a validation round, it is considered to be performing poorly and should be penalised. +:::info +Learn more about technical description of the process [here](https://github.com/ton-blockchain/TIPs/issues/13#issuecomment-786627474) +::: +### Complain Workflow + +- Anyone can make complain and get reward on right complain. +- Validation of complain maintain by Validators and fully decentralized. + +#### Make Complain + +After each validation round (~18 hours), the validator stakes of validators that participated in that round are on the Elector smart contract for another ~9 hours. +During this time, anyone can send a complaint against a validator who performed poorly in said round. This happens on-chain on the Elector smart contract. + +#### Validation of Complaint + +After each validation round, validators receive a list of complaints from the Elector smart contract and double-check them by calling `checkloadall`. +In case the complaint is validated, they on-chain vote in favour of that complaint. + +These actions are built into `mytonctrl` and happen automatically. +If the complaint has 66% of the validators' votes (by their weight), a penalty is taken off from the validator's stake. +There is no way for anyone to single-handedly fine anyone. + +[@tonstatus_notifications](https://t.me/tonstatus_notifications) - list of penalised validators each round. + + +### Fine Value + +The amount of the fine is fixed and equals 101 TON(Network Parameter `ConfigParam40:MisbehaviourPunishmentConfig`), which is roughly equal to the validator's income per round. + +Value of fine may change, due the audience and the number of transactions in TON is growing rapidly and it is vital that the quality of work is at its best. + +### Fine Distribution + +The fine is distributed among the validators minus network costs and a small reward (~8 TON) to the first complainer who sent the correct complaint to the Elector. + +### Validator Guidelines + +To prevent your Validator node from being fined, it is advisable to ensure that the hardware, monitoring, and validator operations are set up properly. +Please make sure you're complying with the [validator maintain guidelines](/participate/run-nodes/become-validator#maintain-guidelines). +If you don't want to do this please consider using staking services https://ton.org/stake. + ## See Also -* [Running a Full Node (Validator)](/participate/run-nodes/full-node) +* [Running a Validator](/participate/run-nodes/become-validator) * [Transaction Fees](/develop/smart-contracts/fees) * [What is blockchain? What is a smart contract? What is gas?](https://blog.ton.org/what-is-blockchain) \ No newline at end of file diff --git a/docs/participate/run-nodes/archive-node.md b/docs/participate/run-nodes/archive-node.md index 70cfd48a5a..82c03c949c 100644 --- a/docs/participate/run-nodes/archive-node.md +++ b/docs/participate/run-nodes/archive-node.md @@ -212,6 +212,11 @@ To force node not to store archive blocks use the value 86400. Check [set_node_a installer set_node_argument --archive-ttl 86400 ``` + +## Support + +Contact technical support with [@mytonctrl_help](https://t.me/mytonctrl_help). + ## See Also * [TON Node Types](/participate/nodes/node-types) diff --git a/docs/participate/run-nodes/become-validator.md b/docs/participate/run-nodes/become-validator.md index 21ac873e05..3d96fec215 100644 --- a/docs/participate/run-nodes/become-validator.md +++ b/docs/participate/run-nodes/become-validator.md @@ -1,9 +1,43 @@ # Validator Node + +## Minimal Hardware Requirements + +- 16 cores CPU +- 128 GB RAM +- 1TB NVME SSD _OR_ Provisioned 64+k IOPS storage +- 1 Gbit/s network connectivity +- public IP address (_fixed IP address_) +- 16 TB/month traffic on peak load + +> Typically you'll need at least a 1 Gbit/s connection to reliably accommodate peak loads (the average load is expected to be approximately 100 Mbit/s). + +> We draw special attention of validators to IOPS disk requirements, it is crucially important for smooth network operation. + +## Port Forwarding + +All types of nodes require a static external IP address, one UDP port to be forwarded for incoming connections and all outgoing connections to be open - the node uses random ports for new outgoing connections. It's necessarily for the node to be visible to the outside world over the NAT. + +It can be done with your network provider or [rent a server](/participate/run-nodes/full-node#recommended-providers) to run a node. + :::info -Read about [Full Node](/participate/run-nodes/full-node) before this article +It's possible to find out which UDP port is opened from the `netstat -tulpn` command. ::: + +## Prerequisite + +### Learn Slashing Policy + +If the validator processed less than 90% of the expected number of blocks during a validation round, this Validator will be fined by 101 TON. +Read more about [slashing policy](/participate/network-maintenance/staking-incentives#decentralized-system-of-penalties). + + +### Run a Fullnode +Launch [Full Node](/participate/run-nodes/full-node) before follow this article. + + + Check that validator mode is enabled using `status_modes` command. If it's not, refer [mytonctrl enable_mode command](/participate/run-nodes/mytonctrl#enable_mode). ## View the List of Wallets @@ -53,4 +87,89 @@ set stake 50000 `set stake 50000` — this sets the stake size to 50k coins. If the bet is accepted and our node becomes a validator, the bet can only be withdrawn in the second election (according to the rules of the electorate). -![setting stake](/img/docs/nodes-validator/manual-ubuntu_mytonctrl-set_ru.png) \ No newline at end of file +![setting stake](/img/docs/nodes-validator/manual-ubuntu_mytonctrl-set_ru.png) + +## Maintain Guidelines + +:::caution Slashing of Poor Validators +If the validator processed less than 90% of the expected number of blocks during a validation round, this Validator will be fined by 101 TON. + +Read more about [slashing policy](/participate/network-maintenance/staking-incentives#decentralized-system-of-penalties). +::: + + +As a TON Validators, make sure you are follow these crucial steps to ensure network stability and to avoid slashing penalties in the future. + +Essential Actions: + +1. Follow the [@tonstatus](https://t.me/tonstatus) turn on notifications and be ready to apply urgent updates if necessary. +2. Ensure your hardware meets or exceeds [minimal system requirements](/participate/run-nodes/become-validator#minimal-hardware-requirements). +3. We imperatively request you to use [mytonctrl](https://github.com/ton-blockchain/mytonctrl). + - In `mytonctrl` keep update due the notification and enable telemetry: `set sendTelemetry true` +4. Set up monitoring dashboards for RAM, Disk, Network, and CPU usage. For technical assistance, contact @mytonctrl_help_bot. +5. Monitor the efficiency of your validator with dashboards. + - Check with `mytonctrl` via `check_ef`. + - [Build dashboard with APIs](/participate/run-nodes/become-validator#validation-and-effectiveness-apis). + +:::info +`mytonctrl` allows to check effectiveness of validators via command `check_ef` which outputs your validator efficiency data for the last round and for current round. +This command retrieves data by calling `checkloadall` utility. +Ensure, that your efficiency is greater than 90% (for the full round period). +::: + +:::info +In case of low efficiency - take action to fix the problem. Contact technical support [@mytonctrl_help_bot](https://t.me/mytonctrl_help_bot) if necessary. +::: + + +## Validation and Effectiveness APIs + +:::info +Please set up dashboards to monitor your validators using these APIs. +::: + +#### Penalised Validators Tracker + +You can track penalised validators on each round with [@tonstatus_notifications](https://t.me/tonstatus_notifications). + +#### Validation API +https://elections.toncenter.com/docs - use this API to get information about current and past validation rounds (cycles) - time of rounds, which validators participated in them, their stakes, etc. + +Information on current and past elections (for the validation round) is also available. + +#### Effieciency API + +https://toncenter.com/api/qos/index.html#/ - use this API to get information on the efficiency of validators over time. + +This API analyses the information from the catchain and builds an estimate of the validator's efficiency. This API does not use the checkloadall utility, but is its alternative. +Unlike `checkloadall` which works only on validation rounds, in this API you can set any time interval to analyse the validator's efficiency. + +Workflow: + +1. Pass ADNL address of your validator and time interval (`from_ts`, `to_ts`) to API. For accurate result it makes sense to take a sufficient interval, for example from 18 hours ago the current moment. + +2. Retrieve the result. If your efficiency percentage field is less than 80%, your validator is not working properly. + +3. It is important that your validator participates in validation and has the same ADNL address throughout the specified time period. + +For example, if a validator participates in validation every second round - then you need to specify only those intervals when he participated in validation. Otherwise, you will get an incorrect underestimate. + +It works not only for Masterchain validators (with index < 100) but also for other validators (with index > 100). + + + + + +## Support + +Contact technical support [@mytonctrl_help_bot](https://t.me/mytonctrl_help_bot). This bot for validators only and will not assist on questions for regular nodes. + +If you have a regular node, then contact the group: [@mytonctrl_help](https://t.me/mytonctrl_help). + + +## See Also + +* [Run a Full Node](/participate/run-nodes/full-node) +* [Troubleshooting](/participate/run-nodes/nodes-troubleshooting) +* [Staking Incentives](/participate/network-maintenance/staking-incentives) + diff --git a/docs/participate/run-nodes/full-node.mdx b/docs/participate/run-nodes/full-node.mdx index 264366ff2f..e2dac8e6b2 100644 --- a/docs/participate/run-nodes/full-node.mdx +++ b/docs/participate/run-nodes/full-node.mdx @@ -204,3 +204,7 @@ Check the node logs upon failure: ```bash tail -f /var/ton-work/log.thread* ``` + +## Support + +Contact technical support with [@mytonctrl_help](https://t.me/mytonctrl_help). \ No newline at end of file diff --git a/sidebars.js b/sidebars.js index 8550f3066f..823d2ffbd1 100644 --- a/sidebars.js +++ b/sidebars.js @@ -368,6 +368,8 @@ const sidebars = { 'develop/dapps/asset-processing/overview', 'develop/dapps/asset-processing/README', 'develop/dapps/asset-processing/jettons', + 'develop/dapps/asset-processing/mintless-jettons', + 'develop/dapps/asset-processing/mass-mint-tools', 'develop/dapps/asset-processing/usdt', 'develop/dapps/asset-processing/nfts', 'develop/dapps/asset-processing/metadata',