proxmox/docs/03-deployment/WEMIX_BRIDGE_VERIFICATION_STATUS.md

WEMIX Bridge Verification Status

Last Updated: 2026-04-20

Current Repo-Backed State

The current repo-backed status for WEMIX 1111 is still not fully live, but the lane is farther along than the older checklist snapshot suggested.

The strongest current evidence in this checkout says:

• CCIPWETH9_BRIDGE_WEMIX=0xD3AD6831aacB5386B8A25BB8D8176a6C8a026f04
• CCIPWETH10_BRIDGE_WEMIX=0xa4B9DD039565AeD9641D45b57061f99d9cA6Df08
• both addresses return deployed bytecode on https://api.wemix.com
• Chain 138 WETH9/WETH10 bridges already include the Wemix selector 5142893604156789321
• the Wemix WETH bridge contracts report Chain 138 as a configured destination
• the remaining gap depends on activation scope:
  • for inbound-only 138 -> 1111, the missing proof artifact is the main blocker
  • for full bidirectional activation, outbound fee coverage on the WEMIX-side bridges is still missing and both WEMIX bridge contracts currently hold 0 LINK

What is still not true yet:

• bridgeAvailable is not promoted to true in the generated deployment graph
• no machine-generated inventory yet treats the Wemix lane as live
• there is not yet a repo-backed successful bridge test receipt for 138 -> 1111

Primary references:

• cross-chain-pmm-lps/config/deployment-status.json
• reports/status/cw-mesh-deployment-matrix-latest.json
• docs/03-deployment/CHAIN_138_TO_WEMIX_1111_BRIDGE_COMPLETION_CHECKLIST.md
• reports/status/MULTI_NETWORK_DEPLOYMENT_AUDIT_20260419.md

Important Contradiction

Older checklist snapshots in this repo still show the WEMIX bridge env vars as unset and treat the lane as purely undeployed.

That is no longer accurate for the current operator environment. The more precise canonical statement is:

• the WEMIX bridge contracts are deployed
• the lane is wired in both directions
• the lane is still not promotable to the repo's current full-bidirectional live standard because outbound fee funding and a successful bridge test are still missing

Activation Modes

Inbound-only activation on WEMIX

Use this mode when the immediate target is to make 138 -> 1111 receipt operational.

Required:

1. CCIPWETH9_BRIDGE_WEMIX and CCIPWETH10_BRIDGE_WEMIX are deployed.
2. The Chain 138 bridges are configured to send to the WEMIX bridges.
3. The WEMIX bridges are configured to recognize Chain 138 as a valid peer.
4. A successful 138 -> 1111 proof transfer is recorded.

Not required for receive-only activation:

• LINK balance on the WEMIX bridge contracts
• WEMIX-side outbound CCIP fee funding

Reason:

• In the current bridge implementation, CCIP fees are paid on sendCrossChain(...).
• ccipReceive(...) on the WEMIX side validates and releases bridged assets but does not pay a fee.

Full bidirectional activation on WEMIX

Use this mode when 1111 -> 138 or 1111 -> other-chain sending must also be live.

Required in addition to the inbound-only conditions:

1. The WEMIX bridges can pay outbound CCIP fees.
2. CCIPWETH9Bridge may use LINK or native WEMIX, because feeToken can be updated to address(0).
3. CCIPWETH10Bridge still requires LINK, because its constructor and updateFeeToken(...) both forbid address(0).
4. Successful outbound proof transfer(s) are recorded from 1111.

What Would Change This Status

WEMIX can move to a verified-live state only after all of the following are repo-backed and consistent for the activation mode being promoted:

1. CCIPWETH9_BRIDGE_WEMIX and CCIPWETH10_BRIDGE_WEMIX remain recorded in the canonical env surface.
2. the operator checklist, routing docs, and generated inventory all agree on the same WEMIX bridge addresses and activation scope.
3. cross-chain-pmm-lps/config/deployment-status.json promotes 1111 out of non-live state and sets bridgeAvailable=true.
4. a successful proof transfer is recorded for the promoted mode.
5. if full bidirectional activation is the target, the WEMIX bridge contracts have outbound fee coverage:
   • WETH9: LINK or native WEMIX
   • WETH10: LINK

Verification Helper

The repo-native verification helper still exists:

cd smom-dbis-138
./scripts/deployment/verify-wemix-bridges.sh

But this should only be used after the deployment addresses themselves are first reconciled.

Required env remains:

• WEMIXSCAN_API_KEY
• WEMIX_RPC
• CCIPWETH9_BRIDGE_WEMIX
• CCIPWETH10_BRIDGE_WEMIX
• CCIP_ROUTER_WEMIX
• WETH9_WEMIX
• WETH10_WEMIX
• LINK_TOKEN_WEMIX

Build Assumption

If and when WEMIX verification is attempted, the repo documents the required build profile as:

• Solidity 0.8.20
• optimizer enabled
• optimizer runs 200
• viaIR=true
• evmVersion=paris