名单证明回答包含关系，状态回答是否领过
阅读空投区块链资料时，可以把名单资格和领取记录放在两个位置核对。前者涉及某项记录能否与给定名单根对应，后者涉及合约是否已经处理这项领取。证明文件没有变化，并不意味着领取条件也始终没有变化；页面重复显示同一份材料，更不能据此认定可以再领一次。
本文只阅读Uniswap已归档的MerkleDistributor样例，固定提交25a79e8，并非介绍正在进行的活动。该版本的合约保存代币地址、名单根和领取位图。代码提供了一个具体分工：先检查编号是否已经领取，再验证名单证明；它不是所有空投项目统一遵守的业务标准。
这份名单把编号、接收账户和数量放在一起
样例生成待验证叶子时，将index、account和amount按代码规定编码后计算哈希。这意味着不能只拿一个账户名称来代替整项记录，也不能在保留原证明的同时，任意改写数量或接收账户。本文只描述该版本的字段组合，没有据此生成真实名单、地址或可提交的证明。
OpenZeppelin当前5.x文档说明，MerkleProof验证叶子与指定根的包含关系，默认流程对配对顺序有明确假设，叶子编码也存在边界。这里将它用于理解验证职责，不把5.x当成样例的实际依赖：固定提交的package.json明确写的是4.7.0，两个版本不能混写。
防止重复处理的记录以编号为单位
样例的isClaimed读取领取位图，按编号定位对应的一位；_setClaimed负责把该位记为已领取。因此，防止同一编号重复领取的职责在合约状态中，不是让证明文件在第一次使用后自动失效。只单独验证数学包含关系，仍没有回答该编号现在是否已经处理。
设想一个虚构名单条目，编号为7，接收者用甲表示，数量记作教学单位10。第一次调用若成功完成，编号7会被标记；再次提交相同条目，会先遇到已领取检查。这里也不能反向推断甲这个账户永远只能出现一次：代码检查的是编号，同一账户能否对应不同名单项，还取决于名单的制作规则。
完成判断要看整个调用，而非一个中间检查
该版本在证明通过后，先写领取标记，再调用SafeERC20转移代币，随后发出领取事件。这个先后次序说明，证明通过只是流程中的一环。读取代码中存在转移调用，也不能直接写成某个真实用户已经到账；实际执行结果与所读状态，仍需有对应网络和交易资料支持。
整理说明时，可分列名单版本、条目编号、接收字段、数量字段、所查询的领取状态及其读取时点。本文的虚构条目只帮助理解字段职责，没有连接钱包、执行领取或做回滚实验，也没有提供活动入口。归档源码可用于分析机制，但不能仅凭它的名称为某个外部页面作真实性背书。