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

refactor: remove deprecated payment URI classes and unify URI handling with `ERC681URI` implementation (#3423)

Public commit record

What the developer wrote

Authored by Konstantin Ullrich

93/100 · Strong
refactor: remove deprecated payment URI classes and unify URI handling with `ERC681URI` implementation (#3423)

* refactor: remove deprecated payment URI classes and unify URI handling with `ERC681URI` implementation

* refactor: apply lint [skip ci]
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Uses a recognizable type or scope✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit is a code cleanup: it removes several old, near-duplicate payment-URI classes for Ethereum-compatible chains (Polygon, Base, Arbitrum, BSC) and makes every EVM chain use a single shared ERC-681 URI builder. It also adds a parser to read those URIs back. The change is mostly a refactor with no obvious security bug, but it touches code that formats crypto payment amounts and addresses, so a small risk of accidental parsing/formatting mistakes remains.

Recommended action

Treat as a routine refactor. Reviewers should verify that ERC681URI.fromUri handles malformed or malicious URIs gracefully (e.g., missing address, invalid hex, oversized amounts, negative values) without crashing or producing incorrect payment amounts. Consider adding unit tests for edge cases in amount parsing and for non-mainnet chain IDs.

Security signals we found

01

EVM payment URI generation now centralized in ERC681URI, reducing duplicated address/amount serialization logic

02

New ERC681URI.fromUri parses untrusted URIs and converts amount strings to BigInt via double parsing and formatFixed

03

_formatAmountForERC20 uses double.parse(amount) * 1e18 then BigInt.from, which can introduce floating-point rounding for token amounts

04

_formatAmountForNative uses double.parse and stringifies as scientific notation, potentially losing precision

05

_normalizeToIntegerWei accepts scientific notation, plain integers, and decimal ETH amounts and shifts by 18 decimals

06

_getTargetAddress uses a non-null assertion (!) on RegExp.firstMatch(path)!.group(0)!, which will throw if the path lacks a valid 0x address

07

No input validation or bounds checks on chainId or amount length before BigInt.parse/formatFixed

Risk score

Why this scored 14/100

Our methodology →
Potential impact 2/30
Exploitability 2/25
Stealth signal 1/15
Affected reach 3/15
Confidence 4/10
Evidence quality 2/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.