b8613905bd
- Submodule pins: dbis_core, cross-chain-pmm-lps, mcp-proxmox (local, push may be pending), metamask-integration, smom-dbis-138 - Atomic swap + cross-chain-pmm-lops-publish, deploy-portal workflow, phoenix deploy-targets, routing/aggregator matrices - Docs, token-lists, forge proxy, phoenix API, runbooks, verify scripts Made-with: Cursor
120 lines
4.6 KiB
Markdown
120 lines
4.6 KiB
Markdown
# 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:
|
|
|
|
```bash
|
|
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`
|