Skip to content

Prevent send-to-self for EVM assets#6026

Open
j0ntz wants to merge 1 commit into
developfrom
jon/evm-prevent-send-to-self
Open

Prevent send-to-self for EVM assets#6026
j0ntz wants to merge 1 commit into
developfrom
jon/evm-prevent-send-to-self

Conversation

@j0ntz

@j0ntz j0ntz commented Jun 10, 2026

Copy link
Copy Markdown
Contributor

CHANGELOG

Does this branch warrant an entry to the CHANGELOG?

  • Yes
  • No

Dependencies

none

Requirements

If you have made any visual changes to the GUI. Make sure you have:

  • Tested on iOS device
  • Tested on Android device
  • Tested on small-screen device (iPod Touch)
  • Tested on large-screen device (tablet)

Description

Asana: https://app.asana.com/0/1215088146871429/1213742694496279

Previously a user could paste their own wallet's receive address into the Send
flow and successfully send to themselves. For EVM assets this is always a
mistake (a single static address per wallet across all EVM chains).

This rejects an entered/pasted/scanned address in the Send flow when it matches
the sending wallet's own receive address, scoped to EVM wallets, surfacing the
error "You cannot send to the same wallet" instead of allowing the send.

  • The guard lives in AddressTile2.changeAddress, right after the URI is parsed
    — the single choke point every entered address passes through (used only by
    SendScene2). It compares parsedUri.publicAddress against
    getReceiveAddress({ tokenId: null }) case-insensitively (EVM addresses are
    checksummed hex).
  • Cross-wallet "self transfer" to a different wallet of the same asset
    (handleSelfTransfer, which excludes the current wallet) is unaffected.
  • Non-EVM assets are unaffected (UTXO change/consolidation to an own address
    stays legal).
  • The duplicated isEvmWallet helper (previously copied in SendScene2 and
    PendingTxModal) is consolidated into CurrencyInfoHelpers.

Verified in-app on the iOS simulator with an EVM (Fantom) wallet: entering the
wallet's own address shows the error and leaves the recipient empty, while a
different address is accepted and advances to the amount entry. See the attached
screenshots.


Note

Low Risk
Send-path validation only for EVM wallets; no auth or payment logic changes, and behavior is limited to rejecting own-address recipients.

Overview
Blocks EVM send flows when the parsed recipient is the same wallet’s own receive address (paste, scan, or manual entry), since one static address is shared across EVM chains and self-sends are almost always user error.

The check runs in AddressTile2 immediately after URI parsing: for EVM wallets it compares parsedUri.publicAddress to getReceiveAddress({ tokenId: null }) case-insensitively and shows send_to_self_error_message instead of accepting the address. Cross-wallet “Myself” transfers and non-EVM sends are unchanged.

isEvmWallet (WalletConnect eip155 namespace) is moved into CurrencyInfoHelpers and reused from SendScene2 and PendingTxModal, removing duplicated helpers.

Reviewed by Cursor Bugbot for commit 15ac90a. Bugbot is set up for automated code reviews on this repo. Configure here.

Reject an entered/pasted/scanned address in the Send flow when it matches the
sending wallet's own receive address, scoped to EVM wallets (single static
address per wallet, so a self-send is always a mistake). Cross-wallet self
transfer to a different wallet of the same asset is unaffected.

Consolidate the duplicated isEvmWallet helper into CurrencyInfoHelpers.
@j0ntz

j0ntz commented Jun 10, 2026

Copy link
Copy Markdown
Contributor Author

📸 Test evidence (iOS, EVM Fantom wallet)

agent proof 1213742694496279 01 own receive address

agent proof 1213742694496279 01 own receive address

agent proof 1213742694496279 02 send to self error

agent proof 1213742694496279 02 send to self error

Captured by the agent's in-app test run (build-and-test).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant