Files
proxmox/docs/07-ccip/CROSS_NETWORK_FUNDING_BOOTSTRAP_STRATEGY.md
defiQUG dbd517b279 Sync workspace: config, docs, scripts, CI, operator rules, and submodule pointers.
- Update dbis_core, cross-chain-pmm-lps, explorer-monorepo, metamask-integration, pr-workspace/chains
- Omit embedded publish git dirs and empty placeholders from index

Made-with: Cursor
2026-04-12 06:12:20 -07:00

7.4 KiB

Cross-Network Funding Bootstrap Strategy

Status date: March 29, 2026

This runbook captures the practical funding graph from Chain 138 after the live relay and recovery work.

Core constraint

Chain 138 uses a custom router that emits MessageSent events but does not natively deliver into public-chain CCIP bridges.

That means:

  • a native destination mapping like 138 -> Gnosis is configuration signal, not proof of a live route
  • the practical first-hop routes out of Chain 138 are the relay-backed lanes
  • the other public chains are best treated as destinations of the mainnet hub after mainnet is funded

This is confirmed by live execution:

  • the relay-backed 138 -> BSC route worked and was used to bootstrap mainnet
  • the original stuck 138 -> Mainnet transfer was completed after relay funding and replay
  • the earlier 138 -> Gnosis native-bridge attempt did not produce a live delivery path

Practical route matrix

Chain Practical route today Current prerequisite Best use
Mainnet Relay-backed direct Mainnet relay bridge must hold enough WETH Direct 138 -> Mainnet when relay inventory is funded
BSC Relay-backed direct BSC relay bridge only covers tiny sends right now Small direct 138 -> BSC, or bootstrap mainnet through BSC
Avalanche Relay-backed direct Avalanche relay bridge only covers tiny sends right now Tiny direct sends only, or top up inventory first
Gnosis Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Gnosis after Mainnet bridge/router fix
Cronos Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Cronos after Mainnet bridge/router fix
Celo Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Celo after Mainnet bridge/router fix
Polygon Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Polygon after Mainnet bridge/router fix
Arbitrum Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Arbitrum after Mainnet bridge/router fix
Optimism Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Optimism after Mainnet bridge/router fix
Base Mainnet hub currently blocked Bootstrap mainnet first and repair Mainnet fan-out 138 -> Mainnet, then Mainnet -> Base after Mainnet bridge/router fix
WEMIX Deploy-first Bridge not deployed and no gas seed Deploy and seed first

Best strategy now

1. Keep mainnet as the hub

This is the best practical topology.

Why:

  • 138 -> Mainnet is a real relay-backed route when the relay bridge has WETH
  • mainnet still has enabled fan-out mappings for Gnosis, Cronos, Celo, Polygon, Arbitrum, Optimism, and Base
  • the successful recovery proved that topping up mainnet relay inventory and replaying is operationally viable

2. Use BSC as the bootstrap and recovery helper

BSC is the best non-mainnet first hop today because:

  • the relay-backed lane is live
  • deployer already has native BNB gas
  • external bridging from BSC into mainnet is easy

Current limitation:

  • BSC relay inventory is only large enough for tiny sends right now

Operational use:

  • use it for small bootstrap steps
  • use it to refill mainnet when mainnet relay inventory is empty

3. Treat Avalanche as a tiny-send lane until it is topped up

Avalanche is structurally similar to BSC but currently weaker because:

  • the relay-backed lane exists
  • deployer has native gas
  • relay inventory is present but still below the 0.01 WETH working threshold

4. Treat the native-mapped chains as blocked mainnet destinations until the source path is repaired

Gnosis, Cronos, Celo, Polygon, Arbitrum, Optimism, and Base are still valuable, but their practical role is:

  • Mainnet -> target destinations after mainnet bootstrap
  • not proven direct Chain 138 first hops
  • currently blocked even as Mainnet fan-out targets on the active WETH9 source bridge path

Live corrections from 2026-04-04:

  • a direct 138 -> Arbitrum WETH send emitted a valid MessageSent event on the Chain 138 router
  • the active relay service still skipped that message because it was running the Mainnet destination profile
  • destination processing on Arbitrum remained untouched (processedTransfers == false)
  • a follow-on Mainnet -> Arbitrum send from MAINNET_CCIP_WETH9_BRIDGE=0xc9901ce2Ddb6490FAA183645147a87496d8b20B6 also failed on-chain in tx 0x97df657f0e31341ca852666766e553650531bbcc86621246d041985d7261bb07
  • debug tracing shows the revert occurs inside the Mainnet CCIP router 0x80226fc0Ee2b096224EeAc085Bb9a8cba1146f7D before any bridge event is emitted, so this is not a wallet-balance issue
  • the failed Mainnet send left deployer balances intact apart from gas; WETH and LINK were not stranded
  • read-only quote preflights now also revert for the current Mainnet WETH9 bridge across the tracked public-chain selectors: BSC, Avalanche, Gnosis, Cronos, Celo, Polygon, Arbitrum, Optimism, and Base

Treat that as confirmation of the current rule: these chains are meaningful destinations after Mainnet bootstrap, not safe first hops from Chain 138 unless a dedicated relay profile and router path are added first. More importantly, the current Mainnet WETH9 public fan-out path should be treated as blocked at the source bridge/router layer until it is repaired or replaced.

What to keep funded

The highest-payoff balances to maintain are:

  1. Mainnet relay bridge WETH
  2. Mainnet bridge LINK
  3. BSC relay bridge WETH
  4. Avalanche relay bridge WETH if Avalanche is needed

Cleaning up legacy return paths back to Chain 138 is still worthwhile, but it is lower priority than keeping the relay-backed lanes liquid.

Exact helpers

Live route printer:

cd /home/intlc/projects/proxmox/smom-dbis-138
./scripts/deployment/print-chain138-public-chain-unload-routes.sh

Focused examples:

TARGET_CHAIN=mainnet ./scripts/deployment/print-chain138-public-chain-unload-routes.sh
TARGET_CHAIN=bsc ./scripts/deployment/print-chain138-public-chain-unload-routes.sh
TARGET_CHAIN=polygon ./scripts/deployment/print-chain138-public-chain-unload-routes.sh
UNLOAD_AMOUNT_WEI=30000000000000000 ./scripts/deployment/print-chain138-public-chain-unload-routes.sh

Live audit:

cd /home/intlc/projects/proxmox/smom-dbis-138
./scripts/deployment/audit-funding-bootstrap-routes.sh
  1. Audit the current route and inventory state.
  2. If mainnet relay inventory is sufficient, use direct 138 -> Mainnet.
  3. If mainnet relay inventory is insufficient, use 138 -> BSC plus the proven external BSC -> Mainnet bridge pattern to refill mainnet.
  4. Keep Mainnet -> target fan-out blocked until the current Mainnet WETH9 source bridge quote/send path is repaired.
  5. Seed Avalanche relay inventory only if Avalanche needs to become an active first hop too.

Bottom line

The practical route graph is now:

  • first hop from Chain 138 through the relay-backed lanes
  • keep mainnet funded and use it as the hub once the Mainnet WETH9 public fan-out path is repaired
  • use BSC as the proven bootstrap and recovery helper
  • treat the native-mapped public-chain bridges as mainnet destinations unless a dedicated relay is added for them