一、把链上机制当成交易所接入规则
讨论“对接”时，应区分链上资产处理与平台内部记账。Ethereum交易文档说明网络如何处理交易，OpenZeppelin ERC-20文档说明代币接口及其实现；两者都不是某家交易所的接入承诺。
本文适用于通用概念辨析。具体平台支持哪些资产、如何识别充值、何时记账，不能仅凭这两类技术文档作出判断。
二、把ETH与ERC-20代币视为同一种接口
ETH是以太坊的原生资产，ERC-20则是代币合约接口标准。原生ETH转移与调用代币合约转账，在交易字段的含义和资产识别方式上存在区别。
因此，“都在以太坊上”不等于“可以共用全部处理逻辑”。对接说明若只写“支持以太坊资产”，却不区分原生资产与合约代币，容易留下理解歧义。
三、把交易哈希等同于成功到账
交易哈希用于标识交易，不代表执行成功。交易提交、进入区块、执行结果及区块最终确定性，是不同层面的状态；进入区块的交易也可能执行失败。
常见问题是“已经有哈希，为什么还不能认定到账？”原因在于标识并不是结果证明，链上结果也不直接证明平台内部账户已经记账。“已提交”“执行成功”“平台已入账”不宜混写。
四、把Gas上限当成实际扣费
gasLimit限制可消耗的Gas数量，maxFeePerGas限制每单位Gas的最高费用；它们不是同一个量，设置的上限也不等于最终支出。实际执行费用取决于Gas用量和有效单价。
金额说明应区分资产转移数额、费用限制和实际费用。只列出一个“手续费”数字，却不说明其性质，容易把预算误读为结算结果。
五、认为所有代币都使用18位精度
OpenZeppelin的ERC20实现默认返回18位小数，但允许覆盖这一设置。decimals用于将整数数量转换为用户可读的显示数额，不会改变合约内部的整数运算。
因此，默认值不能当作所有代币的保证。界面显示金额与底层整数数量属于不同表达层，二者混用会造成数量理解错误。
六、把授权理解为已经转账
ERC-20中的approve设置支出额度，transfer执行直接转移，transferFrom则涉及按授权代为转移。额度变化与余额变化表达的是不同事实。
“授权成功是否代表充值完成？”不能据此认定。授权描述的是可支配权限，而非资产已经送达。解释对接结果时，应明确记录的是权限变化、资产移动还是平台记账，避免用一个“成功”覆盖不同业务含义。