From df56ee2985b1df1eae5ff36ef228a863d782a3e7 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 12 Jul 2024 10:11:34 +0200 Subject: [PATCH 1/2] fix typos --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 35db4ba2..430e8f5b 100644 --- a/README.md +++ b/README.md @@ -1,6 +1,6 @@ # TON Enhancement Proposals (TEPs) -> :warning: **WARNING:** this proposal system is experimental now, the process is a subject to change. +> :warning: **WARNING:** this proposal system is experimental now, the process is subject to change. The main goal of TON Enhancement Proposals is to provide a convenient and formal way to propose changes to TON Blockchain and standardize ways of interaction between different parts of ecosystem. @@ -48,7 +48,7 @@ In particular "Status" below has the following sense: | [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 | +| [130](https://github.com/ton-blockchain/TEPs/pull/130/files) | Rebase Jettons standard | 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 | From eb6f50b53bb81fcba34af5ae535a67e13ced92f8 Mon Sep 17 00:00:00 2001 From: omahs <73983677+omahs@users.noreply.github.com> Date: Fri, 12 Jul 2024 10:15:13 +0200 Subject: [PATCH 2/2] fix typos --- text/0085-sbt-standard.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/text/0085-sbt-standard.md b/text/0085-sbt-standard.md index b93f3106..ba222130 100644 --- a/text/0085-sbt-standard.md +++ b/text/0085-sbt-standard.md @@ -137,7 +137,7 @@ https://github.com/getgems-io/nft-contracts/blob/main/packages/contracts/sources #### Minting It can be done using basic NFT collection, SBT should be an item. In mint message additionally authority address should be passed, [after content](https://github.com/getgems-io/nft-contracts/blob/main/packages/contracts/sources/sbt-item.fc#L90). -Before mint, issuer is recommended to check the wallet code and confirm that it is standartized wallet and not some transferrable contract that can be sold to 3rd parties. +Before mint, issuer is recommended to check the wallet code and confirm that it is standardized wallet and not some transferrable contract that can be sold to 3rd parties. #### Proving you ownership to contracts SBT contracts has a feature that let you implement interesting mechanics with contracts by proving ownership onchain. @@ -241,11 +241,11 @@ slice calculate_sbt_address(slice collection_addr, cell sbt_item_code, int wc, i - **Why is this design the best in the space of possible designs?** -This design allows us to use SBT as certificates, with revoke and onchain proofs, and in the same time allows to make true SBT if authority in not set. +This design allows us to use SBT as certificates, with revoke and onchain proofs, and at the same time allows to make true SBT if authority in not set. - **What other designs have been considered and what is the rationale for not choosing them?** -Initially, the design similar to ETH with address-bounded tokens was considered, but it was extended with usefull onchain proofs and revoke option. +Initially, the design similar to ETH with address-bounded tokens was considered, but it was extended with useful onchain proofs and revoke option. - **What is the impact of not doing this?** @@ -253,7 +253,7 @@ Currently, TON have no owner-bounded token standard, so it is a problem to issue # Prior art -In ETH ([EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973)) - SBT was done as an NFT which could not be transferred between accounts at all. We did tha same but extended the logic with onchain proofs, and added authority which can revoke, so SBT can be used as fully functional certificate. +In ETH ([EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973)) - SBT was done as an NFT which could not be transferred between accounts at all. We did the same but extended the logic with onchain proofs, and added authority which can revoke, so SBT can be used as fully functional certificate. # Drawbacks [EIP-4973 ABT](https://eips.ethereum.org/EIPS/eip-4973) has equip/unequip mechanics which allows to show/hide SBT temporarily. In current proposal we can only destroy SBT. Actually not sure that show/hide logic is needed for us.