Ota/7.88.88#30269
Open
weitingsun wants to merge 24 commits into
Open
Conversation
…29996) - feat(predict): add confirmation hook plumbing (#29914) ## **Description** This PR adds minimal Predict confirmation hook plumbing needed by the upcoming Polymarket Deposit Wallet migration. It wires TransactionController confirmation lifecycle hooks to PredictController while keeping Predict behavior as passthrough by default: - `beforePublish` delegates to `PredictController.beforePublish`, which currently returns `true`. - `publish` delegates to `PredictController.publish` before Transaction Pay / 7702 / Smart Transactions, and continues normal publishing when Predict returns no transaction hash. - If a future Predict publish implementation returns `{ transactionHash, isIntentComplete: true }`, TransactionController marks the latest transaction meta as `isIntentComplete` before returning the hash. This PR intentionally contains no Polymarket Deposit Wallet business logic. It is a small foundation PR for confirmation-team review. ## **Changelog** CHANGELOG entry: null ## **Related issues** Fixes: N/A — preparatory plumbing for the Predict Deposit Wallet migration. ## **Manual testing steps** ```gherkin Feature: Predict confirmation hook plumbing Scenario: non-Predict transactions continue through the normal publish flow Given a transaction is published through TransactionController And PredictController.publish returns no transaction hash When the publish hook runs Then Transaction Pay / 7702 / Smart Transaction publishing continues as before Scenario: Predict publish can complete a transaction intent Given PredictController.publish returns a transaction hash and isIntentComplete When the publish hook runs Then normal publishing is short-circuited And the latest TransactionController transaction meta is marked intent complete ``` Local validation run: ```bash yarn jest app/core/Engine/controllers/transaction-controller/transaction-controller-init.test.ts app/components/UI/Predict/controllers/PredictController.test.ts --runInBand yarn lint:tsc ``` ## **Screenshots/Recordings** N/A — no UI changes. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - N/A — hook plumbing only, no UI/runtime performance path manually exercised. - [x] I've tested with a power user scenario - N/A — hook plumbing only, no account/token rendering path changed. - [x] I've instrumented key operations with Sentry traces for production performance metrics - N/A — this PR only adds passthrough hook plumbing. For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches transaction publishing lifecycle by adding new hooks and a short-circuit path, which could affect submission ordering and integration with Pay/7702/Smart Transactions if miswired. Default behavior remains passthrough, reducing blast radius. > > **Overview** > Adds Predict-specific confirmation hook plumbing into the transaction submission lifecycle. TransactionController init now calls `PredictController:beforePublish` as a new `hooks.beforePublish`, and calls `PredictController:publish` at the start of `hooks.publish`, **short-circuiting** the rest of the publish pipeline when Predict returns a `transactionHash`. > > Updates PredictController to expose new messenger methods (`beforePublish`, `publish`) with default passthrough implementations, extends messenger action typings/permissions accordingly, and adds unit tests verifying delegation, call ordering, and the short-circuit behavior. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3f9d618. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [e5a8b17](e5a8b17) Co-authored-by: Luis Taniça <matallui@gmail.com>
…30019) - feat(predict): add deposit wallet deposit foundation (#29917) ## **Description** This is PR 2 for the Predict Deposit Wallet migration and is temporarily opened against `predict/dw-confirmation-hooks` to accelerate review while PR 1 is reviewed. Once PR 1 merges, this PR should be rebased/retargeted to `main`. Polymarket migrated new API users from the legacy Safe/proxy wallet model to deterministic Deposit Wallets. This PR adds the shared Predict Deposit Wallet foundation and enables the deposit flow while preserving legacy Safe behavior for users with existing Polymarket activity. Included changes: - Adds `walletType` to Predict account state and routes users by legacy Safe activity: - legacy Safe with raw Polymarket activity stays on Safe - legacy Safe without activity routes to Deposit Wallet - deployed legacy Safe + Activity API failure fails closed - Adds Deposit Wallet helper utilities for deterministic address derivation, relayer proxy calls, polling, EIP-712 batch execution, and CLOB balance-allowance sync. - Adds Deposit Wallet deposit preflight to deploy/setup allowances in `beforePublish`. - Adds legacy Safe migration sweep planning for zero-activity users with stranded pUSD/USDC.e. - Updates deposit preparation so Deposit Wallet users receive pUSD transfers to their Deposit Wallet. - Updates balance/position lookup to use the active Predict wallet. - Adds post-confirm best-effort CLOB balance-allowance sync for Deposit Wallet deposits and deposit-and-order deposits. - Keeps order and claim execution support out of scope for this PR; those follow in separate PRs. Validation performed: - `yarn jest app/components/UI/Predict/providers/polymarket/depositWallet.test.ts app/components/UI/Predict/providers/polymarket/preflight/legacySafeMigration.test.ts app/components/UI/Predict/providers/polymarket/preflight/depositWallet.test.ts app/components/UI/Predict/providers/polymarket/preflight/v2AllowanceRequirements.test.ts app/components/UI/Predict/providers/polymarket/PolymarketProvider.test.ts app/components/UI/Predict/controllers/PredictController.test.ts app/components/UI/Predict/hooks/usePredictAccountState.test.ts --runInBand --forceExit` - `yarn lint:tsc` ## **Changelog** CHANGELOG entry: Added support for Polymarket Deposit Wallet deposits in Predict ## **Related issues** Fixes: [PRED-858](https://consensyssoftware.atlassian.net/browse/PRED-858) ## **Manual testing steps** ```gherkin Feature: Predict Deposit Wallet deposits Scenario: new Predict user deposits to a Polymarket Deposit Wallet Given the selected wallet has no legacy Safe Polymarket activity And the user opens Predict deposit When user confirms a Predict deposit Then the Deposit Wallet setup preflight runs through the relayer And the pUSD deposit transaction transfers funds to the derived Deposit Wallet And the deposit completes without changing legacy Safe users' behavior ``` ```gherkin Feature: Legacy Safe compatibility Scenario: existing Predict user with legacy Safe activity deposits Given the selected wallet has a deployed legacy Safe with Polymarket activity When user prepares a Predict deposit Then Predict keeps using the legacy Safe path And no Deposit Wallet relayer preflight is run ``` ## **Screenshots/Recordings** N/A — core/provider flow changes covered by tests and manual wallet-flow validation. ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. [PRED-858]: https://consensyssoftware.atlassian.net/browse/PRED-858?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **High Risk** > High risk because it changes how Predict chooses deposit addresses and adds new pre-publish relayer/batch execution plus post-confirm sync, which directly affects deposit and deposit+order transaction flows and fund routing. > > **Overview** > Adds first-class support for Polymarket **Deposit Wallet** accounts in Predict by extending `AccountState` with `walletType` and routing users to either legacy Safe or a deterministic deposit wallet based on legacy Safe deployment and Polymarket Activity API results (failing closed on API errors). > > Implements deposit-wallet infrastructure in the Polymarket provider: deterministic address derivation, relayer proxy calls/polling, EIP-712 batch execution, allowance-preflight planning (excluding Permit2), and a legacy Safe “sweep” preflight to migrate stranded USDC.e/pUSD to the deposit wallet. > > Updates the deposit pipeline to (1) build deposits targeting the deposit wallet (with optional sweep), (2) run a new `beforePublish` deposit-wallet preflight to ensure wallet deployment and required allowances, and (3) on confirmed deposits/deposit+order, invalidate cached account state and best-effort sync CLOB balance/allowance—waiting for that sync before placing the follow-on order. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c5f61e2. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [36204c5](36204c5) [PRED-858]: https://consensyssoftware.atlassian.net/browse/PRED-858?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Luis Taniça <matallui@gmail.com>
…30022) - feat(predict): add Deposit Wallet order flow (#29933) ## **Description** Adds Predict order placement support for Polymarket Deposit Wallet accounts on top of the Deposit Wallet deposit foundation. This PR: - Adds the `POLY_1271` Polymarket signature type. - Adds Deposit Wallet / ERC-1271 order signing via the `TypedDataSign` wrapper. - Routes order maker/signer fields from active Predict account state. - Uses Deposit Wallet maker/signer for Deposit Wallet users. - Preserves legacy Safe order signing for grandfathered Safe users. - Runs Deposit Wallet create/setup preflight before submitting Deposit Wallet orders. - Passes an optional signed legacy Safe migration sweep as `allowancesTx` for Deposit Wallet orders, so stranded pUSD/USDC.e can be swept before the backend relays the order. - Skips Safe trade allowance and Permit2 fee preflight for Deposit Wallet orders. - Continues signing CLOB L2 headers with the EOA owner address. This PR is temporarily stacked on `predict/dw-deposit-foundation` while PRs 1 and 2 are under review, and should be rebased/retargeted after those merge. Validation run locally: ```bash yarn jest app/components/UI/Predict/providers/polymarket/protocol/orderCodec.test.ts app/components/UI/Predict/providers/polymarket/PolymarketProvider.test.ts --runInBand yarn lint:tsc ``` ## **Changelog** CHANGELOG entry: Fixed Predict order placement for Polymarket Deposit Wallet accounts ## **Related issues** Fixes: [PRED-860](https://consensyssoftware.atlassian.net/browse/PRED-860) ## **Manual testing steps** ```gherkin Feature: Predict Deposit Wallet order flow Scenario: Deposit Wallet user places a Predict order Given a Predict user is routed to a Polymarket Deposit Wallet And the Deposit Wallet has enough pUSD balance and required setup from the deposit flow When the user places a Predict buy or sell order Then the order is signed with POLY_1271 semantics And the order is submitted successfully to the Polymarket CLOB Scenario: Deposit Wallet user places first order before wallet setup Given a Predict user is routed to a Polymarket Deposit Wallet And the Deposit Wallet still needs creation or allowance setup When the user places a Predict buy or sell order Then the app creates/sets up the Deposit Wallet before order submission And the order is submitted successfully to the Polymarket CLOB Scenario: Deposit Wallet user has funds stranded in legacy Safe Given a Predict user is routed to a Polymarket Deposit Wallet And the deterministic legacy Safe has sweepable pUSD or USDC.e When the user places a Predict buy or sell order Then the signed legacy Safe sweep is included as allowancesTx And the backend can submit the sweep before relaying the order Scenario: Legacy Safe user places a Predict order Given a Predict user is grandfathered to the legacy Safe wallet When the user places a Predict buy or sell order Then the order continues to use legacy Safe signing and preflight behavior ``` ## **Screenshots/Recordings** ### **Before** N/A - provider/order-signing change only. ### **After** N/A - provider/order-signing change only. ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. [PRED-860]: https://consensyssoftware.atlassian.net/browse/PRED-860?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes core Predict order submission/signing paths, adding a new ERC-1271 signing format and deposit-wallet preflight flows; mistakes could cause failed or incorrectly-signed orders. Legacy Safe behavior is preserved but now shares more conditional branching. > > **Overview** > Adds end-to-end order placement support for Polymarket **Deposit Wallet** accounts. > > Order submission now derives maker/signer from the resolved account state and, for deposit-wallet users, performs a create/allowance batch preflight before signing/submitting. Deposit-wallet orders use the new `SignatureType.POLY_1271` and are signed via `signProtocolOrder` using an ERC-7739 `TypedDataSign` wrapper, while Safe users keep legacy Safe signing. > > Fee collection and Safe trade preflight steps (Permit2 fee authorization + allowances tx) are skipped for deposit-wallet orders; instead an optional legacy Safe migration sweep can be attached as `allowancesTx`. L2 CLOB headers are consistently signed using the EOA owner address. Tests were expanded to cover both Safe and deposit-wallet order flows and the new signing payload. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit b2bf1ee. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [36fb960](36fb960) [PRED-860]: https://consensyssoftware.atlassian.net/browse/PRED-860?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Luis Taniça <matallui@gmail.com>
…30033) - feat(predict): add deposit wallet claim flow (#29936) ## **Description** Adds Deposit Wallet support for the Predict claim flow. Polymarket Deposit Wallet users still create a normal MetaMask claim confirmation so the transaction is visible in activity, but the signed confirmation transaction is not published directly. Instead, Predict intercepts pending claim transactions in the publish hook, submits the actual claim calls as a Polymarket Deposit Wallet relayer `WALLET` batch, waits only until the relayer returns a transaction hash, and returns that hash to TransactionController. This PR preserves legacy Safe claim behavior: Safe users continue to sign and publish the existing Safe claim transaction path. Key changes: - Add Deposit Wallet claim planning that builds relayer calls from claimable positions. - Mark Deposit Wallet claim confirmation transactions as externally signed before signing. - Publish Deposit Wallet claims through the relayer batch and return as soon as a transaction hash is available. - Trigger best-effort CLOB balance-allowance sync after confirmed claims. - Wire Predict pending-claim context into `beforeSign` and `publish`. - Add `skipInitialGasEstimate` to claim confirmation batch creation. ## **Changelog** CHANGELOG entry: Fixed Predict claims for Polymarket Deposit Wallet users. ## **Related issues** Fixes: [PRED-859](https://consensyssoftware.atlassian.net/browse/PRED-859) ## **Manual testing steps** ```gherkin Feature: Predict Deposit Wallet claim flow Scenario: Deposit Wallet user claims resolved positions Given a Predict user is routed to a Polymarket Deposit Wallet And the user has claimable positions When the user starts the claim flow Then MetaMask shows the normal claim confirmation When the user approves the confirmation Then the claim is submitted through the Polymarket Deposit Wallet relayer And MetaMask activity tracks the returned transaction hash Scenario: legacy Safe user claims resolved positions Given a Predict user is routed to a legacy Safe wallet And the user has claimable positions When the user approves the claim confirmation Then the existing Safe claim publish path is used ``` ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [ ] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [ ] I've completed the PR template to the best of my ability - [ ] I've included tests if applicable - [ ] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [ ] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [ ] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [ ] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [ ] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. [PRED-859]: https://consensyssoftware.atlassian.net/browse/PRED-859?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes claim transaction `beforeSign`/`publish` behavior and introduces a new relayer-based submission path for deposit-wallet users, which could affect transaction lifecycle and activity tracking if metadata or batch matching is wrong. > > **Overview** > Adds **deposit-wallet support for Predict claims** by intercepting pending `predictClaim` transactions in `PredictController` and delegating `beforeSign`/`publish` to new provider hooks (`beforeSignClaim`, `publishClaim`). Deposit-wallet claims are now marked as *externally signed* before signing and are published via a Polymarket relayer `WALLET` batch (planned by new `planDepositWalletClaim`) while legacy Safe claims continue to pass through. > > Claim batch submission is tweaked to set `skipInitialGasEstimate` and include the MATIC collateral gas token, and `confirmClaim` now triggers a best-effort deposit-wallet collateral allowance sync after claim confirmation. Tests are expanded/added across `PredictController`, `PolymarketProvider`, and new `preflight/claim` coverage for requirement filtering and call ordering. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c11a3c6. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [3751d9a](3751d9a) [PRED-859]: https://consensyssoftware.atlassian.net/browse/PRED-859?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Luis Taniça <matallui@gmail.com>
…30036) - fix(predict): disable Deposit Wallet withdrawals (#29941) ## **Description** Temporarily disables the Predict withdraw entry point for Deposit Wallet users until Deposit Wallet withdrawals are fully supported. Deposit Wallet users with a Predict balance now see a dismissible bottom sheet explaining that withdrawals are currently unavailable and to contact Customer Service for assistance. Legacy/Safe users continue through the existing withdraw flow. This is intentionally a temporary UI guard and should be removed once Deposit Wallet withdraw support ships. ## **Changelog** CHANGELOG entry: Fixed Predict withdrawals to show a temporary unavailable message for Deposit Wallet users. ## **Related issues** Fixes: [PRED-869](https://consensyssoftware.atlassian.net/browse/PRED-869) ## **Manual testing steps** ```gherkin Feature: Predict Deposit Wallet withdrawals Scenario: Deposit Wallet user sees withdrawals unavailable notice Given a Predict Deposit Wallet user has an available balance When user taps Withdraw on the Predict balance card Then a bottom sheet is displayed with the title "Withdrawals are currently unavailable" And the bottom sheet description says "For assistance withdrawing your funds, please contact Customer Service." And tapping "Got it" dismisses the bottom sheet Scenario: Safe user keeps the existing withdraw flow Given a Predict Safe user has an available balance When user taps Withdraw on the Predict balance card Then the existing withdraw flow is opened And the withdrawals unavailable bottom sheet is not displayed ``` Validation run locally: - `yarn lint:tsc` - `yarn eslint app/components/UI/Predict/components/PredictWithdrawUnavailableSheet/PredictWithdrawUnavailableSheet.tsx app/components/UI/Predict/components/PredictWithdrawUnavailableSheet/PredictWithdrawUnavailableSheet.test.tsx --cache` - `yarn jest app/components/UI/Predict/components/PredictWithdrawUnavailableSheet/PredictWithdrawUnavailableSheet.test.tsx --runInBand` printed PASS for all tests, then hit the known local Jest OOM after completion. ## **Screenshots/Recordings** ### **Before** N/A - PR changes the Deposit Wallet withdraw press behavior from launching unsupported withdraw handling to displaying a temporary unavailable bottom sheet. ### **After** Manually verified in the iOS simulator: Deposit Wallet users see the withdrawals unavailable bottom sheet and can dismiss it with "Got it". <img width="300" alt="Simulator Screenshot - mm-blue - 2026-05-08 at 20 39 36" src="https://github.com/user-attachments/assets/544500b4-2456-4dfd-b6af-e56bbb844c41" /> ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] N/A - no performance-sensitive code path changed; Android performance testing is not applicable. - Ideally on a mid-range device; emulator is acceptable - [x] N/A - no performance-sensitive code path changed; power-user scenario testing is not applicable. - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] N/A - no new production performance instrumentation is required for this temporary UI guard. - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. [PRED-869]: https://consensyssoftware.atlassian.net/browse/PRED-869?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Changes the withdrawal entry point behavior in the Predict balance card based on detected wallet type, which can block or allow access to a funds-moving flow. Risk is mitigated by added unit/E2E coverage and a conservative default that disables withdraw while account state is unknown. > > **Overview** > **Disables Predict withdrawals for Deposit Wallet users** by gating the `Withdraw` button on `usePredictAccountState` and routing Deposit Wallet presses to a temporary “withdrawals unavailable” bottom sheet. > > Adds the new `PredictWithdrawUnavailableSheet` component (with i18n strings and test IDs) and wires it into `PredictFeed` so it can be opened via a ref callback; Safe/legacy users continue to call `withdraw()` as before, and the Withdraw button is disabled until wallet type is resolved. > > Updates unit tests and Detox/E2E mocks to cover wallet-type branching and keep the withdraw smoke test on the legacy Safe path (new `LEGACY_SAFE_WALLET_ADDRESS` + `POLYMARKET_LEGACY_SAFE_ACCOUNT_MOCKS`). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c60a694. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> [b44e29a](b44e29a) [PRED-869]: https://consensyssoftware.atlassian.net/browse/PRED-869?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ [PRED-869]: https://consensyssoftware.atlassian.net/browse/PRED-869?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Luis Taniça <matallui@gmail.com>
This reverts commit 1591929.
This reverts commit 19aca8a.
This reverts commit 0e7dd19.
This reverts commit baf7ce4.
This reverts commit 0207b3c.
## **Description** Adds a `7.76.3` section to `CHANGELOG.md` covering the 5 cherry-picked PRs on `release/7.76.3-ota` ## **Changelog** CHANGELOG entry: null ## **Related issues** Cherry-picked PRs included in `release/7.76.3-ota`: - #29914 — feat(predict): add confirmation hook plumbing - #29917 — feat(predict): add deposit wallet deposit foundation - #29933 — feat(predict): add Deposit Wallet order flow - #29936 — feat(predict): add deposit wallet claim flow - #29941 — fix(predict): disable Deposit Wallet withdrawals ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. Made with [Cursor](https://cursor.com) <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk documentation-only change: updates `CHANGELOG.md` release notes and compare links with no runtime or logic impact. > > **Overview** > Adds a new `7.76.3` section to `CHANGELOG.md` documenting the Predict Polymarket Deposit Wallet work (deposit/order/claim flows, publishing hooks) and the temporary withdrawal disablement for deposit-wallet users. > > Updates the footer compare links so `[Unreleased]` now compares from `v7.76.3`, and adds the `[7.76.3]` compare link (`v7.76.0...v7.76.3`). > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 271161b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Cursor <cursoragent@cursor.com>
## **Description** Re-enables the `ci` workflow on pull requests whose base is `stable` (the release `release/X.Y.Z -> stable` PRs). PR [#29305](https://github.com/MetaMask/metamask-mobile/pull/29305/changes#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03f) accidentally added `branches-ignore: stable` in `.github/workflows/ci.yml`, which makes the workflow refuse to run on any PR whose base branch is `stable`. We have branch protection on `stable`, which requires the `Check all jobs pass` and `All jobs pass` status checks. So `Check all jobs pass` / `All jobs pass` never appeared (no `ci` run) on the release PR : #29584, so the release PR currently cannot be merged. ## **Changelog** CHANGELOG entry: null ## **Related issues** Refs: #29584 (release/7.76.0 PR currently blocked by the missing CI checks) Refs: #29305 (introduced the regression) ## **Manual testing steps** N/A ## **Screenshots/Recordings** ### **Before** N/A ### **After** N/A ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. #### Performance checks (if applicable) - [x] I've tested on Android - Ideally on a mid-range device; emulator is acceptable - [x] I've tested with a power user scenario - Use these [power-user SRPs](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/edit-v2/401401446401?draftShareId=9d77e1e1-4bdc-4be1-9ebb-ccd916988d93) to import wallets with many accounts and tokens - [x] I've instrumented key operations with Sentry traces for production performance metrics - See [`trace()`](/app/util/trace.ts) for usage and [`addToken`](/app/components/Views/AddAsset/components/AddCustomToken/AddCustomToken.tsx#L274) for an example For performance guidelines and tooling, see the [Performance Guide](https://consensyssoftware.atlassian.net/wiki/spaces/TL1/pages/400085549067/Performance+Guide+for+Engineers). ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- Generated with the help of the pr-description AI skill --> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Low risk: only adjusts GitHub Actions trigger filters so CI runs on `stable`-based pull requests again, with no production code changes. > > **Overview** > Re-enables the `ci` GitHub Actions workflow for pull requests targeting `stable` by removing the `pull_request.branches-ignore: stable` filter, allowing required CI checks to run on release PRs again. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 6e0ed20. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: Cursor <cursoragent@cursor.com>
# 🚀 v7.76.0 Testing & Release Quality Process Hi Team, As part of our new **MetaMask Release Quality Process**, here’s a quick overview of the key processes, testing strategies, and milestones to ensure a smooth and high-quality deployment. --- ## 📋 Key Processes ### Testing Strategy - **Developer Teams:** Conduct regression and exploratory testing for your functional areas, including automated and manual tests for critical workflows. - **QA Team:** Focus on exploratory testing across the wallet, prioritize high-impact areas, and triage any Sentry errors found during testing. - **Customer Success Team:** Validate new functionalities and provide feedback to support release monitoring. ### GitHub Signoff - Each team must **sign off on the Release Candidate (RC)** via GitHub by the end of the validation timeline (**Tuesday EOD PT**). - Ensure all tests outlined in the Testing Plan are executed, and any identified issues are addressed. ### Issue Resolution - **Resolve all Release Blockers** (Sev0 and Sev1) by **Tuesday EOD PT**. - For unresolved blockers, PRs may be reverted, or feature flags disabled to maintain release quality and timelines. ### Cherry-Picking Criteria - Only **critical fixes** meeting outlined criteria will be cherry-picked. - Developers must ensure these fixes are thoroughly reviewed, tested, and merged by **Tuesday EOD PT**. --- ## 🗓️ Timeline and Milestones 1. **Today (Friday):** Begin Release Candidate validation. 2. **Tuesday EOD PT:** Finalize RC with all fixes and cherry-picks. 3. **Wednesday:** Buffer day for final checks. 4. **Thursday:** Submit release to app stores and begin rollout to 1% of users. 5. **Monday:** Scale deployment to 10%. 6. **Tuesday:** Full rollout to 100%. --- ## ✅ Signoff Checklist Each team is responsible for signing off via GitHub. Use the checkbox below to track signoff completion: # Team sign-off checklist - [x] Accounts - [x] Assets - [x] Bots Team - [x] Card - [x] Confirmations - [x] Core Extension UX - [x] Core Platform - [x] Delegation - [x] Design System - [x] Earn - [x] Engagement - [x] Mobile Platform - [x] Mobile UX - [x] Money Movement - [x] Networks - [x] Perps - [x] Portfolio - [x] Predict - [x] Rewards - [x] Social & AI - [x] Swaps and Bridge - [x] team-accounts - [x] Wallet Integrations This process is a major step forward in ensuring release stability and quality. Let’s stay aligned and make this release a success! 🚀 Feel free to reach out if you have questions or need clarification. Many thanks in advance # Reference - Testing plan sheet - https://docs.google.com/spreadsheets/d/1tsoodlAlyvEUpkkcNcbZ4PM9HuC9cEM80RZeoVv5OCQ/edit?gid=404070372#gid=404070372
Bring in OTA hotfix, release changelog, and cherry-picked fixes from the 7.76.3 OTA release line.
Contributor
|
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. |
Contributor
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsE2E Test Selection:
Tag selection rationale:
No other tags are warranted as changes are isolated to the Predictions/Polymarket feature and its transaction controller integration. Performance Test Selection: |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 98e18f6. Configure here.
| transactionID, | ||
| requireCompletion: true, | ||
| }); | ||
| } |
Contributor
There was a problem hiding this comment.
Exported function unused in production code
Low Severity
executeDepositWalletBatchAndWaitForCompletion is exported and tested but never imported by any production consumer. The same execute-batch → get-transaction-ID → wait-for-completion logic is manually implemented inline in PolymarketProvider.ensureDepositWalletReady and publishClaim, making this function dead code that adds maintenance burden without providing value.
Reviewed by Cursor Bugbot for commit 98e18f6. Configure here.
|
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
4 participants
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.
Description
Changelog
CHANGELOG entry:
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Performance checks (if applicable)
trace()for usage andaddTokenfor an exampleFor performance guidelines and tooling, see the Performance Guide.
Pre-merge reviewer checklist
Note
High Risk
Touches Predict transaction lifecycle (
beforePublish/publish/beforeSign) and Polymarket provider signing/publishing paths, which are core, security- and funds-adjacent flows. Risk is elevated due to new relayer interactions, wallet-type routing (Safe vs Deposit Wallet), and new async side-effect ordering around deposits and order placement.Overview
Adds Deposit Wallet support for Predict’s Polymarket integration alongside legacy Safe behavior.
Introduces new controller hooks (
beforePublish,publish) and provider APIs to run deposit-wallet preflight (wallet creation/deployment + allowance setup), publish deposit-wallet claim batches via the relayer, and sync deposit-wallet CLOB balance/allowance after confirmed deposits/claims; deposit-and-order now waits for this sync before placing the order.Updates account-state resolution to choose between legacy Safe and a derived deposit-wallet address (using Polymarket activity as the Safe keep condition), adjusts signing for deposit-wallet orders (1271 / ERC-7739 wrapper), and adds a temporary UI guard that disables Predict withdrawals for deposit-wallet users and shows a new “withdrawals unavailable” bottom sheet. Includes extensive new/updated tests and changelog entry for
7.76.3.Reviewed by Cursor Bugbot for commit 98e18f6. Bugbot is set up for automated code reviews on this repo. Configure here.