feat(solana): populate transaction_type on lifecycle events - #401
Battambang wants to merge 2 commits into
Conversation
Report send for MetaMask-originated transactions, token:approve for card approvals, and unknown for dApp transactions until they are classified from on-chain data.
929ccea to
005e610
Compare
|
| } | ||
|
|
||
| return origin === METAMASK_ORIGIN | ||
| ? TransactionType.Send |
There was a problem hiding this comment.
wouldn't this mark a metamask-originated swap as Send?
There was a problem hiding this comment.
Yes for this first design, the resolver treats every metamask originated request as a send on this snap. The unified send is the only Metamask flow that is actually a send; a swap or bridge goes through the same signAndSendTransaction path with no type, so it would be reported as send.
As snaps are not equals in the send* method called with alternative paths, so for thus where an emitted event cannot distinct a send flow/swap, a following improvement will follow by passing the type in the snap caller.
Also this current one will allow supporting to distinct Dapp events flows with further updates.
|
@metamaskbot publish-preview |
|
Preview builds have been published. Learn how to use preview builds in other projects. Expand for full list of packages and versions. |
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
All reviewed changes have no unresolved blocking issues.
Review effort: Lite
Findings: None
What changed in this PR
Adds Solana transaction classification to lifecycle analytics events.
Changes:
- Resolves transaction types with origin-based defaults and caller overrides.
- Propagates classifications through confirmation, cron, submission, and card approval flows.
- Adds tests and changelog documentation.
| File | Description |
|---|---|
packages/solana-wallet-snap/src/core/utils/transactionType.ts |
Resolves transaction classifications. |
packages/solana-wallet-snap/src/core/utils/transactionType.test.ts |
Tests classification behavior. |
packages/solana-wallet-snap/src/core/services/wallet/WalletService.ts |
Reports submitted transaction types. |
packages/solana-wallet-snap/src/core/services/wallet/WalletService.test.ts |
Tests submitted classifications. |
packages/solana-wallet-snap/src/core/services/confirmation/ConfirmationHandler.ts |
Adds types to confirmation lifecycle events. |
packages/solana-wallet-snap/src/core/services/confirmation/ConfirmationHandler.test.ts |
Tests confirmation classifications. |
packages/solana-wallet-snap/src/core/handlers/onCronjob/backgroundEvents/onTransactionRejected.ts |
Validates and forwards transaction types. |
packages/solana-wallet-snap/src/core/handlers/onCronjob/backgroundEvents/onTransactionBackgroundEvents.test.ts |
Tests background event forwarding. |
packages/solana-wallet-snap/src/core/handlers/onCronjob/backgroundEvents/onTransactionApproved.ts |
Validates and forwards transaction types. |
packages/solana-wallet-snap/src/core/handlers/onCronjob/backgroundEvents/onTransactionAdded.ts |
Validates and forwards transaction types. |
packages/solana-wallet-snap/src/core/handlers/onClientRequest/ClientRequestHandler.ts |
Classifies card approvals. |
packages/solana-wallet-snap/src/core/handlers/onClientRequest/ClientRequestHandler.test.ts |
Tests card approval propagation. |
packages/solana-wallet-snap/CHANGELOG.md |
Documents the analytics change. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Explanation
Stacked on #393. Transaction lifecycle events emitted by the Solana snap could not be attributed to a flow: the payload carried
originbut no classification, so an in-app send, a card token approval, and a dApp transaction were indistinguishable.This adopts the optional
transaction_typeproperty that #393 introduces in@metamask/snap-networks-utils, following the same pattern as the Bitcoin and Tron changes.resolveTransactionType(new,src/core/utils/transactionType.ts) classifies a transaction before broadcast. A Solana transaction is only a raw unsigned message at that point, so it is not inferred from its instructions. The classification uses the@metamask/keyring-apiTransactionTypevocabulary:transaction_typemetamask), including the unified send flowsendtoken:approveunknownA caller-supplied classification wins over the origin. The card approval needs that override: it is also MetaMask-originated, so the origin rule alone would report it as
send.Call sites
ConfirmationHandlerresolves the type once and carries it on the scheduledTransaction Added,Transaction Approved, andTransaction Rejectedevents, so all three agree.transactionTypeand forward it. They do not classify again.WalletService.signAndSendTransactionreports the type onTransaction Submitted.ClientRequestHandlerpassestoken:approvefor the card approval.Transaction Finalizedis unchanged.SignatureMonitoralready reports the type taken from the on-chain transaction.References
Checklist