explorer-monorepo/docs/CCIP_ROUTER_NATIVE_ETH_CHECK.md

CCIP Router Native ETH Support Check

Date: 2025-01-12
Router: 0x42DAb7b888Dd382bD5Adcf9E038dBF1fD03b4817
ChainID: 138

---

Summary

Comprehensive check to determine if the CCIP Router supports native ETH for fees instead of requiring LINK tokens.

---

Methods Tested

Method 1: Fee Token Query

• Method: getFeeToken() / feeToken()
• Result: Returns 0x000000000000000000000000514910771af9ca65...
• Finding: Router references Ethereum Mainnet LINK address, but contract doesn't exist on ChainID 138

Method 2: getFee with address(0)

• Method: getFee(uint64, bytes, address) with address(0)
• Result: Method may not exist or doesn't accept address(0)
• Finding: Router may require explicit fee token parameter

Method 3: Bytecode Analysis

• Method: Check router bytecode for payable functions
• Result: Router has payable functions (can accept ETH via msg.value)
• Finding: Router can receive native ETH, but may still require LINK for fees

Method 4: Standard CCIP Behavior

• Method: Reference Chainlink CCIP documentation
• Result: Standard CCIP Routers typically support:
  • LINK token for fees (preferred)
  • Native ETH for fees (if configured)
  • Both methods may be available

---

Key Findings

Router Configuration

• Fee Token Reference: 0x514910771AF9Ca656af840dff83E8264EcF986CA (Ethereum Mainnet LINK)
• Contract Status: Token does NOT exist on ChainID 138
• Router Status: Operational, but cannot process fees without LINK token

Native ETH Support

• Payable Functions: ✅ Router has payable functions (can receive ETH)
• Fee Token Parameter: Router expects fee token address
• Native ETH via msg.value: ⚠️ May be supported, but requires testing

---

Standard CCIP Router Behavior

According to Chainlink CCIP documentation:

1. LINK Token Fees (Primary)

   • Router uses LINK token for fees
   • Fee token address configured in router
   • Preferred method for cross-chain fees

2. Native ETH Fees (Alternative)

   • Some routers support native ETH via msg.value
   • Requires router configuration
   • May be chain-specific

3. Hybrid Support

   • Router may accept both LINK and native ETH
   • Depends on router implementation
   • Configuration determines which is used

---

Testing Results

Test 1: getFee() Default

cast call <ROUTER> "getFee(uint64,bytes)" <DEST_CHAIN> "0x" --rpc-url <RPC>

• Result: May return fee in default token (LINK or native)

Test 2: getFee() with address(0)

cast call <ROUTER> "getFee(uint64,bytes,address)" <DEST_CHAIN> "0x" "0x0000..." --rpc-url <RPC>

• Result: Tests if router accepts address(0) as fee token

Test 3: ccipSend() with msg.value

cast send <ROUTER> "ccipSend(...)" --value <amount> --rpc-url <RPC>

• Result: Tests if router accepts native ETH for fees

---

Recommendations

Option 1: Deploy LINK Token (Recommended)

• Deploy LINK token to ChainID 138
• Matches router configuration
• Standard CCIP approach
• Most compatible with CCIP infrastructure

Option 2: Test Native ETH Support

• Attempt to send CCIP message with native ETH
• Use msg.value instead of LINK token
• May work if router is configured for native ETH
• Less standard but avoids LINK deployment

Option 3: Update Router Configuration

• If router admin access available
• Update fee token to address(0) for native ETH
• Or deploy LINK and update router to use it
• Requires admin privileges

---

Next Steps

1. Test Native ETH: Attempt a test CCIP send with native ETH
2. Deploy LINK: If native ETH doesn't work, deploy LINK token
3. Check Router Admin: See if router configuration can be updated

---

Last Updated: 2025-01-12
Status: ⚠️ Router configured for LINK, but token not deployed. Native ETH support uncertain.