-
Notifications
You must be signed in to change notification settings - Fork 350
Description
Currently, in the TEP-74 (Jetton standard), the burn internal message handler in the jetton-wallet contract decreases the sender’s balance and sends a notification only to the Jetton-master contract. The standard does not provide a mechanism to notify the original address (the burner) that the burn was processed successfully (TEP-74 link).
It would be highly beneficial to include a burn_notification message that is sent back to the burner’s address (the response_destination) to confirm the successful burn. This would:
• Improve UX: Wallets, UIs, or apps could display instant confirmation to users that their burn request completed.
• Enhance integration: Smart contracts or other services invoking burns could track confirmations programmatically.
• Ensure clarity: Reduces ambiguity about whether a burn has been executed, especially when response_destination might not receive visual feedback otherwise.
⸻
Proposed addition:
Define a burn_notification internal message schema, similar to transfer_notification, sent by the jetton-wallet back to the response_destination upon successful burn. Example TL-B schema:
burn_notification# query_id:uint64 amount:(VarUInteger 16) sender:MsgAddress = InternalMsgBody;
• query_id: same as in the burn request
• amount: number of jettons burnt
• sender: address of the burner (owner of the jetton-wallet)
⸻
Benefits:
• Aligns the burn operation’s feedback loop with the transfer operation, where the transfer_notification message informs the recipient of a successful transfer.
• Enables Wallet Burn History: With a standardized burn_notification message, wallets could track burn transactions directly and annotate them in the user’s transaction history as Burn operations, improving clarity and auditability.
• Ensures consistency across message patterns, making it easier for developers and end users to understand transaction flows.