- A task asks to add a new non-EVM network to bridge or swaps.
- The request mentions chain ID allowlists, bridge constants, account detection, destination account checks, or send type resolution.
- The rollout needs both code-gated and LaunchDarkly-controlled behavior.
Confirm all are true before implementation:
- Wallet snap exists for the target network.
@metamask/bridge-controllersupports the target network.- Account type support exists in
@metamask/keyring-api. - Base network support already exists throughout the extension.
If any prerequisite is missing, stop and report the blocker instead of partially wiring the feature.
- Tron:
https://github.com/MetaMask/metamask-extension/pull/37683 - Bitcoin:
https://github.com/MetaMask/metamask-extension/pull/35597
Review both PRs before coding to mirror existing patterns and naming.
Use these entrypoints:
- SSOT policy + execution standard: this document
- OpenAI/Codex skill entrypoint:
.agents/skills/add-non-evm-swaps-bridge-network/SKILL.md($add-non-evm-swaps-bridge-network) - Cursor skill entrypoint:
.cursor/skills/add-non-evm-swaps-bridge-network/SKILL.md - Claude skill entrypoint:
.claude/skills/add-non-evm-swaps-bridge-network/SKILL.md - Claude command entrypoint:
.claude/commands/add-non-evm-swaps-bridge-network.md - Cursor command entrypoint:
.cursor/commands/add-non-evm-swaps-bridge-network.md - Windsurf and other harnesses: start prompts with
Follow docs/add-non-evm-swaps-bridge-network.md section "Agent Execution Standard (SSOT)".
For agent implementation or review tasks, follow this workflow exactly:
- Confirm the prerequisites are satisfied. If not, stop and report the blocker.
- Review the Tron and Bitcoin reference PRs before making edits.
- Update the code-gated bridge constants in
shared/constants/bridge.ts. - Update the relevant UI and state files for account detection, account compatibility, address validation, send type, and token filtering.
- Apply both rollout controls together: the build-time code gate and the LaunchDarkly
bridge-configtargeting. - Validate that the network stays hidden when the code gate is off, and only appears in allowed LaunchDarkly environments when the code gate is on.
- Run targeted tests for changed areas and note any remaining gaps.
File:
shared/constants/bridge.ts
Update all relevant entries for the new network:
ALLOWED_MULTICHAIN_BRIDGE_CHAIN_IDSALLOWED_BRIDGE_CHAIN_IDSNETWORK_TO_SHORT_NETWORK_NAME_MAPBRIDGE_CHAINID_COMMON_TOKEN_PAIR
Keep naming and ordering consistent with existing networks in the file.
Update these files:
ui/ducks/bridge/selectors.ts- Add
has<Network>Accountsselector. - Update
getFromChainsfiltering to include or exclude the network correctly.
- Add
ui/ducks/bridge/utils.ts- Export
is<Network>ChainIdhelper if no shared helper exists.
- Export
ui/pages/bridge/prepare/components/destination-account-picker-modal.tsx- Add destination account compatibility checks for the network.
ui/pages/bridge/hooks/useExternalAccountResolution.ts- Add network-specific address validation.
ui/pages/confirmations/hooks/send/useSendType.ts- Add send type handling for the network.
ui/selectors/multichain.ts- Add relevant testnet chain IDs to multichain detection logic.
ui/hooks/bridge/useTokensWithFiltering.ts- Filter out non-tradeable resources for this network when applicable.
Apply both controls together:
- Code gate (build-time gate, for example via builds config)
- LaunchDarkly flag targeting through
bridge-config
Important behavior:
- LaunchDarkly enables granular environment targeting.
- The code gate prevents accidental exposure when the feature is not released globally.
- Do not rely on only one of the two controls.
Before finishing, verify:
- The network is absent when the code gate is off.
- The network only appears in environments targeted by LaunchDarkly when the code gate is on.
- The from-chain list only includes the network when the required account or accounts exist.
- The destination account picker blocks incompatible account types.
- External address validation enforces network-specific format rules.
- The send confirmation path resolves to the correct send type.
- Token or resource filtering excludes non-tradeable assets where applicable.
Run targeted tests for changed areas, then broader bridge or swaps coverage:
- Unit tests for modified selectors, hooks, or utils.
- Unit or integration tests for bridge account picker and send type changes.
- E2E swaps or bridge flows for the new network path and regressions in existing networks.
If behavior changes, add or update tests in the closest existing test suites.
When using this standard, return:
Prerequisites CheckImplementation ChecklistFiles ChangedGating Behavior VerifiedTests RunRemaining Gaps