proxmox/docs/archive/historical/CCIP_ADDRESS_DUAL_ROLE_EXPLANATION.md

CCIP Address Dual Role Explanation

Date: $(date)
Purpose: Explain why 0x105F8A15b819948a89153505762444Ee9f324684 appears in CCIP transfers

---

🔍 The Question

Why is 0x105F8A15b819948a89153505762444Ee9f324684 an active contract address in CCIP transfers?

Note: This address on Ethereum mainnet has empty bytecode (0x) and is not functional. Only the Chain 138 deployment is relevant for this project.

---

✅ The Answer

This address has two different roles depending on which chain you're looking at:

On Chain 138 (Source Chain)

Contract Type: CCIP Sender
Address: 0x105F8A15b819948a89153505762444Ee9f324684
Role: Initiates cross-chain messages

• Sends CCIP messages to destination chains
• Prepares and submits messages to the CCIP Router
• Part of the CCIP infrastructure on Chain 138

On Destination Chains

Contract Type: CCIPWETH10Bridge
Address: 0x105f8a15b819948a89153505762444ee9f324684 (same address, lowercase)
Role: Receives and processes WETH10 tokens

Destination Chains Using This Address:

• ✅ BSC (Chain ID: 56)
• ✅ Avalanche (Chain ID: 43114)
• ✅ Base (Chain ID: 8453)
• ✅ Arbitrum (Chain ID: 42161)
• ✅ Optimism (Chain ID: 10)

Note: Polygon uses a different address: 0xdab0591e5e89295ffad75a71dcfc30c5625c4fa2

---

🔄 How CCIP Transfers Work

Flow: Chain 138 → Destination Chain

1. User initiates transfer on Chain 138

   • Calls CCIPWETH10Bridge.sendCrossChain() on Chain 138
   • Bridge contract: 0xe0E93247376aa097dB308B92e6Ba36bA015535D0

2. CCIP Sender prepares message

   • CCIP Sender (0x105F8A15b819948a89153505762444Ee9f324684) on Chain 138
   • Prepares CCIP message with destination chain selector
   • Submits to CCIP Router

3. CCIP Router routes message

   • CCIP Router on Chain 138: 0x8078A09637e47Fa5Ed34F626046Ea2094a5CDE5e
   • Routes message to destination chain via CCIP network

4. Destination bridge receives tokens

   • CCIPWETH10Bridge on destination chain: 0x105f8a15b819948a89153505762444ee9f324684
   • Receives CCIP message
   • Mints/releases WETH10 tokens to recipient

---

📊 Address Mapping

Chain	Address	Contract Type	Role
Chain 138	0x105F8A15b819948a89153505762444Ee9f324684	CCIP Sender	Initiates transfers
BSC	0x105f8a15b819948a89153505762444ee9f324684	CCIPWETH10Bridge	Receives transfers
Avalanche	0x105f8a15b819948a89153505762444ee9f324684	CCIPWETH10Bridge	Receives transfers
Base	0x105f8a15b819948a89153505762444ee9f324684	CCIPWETH10Bridge	Receives transfers
Arbitrum	0x105f8a15b819948a89153505762444ee9f324684	CCIPWETH10Bridge	Receives transfers
Optimism	0x105f8a15b819948a89153505762444ee9f324684	CCIPWETH10Bridge	Receives transfers
Polygon	0xdab0591e5e89295ffad75a71dcfc30c5625c4fa2	CCIPWETH10Bridge	Receives transfers

---

🎯 Why This Design?

Deterministic Deployment

The same address is used across chains due to deterministic deployment (CREATE2):

• Same deployer address
• Same salt value
• Same bytecode hash
• Result: Same contract address on any EVM chain

Benefits

1. Predictable Addresses: Know the bridge address on destination chains before deployment
2. Easier Configuration: Same address pattern simplifies bridge setup
3. Cross-Chain Compatibility: Addresses are consistent across EVM chains

---

🔍 How to Verify

Check Chain 138 (CCIP Sender)

# Get bytecode
cast code 0x105F8A15b819948a89153505762444Ee9f324684 \
  --rpc-url http://192.168.11.250:8545

# Check if it's a contract (should return bytecode)
cast code 0x105F8A15b819948a89153505762444Ee9f324684 \
  --rpc-url http://192.168.11.250:8545 | wc -c
# Should be > 100 (has bytecode)

Check Destination Chain (CCIPWETH10Bridge)

# Example: Check on BSC
cast code 0x105f8a15b819948a89153505762444ee9f324684 \
  --rpc-url https://bsc-dataseed.binance.org

# Should also return bytecode (bridge contract)

---

📝 In CCIP Transfer Events

When you see this address in CCIP transfer events:

On Chain 138 (Outgoing Transfer)

// Event emitted by CCIP Router
event MessageSent(
    bytes32 indexed messageId,
    uint64 indexed sourceChainSelector,
    address sender,  // This will be the CCIP Sender address
    bytes data,
    ...
);

Sender: 0x105F8A15b819948a89153505762444Ee9f324684 (CCIP Sender on Chain 138)

On Destination Chain (Incoming Transfer)

// Event emitted by CCIP Router
event MessageExecuted(
    bytes32 indexed messageId,
    uint64 indexed sourceChainSelector,
    address receiver,  // This will be the bridge address
    bytes data,
    ...
);

Receiver: 0x105f8a15b819948a89153505762444ee9f324684 (CCIPWETH10Bridge on destination)

---

🔗 Related Documentation

• CCIP Sender Contract Reference
• Cross-Chain Bridge Addresses
• Contract Address Cross-Chain Note

---

📋 Summary

• ✅ Chain 138: Address is CCIP Sender (initiates transfers) - RELEVANT
• ✅ Destination Chains: Same address is CCIPWETH10Bridge (receives transfers) - RELEVANT
• ✅ Why Active: It's the destination bridge contract that receives tokens
• ✅ Design Pattern: Deterministic deployment ensures same address across chains
• ❌ Ethereum Mainnet: Address has empty bytecode (0x) - NOT FUNCTIONAL, IGNORE

Important: The mainnet address is completely useless - it has no contract code and cannot be used for any operations. Only focus on Chain 138 and destination chains where the address is actually deployed and functional.

---

Last Updated: $(date)