[dan437]

Explanation

Permit2 approve(address token, address spender, uint160 amount, uint48 expiration) transactions (selector 0x87517c45) were typed contractInteraction, because decodeTransactionData only knew the ERC-20, ERC-721, ERC-1155 and USDC ABIs. Clients choose the confirmation screen from the type, so these approvals got the generic contract interaction screen instead of the approval screen.

The decoder now also knows the Permit2 approve fragment, so determineTransactionType returns the existing tokenMethodApprove type for these transactions, including untyped nested transactions in a batch. Only approve is added, so other Permit2 methods such as transferFrom keep their current type. This is breaking for clients: txParams.to is the Permit2 contract rather than the token, so the token, spender, amount and expiration must be read from the calldata.

getSendRecipients and getEffectiveRecipient never read approve arguments, and Pay, bridge and Money Account code set nested approve types explicitly, so they are unaffected. The client-utils activity mapper already omits the token for Permit2 approvals, but it compared the method ID case-sensitively; it now lowercases it like its other method ID checks.

References

• Related to CONF-2202
• Extension and mobile changes that read the approved token from Permit2 calldata are in progress.

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