Wallet adoption

Current source routes ethereum: links through eth-url-parser, switches to the requested chain, and builds native, ERC-20 transfer, and approve flows. This is not general ABI-driven contract-call support.

The QR scanner and deep-link handler both route ethereum: URIs into a send flow. Current code supports native transfers and ERC-20 transfer, uses chain_id, and rejects other function names.

iOS tests cover native and ERC-20 transfers, scientific notation, ENS, and @chainId. Android tests confirm native payment QR parsing; equivalent Android ERC-20 behavior was not proven in the reviewed tests.

Mobile release 26.5.1 added ERC-681 QR scanning. The parser accepts address-only native requests and ERC-20 transfer with integer amounts and known @chainId values; it rejects native ?value= requests and non-transfer calls.

D'CENT's official announcement says its mobile app populates payment amount and beneficiary from EIP-681 QR codes for native assets and ERC-20 tokens across multiple EVM networks. Exact @chainId and arbitrary-call behavior are not documented.

Version 1.6.0/1.6.1 release notes claim EIP-681 send and receive support, specifically naming XAUt and USA₮. Public release notes do not define the accepted URI grammar or chain-selection behavior.

The provider's iOS listing claims universal QR and EIP-681 with full URI parameter support. No public source or conformance tests were located, so individual transaction shapes remain provider-claimed rather than code-verified.

Official docs reference EIP-681 but define a TokenPocket-specific ethereum:signTransaction protocol for cold-wallet signing. That is not evidence that canonical ERC-681 payment requests are accepted.

Current scanner code accepts ethereum:<address> as an address QR. It does not parse the ERC-681 path, query parameters, or @chainId suffix, so this is address import rather than payment-request support.