Add full monorepo: virtual-banker, backend, frontend, docs, scripts, deployment
Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
130
docs/CCIP_ROUTER_NATIVE_ETH_CHECK.md
Normal file
130
docs/CCIP_ROUTER_NATIVE_ETH_CHECK.md
Normal file
@@ -0,0 +1,130 @@
|
||||
# CCIP Router Native ETH Support Check
|
||||
|
||||
**Date**: 2025-01-12
|
||||
**Router**: `0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e`
|
||||
**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.
|
||||
|
||||
Reference in New Issue
Block a user