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
```bash
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)
```bash
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
```bash
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.