如何检测智能合约是否使用了代理模式？
你向一个合约发起调用，但真正执行代码的可能不是它本身，而是背后的逻辑合约。这就是代理模式。
代理合约本质上是个"壳"——不实现具体业务逻辑，把收到的所有调用通过delegatecall转发给另一个合约执行。被转发的那个叫逻辑合约或实现合约。
为什么搞这么复杂？核心原因就一个：可升级性。合约部署到链上代码就改不了了，但把业务逻辑放在逻辑合约里，代理合约作为固定入口，只需把代理指向新的逻辑合约就能完成升级。地址不变、余额不变、存储状态不变。USDC、UNI、AAVE这些主流DeFi协议，底层全是代理模式。
各大交易所注册链接：
方法一：读EIP-1967标准存储槽
EIP-1967规定了一套存储槽，不用翻源代码，直接读特定位置的存储值就能找到逻辑合约地址。
两种查看方式：用eth_getStorageAt接口（开发用），或在区块浏览器合约页面点"Read Contract"。以USDC合约（0xA0b869...）为例，Etherscan上点"Contract"标签，如果看到"Read as Proxy"按钮，说明是EIP-1967标准代理，点进去就能看到实现合约地址。
| 代理模式 | 逻辑合约存储位置 | 检测方式 |
|---|---|---|
| EIP-1967透明代理 | 0x360894...bbc | 直接读该存储槽 |
| EIP-1967信标代理 | 0xa3f0ad...d50 | 读信标地址再查实现 |
| EIP-1822（UUPS） | 同EIP-1967槽 | 升级逻辑在实现合约中 |
| EIP-897委派代理 | 无固定槽 | 调delegateProxyImplementation() |
| EIP-1167最小代理 | 无存储槽 | 字节码分析：0x363d3d37... |
| EIP-2535钻石代理 | 多Facet分布多槽 | 特殊检测逻辑 |
方法二：区块浏览器，最快最直观
不想折腾代码就用浏览器，但不是所有浏览器都支持自动检测。
Etherscan/BscScan上操作：进合约地址页→切到"Contract"标签→看右侧有没有"Read as Proxy"和"Write as Proxy"按钮。有，就是EIP-1967标准代理，点"Read as Proxy"直接看实现合约地址。
注意：没这两个按钮不代表一定不是代理。未遵循EIP-1967的自定义代理、新部署未被索引的、某些EIP-1167最小克隆代理，都不会显示。
方法三：翻源码找delegatecall
代理模式的代码特征非常明显，打开源代码找三个关键点：
特征1：delegatecall出现在fallback函数里。真正的代理合约几乎一定包含这条EVM指令，在assembly { ... }代码块里搜delegatecall，搜到基本确认。OpenZeppelin代理模板里_delegate()函数的核心就是它。
特征2：有_implementation()函数返回某个地址。这个函数指向的如果不是零地址，就是在告诉你真正的代码在哪。
特征3：fallback()没有任何具体业务逻辑。标准业务合约的fallback通常很短或不写，代理合约却用它接收所有调用并转发。代码高度标准化，一眼能认出来。
三种方法对比
| 方法 | 难度 | 准确性 | 适用场景 |
|---|---|---|---|
| 浏览器"Read as Proxy" | ★☆☆☆☆ | 取决于是否遵循EIP-1967 | 日常快速查看 |
| 读EIP-1967存储槽 | ★★☆☆☆ | 高（遵循标准时） | 确认标准化代理 |
| 手动翻源码找delegatecall | ★★★★☆ | 最高 | 验证非标准代理、安全审计 |
| evm-proxy-detection工具 | ★★☆☆☆ | 高 | 批量检测、开发场景 |
| EVMProxyInspect | ★★★☆☆ | 高 | 多链批量检测，支持12种代理 |
三步确认一个合约是不是代理
浏览器看一眼→Contract标签有没有"Read as Proxy"？有，确认代理，复制逻辑合约地址。没有，下一步。
翻代码搜"delegatecall"→找到，大概率是代理，再找
_implementation()看指向哪。找不到但怀疑是代理，下一步。上工具→单查用evm-proxy-detection，批量多链用EVMProxyInspect，深度安全分析用EVM Proxy MCP。
声明：本文为代理模式检测科普，不构成操作建议。各合约实现有差异，以链上数据和官方文档为准。
