用 Base 上的 USDC 充值：在发起第一次调用前先确认到账

为什么第一次充值最容易出问题

聚合站的计费模型很直接：你按官方价 ×1.3 扣费，用多少扣多少，没有订阅门槛。也正因为没有预付费套餐和人工审核环节，账务完全依赖链上转账和站内入账两步。第一次充值出问题，绝大多数不是"平台跑路"，而是转错了网络、转错了代币，或者链上已确认但站内还没入账时就急着发请求。

下面按实际操作顺序走一遍。

第一步：拿到充值地址，并确认它属于当前账号

登录后在充值/账单页面获取你的 USDC 充值地址。这里有两个容易忽略的点：

• 充值地址通常与账号绑定。不要使用别人的地址，也不要在未登录状态下从公开文档里抄一个示例地址。
• 地址是 EVM 格式（0x 开头）。复制后建议头尾各核对 4 位字符，剪贴板劫持类恶意软件会替换掉中间部分。

如果页面同时提供了二维码，扫码和复制文本应当是同一个地址。

第二步：确认网络是 Base，代币是 Base 上的 USDC

这一步是失败率最高的环节。USDC 在多条链上都有发行，同一个地址格式在不同网络上含义完全不同。

• 提现或转账时选择 Base 网络，不要选 Ethereum 主网、Optimism、Arbitrum 或其他网络。
• 确认资产是 USDC，而不是 USDT、DAI 或其它稳定币。
• 从中心化交易所提现时，网络下拉框里可能写作 "Base" 或 "BASE"，以实际名称为准；不确定就先小额试一笔。

如果你从交易所提现，注意交易所的提现是「交易所 → 你的充值地址」，中间不需要你再做任何操作。千万不要把交易所的充值地址当成自己的收款地址。

第三步：理解「链上确认」和「站内入账」不是一回事

转账广播后，交易会先进入待打包状态，随后被打包、获得确认。链上确认只说明这笔钱到了那个地址，站内余额还需要一个扫链入账的过程。

实践中：

• 链上显示成功（Success）后，仍需等待站内记账完成，余额才会出现在你的账户里。
• 这段时间里发起的 chat completion 请求，如果账户余额为零，会直接返回余额不足的错误，而不是排队等待。
• 不要因为余额没立刻变化就重复转账。

第四步：在发起第一次调用前核对余额

拿到 API key 后，先别急着写业务代码。按这个顺序确认：

1. 打开账单或用量页面，确认可用余额已经是一个非零值。
2. 记下当前的余额数字，作为后续对账的基准。
3. 用 key 发一个最小请求（一条短消息即可），确认返回正常。
4. 回到账单页，确认余额发生了扣减，且扣减幅度符合官方价 ×1.3 的量级。

第 4 步很重要：它同时验证了充值入账和计费链路都是通的。如果第 3 步成功但第 4 步余额不动，说明计费可能有延迟，可以稍后再看，不必立刻重复调用。

充值长时间未到账时的排查顺序

按成本从低到高排查，不要一上来就找客服：

• 看交易哈希：在区块浏览器上查到这笔交易，确认状态是成功而非失败或 pending。
• 核对收款地址：把交易详情里的 to 地址和你页面上的充值地址逐字符比对，尤其是首尾。
• 核对网络和代币：确认交易发生在 Base 上，转账的是 USDC 合约。转错网络或转错币种，通常无法自动入账。
• 核对金额：极小额的测试转账有时会低于入账阈值，具体以页面说明为准。
• 确认是否已过入账窗口：如果链上早已成功而站内仍未记账，再带着交易哈希联系支持。

几个习惯性建议

• 首次充值先小额。确认整条链路通畅后，再转入计划使用的金额。
• 固定用一条链。既然选定了 Base，后续充值保持同一网络，减少出错面。
• 把充值地址存进密码管理器，而不是聊天记录或备忘录截图。
• 保留交易哈希。对账和排查时，哈希比截图有用得多。

顺带一提：贡献 key 的返现也走同一条链路

如果你后续把自己持有的模型 key 贡献出来，返现按官方价 ×1.1（优质 key ×1.2）以 USDC 结算。这意味着你同样需要一个可用的 Base 地址来接收，充值环节养成的核对习惯在这里同样适用。

充值本身不复杂，出问题的往往是「以为到账了」和「其实转错了网络」这两种错觉。把上面四步走完再发第一个请求，能省掉大部分新手期的困惑。