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

Address resolver refactoring (#3291)

Public commit record

What the developer wrote

Authored by Serhii

66/100 · Adequate
Address resolver refactoring (#3291)

* restructure address resolver sources

* refactor address resolver into lookup service

* refactor address resolver to provider pattern

* use addressSource to drive providers & settings

* error handling

* add address source icons

* Update lib/core/address_validator.dart [skip ci]

Co-authored-by: Omar Hatem <omarh.ismail1@gmail.com>

* review fixes

* add validations to extractParsedAddress

* skip address resolver for valid addresses

* minor fix [skip ci]

* fix formattedName x[skip ci]

Co-authored-by: malik1004x <malikowskirobert@gmail.com>

* fix formatted name zano [skip ci]

Co-authored-by: malik1004x <malikowskirobert@gmail.com>

* address PR review comments

* add icons for new address source resolvers

* confirm parsed addresses in contacts

* minor fixes

* LNUrl for BTCLN only and contact name handling

---------

Co-authored-by: Omar Hatem <omarh.ismail1@gmail.com>
Co-authored-by: malik1004x <malikowskirobert@gmail.com>
✓ Descriptive subject✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This is a large code refactor of Cake Wallet's address resolver feature, which turns human-readable names (like Twitter handles, ENS domains, or email-style addresses) into cryptocurrency addresses. The change reorganizes existing lookup logic into a cleaner provider/service pattern and adds new address sources such as Nostr, BIP353, and Zcash names. It is primarily a structural rewrite rather than an obvious security fix, but because it touches many parts of how the app decides where to send money, any bugs in the new resolver could lead to payments going to the wrong address.

Recommended action

Treat this as a high-risk refactor of payment-critical code. Review each AddressLookupProvider for correct input validation, DNS/HTTP response validation, and error handling. Ensure the first-match behavior in AddressResolverService cannot be abused by a malicious or compromised provider to redirect funds. Remove or fix the unreachable multi-currency branch. Add integration tests that verify each provider returns only valid, expected addresses for known handles and rejects malformed or attacker-controlled input. Consider requiring user confirmation when a resolved address differs from a previously saved contact address.

Security signals we found

01

Large refactor of address-resolution code that determines payment destinations

02

New providers perform network/DNS lookups based on user-typed handles and return addresses used in send flows

03

Address extraction from Twitter/Mastodon/Nostr bios relies on regex matching rather than cryptographic verification

04

Dead/unreachable code in AddressResolverService.resolve (return [] before multi-currency TODO block)

05

BIP353 provider fetches DNSSEC TXT records and silently accepts either a silent-payment or on-chain address

06

Zcash.me provider scrapes an HTML page with a regex for Zcash addresses

07

Thorchain provider accepts any non-empty string under 30 characters that is not already a normal address

08

No explicit security advisory, CVE, or researcher attribution present in the commit

Risk score

Why this scored 39/100

Our methodology →
Potential impact 8/30
Exploitability 7/25
Stealth signal 6/15
Affected reach 9/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.