Disperse 批量转账的核心风险集中在"授权"这一步。它采用两步操作：先 approve（授权），再 disperse（分发）。很多人第一次用时会卡在"点了发送但什么都没发生"，原因通常是只完成了第一步，或者名单格式有误导致第二步的交易在链上回滚。
名单：格式必须严格对齐
Disperse 接受两种输入方式：直接粘贴地址列表，或上传 CSV 文件。无论哪种方式，地址和金额的行数必须一一对应。
如果使用 CSV 文件，标准的格式是两列：第一列收款地址，第二列金额。例如：
0x8F9E...7391,0.1 0x7B24...e21C,0.5
注意不要包含表头行，也不要有多余的空格或空行。如果粘贴的地址数量与金额数量不一致，Disperse 合约在链上执行时会直接 revert（回滚），交易失败但 Gas 照扣。先用 2-3 个地址做一笔小额测试，确认名单解析正确再操作大批量，是避免损失最直接的办法。
授权：ERC-20 代币多一步
转账原生币（如 ETH、BNB）时，你只需要在钱包里确认一笔交易。但如果是 ERC-20 代币，流程会多一步。
Disperse 的 disperseToken 函数使用的是 transferFrom 逻辑：它需要先把你钱包里的代币"拉"到合约，再分发给收款人。这意味着，你必须在代币合约上先对 Disperse 合约进行 approve 操作，授权它动用你指定数量的代币。
实操中，Disperse 网页界面通常会按顺序引导你完成两步：先点击 Approve，钱包弹出交易确认，你支付一笔 Gas 完成授权；授权成功后，Disperse 按钮才会变为可点击状态，你再确认第二笔交易完成分发。只点 Approve 是不会转账的，必须完成第二步。
授权数量通常是你的转账总额。如果你不确定，也可以授权一个略大的额度，避免后续加单时重复授权。但授权额度越大，理论上代币合约被恶意利用时的风险敞口也越大。完成转账后，可以在代币合约的授权管理页面把剩余额度撤销。
到账核验：看收据里的 Transfer 事件
交易在钱包里显示"成功"或"已确认"，只代表这笔交易被链上打包了。它是否真的把钱分给了名单上的每一个人，需要看交易的内部交易（Internal Transactions） 或 事件日志（Event Logs）。
在区块浏览器（如 Etherscan）打开这笔交易，切换到 Event Logs 或 Internal Txns 标签页。每一笔成功的分发都会对应一个 Transfer 事件或内部转账记录。核对事件数量是否与你名单上的地址数一致，以及每个事件的接收地址和金额是否正确。
如果名单很长，手动核对不现实。这种情况下，把浏览器页面拉到最底部，查看 Token Transfers 或 Internal Transactions 列表的总条数。如果条数少于你的名单数量，说明有部分转账在合约内部失败了，但整笔交易仍然可能因为只检查了部分 require 而成功。这种情况虽然少见，但在名单中存在合约地址或特殊代币（如带转账税的代币）时有可能发生。
关于 Gas 和合约状态
Disperse 合约是无状态且非托管的，它本身不持有资金。所有操作是"透传"性质：你的钱从钱包出发，经过合约，直接到达收款人。合约没有 owner 权限可以卷走资金，这降低了工具本身的风险。
转账原生币时，有一个细节：如果你发送的 msg.value（附带的原生币数量）略多于名单总金额，多余的会退回你的钱包。所以不需要精确到 wei，多留一点避免因计算误差导致失败。但如果你是通过自己写脚本调用合约，必须手动在交易中附带 value，只填名单不附带资金会导致交易失败。
