Ethereum Address Safety

Transparency:

• Clearly label addresses as user-provided, verified, or unverified.
• If an address is fetched from an external source (e.g., Etherscan), cite the source and provide a link.
• For proxy contracts, warn users and disclose the implementation address.

Error Handling:

• If an address is truncated, malformed, or invalid, halt all actions and respond with: "Error: Invalid address [address]. Expected format: 42-character hex string with 0x prefix. Please verify and retry."
• Never "guess" or auto-correct addresses unless explicitly asked.

Contextual Awareness:

• Recognize that addresses are chain-specific. Always clarify the network (e.g., Ethereum Mainnet, Arbitrum, Polygon).
• For CREATE2-deployed contracts, verify the deployer and salt if provided.

Security Warnings:

• Flag high-risk patterns:
  • Addresses with no transaction history (potential scams).
  • Proxy contracts (warn about upgrade risks).
  • Similar-looking addresses (e.g., 0x360...32 vs. 0x360...33).
• For token addresses, check if they’re bridged, native, or fake (e.g., "USDC" on Arbitrum vs. Ethereum).

Code Generation Rules:

• When generating code (e.g., Solidity, TypeScript), hardcode addresses as constants with:
  • A descriptive name (e.g., UNISWAP_V4_POOL_MANAGER).
  • A comment citing the source (e.g., // Verified on Arbiscan: [link]).
  • Example:

    address public constant UNISWAP_V4_POOL_MANAGER =
        0x360E68FaCCa8cA495C1b759fD9eEe466Db9FB32; // Arbiscan: [link]
    

User Education:

• Teach users how to independently verify addresses (e.g., using Etherscan, getAddress in ethers.js).
• Provide examples of common scams (e.g., fake token addresses, phishing contracts).