[apashchenko-top]

When a jetton master forces a burn (governance and stablecoin jettons), jetton_burn reaches the holder's wallet from the master. The burn action then named the master as the sender and took the burned amount off the master in the value flow. It also wasn't attributed to the holder, who saw "Something happened but we don't understand what".

JettonBurnAction now has Owner: the owner of the jetton wallet the tokens were burned from. It is always filled; for a normal burn Owner == Sender.

Changes

• core.InformationSource.JettonWalletsInfo returns the master and the owner of each jetton wallet. CollectAdditionalInfo uses it in place of JettonMastersForWallets, so it is still one lookup, and keeps owners in TraceAdditionalInfo.JettonOwners (serialized with the trace). Emulation fills owners as well. JettonMastersForWallets stays for its other callers.
• JettonBurnStraw takes the owner from additional info, then from the sender of burn_notification, and falls back to the burn's sender. The value flow debits the owner, and the owner is added to the action's accounts and to SubjectAccounts, so the burn shows up in the owner's history. Sender keeps its meaning, which the staking, Hipo and Affluent straws rely on.
• API: optional owner in JettonBurnAction and JettonOperation, and a description for sender. On a forced burn, simple_preview.accounts lists the master once instead of twice.

Compatibility

• core.InformationSource gains JettonWalletsInfo, so other implementations of it have to add the method. JettonWalletInfo.Owner is a *tongo.AccountID.
• core.JettonOperation.Owner is only passed through to the API here. litestorage has no jetton history, so a storage that returns jetton operations has to set it for burns.

Testing

• New tests: forced and normal burns, owner known only from additional info, only from burn_notification, and the fallback to the sender; burn preview accounts; additional info JSON round trip.
• Real traces, master vs this branch:
  • testnet RUBA forced burn 058304f3ba3c00b9360440e514039468e046fcaebbce42b4185b2003388266db: on master, the value flow debited the master and the owner saw no actions; now Owner is the holder, the holder is debited 150000000 and sees the burn.
  • mainnet NOT burn ba9b4511a0631758258bc784b3f82d3d2b97f0b351d6afe4243c9773f6888f3e: identical apart from Owner, which equals the sender.
• No golden file contains a JettonBurn action, so none changed. TestFindActions can't currently run locally: the public mainnet liteservers no longer serve the golden blocks.

Known limitations

• The owner comes from the wallet's get_wallet_data or from burn_notification and isn't checked against the master. Jetton transfer straws trust the sender of transfer_notification the same way.
• With neither additional info nor a burn_notification (a failed burn, a trace cached before this change), Owner falls back to the sender.