Files
proxmox/docs/archive/historical/CONTRACT_ADDRESS_CROSS_CHAIN_NOTE.md
defiQUG bea1903ac9
Some checks failed
Deploy to Phoenix / deploy (push) Has been cancelled
Sync all local changes: docs, config, scripts, submodule refs, verification evidence
Co-authored-by: Cursor <cursoragent@cursor.com>
2026-02-21 15:46:06 -08:00

4.0 KiB

Contract Address Cross-Chain Note

Date: $(date)
Purpose: Explanation of why the same contract address exists on different chains with different states


🔍 The Situation

The contract address 0x105F8A15b819948a89153505762444Ee9f324684 exists on both:

  1. Ethereum Mainnet - Has empty bytecode (0x)
  2. Chain 138 - Has deployed contract bytecode (~5KB)

Why Does This Happen?

Deterministic Address Generation

Contract addresses can be the same across different chains when:

  1. CREATE2 Deployment: Using CREATE2 opcode with the same:

    • Deployer address
    • Salt value
    • Bytecode hash

    Results in the same address on any EVM-compatible chain.

  2. Pre-calculated Addresses: Addresses calculated before deployment can match across chains if:

    • Same deployment parameters are used
    • Same nonce is used (for CREATE)
    • Same CREATE2 parameters are used
  3. Genesis Pre-deployment: Some chains pre-deploy contracts at specific addresses in genesis, which may match addresses on other chains by coincidence.


📊 Current State Comparison

Network Address Bytecode Status Relevance
Ethereum Mainnet 0x105F8A15b819948a89153505762444Ee9f324684 0x (empty) No contract Not relevant - ignore
Chain 138 0x105F8A15b819948a89153505762444Ee9f324684 ~5KB bytecode CCIP Sender deployed Only relevant address

What This Means

For Chain 138 Operations

  • Use this address: 0x105F8A15b819948a89153505762444Ee9f324684
  • Network: Chain 138 (ChainID 138)
  • RPC: http://192.168.11.250:8545 or https://rpc-core.d-bis.org
  • Status: Contract is deployed and operational

For Ethereum Mainnet

  • Do NOT use this address on mainnet
  • The address has no contract code (empty bytecode)
  • Not functional - completely useless for any operations
  • Not relevant for this project - ignore mainnet address entirely

🔐 Security Implications

Always Verify Chain Context

When interacting with contract addresses:

  1. Always specify the chain ID in your code

  2. Verify bytecode before interacting:

    # Check Chain 138
    cast code 0x105F8A15b819948a89153505762444Ee9f324684 \
      --rpc-url http://192.168.11.250:8545
    
    # Check Mainnet (will return 0x)
    cast code 0x105F8A15b819948a89153505762444Ee9f324684 \
      --rpc-url https://eth.llamarpc.com
    
  3. Use chain-specific RPC endpoints in your applications

  4. Validate contract existence before calling functions


📝 Best Practices

In Smart Contracts

// Always check contract exists
function callContract(address target) external {
    require(target.code.length > 0, "Target is not a contract");
    // ... rest of code
}

In Frontend/Backend Code

// Always specify chain ID
const provider = new ethers.providers.JsonRpcProvider(
  "http://192.168.11.250:8545", // Chain 138 RPC
  { chainId: 138, name: "SMOM-DBIS-138" }
);

// Verify contract exists
const code = await provider.getCode(contractAddress);
if (code === "0x") {
  throw new Error("Contract does not exist at this address");
}

In Configuration Files

# Always include chain ID
CCIP_SENDER_ADDRESS=0x105F8A15b819948a89153505762444Ee9f324684
CHAIN_ID=138
RPC_URL=http://192.168.11.250:8545


📋 Summary

  • Chain 138: Address has deployed CCIP Sender contract - USE THIS
  • Ethereum Mainnet: Address has empty bytecode - NOT FUNCTIONAL, IGNORE
  • ⚠️ Only use on Chain 138 - mainnet address is useless
  • 🔐 Always verify you're on Chain 138 when interacting with this address

Last Updated: $(date)