proxmox/docs/07-ccip/CROSS_NETWORK_FUNDING_BOOTSTRAP_STRATEGY.md

# 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:

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

Focused examples:

```bash
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:

```bash
cd /home/intlc/projects/proxmox/smom-dbis-138
./scripts/deployment/audit-funding-bootstrap-routes.sh
```

## Recommended execution order

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