smom-dbis-138/docs/deployment/CHAIN138_MAINNET_CCIP_RESOLUTION.md

ChainID 138 → Mainnet CCIP Configuration Resolution

Date: 2025-01-18
Status: 🔄 RESOLUTION IN PROGRESS

---

Problem Summary

Issue: ChainID 138 bridge contracts revert with empty data (0x) when attempting to configure Mainnet destinations via addDestination().

Symptoms:

• ✅ admin() function works - admin confirmed
• ❌ addDestination() reverts with empty data
• ❌ getDestinationChains() reverts with empty data
• ❌ destinations(uint64) mapping query reverts
• ❌ Immutable variables (ccipRouter, weth9, feeToken) revert when queried

---

Root Cause Analysis

Contract Code Review

From CCIPWETH9Bridge.sol lines 228-243:

function addDestination(
    uint64 chainSelector,
    address receiverBridge
) external onlyAdmin {
    require(receiverBridge != address(0), "CCIPWETH9Bridge: zero address");
    require(!destinations[chainSelector].enabled, "CCIPWETH9Bridge: destination already exists");
    
    destinations[chainSelector] = DestinationChain({
        chainSelector: chainSelector,
        receiverBridge: receiverBridge,
        enabled: true
    });
    destinationChains.push(chainSelector);
    
    emit DestinationAdded(chainSelector, receiverBridge);
}

Possible Causes

1. Destination Already Configured (MOST LIKELY)

   • If destinations[chainSelector].enabled == true, the second require() fails
   • Empty revert suggests the contract may have custom error handling or the destination was configured during deployment

2. Contract Bytecode Mismatch

   • Immutable variables reverting suggests deployed bytecode differs from source
   • Could be an older version or custom deployment

3. Storage Slot Issues

   • If using a proxy pattern, storage slots may be incorrect

---

Resolution Strategies

Strategy 1: Event Log Verification (RECOMMENDED)

Check if destinations were already configured by searching for DestinationAdded events:

# Check WETH9 Bridge
cast logs --from-block 0 \
  --address 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6 \
  "DestinationAdded(uint64,address)" \
  --rpc-url http://192.168.11.211:8545

# Check WETH10 Bridge  
cast logs --from-block 0 \
  --address 0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e \
  "DestinationAdded(uint64,address)" \
  --rpc-url http://192.168.11.211:8545

If events found: Destinations already configured → Configuration complete ✅

Script: scripts/configuration/check-existing-destinations.sh

---

Strategy 2: Test Bridge Functionality

Attempt a test cross-chain transfer to verify if configuration actually works despite query failures:

# This would test if the bridge can actually send to Mainnet
# even if querying destinations fails

Note: This requires LINK tokens and proper fee configuration.

---

Strategy 3: Use Foundry Script with Better Error Handling

Create a Foundry script that provides better revert reason decoding:

// TestBridgeConfig.s.sol
function testAddDestination() external {
    CCIPWETH9Bridge bridge = CCIPWETH9Bridge(0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6);
    uint64 mainnetSelector = 5009297550715157269;
    address mainnetBridge = 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6;
    
    try bridge.addDestination(mainnetSelector, mainnetBridge) {
        console.log("Success!");
    } catch Error(string memory reason) {
        console.log("Error:", reason);
    } catch (bytes memory lowLevelData) {
        console.log("Low-level error:", vm.toString(lowLevelData));
    }
}

---

Strategy 4: Direct Storage Inspection

Check storage slots directly to verify destination state:

# Calculate storage slot for destinations mapping
# Slot = keccak256(abi.encode(chainSelector, destinations.slot))

# For Mainnet selector 5009297550715157269
cast keccak256 $(cast --to-uint256 5009297550715157269) \
  $(cast keccak256 $(cast sig "destinations(uint64)"))

# Then read storage slot
cast storage 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6 \
  <calculated_slot> \
  --rpc-url http://192.168.11.211:8545

---

Immediate Actions

✅ Completed

1. ✅ LINK token verified at 0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03
2. ✅ Wallet has ~999,980 LINK tokens
3. ✅ Admin address confirmed: 0x4A666F96fC8764181194447A7dFdb7d471b301C8

🔄 In Progress

1. Event Log Verification: Check if DestinationAdded events exist
2. Storage Inspection: Direct storage slot reading
3. Functional Testing: Test actual bridge transfer

⏳ Pending

1. Update fee token configuration if needed
2. Fund bridge contracts with LINK for fees
3. Verify cross-chain message delivery

---

Configuration Parameters

ChainID 138 Bridges:

• WETH9 Bridge: 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6
• WETH10 Bridge: 0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e

Mainnet Target:

• Chain Selector: 5009297550715157269
• WETH9 Bridge: 0x3304b747E565a97ec8AC220b0B6A1f6ffDB837e6
• WETH10 Bridge: 0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e

LINK Token (ChainID 138):

• Address: 0xb7721dD53A8c629d9f1Ba31a5819AFe250002b03
• Wallet Balance: ~999,980 LINK ✅

---

Testing Checklist

• Verify DestinationAdded events exist (Strategy 1)
• Check storage slots for destination state (Strategy 4)
• Test Foundry script with error handling (Strategy 3)
• Perform test cross-chain transfer (Strategy 2)
• Verify Mainnet bridge can receive messages
• Test bidirectional flow: 138 → Mainnet → 138

---

Scripts Available

1. check-existing-destinations.sh - Event log verification
2. diagnose-chain138-bridge-revert.sh - Comprehensive diagnostics
3. configure-chain138-direct.sh - Direct configuration attempt
4. verify-bridge-configuration.sh - Configuration verification

---

Next Steps

1. Run event log check when RPC is available:

   ./scripts/configuration/check-existing-destinations.sh
   

2. If no events found, proceed with storage inspection and Foundry script testing

3. If events found (destination already configured):

   • Verify bridge functionality with test transfer
   • Mark configuration as complete ✅

4. Update documentation with final resolution

---

Status: ⏳ AWAITING RPC ACCESS FOR EVENT LOG VERIFICATION