feat(earn): add geo-blocking for mUSD conversion feature#24501
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
c7b8d6b to
5daf61a
Compare
5daf61a to
e9d1bbd
Compare
Matt561
left a comment
There was a problem hiding this comment.
Pre-approving so you're not blocked. We should double-check if we want to block or allow by default.
426125b to
99b4a75
Compare
…e-to-geofence-the-convert-feature-so-that-it-is-not-available-in-countries-where-it-is-not-compliant
…e-to-geofence-the-convert-feature-so-that-it-is-not-available-in-countries-where-it-is-not-compliant
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsThis PR adds geo-blocking functionality for the mUSD conversion feature within the Earn module. The changes are:
The changes affect:
Since there are no E2E tests for the Earn/mUSD feature, and the changes are purely additive geo-blocking logic that doesn't affect any existing E2E test flows, no E2E tags need to be run. |
| showNetworkIcon: false, | ||
| selectedChainId: null, | ||
| }; | ||
| } |
There was a problem hiding this comment.
Missing isEmptyWallet in geo-blocked return path
Medium Severity
The shouldShowBuyGetMusdCta function's return object when the user is geo-blocked is missing the isEmptyWallet property that all other return paths include. The function's documented return type and consumer code (MusdConversionAssetListCta) expect isEmptyWallet to always be present. While the current component early-returns when shouldShowCta is false (preventing immediate runtime issues), this inconsistency breaks the function's contract, causes type inference issues, and could lead to bugs if consuming code is refactored.
There was a problem hiding this comment.
This won't break anything, I'll address it in another PR.
|



Description
What is the reason for the change?
As MetaMask Legal, we need to geofence the mUSD conversion feature so it is not available in countries where it is not compliant. This ensures regulatory compliance by restricting access to the convert feature in specific regions.
What is the improvement/solution?
This PR implements geo-blocking for the mUSD conversion feature using a two-tier approach:
The implementation leverages the existing RampsController geolocation data and integrates geo-blocking checks everywhere the mUSD conversion flow is enabled.
Key changes:
Changelog
CHANGELOG entry: Added geo-blocking for mUSD conversion feature to restrict access in non-compliant countries
Related issues
Fixes: https://consensyssoftware.atlassian.net/browse/MUSD-194
Manual testing steps
Screenshots/Recordings
Before
n/a
After
n/a
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Implements geofencing for the mUSD conversion experience across Earn surfaces, driven by remote config with a local fallback.
selectMusdConversionBlockedCountries(LDearnMusdConversionGeoBlockedCountries→{ blockedRegions: string[] }) with env fallbackMM_MUSD_CONVERSION_GEO_BLOCKED_COUNTRIESandparseBlockedCountriesEnv; defaults to['GB']viaDEFAULT_MUSD_BLOCKED_COUNTRIESuseMusdConversionEligibility(usesgetDetectedGeolocation; blocks by default when undefined) returningisEligible,isLoading,geolocation,blockedCountriesuseMusdCtaVisibility(Buy/Get, token-list-item, asset-overview CTAs),EarnBalance(requiresisGeoEligibleforisConvertibleStablecoin),EarnLendingBalance(asset overview CTA),TokenListItemandTokens(list CTA),useCustomAmount(mUSD tag).js.env.examplewithMM_MUSD_CONVERSION_GEO_BLOCKED_COUNTRIESand adds constants inmusd.tsWritten by Cursor Bugbot for commit 96cb7be. This will update automatically on new commits. Configure here.