Normalize recipient addresses to checksum format#280
Draft
DRadmir wants to merge 8 commits into
Draft
Conversation
Closes #202. Recipient screen now applies EIP-55 checksum to EVM addresses on paste, QR scan, and ENS resolution, so the Confirm screen always sees normalized addresses. Non-EVM chains pass through unchanged. Both platforms route through the new Gemstone uniffi function checksum_address via Chain extensions, replacing the iOS WalletCore-based implementation and the Android operator/DI pattern.
…m-screen-should-always-have-addresses-in-checksum-format # Conflicts: # core
Rename AddressInputViewModel.resolvedAddress to address and update call sites accordingly across iOS (ManageContactAddressViewModel, RecipientSceneViewModel). Ensure decoded payment addresses are checksummed at decode time and use payment.address consistently for validation and recipient creation. Also fix a duplicate owner declaration and redundant null check in the Android RecipientViewModel.
…m-screen-should-always-have-addresses-in-checksum-format
…m-screen-should-always-have-addresses-in-checksum-format # Conflicts: # core
…m-screen-should-always-have-addresses-in-checksum-format # Conflicts: # core
Replaces Gemstone.checksumAddress free function with GemChainAddress constructor — already validates and now normalizes on construction. Chain.checksumAddress(_) is now throws on both platforms (matches the GemstoneException surface). Soft callsites (text input on every keystroke, QR scan into ViewModel state) wrap with try?/runCatching and fall back to the input on error. Callers inside throwing contexts propagate.
GemChainAddress::new validates address before normalizing, but gemstone's validate_address returns false for Bitcoin/XRP/Polkadot/Cardano (no validator implemented). That means a strict throws API would reject valid Bitcoin addresses outright — breaking ImportWalletSceneViewModel and the GemstonePrimitivesTests case. Make Chain.checksumAddress(_:) non-throws with a try?/runCatching fallback to the input. Soft semantics belong at this boundary; the underlying GemChainAddress.init can stay throws for callers that need strict validation. Drops the now-redundant try?/runCatching wrappers from callsites.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #202.
Recipient screen now applies EIP-55 checksum to EVM addresses on paste, QR scan, and ENS resolution, so the Confirm screen always sees normalized addresses. Non-EVM chains pass through unchanged.
Both platforms route through the new Gemstone uniffi function checksum_address via Chain extensions, replacing the iOS WalletCore-based implementation and the Android operator/DI pattern.