TEP: discoverable jetton wallets #89
Conversation
|
I think this enhancement solves the jetton discovery/circular dependency problem between a new contract and its future jetton wallet. I currently working on a DEX and I encountered the same problem, and this solution does solve the problem in an elegant way. |
|
This is a crucial feature for the DEX systems that allows a Pool(Pair) rely on Jetton Minter+Jetton Discovery addresses only and do not store jetton wallet address to the init data. Also, there could be some solutions where this feature is usefull, e.g. a smart contract that is created dynamically and receives payments in jettons. This proposal solves the missing parts of the current Jetton implementation. |
text/0089-jetton-wallet-discovery.md
Outdated
| and either throw an exception if amount of incoming value is not enough to calculate wallet address or | ||
| response with message (sent with mode 64) | ||
|
|
||
| `report_wallet_address#ad30f94a query_id:uint64 wallet_address:MsgAddress owner_address:(Maybe ^MsgAddress) = InternalMsgBody;` |
There was a problem hiding this comment.
Please consider naming report_wallet_address return_wallet_address, because report has the context of marking an entity as malicious etc.
There was a problem hiding this comment.
other potential terms instead of "report" are "return" / "query" / "get"
There was a problem hiding this comment.
Currently we mimic names used in NFT for get_static_data.
I don't like return/query naming because I think it will looks a little bit counterintuitive to implement "return_wallet_address" method on recipient side to actually handle the response.
What about a take_static_data? Alternatively we can just use get_static_data op-code with high-bit set to true (to emphasize it is response), however we doesn't have TL-B notation for that.
Anyway, I don't think that this issue is important and any decision will work ok.
There was a problem hiding this comment.
We realised that op should represent the operation that a receiver should execute.
With that in mind the best way to name our ops is: provide_wallet_address and take_wallet_address.
- Smart-contract sends op:provide_wallet_address
- Discoverable minter receives op:provide_wallet_address and sends op:take_wallet_address
- Smart-contract receives op:take_wallet_address and handles the message
|
@NickNekilov @ex3ndr As independent but with experience and interest in the field experts, please review this TEP |
|
@EmelyanenkoK For me, it looks good. |
|
This pull request enters its Final Comment Period. It ends in 10 calendar days, 03.10.2022. |
|
LGTM! |
|
FCP is over. |
No description provided.