feat: warn on self-sends in sendTransfer confirmation#607
Open
jeremytsng wants to merge 3 commits intomainfrom
Open
feat: warn on self-sends in sendTransfer confirmation#607jeremytsng wants to merge 3 commits intomainfrom
jeremytsng wants to merge 3 commits intomainfrom
Conversation
The dApp-initiated sendTransfer flow built ConfirmSendFormContext without checking whether the recipient address belonged to the sending account, so UnifiedSendFormView rendered self-sends as ordinary outgoing transfers. The signPsbt flow already runs account.isMine on each output. Bring sendTransfer to parity: derive isMine from the recipient's script_pubkey in JSXConfirmationRepository and surface a warning banner in the confirmation modal when it's true.
Address codex audit findings on the previous commit:
- isMine was optional and only populated by the dApp keyring path; the
in-app SendFlowUseCases.confirmSendFlow renders the same
UnifiedSendFormView and was missing the warning. Make isMine required
on ConfirmSendFormContext and derive it from the recipient script in
both producers.
- The new self-send copy was only added to en.json, so non-English
locales would render the raw {key} placeholder. Add the keys to every
locale file with the English text as a placeholder until translations
land.
- Adjust the warning copy to acknowledge that self-sends still pay
network fees.
- Regenerate the snap manifest shasum after the source changes.
Author
|
@metamaskbot publish-preview |
Contributor
|
Please, consider:
|
Contributor
|
Preview builds have been published. See these instructions for more information about preview builds. Expand for full list of packages and versions. |
Also regenerates snap.manifest.json shasum to match the current bundle output.
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
The dApp-initiated
sendTransferkeyring flow builtConfirmSendFormContextwithout checking whether the recipient address belonged to the sending account. The companionsignPsbtflow already runsaccount.isMineon each output (so it can label change vs. recipient), butsendTransferdid not — soUnifiedSendFormViewrendered self-sends as ordinary outgoing transfers with no indication that the funds were going back to the same wallet.This change brings
sendTransferto parity withsignPsbt:JSXConfirmationRepository.insertSendTransferderivesisMinefrom the recipient'sscript_pubkey(BdkAddress.from_string(recipient.address, account.network).script_pubkey→account.isMine(...)), with atry/catchdefaulting tofalseon parse failure — same defensive pattern used ininsertSignPsbt.UnifiedSendFormViewrenders a warningBannerabove the estimated changes whenisMine === true("Sending to your own address — the recipient address belongs to this wallet. The amount will stay in your account, but network fees still apply.").isMinederivation is added to the in-appSendFlowUseCases.confirmSendFlowpath so both producers ofConfirmSendFormContext(the dApp keyring path and the in-app send flow) behave consistently.isMineis a required field onConfirmSendFormContextso the type system enforces parity for any future producer.A note on visual treatment:
signPsbt's confirmation labels per-output rows as "Change" whenisMineis true.sendTransferenforces exactly one recipient, so labelling the only output as "Change" would be misleading — it's the actual recipient. A top-level Banner is the closest equivalent to the "alert" the suggestion describes, and is functionally equivalent (and arguably more prominent) than per-row labelling.References
Closes the security-audit suggestion: "sendTransfer Confirmation Does Not Check for Self-Sends".
Checklist
Note
Medium Risk
Changes the send-confirmation context and UI to detect and warn on self-sends, which could affect transaction confirmation behavior if address parsing or ownership checks are wrong. Logic is guarded with try/catch and covered by new tests, limiting blast radius to confirmation UX.
Overview
Adds self-send detection to the send confirmation flow by deriving a new required
ConfirmSendFormContext.isMineflag from the recipient address’script_pubkeyandaccount.isMine(...)(with a safe fallback tofalseon parse errors).Updates
UnifiedSendFormViewto show a warningBannerwhenisMineis true, and introduces new i18n message keys acrossmessages.jsonand all locale files (plus a changelog entry). Unit tests are expanded to coverisMinetrue/false and invalid-address scenarios in both the dAppinsertSendTransferpath and the in-appconfirmSendFlowpath.Reviewed by Cursor Bugbot for commit b198577. Bugbot is set up for automated code reviews on this repo. Configure here.