I have an idea how to improve NFT and jettons: Authorized-Controllable Tokens.
For example, consider someone who needs to transfer NFT to other person at specified time. First person would request timer to schedule message. Then he needs to allow this message to transfer NFT; he could transfer NFT to timer account first but then (1) NFT wouldn't be visible on the first account, (2) in case of some bugs NFT will remain on timer account forever, (3) someone could request another message transferring NFT from timer smart-contract to her first.
So I propose to create Authorized-Controllable Tokens. Owner of some assets sends an authorization message (contanining address of controlled tokens, allowed operations and so on) to smart-contract. At needed time smart-contract sends a message with Merkle proof of its authorization to NFT/jetton wallet contract, token checks the proof and performs the requested operation.
If owner wishes to revoke control on his token, he could send a message revoke_authorizations_before to his token (not to authorized contract, because that would need to increase Merkle proof to prove that there were no deauthorize messages).
Oct 31, 2022, 12:59 PM
You just invented deferred transactions
Oct 31, 2022, 1:05 PM
I've looked through the docs and found out that Authorized-Controllable Tokens would need information about TON blocks. So I have three proposals for TON developers and validators:
1. add shardchain configuration into either global config parameters or c7 (temporary data)
2. add most recent masterchain and shardchain block data into c7 (not representation hashes but full data)
3. possibly add representation hash of some key block (for example, last block signed by previous validators group) into each block serialization to reduce sizes of Merkle proof of transaction existence
1. add shardchain configuration into either global config parameters or c7 (temporary data)
2. add most recent masterchain and shardchain block data into c7 (not representation hashes but full data)
3. possibly add representation hash of some key block (for example, last block signed by previous validators group) into each block serialization to reduce sizes of Merkle proof of transaction existence
Nov 1, 2022, 1:18 PM
I would suggest you to write a paper on your proposal if you are serious about it.
After that, file it as TEP.
Nov 1, 2022, 1:49 PM
TEP template requires me to discuss idea in TON Dev Chats first 🙂
Nov 1, 2022, 1:51 PM
OK
break;
break;
Nov 1, 2022, 1:57 PM