refactor: unify submitTx and submitIntent

[micaelae]

Explanation

Before

Currently, submitTx and submitIntent are separate entry points that have overlapping logic. This obscures how the flows differ and some behaviors are inconsistent, although needed by both.

• submitTx inlines long branching for non-EVM, batch/STX/7702, and default EVM paths, with history, rekeying, polling, and analytics mixed into each branch
• submitIntent is a second large path: intent-specific steps (approval, signing, API submit, synthetic tx) with its own history and polling/intent-manager logic

%%{init: {"themeVariables": {"noteBkgColor": "#ffffff", "noteTextColor": "#333333", "noteBorderColor": "#cccccc"}}}%%
sequenceDiagram
  participant Ext as Client
  participant BSC as BridgeStatusController

  Ext->>BSC: submitTx
  Note left of BSC: pick one flow based on quote + client <br/>flags. each branch has its own step<br/> sequence and error handling
  alt non-EVM chains
    Note right of BSC: submitApproval if Tron
    Note right of BSC: submitTrade
    Note right of BSC: setTradeMeta
    Note right of BSC: publishFailedEvent
  else gasless, STX or 7702
    Note right of BSC: submitBatch
    Note right of BSC: setTradeMeta
  else EVM
    Note right of BSC: submitApproval
    Note right of BSC: addHistoryItem
    Note right of BSC: submitTrade
    Note right of BSC: rekeyHistoryItem
    Note right of BSC: setTradeMeta
  else shared
    Note right of BSC: startPolling if Tron or bridge tx
    Note right of BSC: addHistoryItem if non-EVM or gasless
    Note right of BSC: publishCompletedEvent if non-EVM swap
  end

  Ext->>BSC: submitIntent
  Note right of BSC: submitApproval
  Note right of BSC: sign EIP-712 intent payload
  Note right of BSC: submit intent order via IntentManager
  Note right of BSC: add a synthetic tx using <br/> orderId from order submission
  Note right of BSC: addHistoryItem

Loading

After

This PR reorganizes tx submission into strategies (reduces quote-specific if conditions in the controller) and an action stream (strategies yield step results, and the controller uses those to update history, poll, and publish metrics). Each strategy yields results in their own order.

%%{init: {"flowchart": {"useMaxWidth": true, "padding": 16, "nodeSpacing": 32, "rankSpacing": 48}}}%%
flowchart TB
  subgraph top[" "]
    direction LR
    SI["submitIntent entrypoint<br/>proxies to submitTx"] --> ST["submitTx orchestrates tracing,<br/>metrics, error handling,<br/>and strategy execution"]
  end
  REG["executeSubmitFlow picks <br/> a strategy based on  <br/> quote and params"]

  subgraph s_non[" "]
    direction TB
    nn0["submitApproval"] -->  nn1["submitTrade"] --> nn2["setTradeMeta"] --> nn3["addHistoryItem"] --> nn4["startPolling"] --> nn5["publishCompletedEvent"]
  end

  subgraph s_batch[" "]
    direction TB
    bb0["submitBatch"] --> bb1["setTradeMeta"] --> bb2["addHistoryItem"]
  end

  subgraph s_intent[" "]
    direction TB
    iia["submitApproval"] --> iic["signIntentPayload"] -->  ii0["postIntentOrder"] --> iib["submitSyntheticTrade"] --> ii1["setTradeMeta"] --> ii2["addHistoryItem"] --> ii3["startPolling"]
  end

  subgraph s_evm[" "]
    direction TB
    eea["submitResetApproval"]--> eeb["submitApproval"]--> eec["addHistoryItem"] -->  ee1["submitTrade"] -->  ee2["rekeyHistoryItem"] --> ee3["setTradeMeta"]
  end

  ST --> REG
  REG --> lblNon["non-evm-strategy"]
  lblNon --> nn0
  REG --> lblBatch["batch-strategy"]
  lblBatch --> bb0
  REG --> lblIntent["intent-strategy"]
  lblIntent --> iia
  REG --> lblEvm["evm-strategy default"]
  lblEvm --> eea

  classDef stratLabel fill:#ffffff,stroke:#57606a,color:#1f2328
  class lblNon,lblBatch,lblIntent,lblEvm stratLabel

Loading

Each strategy is an async generator that yields step results for the BridgeStatusController to apply

%%{init: {"themeVariables": {"noteBkgColor": "#ffffff", "noteTextColor": "#333333", "noteBorderColor": "#cccccc"}}}%%
sequenceDiagram
  participant BSC as submitTx
  participant IDX as executeSubmitFlow
  participant STR as strategy

  BSC->>IDX: starts executing submit strategy
  IDX->>STR: selects and executes strategy (async generator)

  Note over STR,IDX: Each strategy yields a subset of these steps in different orders

  STR-->>BSC: setTradeMeta
  Note right of BSC: set the tradeMeta to be returned to the client

  STR-->>BSC: addHistoryItem
  Note right of BSC: include metadata in action payload and update state

  STR-->>BSC: rekeyHistoryItem
  Note right of BSC: update state historyItem with trade metadata

  STR-->>BSC: startPolling
  Note right of BSC: starts polling by the provided key (actionId, orderId, tradeMetaId)

  STR-->>BSC: publishCompletedEvent
  Note right of BSC: call trackUnifiedSwapBridgeEvent with txHistory key

  STR-->>IDX: generator is done
  IDX-->>BSC: return

  Note right of BSC: return tradeMeta

Loading

Example dev workflows

Add a step to some flows

1. Extend the SubmitStepResult with a new variant describing the step
2. Add any new controller calls to utils (avoid bridge-status-controller.ts)
3. Handle the new type in submitTx's generator processing loop
4. For each strategy generator that needs the step, yield the new SubmitStepResult when it should run (order matters)

Add a step that applies to all flows

1. Add any new controller calls to utils (avoid bridge-status-controller.ts)
2. Implement the step in submitTx, outside of the generator processing loop

Add logic that does not need BridgeStatusController state updates or events

These can stay within the relevant strategy as plain async code. No new SubmitStepResult type is needed if it doesn't touch bridge history, polling, or metrics publishing

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Medium Risk
Refactors core transaction/intent submission paths (including approvals, batching, history keys, and polling), so regressions could affect swap/bridge execution tracking and analytics despite largely preserving behavior.

Overview
Unifies submitTx and submitIntent by moving chain/quote-specific submission logic into new strategy async-generators (evm, batch, non-evm, intent) selected by executeSubmitFlow, while submitTx now just traces, iterates yielded steps, and performs history updates/polling/metrics.

History management is tightened: history items are now added with an explicit historyKey, rekeying now takes oldKey→newKey, and intent history uses the order UID as the history key while preserving the synthetic transaction id separately.

Batch/gas handling is refactored: getAddTransactionBatchParams now accepts tradeData[] (with optional assetsFiatValues) and centralizes gasless/7702 decisions; related tests/snapshots/jest coverage ignores are updated accordingly.

^{Reviewed by Cursor Bugbot for commit 5b79bb8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

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

^{❌ 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 5b79bb8. Configure here.}

[cursor]

Exported SubmitStrategy type is never used anywhere

Low Severity

The SubmitStrategy type is defined and exported but never imported or referenced anywhere in the codebase. The actual strategy selection in executeSubmitFlow uses direct function calls rather than this interface pattern. This is dead code that adds confusion about the intended architecture.

 

^{Triggered by project rule: Guidance for Bugbot}

^{Reviewed by Cursor Bugbot for commit 5b79bb8. Configure here.}

[cursor]

Metrics location priority silently changed for event tracking

Low Severity

The location resolution in #trackUnifiedSwapBridgeEvent changed priority. Previously, eventProperties?.location was preferred (the spread overrode the computed value). Now, when txMetaId is provided, history.location always wins because location is placed after the eventProperties spread. Additionally, the ternary now ignores eventProperties?.location entirely when txMetaId is truthy.

 

^{Reviewed by Cursor Bugbot for commit 5b79bb8. Configure here.}

[cursor]

Intent strategy omits approval trace wrapper present before

Low Severity

The submitIntentHandler calls handleEvmApprovals directly without wrapping it in traceFn(getApprovalTraceParams(...)), unlike the old submitIntent flow which traced the approval via this.#trace(getApprovalTraceParams(...), ...). The EVM strategy correctly wraps its approval in a trace, but the intent strategy does not, causing approval performance data to be lost for intent transactions.

Additional Locations (1)

• packages/bridge-status-controller/src/strategy/intent-strategy.ts#L151-L153

 

^{Reviewed by Cursor Bugbot for commit 5b79bb8. Configure here.}