diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3be6063258..e389331bce 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,4 +5,4 @@ ### Thank you for your interest in contributing! -Please see [our contributing guide on documentation](https://docs.ton.org/contribute/) for the latest information on how to contribute! \ No newline at end of file +Please see [our contributing guide on documentation](/v3/contribute/) for the latest information on how to contribute! diff --git a/README.md b/README.md index d21a549a27..875d5e629a 100644 --- a/README.md +++ b/README.md @@ -36,7 +36,7 @@ If you are a developer and faced some difficulties, successfully overcoming them — Have an idea? [Submit a Feature Request](https://github.com/ton-community/ton-docs/issues/new/choose). — Want to contribute? [Setup your environment](https://github.com/ton-community/ton-docs#set-up-your-environment-%EF%B8%8F). -Contributing best practices: [docs/contribute](https://ton.org/docs/v3/contribute) +Contributing best practices: [docs/contribute](/v3/contribute) --- diff --git a/docs/learn/overviews/addresses.md~upstream_staging b/docs/learn/overviews/addresses.md~upstream_staging deleted file mode 100644 index 5557a198af..0000000000 --- a/docs/learn/overviews/addresses.md~upstream_staging +++ /dev/null @@ -1,224 +0,0 @@ -# Smart Contract Addresses Documentation - -This section will describe the specifics of smart contract addresses on TON Blockchain. It will also explain how actors are synonymous with smart contracts on TON. - -## Everything is a Smart Contract - -On TON, smart contracts are built using the [Actor model](/learn/overviews/ton-blockchain#single-actor). In fact, actors in TON are technically represented as smart contracts. This means that even your wallet is a simple actor (and a smart contract). - -Typically, actors process incoming messages, change their internal state, and generate outbound messages as a result. That's why every actor (i.e., smart contract) on TON Blockchain must have an address, so it is able to receive messages from other actors. - -:::info EVM EXPERIENCE -On the Ethereum Virtual Machine (EVM), addresses are completely separate from smart contracts. Feel free to learn more about the differences by reading our article ["Six unique aspects of TON Blockchain that will surprise Solidity developers"](https://blog.ton.org/six-unique-aspects-of-ton-blockchain-that-will-surprise-solidity-developers) by Tal Kol. -::: - -## Address of Smart Contract - -Smart contract addresses operating on TON typically consist of two main components: - -* **(workchain_id)**: denotes the workchain ID (a signed 32-bit integer) - -* **(account_id)** denotes the address of the account (64-512 bits, depending on the workchain) - -In the raw address overview section of this documentation, we'll discuss how **(workchain_id, account_id)** pairs present themselves. - -### Workchain ID and Account ID - -#### Workchain ID - -[As we've seen before](/learn/overviews/ton-blockchain#workchain-blockchain-with-your-own-rules), it is possible to create as many as `2^32` workchains operating on TON Blockchain. We also noted how 32-bit prefix smart contract addresses identify and are linked to smart contract addresses within different workchains. This allows smart contracts to send and receive messages to and from different workchains on TON Blockchain. - -Nowadays, only the Masterchain (workchain_id=-1) and occasionally the basic workchain (workchain_id=0) are running in TON Blockchain. - -Both of them have 256-bit addresses, therefore, we assume that the workchain_id is either 0 or -1, and the address within the workchain is precisely 256 bits. - -#### Account ID - -All account IDs on TON make use of 256-bit addresses on the Masterchain and Basechain (or basic workchain). - -In fact, Account ID’s **(account_id)** defined as hash functions for smart contract objects (particular, the SHA-256). Every smart contract operating on TON Blockchain stores two main components. These include: - -1. _Compiled code_. Logic of the smart contract compiled in the form of bytecode. -2. _Initial state_. The contract's values at the moment of its deployment on-chain. - - -Finally, to accurately derive the contract's address, it is necessary to calculate the hash corresponding to the pair **(Initial code, Initial state)** object. At this time, we won't take a deep dive into how the [TVM](/learn/tvm-instructions/tvm-overview) works, but it's important to understand that account IDs on TON are determined using this formula: -: -**account_id = hash(initial code, initial state)** - -In time, throughout this documentation, we'll dive deeper into the technical specifications and overview of the TVM and TL-B scheme. Now that we are familiar with the generation of the **account_id** and their interaction with smart contract addresses on TON, let’s explain Raw and User-Friendly addresses. - -## Addresses state - -Each address can be in one of possible states: - -- `nonexist` - there were no accepted transactions on this address, so it doesn't have any data (or the contract was deleted). We can say that initially all 2256 address are in this state. -- `uninit` - address has some data, which contains balance and meta info. At this state address doesn't have any smart contract code/persistent data yet. An address enters this state, for example, when it was nonexist and some other address sent some tokens to it. -- `active` - address has smart contract code, persistent data and balance. At this state it can perform some logic during the transaction and change its persistent data. An address enters this state when it was `uninit` and there was an incoming message with state_init param (note, that to be able to deploy this address, hash of `state_init` and `code` must be equal to address). -- `frozen` - address cannot perform any operations, this state contains only two hashes of the previous state (code and state cells respectively). When an address's storage charge exceeds its balance, it goes into this state. To unfreeze it, you can send an internal message with `state_init` and `code` which store the hashes described earlier and some Toncoin. It can be difficult to recover it, so you should not allow this situation. There is a project to unfreeze the address, which you can find [here](https://unfreezer.ton.org/). - -## Raw and User-Friendly Addresses - -After providing a brief overview of how smart contract addresses on TON leverage workchains and account IDs (for the Masterchain and Basechain specifically), it is important to understand that these addresses are expressed in two main formats: - -* **Raw addresses**: Original full representation of smart contract addresses. -* **User-friendly addresses**: User-friendly addresses are an enhanced format of raw address that employ better security and ease of use. - -Below, we’ll explain more about the differences between these two address types and dive deeper into why user-friendly addresses are used on TON. - -### Raw address - -Raw smart contract addresses consist of a workchain ID and account ID *(workchain_id, account_id)* and are displayed in the following format: - -* [decimal workchain_id\]:[64 hexadecimal digits with account_id\] - - -Provided below, is an example of a raw smart contract address using a workchain ID and account ID together (expressed as **workchain_id** and **account_id**): - -`-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260` - -Notice the `-1` at the start of the address string, which denotes a _workchain_id_ that belongs to the Masterchain. - -:::note -Uppercase letters (such as 'A', ‘B’, ‘C’, ‘D’ etc.) may be used in address strings instead of their lower-case counterparts (such as 'a', ‘b’, ’c’ 'd' etc.). -::: - -#### Issues With Raw Addresses - -Using the Raw Address form presents two main issues: - -1. When using the raw address format, it's not possible to verify addresses to eliminate errors prior to sending a transaction. - This means that if you accidentally add or remove characters in the address string prior to sending the transaction, your transaction will be sent to the wrong destination, resulting in loss of funds. -2. When using the raw address format, it's impossible to add special flags like those used when sending transactions that employ user-friendly addresses. - To help you better understand this concept, we’ll explain which flags can be used below. - -### User-Friendly Address - -User-friendly addresses were developed to secure and simplify the experience for TON users who share addresses on the internet (for example, on public messaging platforms or via their email service providers), as well as in the real world. - -#### User-Friendly Address Structure - -User-friendly addresses are made up of 36 bytes in total and are obtained by generating the following components in order: - -1. _[flags - 1 byte]_ — Flags that are pinned to addresses change the way smart contracts react to the received message. - Flags types that employ the user-friendly address format include: - - - isBounceable. Denotes a bounceable or non-bounceable address type. (_0x11_ for "bounceable", _0x51_ for "non-bounceable") - - isTestnetOnly. Denotes an address type used for testnet purposes only. Addresses beginning with _0x80_ should not be accepted by software running on the production network - - isUrlSafe. Denotes a deprecated flag that is defined as URL-safe for an address. All addresses are then considered URL-safe. -2. _\[workchain_id - 1 byte]_ — The workchain ID (_workchain_id_) is defined by a signed 8-bit integer _workchain_id_. -(_0x00_ for the BaseChain, _0xff_ for the MasterChain) -3. _\[account_id - 32 byte]_ — The account ID is made up of a ([big-endian](https://www.freecodecamp.org/news/what-is-endianness-big-endian-vs-little-endian/)) 256-bit address in the workchain. -4. _\[address verification - 2 bytes]_ — In user-friendly addresses, address verification is composed of a CRC16-CCITT signature from the previous 34 bytes. ([Example](https://github.com/andreypfau/ton-kotlin/blob/ce9595ec9e2ad0eb311351c8a270ef1bd2f4363e/ton-kotlin-crypto/common/src/crc32.kt)) - In fact, the idea pertaining to verification for user-friendly addresses is quite similar to the [Luhn algorithm](https://en.wikipedia.org/wiki/Luhn_algorithm), which is used on all credit cards to prevent users from entering non-existing card numbers by mistake. - -The addition of these 4 main components means that: `1 + 1 + 32 + 2 = 36` bytes in total (per user-friendly address). - -To generate a user-friendly address, the developer must encode all 36 bytes using either: -- _base64_ (i.e., with digits, upper and lowercase Latin letters, '/' and '+') -- _base64url_ (with '_' and '-' instead of '/' and '+') - -After this process is complete, the generation of a user-friendly address with a length of 48 non-spaced characters is finalized. - -:::info DNS ADDRESS FLAGS -On TON, DNS addresses such as mywallet.ton are sometimes used instead of raw and user-friendly addresses. In fact, DNS addresses are made up of user-friendly addresses and include all the required flags that allow developers to access all the flags from the DNS record within the TON domain. -::: - -#### User-Friendly Address Encoding Examples - -For example, the "test giver" smart contract (a special smart contract residing in the testnet masterchain that sends 2 test tokens to anyone who requests them) makes use of the following raw address: - -`-1:fcb91a3a3816d0f7b8c2c76108b8a9bc5a6b7a55bd79f8ab101c52db29232260` - -The above "test giver" raw address must be converted into the user-friendly address form. This is obtained using either the base64 or base64url forms (that we introduced previously) as follows: - -* `kf/8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15+KsQHFLbKSMiYIny` (base64) -* `kf_8uRo6OBbQ97jCx2EIuKm8Wmt6Vb15-KsQHFLbKSMiYIny` (base64url) - -:::info -Notice that both forms (_base64_ and _base64url_) are valid and must be accepted! -::: - -#### Bounceable vs Non-Bounceable Addresses - -The core idea behind the bounceable address flag is sender's funds security. - -For example, if the destination smart contract does not exist, or if some issue happens during the transaction, the message will be "bounced" back to the sender and constitute the remainder of the original value of the transaction (minus all transfer and gas fees). This ensures the sender doesn't lose their funds that were sent by accident to an address that cannot accept the transaction. - -In relation to bounceable addresses specifically: - -1. The **bounceable=false** flag generally means the receiver is a wallet. -2. The **bounceable=true** flag typically denotes a custom smart contract with its own application logic (for example, a DEX). In this example, non-bounceable messages should not be sent because of security reasons. - -Feel free to read more on this topic in our documentation to gain a better understanding of [non-bounceable messages](/develop/smart-contracts/guidelines/non-bouncable-messages). - -#### Armored base64 Representations - -Additional binary data related to TON Blockchain employs similar "armored" base64 user-friendly address representations. These differentiate from one another depending on the first 4 characters of their byte tag. For example, 256-bit Ed25519 public keys are represented by first creating a 36-byte sequence using the below process in order: - -- A single byte tag using the _0x3E_ format denotes a public key -- A single byte tag using the _0xE6_ format denotes a Ed25519 public key -- 32 bytes containing the standard binary representation of the Ed25519 public key -- 2 bytes containing the big-endian representation of CRC16-CCITT of the previous 34 bytes - - -The resulting 36-byte sequence is converted into a 48-character base64 or base64url string in the standard fashion. For example, the Ed25519 public key `E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D` (usually represented by a sequence of 32 bytes such as: `0xE3, 0x9E, ..., 0x7D`) presents itself through the "armored" representation as follows: - -`Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2` - - -### Converting User-Friendly Addresses and Raw Addresses - -The simplest way to convert user-friendly and raw addresses is to use one of several TON APIs and other tools, including: - -* [ton.org/address](https://ton.org/address) -* [dton.io API method](https://dton.io/api/address/0:867ac2b47d1955de6c8e23f57994fad507ea3bcfe2a7d76ff38f29ec46729627) -* [toncenter API methods in mainnet](https://toncenter.com/api/v2/#/accounts/pack_address_packAddress_get) -* [toncenter API methods in testnet](https://testnet.toncenter.com/api/v2/#/accounts/pack_address_packAddress_get) - -Additionally, there are two ways to convert user-friendly and raw addresses for wallets using JavaScript: - -* [Convert address from/to user-friendly or raw form using ton.js](https://github.com/ton-org/ton-core/blob/main/src/address/Address.spec.ts) -* [Convert address from/to user-friendly or raw form using tonweb](https://github.com/toncenter/tonweb/tree/master/src/utils#address-class) - -It's also possible to make use of similar mechanisms using [SDKs](/develop/dapps/apis/sdk). - -### Address Examples - -Learn more examples on TON Addresses in the [TON Cookbook](/develop/dapps/cookbook#working-with-contracts-addresses). - -## Possible problems - -When interacting with the TON blockchain, it's crucial to understand the implications of transferring TON coins to `uninit` wallet addresses. This section outlines the various scenarios and their outcomes to provide clarity on how such transactions are handled. - -### What happens when you transfer Toncoin to an uninit address? - -#### Transaction with `state_init` included - -If you include the `state_init` (which consists of the wallet or smart contract's code and data) with your transaction. The smart contract is deployed first using the provided `state_init`. After deployment, the incoming message is processed, similar to sending to an already initialized account. - -#### Transaction without `state_init` and `bounce` flag set - -The message cannot be delivered to the `uninit` smart contract, and it will be bounced back to the sender. After deducting the consumed gas fees, the remaining amount is returned to the sender's address. - -#### Transaction without `state_init` and `bounce` flag unset - -The message cannot be delivered, but it will not bounce back to the sender. Instead, the sent amount will be credited to the receiving address, increasing its balance even though the wallet is not yet initialized. They will be stored there until the address holder deploys a smart wallet contract and then they can access the balance. - -#### How to do it right - -The best way to deploy a wallet is to send some TON to its address (which is not yet initialized) with the `bounce` flag cleared. After this step, the owner can deploy and initialize the wallet using funds at the current uninitialized address. This step usually occurs on the first wallet operation. - -### The TON blockchain implements protection against erroneous transactions - -In the TON blockchain, standard wallets and apps automatically manage the complexities of transactions to uninitialized addresses by using bounceable and non-bounceable address, which are described [here](#bounceable-vs-non-bounceable-addresses). It is common practice for wallets, when sending coins to non-initialized addresses, to send coins to both bounceable and non-bounceable addresses without return. - -If there is a need to quickly get an address in bounceable/non-bounceable form this can be done [here](https://ton.org/address/). - -### Responsibility for custom products - -If you are developing a custom product on the TON blockchain, it is essential to implement similar checks and logic: - -Ensure your application verifies whether the recipient address is initialized before sending funds. -Based on the address state, use bounceable addresses for user smart contracts with custom application logic to ensure funds are returned. Use non-bounceable addresses for wallets. - diff --git a/docs/participate/wallets/contracts.md~upstream_staging b/docs/participate/wallets/contracts.md~upstream_staging deleted file mode 100644 index 07930cf4d8..0000000000 --- a/docs/participate/wallets/contracts.md~upstream_staging +++ /dev/null @@ -1,198 +0,0 @@ -# Types of Wallet Contracts - -You have probably heard somewhere about different versions of wallets in TON Blockchain. But what do these versions really mean and how do they differ? - -In this article, we'll look at all versions and modifications of TON wallets. - -## How can wallets be different? - -Before we start, we need to understand how wallets can differ at all. - -If we look at Ethereum, Solana or almost any other blockchain, there are not different types or versions of wallets. But why do they exist in TON? It's because wallets in TON are made by smart contracts. Basically, any wallet (even yours) is a smart contract running on TON Blockchain which can accept and send transactions to other wallets which are also smart contracts. - -These smart contracts can be set up in different ways and can have different features. That's why there are several versions of wallets in TON. - -## Basic wallets - -### Wallet V1 - -This is the simplest one. It only allows you to send one transaction at the time and it doesn't check anything besides your signature and seqno. - -This version isn't even used in regular apps because it has some major issues: - - No easy way to retrieve the seqno and public key from the contract - - No `valid_until` check, so you can't be sure that the transaction won't be confirmed too late. - -The first issue is fixed in `V1R2` and `V1R3`. That `R` letter means `revision`. Usually revisions are just small updates which only add get-methods which allows you to retrieve seqno and public key from the contract. -But this version also has a second issue, which is fixed in the next version. - -Wallet source code: - * [ton/crypto/smartcont/wallet-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet-code.fc) - -### Wallet V2 - -This version introduces the `valid_until` parameter which is used to set a time limit for a transaction in case you don't want it to be confirmed too late. This version also doesn't have the get-method for public key, which is added in `V2R2`. - -It can be used in most cases, but it misses one cool feature, which was added in `V3`. - -Wallet source code: - * [ton/crypto/smartcont/new-wallet-v2.fif](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/new-wallet-v2.fif) - -### Wallet V3 - -This version introduces the `subwallet_id` parameter, which allows you to create multiple wallets using the same public key (so you can have only one seed phrase and lots of wallets). And, as before, `V3R2` only adds the get-method for public key. - -Basically, `subwallet_id` is just a number which is added to the contract state when it is deployed. And since the contract address in TON is a hash of its state and code, the wallet address will change with a different `subwallet_id`. - -This version is the most used right now. It covers most use-cases and remains clean and simple. - -Wallet source code: - * [ton/crypto/smartcont/wallet-v3-code.fif](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/wallet-v3-code.fif) - -### Wallet V4 - -It is the most modern wallet version at the moment. It still has all the functionality of the previous versions, but also introduces something very powerful — `plugins`. - -This feature allows developers to implement complex logic that will work in tandem with a user's wallet. For example, some DApp may require a user to pay a small amount of coins every day to use some features, so the user will need to install the plugin on their wallet by signing a transaction. This plugin will send coins to the destination address every day when it will be requested by an external message. - -This is a very customizable feature which is unique to TON Blockchain. - -Wallet source code: - * [ton-blockchain/wallet-contract](https://github.com/ton-blockchain/wallet-contract) - -### Wallet V5 - -This is an extensible wallet specification developed by the Tonkeeper team, aimed at replacing V4 and allowing arbitrary extensions. - -The W5 wallet standard offers many benefits that improve the experience for both users and merchants. W5 supports gas-free transactions, account delegation and recovery, subscription payments using tokens and Toncoin, and low-cost multi-transfers. - -Users will have access to a 25% reduction in blockchain fees, a new flexible plugin interface for developers, and an internal message signature that enables delegation of gas payments. - -In addition to retaining the previous functionality (v4), the new contract allows you to send up to 255 messages at a time, as well as to make full-fledged gasless transactions (e.g., payment of network fees when transferring USDt in USDt itself) and other features. We believe it will enhance the usability and capabilities for TON users. - -:::tip -Wallet V5 wallets allow transactions to be initiated by the user but paid for by another contract. Consequently, there will be services (such as [Tonkeeper's Battery](https://blog.ton.org/tonkeeper-releases-huge-update#tonkeeper-battery)) that provide this functionality: they pay the transaction fees in TONs on behalf of the user, but charge a fee in tokens. -::: - -#### UI Preparation and Beta Testing - -- UI: Already now, wallet teams can start UI preparations. You can use the v5-beta smart contract as a test smart contract, but keep in mind that it will can change. UI suggestion: wallets that have multi-accounts could support the new v5 smart contract as a separate account in the UI. Provide a “Transfer funds between your accounts” functionality. -- Beta: If you build v5 functionality into public versions of your products, please mark it as “beta” and do not use the v5 contract by default, but only when explicitly enabled in the settings. Please observe this rule to prevent too wide distribution of the non-final beta version of the v5 smart contract. -- Release: The final smart contract will be ready around June 20, after which wallets can enable v5 by default using the final smart contract. It will be written about here. - -#### Preparing for Gasless Transactions - -The v5 wallet smart contract allows the processing of internal messages signed by the owner. This also allows you to make gasless transactions, e.g., payment of network fees when transferring USDt in USDt itself. - -#### Flow - -1. When sending USDt, the user signs one message containing two outgoing USDt transfers: - 1. USDt transfer to the recipient's address. - 2. Transfer of a small amount of USDt in favor of the Service. -2. This signed message is sent off-chain by HTTPS to the Service backend. The Service backend sends it to the TON blockchain, paying Toncoins for network fees. - -Beta version of the gasless backend API is available on [tonapi.io/api-v2](https://tonapi.io/api-v2). If you are developing any wallet app and have feedback about these methods please share it ton [@tonapitech](https://t.me/tonapitech) chat. - -Wallet source code: - * [ton-blockchain/wallet-contract-v5](https://github.com/ton-blockchain/wallet-contract-v5) - -## Special wallets - -Sometimes the functionality of basic wallets isn't enough. That's why there are several types of specialized wallet: `high-load`, `lockup` and `restricted`. - -Let's have a look at them. - -### Highload Wallets - -When working with many messages in a short period, there is a need for special wallet called Highload Wallet. Read [the article](/participate/wallets/highload) for more information. - -### Lockup wallet - -If you, for some reason, need to lock coins in a wallet for some time without the possibility to withdraw them before that time passes, have a look at the lockup wallet. - -It allows you to set the time until which you won't be able to withdraw anything from the wallet. You can also customize it by setting unlock periods so that you will be able to spend some coins during these set periods. - -For example: you can create a wallet which will hold 1 million coins with total vesting time of 10 years. Set the cliff duration to one year, so the funds will be locked for the first year after the wallet is created. Then, you can set the unlock period to one month, so `1'000'000 TON / 120 months = ~8333 TON` will unlock every month. - -Wallet source code: - * [ton-blockchain/lockup-wallet-contract](https://github.com/ton-blockchain/lockup-wallet-contract) - -### Restricted wallet - -This wallet's function is to act like a regular wallet, but restrict transfers to only one pre-defined destination address. You can set the destination when you create this wallet and then you'll be only able to transfer funds from it to that address. But note that you can still transfer funds to validation contracts so you can run a validator with this wallet. - -Wallet source code: - * [EmelyanenkoK/nomination-contract/restricted-wallet](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet) - -## Known op codes - -:::info -Also op-code, op::code and operational code -::: - - -| Contract type | Hex code | OP::Code | -|-----------------|-----------------|----------------------------| -| Global | 0x00000000 | Text Comment | -| Global | 0xffffffff | Bounce | -| Global | 0x2167da4b | [Encrypted Comment](https://docs.ton.org/develop/smart-contracts/guidelines/internal-messages#messages-with-encrypted-comments) | -| Global | 0xd53276db | Excesses | -| Elector | 0x4e73744b | New Stake | -| Elector | 0xf374484c | New Stake Confirmation | -| Elector | 0x47657424 | Recover Stake Request | -| Elector | 0x47657424 | Recover Stake Response | -| Wallet | 0x0f8a7ea5 | Jetton Transfer | -| Wallet | 0x235caf52 | [Jetton Call To](https://testnet.tonviewer.com/transaction/1567b14ad43be6416e37de56af198ced5b1201bb652f02bc302911174e826ef7) | -| Jetton | 0x178d4519 | Jetton Internal Transfer | -| Jetton | 0x7362d09c | Jetton Notify | -| Jetton | 0x595f07bc | Jetton Burn | -| Jetton | 0x7bdd97de | Jetton Burn Notification | -| Jetton | 0xeed236d3 | Jetton Set Status | -| Jetton-Minter | 0x642b7d07 | Jetton Mint | -| Jetton-Minter | 0x6501f354 | Jetton Change Admin | -| Jetton-Minter | 0xfb88e119 | Jetton Claim Admin | -| Jetton-Minter | 0x7431f221 | Jetton Drop Admin | -| Jetton-Minter | 0xcb862902 | Jetton Change Metadata | -| Jetton-Minter | 0x2508d66a | Jetton Upgrade | -| Vesting | 0xd372158c | [Top Up](https://github.com/ton-blockchain/liquid-staking-contract/blob/be2ee6d1e746bd2bb0f13f7b21537fb30ef0bc3b/PoolConstants.ts#L28) | -| Vesting | 0x7258a69b | Add Whitelist | -| Vesting | 0xf258a69b | Add Whitelist Response | -| Vesting | 0xa7733acd | Send | -| Vesting | 0xf7733acd | Send Response | -| Dedust | 0x9c610de3 | Dedust Swap ExtOut | -| Dedust | 0xe3a0d482 | Dedust Swap Jetton | -| Dedust | 0xea06185d | Dedust Swap Internal | -| Dedust | 0x61ee542d | Swap External | -| Dedust | 0x72aca8aa | Swap Peer | -| Dedust | 0xd55e4686 | Deposit Liquidity Internal | -| Dedust | 0x40e108d6 | Deposit Liquidity Jetton | -| Dedust | 0xb56b9598 | Deposit Liquidity all | -| Dedust | 0xad4eb6f5 | Pay Out From Pool | -| Dedust | 0x474а86са | Payout | -| Dedust | 0xb544f4a4 | Deposit | -| Dedust | 0x3aa870a6 | Withdrawal | -| Dedust | 0x21cfe02b | Create Vault | -| Dedust | 0x97d51f2f | Create Volatile Pool | -| Dedust | 0x166cedee | Cancel Deposit | -| StonFi | 0x25938561 | Swap Internal | -| StonFi | 0xf93bb43f | Payment Request | -| StonFi | 0xfcf9e58f | Provide Liquidity | -| StonFi | 0xc64370e5 | Swap Success | -| StonFi | 0x45078540 | Swap Success ref | - -:::info -[DeDust docs](https://docs.dedust.io/docs/swaps) - -[StonFi docs](https://docs.ston.fi/docs/developer-section/architecture#calls-descriptions) -::: - -## Conclusion - -As you see, there are many different versions of wallets in TON. But in most cases, you only need `V3R2` or `V4R2`. You can also use one of the special wallets if you want to have some additional functionality like a periodic unlocking of funds. - -## See Also - - - [Sources of basic wallets](https://github.com/ton-blockchain/ton/tree/master/crypto/smartcont) - - [More technical description of versions](https://github.com/toncenter/tonweb/blob/master/src/contract/wallet/WalletSources.md) - - [Wallet V4 sources and detailed description](https://github.com/ton-blockchain/wallet-contract) - - [Lockup wallet sources and detailed description](https://github.com/ton-blockchain/lockup-wallet-contract) - - [Restricted wallet sources](https://github.com/EmelyanenkoK/nomination-contract/tree/master/restricted-wallet) diff --git a/docs/participate/wallets/highload.md b/docs/participate/wallets/highload.md deleted file mode 100644 index e1fb3fcc19..0000000000 --- a/docs/participate/wallets/highload.md +++ /dev/null @@ -1,64 +0,0 @@ -# Highload Wallet - -When working with many messages in a short period, there is a need for special wallet called Highload Wallet. Highload Wallet V2 was the main wallet on TON for a long time, but you had to be very careful with it. Otherwise, you could [lock all funds](https://t.me/tonstatus/88). - -[With the advent of Highload Wallet V3](https://github.com/ton-blockchain/Highload-wallet-contract-v3), this problem has been solved at the contract architecture level and consumes less gas. This chapter will cover the basics of Highload Wallet V3 and important nuances to remember. - -## Highload Wallet v3 - -This wallet is made for who need to send transactions at very high rates. For example, crypto exchanges. - -- [Source code](https://github.com/ton-blockchain/Highload-wallet-contract-v3) - -Any given external message (transfer request) to a Highload v3 contains: -- a signature (512 bits) in the top level cell - the other parameters are in the ref of that cell -- subwallet ID (32 bits) -- message to send as a ref (the serialized internal message that will be sent) -- send mode for the message (8 bits) -- composite query ID - 13 bits of "shift" and 10 bits of "bit number", however the 10 bits of bit number can only go up to 1022, not 1023, and also the last such usable query ID (8388605) is reserved for emergencies and should not be normally used -- created at, or message timestamp -- timeout - -Timeout is stored in Highload as a parameter and is checked against the timeout in all requests - so the timeout for all requests is equal. The message should be not older than timeout at the time of arrival to the Highload wallet, or in code it is required that `created_at > now() - timeout`. Query IDs are stored for the purposes of replay protection for at least timeout and possibly up to 2 * timeout, however one should not expect them to be stored for longer than timeout. Subwallet ID is checked against the one stored in the wallet. Inner ref's hash is checked along with the signature against the public key of the wallet. - -Highload v3 can only send 1 message from any given external message, however it can send that message to itself with a special op code, allowing one to set any action cell on that internal message invocation, effectively making it possible to send up to 254 messages per 1 external message (possibly more if another message is sent to Highload wallet again among these 254). - -Highload v3 will always store the query ID (replay protection) once all the checks pass, however a message may not be sent due to some conditions, including but not limited to: -- **containing state init** (such messages, if required, may be sent using the special op code to set the action cell after an internal message from Highload wallet to itself) -- not enough balance -- invalid message structure (that includes external out messages - only internal messages may be sent straight from the external message) - -Highload v3 will never execute multiple externals containing the same `query_id` **and** `created_at` - by the time it forgets any given `query_id`, the `created_at` condition will prevent such a message from executing. This effectively makes `query_id` **and** `created_at` together the "primary key" of a transfer request for Highload v3. - -When iterating (incrementing) query ID, it is cheaper (in terms of TON spent on fees) to iterate through bit number first, and then the shift, like when incrementing a regular number. After you've reached the last query ID (remember about the emergency query ID - see above), you can reset query ID to 0, but if Highload's timeout period has not passed yet, then the replay protection dictionary will be full and you will have to wait for the timeout period to pass. - - -## Highload wallet v2 - -:::danger -Legacy contract, it is suggest to use Highload wallet v3. -::: - -This wallet is made for those who need to send hundreds of transactions in a short period of time. For example, crypto exchanges. - -It allows you to send up to `254` transactions in one smart contract call. It also uses a slightly different approach to solve replay attacks instead of seqno, so you can call this wallet several times at once to send even thousands of transactions in a second. - -:::caution Limitations -Note, when dealing with Highload wallet the following limits need to be checked and taken into account. -::: - -1. **Storage size limit.** Currently, size of contract storage should be less than 65535 cells. If size of -old_queries will grow above this limit, exception in ActionPhase will be thrown and transaction will fail. -Failed transaction may be replayed. -2. **Gas limit.** Currently, gas limit is 1'000'000 GAS units, that means that there is a limit of how much -old queries may be cleaned in one tx. If number of expired queries will be higher, contract will stuck. - -That means that it is not recommended to set too high expiration date: -number of queries during expiration time span should not exceed 1000. - -Also, number of expired queries cleaned in one transaction should be below 100. - - - -Wallet source code: - * [ton/crypto/smartcont/Highload-wallet-v2-code.fc](https://github.com/ton-blockchain/ton/blob/master/crypto/smartcont/Highload-wallet-v2-code.fc) \ No newline at end of file diff --git a/docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md b/docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md index f2899d267b..dd276761e2 100644 --- a/docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md +++ b/docs/v3/concepts/dive-into-ton/go-from-ethereum/solidity-vs-func.md @@ -219,4 +219,4 @@ This example presented how smart contracts can communicate with each other. - [Internal Messages](/v3/documentation/smart-contracts/message-management/internal-messages) - [Sending Messages](/v3/documentation/smart-contracts/message-management/sending-messages) -- [Non-bouncable messages](v3/guidelines/smart-contracts/guidelines/non-bouncable-messages) +- [Non-bouncable messages](/v3/documentation/smart-contracts/message-management/non-bounceable-messages) diff --git a/docs/v3/concepts/dive-into-ton/introduction.mdx b/docs/v3/concepts/dive-into-ton/introduction.mdx index 96c5803565..45ed298b20 100644 --- a/docs/v3/concepts/dive-into-ton/introduction.mdx +++ b/docs/v3/concepts/dive-into-ton/introduction.mdx @@ -11,7 +11,6 @@ TON is focused on achieving widespread cross-chain interoperability, while opera __TON Blockchain__ is designed as a distributed supercomputer, or “_superserver_,” intended to provide a variety of products and services to contribute to the development of the decentralized vision for the new internet. -* Discover which services TON provides for its users by reviewing this section: [Participate in TON](/participate/) * To learn more about the technical aspects of TON Blockchain review the [Blockchain of Blockchains](/v3/concepts/dive-into-ton/ton-blockchain/blockchain-of-blockchains) * Learn more about the development of all things TON by reviewing this section: [Getting Started](/v3/documentation/ton-documentation) diff --git a/docs/v3/concepts/dive-into-ton/ton-blockchain/ton-networking.md b/docs/v3/concepts/dive-into-ton/ton-blockchain/ton-networking.md index 268aee55f7..a8e96ff815 100644 --- a/docs/v3/concepts/dive-into-ton/ton-blockchain/ton-networking.md +++ b/docs/v3/concepts/dive-into-ton/ton-blockchain/ton-networking.md @@ -22,6 +22,6 @@ blockchain itself, thus providing more possibilities and flexibility for creatin ## See Also * [ADNL Protocol](/v3/documentation/network/protocols/adnl/overview) -* [Overlay Subnetworks](/learn/networking/overlay-subnetworks) -* [RLDP Protocol](/learn/networking/rldp) +* [Overlay Subnetworks](/v3/documentation/network/protocols/overlay) +* [RLDP Protocol](/v3/documentation/network/protocols/rldp) * [TON DHT Service](/v3/documentation/network/protocols/dht/ton-dht) diff --git a/docs/v3/concepts/dive-into-ton/ton-ecosystem/explorers-in-ton.mdx b/docs/v3/concepts/dive-into-ton/ton-ecosystem/explorers-in-ton.mdx index 52882b3a6c..ab64fa1b97 100644 --- a/docs/v3/concepts/dive-into-ton/ton-ecosystem/explorers-in-ton.mdx +++ b/docs/v3/concepts/dive-into-ton/ton-ecosystem/explorers-in-ton.mdx @@ -162,7 +162,7 @@ Displays various statistics such as number of registered network addresses and w ## Want to be in this list? -Please, write to one of the [maintainers](/docs/v3/contribute/maintainers.md). +Please, write to one of the [maintainers](/v3/contribute/maintainers). ## References diff --git a/docs/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps.mdx b/docs/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps.mdx index 5ec4e423a8..f6b7e82ca5 100644 --- a/docs/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps.mdx +++ b/docs/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps.mdx @@ -133,7 +133,7 @@ You will need to download separate application to connect to the Testnet. #### Links - [GitHub](https://github.com/tonwhales/wallet) - [Sandbox iOS](https://apps.apple.com/app/ton-development-wallet/id1607857373) -- [Sandbox Android](https://play.google.com/store/apps/details?id=com.tonhub.wallet.testnet) +- [Sandbox Android](https://play.google.com/store/apps/details?id=com.tonhub.wallet) ### OpenMask diff --git a/docs/v3/concepts/qa-outsource/outsource.mdx b/docs/v3/concepts/qa-outsource/outsource.mdx index 8cae0aae02..3efd865f19 100644 --- a/docs/v3/concepts/qa-outsource/outsource.mdx +++ b/docs/v3/concepts/qa-outsource/outsource.mdx @@ -7,7 +7,6 @@ import Button from '@site/src/components/button' Discover 3rd party development teams for your TON project * [Astralyx](#astralyx) -* [Blockczech R&D Lab](#blockczech-rd-lab) * [Coinvent](#coinvent) * [EvaCodes](#evacodes) * [Pixelplex](#pixelplex) @@ -28,37 +27,12 @@ Company with big experience in TON and other chains development. You can ask us - [t.me/xjetswapbot](http://t.me/xjetswapbot) (frontend, design), - [github.com/astralyxdev/lockup-jettons-contract](http://github.com/astralyxdev/lockup-jettons-contract) (smartcontract, web interface, tests) - [github.com/astralyxdev/ton-proxy](http://github.com/astralyxdev/ton-proxy) (TON Proxy extension, one of the first) -- [store.devdao.io](http://store.devdao.io) (front-end, design) - [scaleton.io](http://scaleton.io) (landing, frontend, design) -- [burn.astralyx.dev](http://burn.astralyx.dev) (service for burning SBT NFT in TON, frontend, design) #### Contacts [astralyx.dev](http://astralyx.dev), contact@astralyx.dev -### Blockczech R&D Lab - -#### Summary -Web3.0 Software House & Startup Studio with a strong focus on blockchain-based solutions for games and eSports. - -#### Workstreams -- dApps -- TMA Development -- blockchain games -- Integration - -#### Projects -- [TCG.world](http://TCG.world) -- [cryptomeda.tech ](http://cryptomeda.tech) -- [liithos.com](http://liithos.com) -- [x.la/contracts/](http://x.la/contracts/) -- [About Blockczech R&D Lab](https://docs.google.com/presentation/d/1htMH1ihm31wQSn08ZziFfK6NpbPSHA3M/edit?usp=sharing&ouid=105247529013711719883&rtpof=true&sd=true) - -#### Contacts -- http://blockczech.io -- [@blockczech](https://t.me/blockczech) - - ### Coinvent #### Summary @@ -74,7 +48,6 @@ Coinvent is a dedicated outsource development team, passionately committed to cr #### Projects - [Tonraffles Lock module](https://tonraffles.app/lock) (smart-contract, front-end) - [Tonraffles NFT Launchpad](https://tonraffles.app/nft/launchpad) (smart-contracts) -- [OOIA shopping cart feature](https://testnet.ooia.art/) (smart-contract) - [Monaki NFT Staking](https://www.monaki.life/) (smart-contracts) #### Contacts @@ -95,7 +68,6 @@ EvaCodes is a top Eastern European blockchain development company with teams loc #### Projects - [alium.finance](https://alium.finance/) -- [trush.io](https://trush.io/) - [konsta.network](https://konsta.network/) #### Contacts @@ -148,7 +120,7 @@ The most bizarre company with the bravest ideas of Ton and FunC programming. #### Contacts - [serokell.io](https://serokell.io/) -- Telegram [Roman Alterman](https://t.me/alterroman) +- Telegram [Roman Alterman](https://t.me/alterroman) - hi@serokell.io ### softstack diff --git a/docs/v3/concepts/ton-blockchain/shards.md b/docs/v3/concepts/ton-blockchain/shards.md index 9b0fc8cd8d..96af82cac3 100644 --- a/docs/v3/concepts/ton-blockchain/shards.md +++ b/docs/v3/concepts/ton-blockchain/shards.md @@ -21,5 +21,5 @@ In addition to the dynamic creation of shards, TON uses **Split Merge** function ## See Also -* [Shards Dive In](/develop/blockchain/shards) -* [# Infinity Sharding Paradigm](/develop/blockchain/sharding-lifecycle) +* [Shards Dive In](/v3/documentation/smart-contracts/shards) +* [# Infinity Sharding Paradigm](/v3/documentation/smart-contracts/infinity-sharding-paradigm) diff --git a/docs/v3/contribute/participate.md b/docs/v3/contribute/participate.md index 8e9b825faf..0638922c6a 100644 --- a/docs/v3/contribute/participate.md +++ b/docs/v3/contribute/participate.md @@ -30,10 +30,10 @@ Write a _ton-footstep_ to receive a funding for your contributing. ## Writing a tutorial **Preparations**. Minimize future amount of requested changes, _save your time_: -1. Follow [Tutorial Guidelines](/v3/contribute/guidelines) and check them with [Sample Tutorial Structure](/v3/contribute/sample-tutorial) -2. Read [Principles of a Good Tutorial](/v3/contribute/principles-of-a-good-tutorial) to write amazing tutorial :) +1. Follow [Tutorial Guidelines](/v3/contribute/contribution-rules) and check them with [Sample Tutorial Structure](/v3/contribute/tutorials/sample-tutorial) +2. Read [Principles of a Good Tutorial](/v3/contribute/tutorials/principles-of-a-good-tutorial) to write amazing tutorial :) 3. Inspire with [Mint your first Jetton](/v3/guidelines/dapps/tutorials/mint-your-first-token) example in sources. -4. **Setup environment**. [Check the tutorial](/contribute#online-one-click-contribution-setup) running your fork locally or using Gitpod. +4. **Setup environment**. [Check the tutorial](/v3/contribute#online-one-click-contribution-setup) running your fork locally or using Gitpod. 5. **Write tutorial**. Using the environment, see how tutorial looks like on your fork. 6. **Make a Pull Request**. Open PR to get some feedback from maintainers. 7. Get merged! diff --git a/docs/v3/documentation/archive/hacktoberfest-2022/README.mdx b/docs/v3/documentation/archive/hacktoberfest-2022/README.mdx index dc338830d6..e372988f8a 100644 --- a/docs/v3/documentation/archive/hacktoberfest-2022/README.mdx +++ b/docs/v3/documentation/archive/hacktoberfest-2022/README.mdx @@ -4,7 +4,7 @@ import Button from '@site/src/components/button'
tlb structure
@@ -33,7 +33,7 @@ To motivate the community to contribute to open source projects in the TON Ecosy