feat(predict): always use Permit2 fee auth and attach allowancesTx via feature flag

[matallui]

Description

When the Permit2 feature flag is enabled, the provider now:

1. Always uses Permit2 fee authorization — removes the on-chain allowance readiness gate that previously caused a fallback to Safe fee authorization when the Permit2 allowance wasn't set on-chain yet.
2. Attaches allowancesTx to the relay order when the proxy wallet lacks the required Permit2 allowances, so the relay can submit the allowance transaction on-chain before processing the order.
3. Simplifies previewOrder FAK logic — FAK order type is now determined purely from feature flags and Permit2 config, since placeOrder guarantees allowances are available.
4. Gates FAK on actual allowance readiness — for fee-bearing Buy orders, FAK requires both Permit2 fee auth AND confirmed allowance availability (on-chain or via allowancesTx).
5. Replaces on-chain Permit2 nonce bitmap with random nonce generation to avoid collisions on back-to-back orders and eliminate an RPC round-trip.

Changelog

CHANGELOG entry: null

Related issues

Fixes: https://consensyssoftware.atlassian.net/browse/PRED-720

Manual testing steps

Feature: Permit2 fee authorization and allowancesTx relay

  Scenario: user places a BUY order with Permit2 enabled and proxy wallet lacking allowances
    Given Permit2 feature flag is enabled
    And the proxy wallet does not have Permit2 allowances set on-chain

    When user places a BUY order with fees
    Then the order uses Permit2 fee authorization (not Safe fallback)
    And an allowancesTx is attached to the relay request
    And the order type is FAK (if fakOrdersEnabled)

  Scenario: user places a BUY order with Permit2 enabled and proxy wallet already has allowances
    Given Permit2 feature flag is enabled
    And the proxy wallet already has Permit2 allowances on-chain

    When user places a BUY order with fees
    Then the order uses Permit2 fee authorization
    And no allowancesTx is attached
    And the order type is FAK (if fakOrdersEnabled)

  Scenario: user places a SELL order with Permit2 enabled
    Given Permit2 feature flag is enabled

    When user places a SELL order (no fees)
    Then no fee authorization is generated
    And an allowancesTx is attached if proxy wallet lacks allowances
    And the order type is FAK (if fakOrdersEnabled)

  Scenario: allowancesTx generation fails gracefully
    Given Permit2 feature flag is enabled
    And getProxyWalletAllowancesTransaction throws an error

    When user places a BUY order with fees
    Then the order still submits (without allowancesTx)
    And the order type falls back to FOK (not FAK)
    And the error is logged but does not block order placement

Screenshots/Recordings

Before

https://www.loom.com/share/5bd9ee06414042e7a4ba944c666b1b9a

After

FOK + Permit2:
https://www.loom.com/share/1241e70594684c43bf86880ad29b9fdf

FAK + Permit2:
https://www.loom.com/share/94c01e493c6149ef806f09b32afe5430

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• 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 format if applicable
• I've applied the right labels on the PR (see labeling guidelines). 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.

---

Note

Medium Risk
Touches order submission/fee-collection logic and relayer request payloads; incorrect gating or allowance handling could cause orders to fail or use the wrong order type (FAK vs FOK). Changes are localized but impact a critical trading path.

Overview
Permit2 fee collection is now treated as always-available when enabled. placeOrder no longer falls back to Safe fee authorization based on an on-chain Permit2 allowance check, and previewOrder now selects FAK purely from feature flags/config.

Order submission can now include a prerequisite allowances transaction. When the Permit2 feature flag is on and the proxy wallet lacks allowances, placeOrder generates and sends an allowancesTx to the relayer (and logs/continues if generation fails); submitClobOrder includes this optional field in the request body. Permit2 nonce generation was also switched from on-chain bitmap reads to a random nonce to avoid extra RPC calls/collisions, with tests updated accordingly.

^{Written by Cursor Bugbot for commit 373d73b. This will update automatically on new commits. Configure here.}

[github-actions]

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.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

[github-actions]

🔍 Smart E2E Test Selection

• Selected E2E tags: SmokePredictions, SmokeWalletPlatform, SmokeConfirmations
• Selected Performance tags: None (no tests recommended)
• Risk Level: medium
• AI Confidence: 90%

click to see 🤖 AI reasoning details

E2E Test Selection:
The changes are focused on the Polymarket prediction market provider, specifically modifying how Permit2 allowances and order types (FAK/FOK) are handled. Key changes include:

1. Removed on-chain Permit2 allowance checks in favor of always using Permit2 fee authorization when enabled
2. Added new allowancesTx parameter to attach allowance transactions to orders for the relay to submit
3. Changed Permit2 nonce generation from on-chain bitmap reading to random generation to avoid RPC calls and nonce collisions

These changes affect the order placement flow in Polymarket predictions. Per the tag descriptions:

• SmokePredictions: Primary tag for Polymarket prediction market testing (opening positions, cashing out, claiming winnings)
• SmokeWalletPlatform: Required per SmokePredictions description as Predictions is a section inside Trending
• SmokeConfirmations: Required per SmokePredictions description as opening/closing positions are on-chain transactions

The risk is medium because:

• Changes are isolated to Polymarket provider (no shared components affected)
• Logic changes could affect order placement success/failure
• Comprehensive unit tests were updated alongside the changes
• No UI or navigation changes that could break other tests

Performance Test Selection:
No performance tests needed. The changes are internal logic modifications to the Polymarket provider that don't affect UI rendering, list performance, or data loading patterns. The change to random nonce generation actually reduces RPC calls (improves performance by avoiding on-chain reads). No changes to performance test infrastructure or critical user flow performance characteristics.

View GitHub Actions results

[github-actions]

⚠️ E2E Fixture Validation — Structural changes detected

Category	Count
New keys	66
Missing keys	7
Type mismatches	0
Value mismatches	7 (informational)

The committed fixture schema is out of date. To update, comment:

@metamaskbot update-mobile-fixture

View full details | Download diff report

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
93.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[caieu]

LGTM