diff --git a/README.md b/README.md index d4b39686..35db4ba2 100644 --- a/README.md +++ b/README.md @@ -16,13 +16,45 @@ Proposal management is done using GitHub pull requests, the process is described ## Merged TEPs ## Active -| TEP | Title | Type | Created | -|--------------------------------------------|----------------------------------|------------------|-----------| -| [1](./text/0001-tep-lifecycle.md) | TEP Lifecycle | Meta | 11.06.2022| -| [62](./text/0062-nft-standard.md) | NFT Standard |Contract Interface| 01.02.2022| -| [64](./text/0064-token-data-standard.md) | Token Data Standard |Contract Interface| 03.02.2022| -| [66](./text/0066-nft-royalty-standard.md) | NFTRoyalty Standard Extension |Contract Interface| 12.02.2022| -| [74](./text/0074-jettons-standard.md) |Fungible tokens (Jettons) standard|Contract Interface| 12.03.2022| -| [81](./text/0081-dns-standard.md) | TON DNS Standard |Contract Interface| 25.06.2022| -| [85](./text/0085-sbt-standard.md) | SBT Contract |Contract Interface| 09.08.2022| -|[89](./text/0089-jetton-wallet-discovery.md)| Discoverable Jettons Wallets |Contract Interface|08.09.2022 | +| TEP | Title | Type | Created | +|----------------------------------------------|------------------------------------|--------------------|------------| +| [1](./text/0001-tep-lifecycle.md) | TEP Lifecycle | Meta | 11.06.2022 | +| [2](./text/0002-address.md) | TON Addresses | Core | 07.09.2019 | +| [62](./text/0062-nft-standard.md) | NFT Standard | Contract Interface | 01.02.2022 | +| [64](./text/0064-token-data-standard.md) | Token Data Standard | Contract Interface | 03.02.2022 | +| [66](./text/0066-nft-royalty-standard.md) | NFTRoyalty Standard Extension | Contract Interface | 12.02.2022 | +| [74](./text/0074-jettons-standard.md) | Fungible tokens (Jettons) standard | Contract Interface | 12.03.2022 | +| [81](./text/0081-dns-standard.md) | TON DNS Standard | Contract Interface | 25.06.2022 | +| [85](./text/0085-sbt-standard.md) | SBT Contract | Contract Interface | 09.08.2022 | +| [89](./text/0089-jetton-wallet-discovery.md) | Discoverable Jettons Wallets | Contract Interface | 08.09.2022 | +| [115](./text/0115-ton-connect.md) | TON Connect | Core | 20.10.2022 | + + +## WIP +Since standard truly become a _Standard_ not when it gets merged into this repository, but when multiple parties accept it and use to interact with each other, below we list proposals to which developers may refer in documentation and so on. +In particular "Status" below has the following sense: +* "Proposed" - this standard hasn't implementation or implementation is used only by authors +* "Partially Deployed" - this standard is used by pair of actors (for instance one dApp and one wallet, or similar), but not by interconnected set of actors +* "Deployed" - this standard is used by multiple actors (and generally should be on the way of merging) + +| TEP | Title | Type | Created | Status | +|----------------------------------------------|------------------------------------|--------------------|------------|------------| +| [91](https://github.com/ton-blockchain/TEPs/pull/91/files) | Contract Source Registry | Infrastructure | 09.09.2022 | ✅Deployed✅ | +| [92](https://github.com/ton-blockchain/TEPs/pull/92/files) | Wallet Registry | Infrastructure | 11.09.2022 | Proposed | +| [96](https://github.com/ton-blockchain/TEPs/pull/96/files) | Dicts/Arrays in Metadata | Contract Interface | 21.09.2022 | Proposed | +| [104](https://github.com/ton-blockchain/TEPs/pull/104/files) | Data Signatures | Contract Interface | 13.12.2022 | Proposed | +| [121](https://github.com/ton-blockchain/TEPs/pull/121/files) | Lockable Jetton Wallet | Contract Interface | 13.04.2023 | Proposed | +| [122](https://github.com/ton-blockchain/TEPs/pull/122/files) | Onchain reveal mechanic | Contract Interface | 31.10.2022 | ✅Deployed✅ | +| [123](https://github.com/ton-blockchain/TEPs/pull/123/files) | Address Guideline update | Guidelines | 13.06.2023 | 🛠️Partially Deployed🛠️ | +| [126](https://github.com/ton-blockchain/TEPs/pull/126/files) | Compressed NFT Standard | Contract Interface | 28.07.2023 | 🛠️Partially Deployed🛠️ | +| [127](https://github.com/ton-blockchain/TEPs/pull/127/files) | TON Storage in Metadata | Contract Interface | 23.09.2023 | Proposed | +| [130](https://github.com/ton-blockchain/TEPs/pull/130/files) | Rebase Jettons standart | Contract Interface | 04.12.2023 | Proposed | +| [131](https://github.com/ton-blockchain/TEPs/pull/131/files) | Referral code in Query ID | Contract Interface | 26.12.2023 | 🛠️Partially Deployed🛠️ | +| [137](https://github.com/ton-blockchain/TEPs/pull/137/files) | Jetton Wallet Balance Query | Contract Interface | 09.01.2024 | Proposed | +| [140](https://github.com/ton-blockchain/TEPs/pull/140/files) | Programmable Action Phase | Core | 20.01.2024 | Proposed | +| [141](https://github.com/ton-blockchain/TEPs/pull/141) | Remote onchain execution | Core | 20.01.2024 | Proposed | +| [142](https://github.com/ton-blockchain/TEPs/pull/142/files) | TBRC-20 Inscription Token Standard | Contract Interface | 26.01.2024 | Proposed | +| [145](https://github.com/ton-blockchain/TEPs/pull/145/files) | Metadata "Hidden" render type | Contract Interface | 26.01.2024 | ✅Deployed✅ | +| [146](https://github.com/ton-blockchain/TEPs/pull/146/files) | Semi-fungible token standard | Contract Interface | 17.03.2024 | Proposed | +| [160](https://github.com/ton-blockchain/TEPs/pull/160) | Dispatch Queue | Core | 13.06.2024 | 🛠️Partially Deployed🛠️ | +| [161](https://github.com/ton-blockchain/TEPs/pull/161/files) | Proxy TON (wTON) | Contract Interface | 13.06.2024 | 🛠️Partially Deployed🛠️ | diff --git a/text/0002-address.md b/text/0002-address.md new file mode 100644 index 00000000..57d696e6 --- /dev/null +++ b/text/0002-address.md @@ -0,0 +1,132 @@ +- **TEP**: [2](https://github.com/ton-blockchain/TEPs/pull/2) +- **title**: TON Addresses +- **status**: Active +- **type**: Core +- **authors**: - +- **created**: 07.09.2019 +- **replaces**: - +- **replaced by**: - + +# Summary + +This document describes TON addresses and their representation. + +# Specification + +## Smart-contract addresses + +Smart-contract addresses in the TON Network consist of two parts: + +(a) the workchain ID (a signed 32-bit integer) and + +(b) the address inside the workchain (64-512 bits depending on the workchain). + +Currently, only the masterchain (workchain_id=-1) and the basic workchain (workchain_id=0) are running in the TON Blockchain Network. Both of them have 256-bit addresses, so until a new different workchains appears we assume that workchain_id is either 0 or -1 and that the address inside the workchain is exactly 256-bit. + +Under the conditions stated above, the smart-contract address can be represented in the following forms: + +A) "Raw": :<64 hexadecimal digits with address> + +B) "User-friendly", which is obtained by first generating: +- one tag byte (0x11 for "bounceable" addresses, 0x51 for "non-bounceable"; add +0x80 if the address should not be accepted by software running in the mainnet network) +- one byte containing a signed 8-bit integer with the workchain_id (0x00 for the basic workchain, 0xff for the masterchain) +- 32 bytes containing 256 bits of the smart-contract address inside the workchain (big-endian) +- 2 bytes containing CRC16-CCITT of the previous 34 bytes + +In case B), the 36 bytes thus obtained are then encoded using base64 (i.e., with digits, upper- and lowercase Latin letters, '/' and '+') or base64url (with '_' and '-' instead of '/' and '+'), yielding 48 printable non-space characters. + +Example: + +The "root dns" (a special smart contract residing in the masterchain) has the address + +`-1:e56754f83426f69b09267bd876ac97c44821345b7e266bd956a7bfbfb98df35c` + +in the "raw" form (notice that uppercase Latin letters 'A'..'F' may be used instead of 'a'..'f') + +and + +`Ef_lZ1T4NCb2mwkme9h2rJfESCE0W34ma9lWp7-_uY3zXDvq` (bounceable) + +`Uf_lZ1T4NCb2mwkme9h2rJfESCE0W34ma9lWp7-_uY3zXGYv` (non-bounceable) + +in the "user-friendly" form (to be displayed by user-friendly clients). + +Notice that both forms (base64 and base64url) are valid and must be accepted. + +## Wallets applications + +At the moment, TON wallets work with addresses as follows: + +For receiving: + +- Wallets display the user's address in a user-friendly bounceable or non-bounceable form (at the moment, the majority of wallet apps display bounceable form). + +When sending: + +1) The wallet app checks the validity of the destination address representation - its length, valid characters, prefix and checksum. If the address is not valid, then an alert is shown and the sending operation is not performed. + +2) If the address has a testnet flag, and the wallet app works with the mainnet network, then an alert is shown and the sending operation is not performed. + +3) The wallet app retrieve from address bounceable flag. + +4) The wallet app check the destination address - if it has `unitialized` state wallet force set `bounce` field of sending message to `false` and ignore bounceable/non-bounceable flag from address representation. + +5) If destination is not `unitialized` then wallet app uses the bounceable/non-bounceable flag from the address representation for the `bounce` field of sending message. + +## Public keys + +The ubiquitous 256-bit Ed25519 public keys can be represented in the following forms: + +A) "Raw": <64 hexadecimal digits with address> + +B) "User-friendly" or "armored", which is obtained by first generating: + +- one tag byte 0x3E, meaning that this is a public key +- one tag byte 0xE6, meaning that this is 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 `0xE3, 0x9E, ..., 0x7D`) has the following "armored" representation: + +`Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2` + +## ADNL address + +The ADNL protocol based on 256-bit abstract addresses. + +The ADNL address can be represented in the following forms: + +A) "Raw": <64 hexadecimal digits with address> + +B) "User-friendly" or "armored", which is obtained by first generating: + +- one tag byte 0x2d, meaning that this is a ADNL address +- 32 bytes containing 256 bits of the ADNL address (big-endian) +- 2 bytes containing the big-endian representation of CRC16-CCITT of the previous 34 bytes. + +The resulting 35-byte sequence is converted into a 55-character base32 string in the standard fashion. + +Example: + +For example ADNL address `45061C1D4EC44A937D0318589E13C73D151D1CEF5D3C0E53AFBCF56A6C2FE2BD` has the following "armored" representation: + +`vcqmha5j3ceve35ammfrhqty46rkhi455otydstv66pk2tmf7rl25f3` + +# Drawbacks + +- It is impossible to extract the public key from the address, which is needed for some tasks (for example, to send an encrypted message to this address). + Thus, until the smart contract is deployed for this address, there is no way to get the public key on-chain. + +- (UI) Most OS do not allow you to select an address with double click because of '_', '-', '/', '+' base64 symbols. + +# Rationale and alternatives + +- The prefix (the first byte(s)) allows you to understand exactly what type this address or key is. + +- The checksum built into the address prevents the loss of funds due to a user typo. + +- Built-in testnet flag prevents loss of funds by a user who mistakenly tries to send real coins to a testnet address. + +- A different form of address than most other blockchains allows the user to more easily identify the TON address. \ No newline at end of file diff --git a/text/0064-token-data-standard.md b/text/0064-token-data-standard.md index 623ea879..94f91011 100644 --- a/text/0064-token-data-standard.md +++ b/text/0064-token-data-standard.md @@ -82,6 +82,7 @@ Three options can be used: Data encoded as described in "2. On-chain content layout". The dictionary must have `uri` key with a value containing the URI pointing to the JSON document with token metadata. Clients in this case should merge the keys of the on-chain dictionary and off-chain JSON doc. + In case of collisions (the field exists in both off-chain data and on-chain data), on-chain values are used. ## Data serialization Data that does not fit in one cell can be stored in two ways: @@ -107,9 +108,9 @@ If the prefix is not `0x00` or `0x01`, then the data is probably encoded by the ## Informal TL-B scheme: ``` text#_ {n:#} data:(SnakeData ~n) = Text; -snake#00 data:(SnakeData ~n) = ContentData; +snake#00 {n:#} data:(SnakeData ~n) = ContentData; chunks#01 data:ChunkedData = ContentData; -onchain#00 data:(HashMapE 256 ^ContentData) = FullContent; +onchain#00 data:(HashmapE 256 ^ContentData) = FullContent; offchain#01 uri:Text = FullContent; ``` @@ -171,3 +172,5 @@ None * 31 Aug 2022 - added note about data encoded in TL-B schema in "Data serialization" paragraph. * 14 Oct 2022 - render_type and amount_style for Jetton metadata + +* 20 Dec 2023 - added clarification for semi-chain data: "In case of collisions (the field exists in both off-chain data and on-chain data), on-chain values are used." diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 6a8dd54e..eeaa8210 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -58,7 +58,7 @@ NFT Collection smart contract MUST implement: Send back message with the following layout and send-mode `64` (return msg amount except gas fees): TL-B schema `report_royalty_params#a8cb00ad query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody;` -It is expected that marketplaces which want to participate in royalty payments will send `muldiv(price, nominator, denominator)` to `destination` address after NFT sale. +It is expected that marketplaces which want to participate in royalty payments will send `muldiv(price, numerator, denominator)` to `destination` address after NFT sale. Marketplaces SHOULD neglect zero-value royalty payments. diff --git a/text/0074-jettons-standard.md b/text/0074-jettons-standard.md deleted file mode 100644 index 16f540db..00000000 --- a/text/0074-jettons-standard.md +++ /dev/null @@ -1,253 +0,0 @@ -- **TEP**: [74](https://github.com/ton-blockchain/TEPs/pull/4) -- **title**: Fungible tokens (Jettons) standard -- **status**: Active -- **type**: Contract Interface -- **authors**: [EmelyanenkoK](https://github.com/EmelyanenkoK), [Tolya](https://github.com/tolya-yanot) -- **created**: 12.03.2022 -- **replaces**: - -- **replaced by**: - - -# Summary - -A standard interface for Jettons (TON fungible tokens). - -# Motivation - -A standard interface will greatly simplify interaction and display of different tokenized assets. - -Jetton standard describes: - -* The way of jetton transfers. -* The way of retrieving common information (name, circulating supply, etc) about given Jetton asset. - -# Guide - -## Useful links -1. [Reference jetton implementation](https://github.com/ton-blockchain/token-contract/) -2. [Jetton deployer](https://jetton.live/) -3. FunC Jetton lesson ([en](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/9lesson/ninthlesson.md)/[ru](https://github.com/romanovichim/TonFunClessons_ru/blob/main/9lesson/ninthlesson.md)) - -# Specification - -Here and following we use "Jetton" with capital `J` as designation for entirety of tokens of the same type, while "jetton" with `j` as designation of amount of tokens of some type. - -Jettons are organized as follows: each Jetton has master smart-contract which is used to mint new jettons, account for circulating supply and provide common information. - -At the same time information about amount of jettons owned by each user is stores in decentralized manner in individual (for each owner) smart-contracts called "jetton-wallets". - -Example: if you release a Jetton with circulating supply of 200 jetton which are owned by 3 people, then you will deploy 4 contracts: 1 Jetton-master and 3 jetton-wallets. - -## Jetton wallet smart contract -Must implement: - -### Internal message handlers -#### 1. `transfer` -**Request** - -TL-B schema of inbound message: - -``` -transfer#0f8a7ea5 query_id:uint64 amount:(VarUInteger 16) destination:MsgAddress - response_destination:MsgAddress custom_payload:(Maybe ^Cell) - forward_ton_amount:(VarUInteger 16) forward_payload:(Either Cell ^Cell) - = InternalMsgBody; -``` - -`query_id` - arbitrary request number. - -`amount` - amount of transferred jettons in elementary units. - -`destination` - address of the new owner of the jettons. - -`response_destination` - address where to send a response with confirmation of a successful transfer and the rest of the incoming message Toncoins. - -`custom_payload` - optional custom data (which is used by either sender or receiver jetton wallet for inner logic). - -`forward_ton_amount` - the amount of nanotons to be sent to the destination address. - -`forward_payload` - optional custom data that should be sent to the destination address. - -**Should be rejected if:** - -1. message is not from the owner. -2. there is no enough jettons on the sender wallet -3. there is no enough TON (with respect to jetton own storage fee guidelines and operation costs) to process operation, deploy receiver's jetton-wallet and send `forward_ton_amount`. -4. After processing the request, the receiver's jetton-wallet **must** send at least `in_msg_value - forward_ton_amount - 2 * max_tx_gas_price - 2 * fwd_fee` to the `response_destination` address. - If the sender jetton-wallet cannot guarantee this, it must immediately stop executing the request and throw error. - `max_tx_gas_price` is the price in Toncoins of maximum transaction gas limit of FT habitat workchain. For the basechain it can be obtained from [`ConfigParam 21`](https://github.com/ton-blockchain/ton/blob/78e72d3ef8f31706f30debaf97b0d9a2dfa35475/crypto/block/block.tlb#L660) from `gas_limit` field. `fwd_fee` is forward fee for transfer request, it can be obtained from parsing transfer request message. - -**Otherwise should do:** - -1. decrease jetton amount on sender wallet by `amount` and send message which increase jetton amount on receiver wallet (and optionally deploy it). -2. if `forward_amount > 0` ensure that receiver's jetton-wallet send message to `destination` address with `forward_amount` nanotons attached and with the following layout: - TL-B schema: - -``` -transfer_notification#7362d09c query_id:uint64 amount:(VarUInteger 16) - sender:MsgAddress forward_payload:(Either Cell ^Cell) - = InternalMsgBody; -``` - -`query_id` should be equal with request's `query_id`. - -`amount` amount of transferred jettons. - -`sender` is address of the previous owner of transferred jettons. - -`forward_payload` should be equal with request's `forward_payload`. - -If `forward_amount` is equal to zero, notification message should not be sent. - -3. Receiver's wallet should send all excesses of incoming message coins to `response_destination` with the following layout: - TL-B schema: `excesses#d53276db query_id:uint64 = InternalMsgBody;` - `query_id` should be equal with request's `query_id`. - -#### `forward_payload` format - -If you want to send a simple comment in the `forward_payload` then the `forward_payload` must starts with `0x00000000` (32-bits unsigned integer equals to zero) and the comment is contained in the remainder of the `forward_payload`. - -If comment does not begin with the byte `0xff`, the comment is a text one; it can be displayed "as is" to the end user of a wallet (after filtering invalid and control characters and checking that it is a valid UTF-8 string). -For instance, users may indicate the purpose ("for coffee") of a simple transfer from their wallet to the wallet of another user in this text field. - -On the other hand, if the comment begins with the byte `0xff`, the remainder is a "binary comment", which should not be displayed to the end user as text (only as hex dump if necessary). -The intended use of "binary comments" is, e.g., to contain a purchase identifier for payments in a store, to be automatically generated and processed by the store's software. - -If the `forward_payload` contains a binary message for interacting with the destination smart contract (for example, with DEX), then there are no prefixes. - -These rules are the same with the payload format when simply sending Toncoins from a regular wallet ([Smart Contract Guidelines: Internal Messages, 3](https://ton.org/docs/#/howto/smart-contract-guidelines?id=internal-messages)). - -#### 2. `burn` -**Request** - -TL-B schema of inbound message: - -``` -burn#595f07bc query_id:uint64 amount:(VarUInteger 16) - response_destination:MsgAddress custom_payload:(Maybe ^Cell) - = InternalMsgBody; -``` - -`query_id` - arbitrary request number. - -`amount` - amount of burned jettons - -`response_destination` - address where to send a response with confirmation of a successful burn and the rest of the incoming message coins. - -`custom_payload` - optional custom data. - -**Should be rejected if:** - -1. message is not from the owner. -2. there is no enough jettons on the sender wallet -3. There is no enough TONs to send after processing the request at least `in_msg_value - max_tx_gas_price` to the `response_destination` address. - If the sender jetton-wallet cannot guarantee this, it must immediately stop executing the request and throw error. - -**Otherwise should do:** - -1. decrease jetton amount on burner wallet by `amount` and send notification to jetton master with information about burn. -2. Jetton master should send all excesses of incoming message coins to `response_destination` with the following layout: - TL-B schema: `excesses#d53276db query_id:uint64 = InternalMsgBody;` - `query_id` should be equal with request's `query_id`. - -### Get-methods -1. `get_wallet_data()` returns `(int balance, slice owner, slice jetton, cell jetton_wallet_code)` - `balance` - (uint256) amount of jettons on wallet. - `owner` - (MsgAddress) address of wallet owner; - `jetton` - (MsgAddress) address of Jetton master-address; - `jetton_wallet_code` - (cell) with code of this wallet; - -## Jetton master contract -### Get-methods -1. `get_jetton_data()` returns `(int total_supply, int mintable, slice admin_address, cell jetton_content, cell jetton_wallet_code)` - `total_supply` - (integer) - the total number of issues jettons - `mintable` - (-1/0) - flag which indicates whether number of jettons can increase - `admin_address` - (MsgAddressInt) - address of smart-contrac which control Jetton - `jetton_content` - cell - data in accordance to [Token Data Standard #64](https://github.com/ton-blockchain/TEPs/blob/master/text/0064-token-data-standard.md) - `jetton_wallet_code` - cell - code of wallet for that jetton -2. `get_wallet_address(slice owner_address)` return `slice jetton_wallet_address` - Returns jetton wallet address (MsgAddressInt) for this owner address (MsgAddressInt). - -# TL-B schema -``` -nothing$0 {X:Type} = Maybe X; -just$1 {X:Type} value:X = Maybe X; -left$0 {X:Type} {Y:Type} value:X = Either X Y; -right$1 {X:Type} {Y:Type} value:Y = Either X Y; -var_uint$_ {n:#} len:(#< n) value:(uint (len * 8)) - = VarUInteger n; - -addr_none$00 = MsgAddressExt; -addr_extern$01 len:(## 9) external_address:(bits len) - = MsgAddressExt; -anycast_info$_ depth:(#<= 30) { depth >= 1 } - rewrite_pfx:(bits depth) = Anycast; -addr_std$10 anycast:(Maybe Anycast) - workchain_id:int8 address:bits256 = MsgAddressInt; -addr_var$11 anycast:(Maybe Anycast) addr_len:(## 9) - workchain_id:int32 address:(bits addr_len) = MsgAddressInt; -_ _:MsgAddressInt = MsgAddress; -_ _:MsgAddressExt = MsgAddress; - -transfer query_id:uint64 amount:(VarUInteger 16) destination:MsgAddress - response_destination:MsgAddress custom_payload:(Maybe ^Cell) - forward_ton_amount:(VarUInteger 16) forward_payload:(Either Cell ^Cell) - = InternalMsgBody; - -transfer_notification query_id:uint64 amount:(VarUInteger 16) - sender:MsgAddress forward_payload:(Either Cell ^Cell) - = InternalMsgBody; - -excesses query_id:uint64 = InternalMsgBody; - -burn query_id:uint64 amount:(VarUInteger 16) - response_destination:MsgAddress custom_payload:(Maybe ^Cell) - = InternalMsgBody; - -// ----- Unspecified by standard, but suggested format of internal message - -internal_transfer query_id:uint64 amount:(VarUInteger 16) from:MsgAddress - response_address:MsgAddress - forward_ton_amount:(VarUInteger 16) - forward_payload:(Either Cell ^Cell) - = InternalMsgBody; -burn_notification query_id:uint64 amount:(VarUInteger 16) - sender:MsgAddress response_destination:MsgAddress - = InternalMsgBody; -``` - -`crc32('transfer query_id:uint64 amount:VarUInteger 16 destination:MsgAddress response_destination:MsgAddress custom_payload:Maybe ^Cell forward_ton_amount:VarUInteger 16 forward_payload:Either Cell ^Cell = InternalMsgBody') = 0x8f8a7ea5 & 0x7fffffff = 0xf8a7ea5` - -`crc32('transfer_notification query_id:uint64 amount:VarUInteger 16 sender:MsgAddress forward_payload:Either Cell ^Cell = InternalMsgBody') = 0xf362d09c & 0x7fffffff = 0x7362d09c` - -`crc32('excesses query_id:uint64 = InternalMsgBody') = 0x553276db | 0x80000000 = 0xd53276db` - -`crc32('burn query_id:uint64 amount:VarUInteger 16 response_destination:MsgAddress custom_payload:Maybe ^Cell = InternalMsgBody') = 0x595f07bc & 0x7fffffff = 0x595f07bc` - -`crc32('internal_transfer query_id:uint64 amount:VarUInteger 16 from:MsgAddress response_address:MsgAddress forward_ton_amount:VarUInteger 16 forward_payload:Either Cell ^Cell = InternalMsgBody') = 0x978d4519 & 0x7fffffff = 0x178d4519` - -`crc32('burn_notification query_id:uint64 amount:VarUInteger 16 sender:MsgAddress response_destination:MsgAddress = InternalMsgBody') = 0x7bdd97de & 0x7fffffff = 0x7bdd97de` - -# Drawbacks - -There is no way to get actual wallet balance onchain, because when the message with balance will arrive, wallet balance may be not actual. - -# Rationale and alternatives - -Distributed architecture "One wallet - one contract" well described in the [NFT standard](https://github.com/ton-blockchain/TEPs/blob/master/text/0062-nft-standard.md#rationale-and-alternatives) in paragraph "Rationale". - -# Prior art - -1. [EIP-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20) -2. [Sharded Smart Contracts for Smart Contract Developers](https://www.youtube.com/watch?v=svOadLWwYaM) - -# Unresolved questions - -1. There is no standard methods to perform "safe transfer", which will revert ownership transfer in case of contract execution failure. - -# Future possibilities - -There was an idea to implement [external message tokens](https://t.me/ton_overview/35) (by [EmelyanenkoK](https://github.com/EmelyanenkoK)). - -# Changelog - -31 Aug 2022 - Added `forward_payload` format. diff --git a/text/0081-dns-standard.md b/text/0081-dns-standard.md index 69a03e33..b9c443ff 100644 --- a/text/0081-dns-standard.md +++ b/text/0081-dns-standard.md @@ -143,10 +143,7 @@ proto_list_next$1 head:Protocol tail:ProtoList = ProtoList; -cap_method_seqno#5371 = SmcCapability; -cap_method_pubkey#71f4 = SmcCapability; cap_is_wallet#2177 = SmcCapability; -cap_name#ff name:Text = SmcCapability; cap_list_nil$0 = SmcCapList; cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList; @@ -193,3 +190,13 @@ None # Future possibilities 1. Implement private (encrypted) fields + +# Changelog + +* 20 Dec 2023 - deleted unused capabilities: + + ``` + cap_method_seqno#5371 = SmcCapability; + cap_method_pubkey#71f4 = SmcCapability; + cap_name#ff name:Text = SmcCapability; + ``` diff --git a/text/0085-sbt-standard.md b/text/0085-sbt-standard.md index 3808e7be..b93f3106 100644 --- a/text/0085-sbt-standard.md +++ b/text/0085-sbt-standard.md @@ -34,8 +34,10 @@ forward_payload:^Cell with_content:Bool = InternalMsgBody; `with_content` - if true, SBT's content cell will be included in message to contract. -**Should do:** +**Should be rejected if:** +* Sender address is not the owner's address. +**Otherwise should do:** Send message with TL-B schema to `dest` contract: ``` ownership_proof#0524c7ae query_id:uint64 item_id:uint256 owner:MsgAddress diff --git a/text/0000-ton-connect.md b/text/0115-ton-connect.md similarity index 98% rename from text/0000-ton-connect.md rename to text/0115-ton-connect.md index 635c44f1..74a0876c 100644 --- a/text/0000-ton-connect.md +++ b/text/0115-ton-connect.md @@ -1,4 +1,4 @@ -- **TEP**: [0](https://github.com/ton-blockchain/TEPs/pull/0) +- **TEP**: [115](https://github.com/ton-blockchain/TEPs/blob/master/text/0115-ton-connect.md) - **title**: TON Connect - **status**: Active - **type**: Core