Repository navigation
feat(tron): classify swap, bridge, and send transactions in analytics - #434
Merged
Merged
Conversation
Battambang
force-pushed
the
feat/tron-flow-classification-analytics
branch
from
October 9, 2026 14:41
3d867df to
aa682db
Compare
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
The unified TRC20 send path lacks a service-level regression test, and the changelog omits part of the shipped behavior.
2 open findings
What changed in this PR
Adds Tron analytics classification for swaps, bridges, TRC20 sends, and approvals.
Changes:
- Adds transaction classification using asset chains and TRC20 selectors.
- Propagates classifications through submission, confirmation, and finalization events.
- Extends request validation and analytics tests.
| File | Description |
|---|---|
packages/tron-wallet-snap/src/utils/transactionType.ts |
Adds transaction-type resolution. |
packages/tron-wallet-snap/src/utils/transactionType.test.ts |
Tests resolver classifications. |
packages/tron-wallet-snap/src/services/send/SendService.ts |
Classifies unified sends. |
packages/tron-wallet-snap/src/services/confirmation/ConfirmationHandler.ts |
Classifies keyring transactions. |
packages/tron-wallet-snap/src/services/confirmation/ConfirmationHandler.test.ts |
Tests dApp classifications. |
packages/tron-wallet-snap/src/handlers/cronjob/cronjob.test.tsx |
Tests finalized classification propagation. |
packages/tron-wallet-snap/src/handlers/clientRequest/validation.ts |
Accepts optional asset IDs. |
packages/tron-wallet-snap/src/handlers/clientRequest/clientRequest.ts |
Classifies swaps and bridges. |
packages/tron-wallet-snap/src/handlers/clientRequest/clientRequest.test.ts |
Tests submission classifications. |
packages/tron-wallet-snap/CHANGELOG.md |
Documents analytics changes. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Battambang
force-pushed
the
feat/tron-flow-classification-analytics
branch
2 times, most recently
from
October 9, 2026 15:11
c78d685 to
f85e565
Compare
3 of 4 tasks
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Battambang
marked this pull request as ready for review
October 9, 2026 15:26
Battambang
force-pushed
the
feat/tron-flow-classification-analytics
branch
from
October 12, 2026 09:16
e065093 to
62e7473
Compare
Add resolveTransactionType, which classifies a transaction from the unified swap/bridge sourceAssetId/destAssetId options (cross-chain -> bridgeSend, same-chain -> swap) and otherwise falls back to the contract type and TRC20 call selector (transfer -> send, approve -> tokenApprove). Accept the optional sourceAssetId/destAssetId on signAndSendTransaction and use the resolver at the client request, keyring sign, and unified send emission sites so the classification is carried from submit through Transaction Finalized. This also fixes TRC20 sends, which previously reported unknown.
Battambang
force-pushed
the
feat/tron-flow-classification-analytics
branch
from
October 12, 2026 09:21
62e7473 to
0bc67e1
Compare
Contributor
Author
|
@metamaskbot publish-preview |
Contributor
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
Julink-eth
reviewed
Oct 12, 2026
| return undefined; | ||
| } | ||
|
|
||
| return callData.slice(0, 8).toLowerCase(); |
Contributor
There was a problem hiding this comment.
Are we sure the callData does not come with a 0x prefix ? Because if it does we won't get the right data selector, maybe we could strip it first to make sure ?
Contributor
Author
There was a problem hiding this comment.
Fixed with commit: d52c800 fix(tron): normalize contract data selectors
Contributor
Author
|
@metamaskbot publish-preview |
|
Julink-eth
approved these changes
Oct 12, 2026
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
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
Current state
The Tron Snap reports
transaction_typeon its transaction lifecycle analytics events, but the value is derived only from the raw Tron contract type. EveryTriggerSmartContract— which covers unified swap, unified bridge, and TRC20 token sends — therefore reportsunknown. As a result the three non-EVM user flows (unified swap/bridge, unified send, dApp send) cannot be told apart from the Snap payload alone.Solution
Add
resolveTransactionType, which classifies a transaction in two ways:options.sourceAssetIdandoptions.destAssetId, their CAIP-2 chains are compared: a cross-chain pair reportsbridgeSend, a same-chain pair reportsswap. This mirrors the Stellar Snap.transfer(0xa9059cbb) reportssend, TRC20approve(0x095ea7b3) reportstokenApprove, and anything else staysunknown.The optional
sourceAssetId/destAssetIdfields are added to thesignAndSendTransactionoptions struct, and the resolver is used at all three emission sites (client request, keyring sign, and unified send). The classification is resolved at submit time and already carried through theTrackTransactionbackground event, soTransaction Finalizedreports the same value.Non-obvious points
unknownand now reportssend.bridge-status-controlleronly starts sending the asset ids for Tron trades after this Snap ships, so this change must land first.References
Checklist