AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 34 Monero

CW-1208: Pay Anything EVM enahancements (#2600)

Public commit record

What the developer wrote

Authored by David Adegoke

76/100 · Adequate
CW-1208: Pay Anything EVM enahancements (#2600)

* feat: Pay Anything EVM enahancements

* ifx: Add baseEth to address validator switch case

* fix: Error detecting other wallet types

* feat: Preserve QR amount and other data through evm chain selection flow

* Update container color to surfaceContainer

* feat: Add support for Bitcoin Lightning Network detection

- Identify Base QR codes when scanned
- Display all available currencies for network
- Enhance detector to recognize lightning addresses

* fix: Update token selection for currently selected wallet

* fix: Improve token matching logic for EVM networks

* feat: Update selected currency when wallet is switched

* ui: Add chain badge to the swap confirmation bottomsheet

* fix: Asks to switch wallets even if the current wallet type is the same as the QR. Fix merge conflicts too

* fix: Handle matching logic internally and general cleanups

* fix: Terminate flow if address is not a valid parsed address

---------

Co-authored-by: Omar Hatem <omarh.ismail1@gmail.com>
Co-authored-by: tuxsudo <tuxsudo@tux.pizza>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit adds user-facing features to Cake Wallet for handling EVM (Ethereum-like) addresses and Bitcoin Lightning payments. It lets users pick which EVM network and token to use when scanning a generic 0x address, improves token matching, and adds detection for Lightning invoices, Lightning email-style addresses, and LNURL codes. There is no clear security bug in the diff, but the new address-detection logic is broad and could misclassify ordinary email addresses as Lightning payment addresses, which might confuse users or lead to incorrect payment flows.

Recommended action

Review the new address-detection heuristics before release. Tighten the Lightning-address regex so it does not match arbitrary email addresses, and add explicit allow-lists or separators for LNURL strings. Add unit tests for false-positive cases (e.g., regular emails, non-Lightning `LNURL...` strings). Verify that the EVM network-selection flow cannot be used to send funds to a contract address intended for a different chain, and that token deduplication by contract address does not hide legitimate user tokens.

Security signals we found

01

Overly permissive regex now classifies any email-like string as a Lightning address

02

LNURL detection uses a broad case-insensitive prefix match without length/character-set validation

03

EVM address detection treats all 0x40-hex strings as requiring network selection, shifting chain resolution to user choice

04

Token matching logic changed from title+tag equality to title+tag case-insensitive comparison with tag fallback semantics

05

No input sanitization changes visible for addresses passed into swap/payment flows

Risk score

Why this scored 34/100

Our methodology →
Potential impact 5/30
Exploitability 5/25
Stealth signal 5/15
Affected reach 10/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.