feat: Implement extra validations and alert when sending burn address in EVM transfer transactions

[OGPoyraz]

Description

This PR aims to integrate extra validations and alert when sending to burn address in EVM transfer transactions.
The list of the additions:

1. Extend isNative check to check asset address when creating transaction in send flow
2. Implement new "burnAddress" alert in transfer confirmations - this will also be raised if nested transactions have burn address too.
3. Filter contacts that has burn address to prevent proceeding to confirmations

Changelog

CHANGELOG entry: Implement extra validations and alert when sending burn address in EVM transfer transactions

Related issues

Fixes: https://github.com/MetaMask/MetaMask-planning/issues/6124

Manual testing steps

• You shouldn't be able to proceed to confirmation when you type 0x0000000000000000000000000000000000000000 as recipient
• Only possibility is to get a confirmation with burn address alert is from test-dapp

1. Go into the section where you can type recipient
2. Type 0x0000000000000000000000000000000000000000 to "To" and type something in "Amount" 0x123
3. When you create transaction, you should be able to see confirmation

Screenshots/Recordings

Before

After

Pre-merge author checklist

• I’ve followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I’ve included tests if applicable
• I’ve documented my code using JSDoc format if applicable
• I’ve applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Pre-merge reviewer checklist

• I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed).
• I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots.

---

Note

Adds burn-address detection across send/confirm flows (alerting, contact filtering, nested recipient support) and updates native-token checks for transaction typing.

• Confirmations:
  • Burn-address alert: New useBurnAddressAlert, AlertKeys.BurnAddress, RowAlertKey.BurnAddress, i18n strings, and metrics mapping; integrated into useConfirmationAlerts and rendered in from-to-row via AlertRow.
  • Recipient detection: Refactor useTransferRecipient and add useNestedTransactionTransferRecipients to extract recipients from nested transactions.
  • UI: InfoRow now supports optional label and renders labelChildren without a label; added labelContainerWithoutLabel style.
• Send flow:
  • Contacts: useContacts filters out EVM burn addresses using exported LOWER_CASED_BURN_ADDRESSES.
  • Native token check: isNativeToken now matches chain-specific native token addresses (getNativeTokenAddress); used in prepareEVMTransaction/submitEvmTransaction for typing.
• Validation/Utils:
  • Export LOWER_CASED_BURN_ADDRESSES from send-address-validations for reuse.
• Tests: Added/updated unit tests for burn-address alert, confirmation alerts aggregation, contacts filtering, recipient hooks (incl. nested), and generic.isNativeToken behavior.

^{Written by Cursor Bugbot for commit 2d0f1aa. This will update automatically on new commits. Configure here.}

[jpuri]

The 2 label children created now can be merged by adding condition.

[OGPoyraz]

{(hasLabel || labelChildren) && (
  <View style={{
    ...styles.labelContainer,
    ...(!hasLabel && styles.labelContainerWithoutLabel),
  }}>
    {hasLabel && (
      <>
        <Text variant={TextVariant.BodyMDMedium} color={variant}>
          {label}
        </Text>
        {labelChildren}
        {!labelChildren && tooltip && (
          <Tooltip
            content={tooltip}
            onPress={onTooltipPress}
            title={tooltipTitle ?? label}
          />
        )}
      </>
    )}
    {!hasLabel && labelChildren}
  </View>
)}

Wouldn't it look more complicated if we merge conditions here?

[jpuri]

nit: sorting imports

[OGPoyraz]

I am not going to address sortings anymore as lint rules of the repo doesn't dictate it.

[jpuri]

We can make label an optional parameter in AlertRow

[OGPoyraz]

Done

[jpuri]

Since we are showing alert of burn address do we need to filter it out here ?

[OGPoyraz]

It's still needed - if contact has burn address, it's still bypassing regardless of the validations. This is an extra guard to prevent error prone. We can also remove it once they remove possibility of adding burn address as contact.

[bschorchit]

Approving the copy added

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
3 Security Hotspots
93.4% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud