转账税：核对发出与到账的代币数量

对转账时发生扣减的代币，请求数量、发送方扣款和接收方到账可能不同。解释成交量或费用收入之前，应逐跳核对实际余额变化。交易参数中的名义输入，不一定就是最终收到的数量。

Uniswap v3集成警告指出，收取转账费用的代币无法按标准方式与其路由合约正常配合。这是特定版本的兼容说明，不代表所有场所处理方式相同。仍需核对目标代币实现和本次实际路径。

扣减与接收方分开记录

确定网络、合约、观察区块和完整转账路径，相关时列出发送方、路由器、池子、中间合约和最终接收方。扣减可能销毁、留存、转给其他地址，或通过特殊余额机制实现。没有目的地与权利证据，不能全部称为协议收入。

证据允许时，记录每方请求数量及转账前后余额。事件日志适合定位，但非标准代币的名义事件值需要与实际状态对照。看到一条转账事件，并不能回答实际到账的所有问题，也不能证明每个中间环节与标准接口兼容。

进一步检查扣减是否随地址、转账方向、豁免名单或管理设置变化。一次观察不证明永久税率。把观察条件写清，区分代码允许的能力和选定区块实际启用的设置，避免把潜在能力误当已发生事实。

假设虚构燧石代币在简化路径中每次转账扣百分之二。发送方请求转出一百，中间方收到九十八。中间方把全部九十八再转出，若同一规则继续适用，最终到账九十六点零四。总差额为三点九六，并非恰好四。

这个例子假设两跳都收取扣减，且没有舍入问题。真实路由可能豁免，也可能因为预期到账量不匹配而失败。不能把例子当某真实代币的执行预测，更不能据此推荐绕行路径。

如果第一跳扣掉的两个单位中，一个进入金库，一个销毁，就应分开归类。发送方少了两个，不代表金库收入两个。尚无法归属的差额要保留待核，不应填给“最可能”的接收方。

简化公式可写为“最终到账＝输入×（一减扣减率）的收税跳数次方”，但只有每跳确实采用相同比例时才适用。复杂阶梯、白名单和方向规则，应回到逐事件台账。公式算得精确，不能弥补规则用错。

把用户成本、交易场所费用与代币层扣减分开。混成一个费率，会隐藏不同接收方与控制权。可变扣减设置也是治理依赖，应保留权限和变更历史，而不是只保存今天的一个百分比。

常见错误包括把一次成功转账当路由兼容证明、把一次扣减年化成协议收入，以及多跳路径只扣一次。最终备忘录应报告观察到的毛额、净额、归属与尚未核实的条件。没有充分部署和状态证据时，不应向读者保证某条路径的到账量。

还要留意代币余额显示的小数位和原始整数，舍入可能影响很小的转账。如果差额无法解释，应保持未调节状态，不能自动称为损失、收入或攻击。研究目标是复原权利与流量，而不是为每个差异找到一个听起来完整的故事。

非标准行为应先把事件与实际余额、实现语义核对，再决定能否采用。

不代表。跳数、豁免、方向、设置变化和兼容性失败都可能改变结果。