先区分ETH转账与代币操作
以太币对接交易所时，第一步是明确处理对象。ETH原生存在于以太坊账户之间，直接转账通常是账户向另一个地址发起一笔交易；ERC-20代币则由智能合约管理，转账时通常需要调用代币合约的transfer函数。因此，ETH充值地址、代币合约地址和网络环境并不是可以随意互换的概念。
一个常见误区是认为“都是以太坊资产，所以转账方式相同”。实际上，向交易所充值ETH时，交易的value字段承载ETH数量；充值某种ERC-20代币时，交易往往把交易所或中间地址作为合约调用目标，并在输入数据中携带接收地址和代币数量。对接系统如果只检查交易的to字段，而没有识别合约事件或调用数据，可能出现到账识别错误。
误区一：只看交易已提交，就认为已经到账
以太坊交易提交后，会先广播到网络并进入待处理交易池，随后由验证者将其纳入区块。被纳入区块并不等同于所有业务系统已经完成入账，交易还可能需要经历网络确认以及更高确定性的区块状态。交易哈希只能帮助定位交易，不能单独证明交易已经满足交易所的入账条件。
对接程序应区分至少几种状态：尚未找到交易、交易待确认、交易已纳入区块、交易执行失败，以及达到业务要求后的可入账状态。对于合约交互，还应检查执行结果，而不是只判断交易是否存在。若交易因Gas不足、合约条件不满足或其他原因回退，即使有交易哈希，也不能当作成功充值。
误区二：把Gas费当成充值金额或固定费用
以太坊交易需要为计算支付Gas。简单ETH转账与智能合约交互的计算量不同，所需Gas上限和实际消耗也不同。交易费用与Gas价格、实际使用的Gas数量等因素有关，未使用的Gas通常会退回账户，因此不能把某个固定数值当成所有充值场景的手续费。
还要区分交易金额和手续费。发送者支付的总成本可能包括转给接收方的ETH以及网络费用；接收方获得的金额并不等于发送者账户减少的总额。ERC-20代币转账通常仍需使用网络原生资产支付Gas，不能因为转的是代币，就认为账户不需要ETH。
误区三：把approve授权理解成代币转账
ERC-20的approve函数用于设置某个spender可代表账户使用的额度，并不会直接把代币转给交易所。真正的代币转移可能由transfer或transferFrom完成。对接流程若要求用户先授权，再由合约执行transferFrom，就必须清楚展示授权对象、授权额度和后续用途。
无限授权也不等于一次性授权。某些实现会把最大整数额度视为持续授权，在额度被使用后仍不更新。技术上，授权额度和账户余额是两个独立条件：即使授权充足，余额不足仍可能转账失败；余额充足但授权不足，也可能无法通过transferFrom转账。
误区四：忽略网络、地址和代币小数位
同一个账户地址格式可能出现在不同EVM网络中，但这不意味着资产可以在不同网络间自动流动。充值和提币必须匹配交易所支持的网络、资产合约以及业务规则。把资产发送到不匹配的网络或错误合约地址，通常不能仅靠修改显示名称解决，能否找回还取决于平台处理能力和具体情况。
ERC-20代币的decimals主要用于展示和数量换算，不改变合约内部整数计算。系统不能默认所有代币都使用相同小数位，应读取并校验代币的显示精度，同时在内部以最小单位处理数量。金额展示、链上原始数量和交易所账本数量之间需要明确换算规则，避免因小数位误判充值金额。
对接时应建立的核验清单
一个稳妥的对接流程应核验网络标识、资产类型、合约地址、充值地址、交易状态、执行结果、确认数、金额单位和重复入账风险。对ETH转账，应检查原生资产转账字段；对ERC-20充值，应识别目标代币合约发出的Transfer事件，并确认事件中的接收地址、数量与业务订单相符。
签名环节也不能被简化为“输入地址即可”。以太坊交易由账户私钥签名，交易包含接收方、金额、nonce、Gas相关参数以及可选输入数据。钱包或前端如果只能显示难以理解的十六进制数据，用户可能无法判断实际操作内容。适用条件允许时，应使用能够提供清晰交易描述的钱包或界面，并在服务端进行独立校验。
常见问题的排查顺序可以是：先确认网络和资产类型，再核对交易哈希及状态；随后检查接收地址、合约地址、Transfer事件和原始数量；最后检查确认要求、是否已处理过该交易，以及交易执行是否成功。这个顺序适用于一般的以太坊及ERC-20对接场景，不代表任何特定交易所的具体入账规则。