feat(tron): populate transaction_type on lifecycle events - #399
Merged
Battambang merged 3 commits intoOct 1, 2026
Merged
Conversation
Battambang
added this pull request to stack #400
October 1, 2026 08:53
Base automatically changed from
feat/non-evm-transaction-type-lifecycle-events
to
main
October 1, 2026 14:09
Transaction lifecycle events could not be attributed to a flow: the payload carried `origin` but no classification, so an in-app send, a dApp `signTransaction`, and a staking operation were indistinguishable. Classify each event from the contract type with a new `mapRawTransactionType` helper, reusing the `@metamask/keyring-api` `TransactionType` vocabulary: - `ConfirmationHandler` reports the contract type for dApp `signTransaction` confirmations, and `send` for the unified send confirmation, which is only reachable from the send flow. - `SendService` and the Wallet Standard `signAndSendTransaction` report the type of the transaction they broadcast. - `CronHandler` reports the type resolved at submit time, carried through the background event, because `gettransactioninfobyid` does not return `raw_data` to re-derive it from. A smart-contract call is reported as `unknown`: it cannot be classified before confirmation without an ABI.
The entry referenced the stack base (#393) because the branch had no PR number yet. Use the actual PR.
Battambang
force-pushed
the
feat/tron-non-evm-transaction-type-lifecycle-events
branch
from
October 1, 2026 14:13
82f501a to
8f86c24
Compare
The cron job stored the submit-time classification as a string, which no longer matches the lifecycle event property.
|
mikesposito
approved these changes
Oct 1, 2026
Contributor
Author
|
@metamaskbot publish-preview |
Battambang
deleted the
feat/tron-non-evm-transaction-type-lifecycle-events
branch
October 1, 2026 14:53
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
Stacked on #393. Transaction lifecycle events emitted by the Tron snap could not be attributed to a flow: the payload carried
originbut no classification, so an in-app send, a dAppsignTransaction, and a staking operation were indistinguishable.This adopts the optional
transaction_typeproperty that #393 introduces in@metamask/snap-networks-utils, following the same pattern as the Bitcoin change.mapRawTransactionType(new,src/utils/transactionType.ts) classifies a transaction from its contract type using the@metamask/keyring-apiTransactionTypevocabulary:transaction_typeTransferContract,TransferAssetContractsendFreezeBalanceContract,FreezeBalanceV2Contractstake:depositUnfreezeBalanceContract,UnfreezeBalanceV2Contract,WithdrawExpireUnfreezeContractstake:withdrawunknownCall sites
ConfirmationHandlerreports the contract type for dAppsignTransactionconfirmations, andsendfor the unified send confirmation, which is only reachable from the send flow.SendServiceand the Wallet StandardsignAndSendTransactionreport the type of the transaction they broadcast.CronHandlerreports the type resolved at submit time, carried through theonTrackTransactionbackground event.Two notes on the classification
unknown. It cannot be classified before confirmation without an ABI, which matches the Bitcoin precedent of reportingunknownfor the arbitrary-PSBT confirmation.gettransactioninfobyiddoes not returnraw_data. Without this,Transaction Finalizedcould not report a type at all.References
Checklist