Skip to content

fix: include safeTransferFrom in first-time interaction recipient decoding#8723

Open
vinistevam wants to merge 2 commits intomainfrom
vs/safe-transfer-first-time-interaction
Open

fix: include safeTransferFrom in first-time interaction recipient decoding#8723
vinistevam wants to merge 2 commits intomainfrom
vs/safe-transfer-first-time-interaction

Conversation

@vinistevam
Copy link
Copy Markdown
Contributor

@vinistevam vinistevam commented May 6, 2026

Explanation

Follow-up to #8130. Extends the first-time-interaction recipient-decoding fix to ERC721/ERC1155 safeTransferFrom transfers, which were not covered by the original change and silently suppress the first-time-interaction warning when sending NFTs to a new recipient.

Problem

getEffectiveRecipient in first-time-interaction.ts only treated tokenMethodTransfer and tokenMethodTransferFrom as token-transfer types. For tokenMethodSafeTransferFrom (ERC721 safeTransferFrom(from,to,tokenId), ERC721 safeTransferFrom(from,to,tokenId,data), and ERC1155 safeTransferFrom/safeBatchTransferFrom), it fell through to txParams.to — i.e. the NFT contract address — instead of decoding the actual recipient.
This caused two failure paths, both suppressing the warning:

  1. API call uses contract as recipient. getAccountAddressRelationship was queried with the NFT contract address as to. Any popular collection returns count > 0, so isFirstTimeInteraction = false and the alert never fires.
  2. Existing-transaction short-circuit matches on contract identity. Once a user had any prior safeTransferFrom to the same NFT contract, existingTransactions.find() matched on contract address and skipped the API call entirely, even when the new transfer's recipient was a never-before-seen address.
    Net effect: the first-time-interaction warning was silently suppressed for NFT transfers — including transfers to lookalike/attacker addresses.

Solution

Add TransactionType.tokenMethodSafeTransferFrom to TOKEN_TRANSFER_TYPES so getEffectiveRecipient decodes the recipient from txParams.data. The existing parsed?.args?._to ?? parsed?.args?.to ?? to fallback chain already handles all three relevant ABI shapes (ERC721 3-arg, ERC721 4-arg with bytes, and ERC1155 safeTransferFrom/safeBatchTransferFrom).
Comments updated to reflect that the rationale applies to ERC20/ERC721/ERC1155, not just ERC20.

References

Fixes https://consensyssoftware.atlassian.net/browse/CONF-1350

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed
  • I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

Note

Medium Risk
Updates first-time-interaction recipient resolution for safeTransferFrom token/NFT transfers, affecting when security warnings are shown and when API calls are skipped based on prior transactions.

Overview
Fixes first-time-interaction detection for NFT/token safeTransferFrom transfers by treating TransactionType.tokenMethodSafeTransferFrom as a token-transfer type and decoding the effective recipient from txParams.data instead of using the token contract address.

This ensures both the account-relationship API request and the existing-transaction short-circuit compare against the decoded recipient, and adds targeted tests covering ERC721 (3-arg/4-arg) and ERC1155 safeTransferFrom shapes plus effective-recipient matching behavior. Documentation/changelog entries were updated accordingly.

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

@vinistevam vinistevam force-pushed the vs/safe-transfer-first-time-interaction branch from 2bd91ea to 6dae597 Compare May 6, 2026 13:03
@vinistevam vinistevam force-pushed the vs/safe-transfer-first-time-interaction branch from 6dae597 to d80dab4 Compare May 6, 2026 13:20
@vinistevam vinistevam marked this pull request as ready for review May 6, 2026 13:54
@vinistevam vinistevam requested review from a team as code owners May 6, 2026 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant