feat: intent-based swaps support

[dawnseeker8]

References

Relates to https://consensyssoftware.atlassian.net/browse/BETR-5

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, highlighting breaking changes as necessary
• I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

---

Note

Introduces intent-based swap/bridge flow end-to-end.

• Types/validators: Add Intent/IntentOrder schemas and optional quote.intent; extend StatusTypes with SUBMITTED
• BridgeStatusController: New submitIntent action; create synthetic TC tx, write history (originalTransactionId, srcTxHashes), and poll intent order status via new IntentApiImpl; map intent statuses to bridge/TC statuses; start/stop polling and track events (skip when featureId)
• API: Implement IntentApiImpl with submitIntent/getOrderStatus and status mapping
• Tests: Comprehensive unit tests for intent submission, polling, and validators; snapshot updates; jest coverage thresholds adjusted
• Misc: Export intent types; changelogs updated; .gitignore adds Emacs patterns

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

[matthewwalsh0]

Given the volume of code here, I'd recommend merging the bridge controllers code in isolation, then we can address any required changes to the TransactionController separately without blocking the full code changes.

[cursor]

Cancelled intent orders incorrectly mapped to submitted status

Medium Severity

The mapIntentOrderStatusToTransactionStatus function is missing a case for IntentOrderStatus.CANCELLED, causing it to fall through to the default and return TransactionStatus.submitted. However, in #updateBridgeHistoryFromIntentOrder, CANCELLED is correctly included in the isFailed array and mapped to StatusTypes.FAILED. This inconsistency means cancelled orders will show as "submitted" in the TransactionController but "failed" in the bridge history, creating a confusing user experience where the same order appears in different states across the UI.

Additional Locations (1)

• packages/bridge-status-controller/src/bridge-status-controller.ts#L763-L768

 

[cursor]

String txHashes ignored when not array format

Medium Severity

The IntentOrder type and schema explicitly allow metadata.txHashes to be either string[] or string, but the code only handles the array case. When txHashes is a single string, Array.isArray() returns false and metadataTxHashes becomes an empty array, silently discarding the transaction hash. If intentOrder.txHash is also undefined, this results in lost transaction hash data that won't be recorded in the history.

 

[cursor]

Cancelled intent orders mapped to wrong transaction status

Medium Severity

The mapIntentOrderStatusToTransactionStatus function is missing a case for IntentOrderStatus.CANCELLED. When an intent order is cancelled, it falls through to the default case and incorrectly returns TransactionStatus.submitted. This is inconsistent with #updateBridgeHistoryFromIntentOrder which correctly treats CANCELLED as a failed state. The result is that the bridge history shows the order as failed, but the TransactionController transaction shows it as submitted, causing conflicting UI states.

Additional Locations (1)

• packages/bridge-status-controller/src/bridge-status-controller.ts#L763-L768

 

[cursor]

String value in metadata.txHashes silently discarded

Medium Severity

The IntentOrder type defines metadata.txHashes as string[] | string, but the code at #updateBridgeHistoryFromIntentOrder only handles the array case. When the API returns a single string instead of an array, Array.isArray() returns false and the code falls back to an empty array, losing the transaction hash. This could cause transaction hashes to be missing from the history when the API returns txHashes as a single string value.

 

[cursor]

Intent transactions excluded from polling restart on browser reopen

High Severity

The #restartPollingForIncompleteHistoryItems method has two gaps that prevent intent-based transactions from resuming polling after browser restart. First, the status filter (lines 404-408) only checks for PENDING and UNKNOWN, but excludes the new StatusTypes.SUBMITTED status used by intent orders. Second, the filter at lines 415-422 only passes cross-chain bridge transactions, excluding same-chain intent swaps entirely. However, #startPollingForTxId correctly handles intent transactions via txId.startsWith('intent:'). This causes intent-based swaps to become stuck with no status updates if the user closes and reopens their browser while a swap is in progress.