这些接口都会给你一个看起来完全正常的返回：有数据、格式对、不报错。 问题在于它返回的不是你以为的那个东西 —— 少了一截、换了口径、或者干脆是个占位符。 八个都是我们自己撞过的，其中一个直接害我们发表了一个错的结论，后来撤回。
我们做过一次赢家普查，想回答一个很自然的问题：拿 $1,000 进场，跟着顶尖玩家的打法能做到多少？
做法看着也没问题：拿排行榜接口查每个赢家的盈利，再拿另一个接口查他的持仓， 两者相除，得到「资金效率」，然后按 $1,000 的本金折算。算出来是 $1,000 → $3,723。
这个数是错的，而且错得离谱。原因只有一句话：
样本里有一个钱包终身盈利 $455 万，而当前持仓只有 $5,700 —— 一个早就收手、把钱提走的老玩家。这一除，他就成了「用几千块赚了几百万」的神。 整个推算被这类钱包拉爆了。
我们撤回了那个数字。接口没有骗人，是我们没问清楚它在说哪个时间尺度。 下面八条，本质上都是同一件事的不同版本。
| # | 接口 / 字段 | 你以为 | 实际 |
|---|---|---|---|
| ① | 活动流 /activity | 这个钱包的全部记录 | 最多 5,500 行，更早的取不到 |
| ② | 同上，用在高频钱包上 | 够算「每天多少」 | 可能只覆盖几小时 |
| ③ | 排行榜 /profit | 这个人赚了多少 | 不含任何补贴收入 |
| ④ | /profit ÷ /value | 资金效率 | 终身 ÷ 此刻，没有意义 |
| ⑤ | 某个高额收款地址 | 一个超级玩家 | 会污染统计，必须剔除 |
| ⑥ | clobRewards: [] | 这个盘没有奖励 | 推不出这个结论，得换权威源 |
| ⑦ | 公共 RPC eth_getLogs | 随便找一家就能查链上 | 大部分直接拒你，能用的也有硬限制 |
| ⑧ | /rebates/current | 文档说免鉴权，能查返利 | 实测返回 None |
下面按「它会让你犯什么错」分三组展开。
查一个钱包的历史成交，接口会一页一页给你，看起来能一直翻下去。 实际上翻到 5,500 行就没了 —— 不报错，不提示，就是没有更多了。
所以你拿到的永远是最近的一段，不是终身。这一段有多长， 完全取决于这个钱包有多活跃。我们拆过的两个例子，差了十几倍：
| 钱包类型 | 5,500 行覆盖了 | 如果你以为是终身 |
|---|---|---|
| 中频套利钱包 | 18.5 天 | 把半个月当成一辈子 |
| 高频做市钱包 | 约 30 小时 | 把一天当成一辈子 |
接上一条。你从活动流里加总出一个数，除以「天数」——问题是除以几天？
拿到数据后，第一件事是看第一行和最后一行的时间戳差多少，用这个当分母。 一个高频钱包的 5,500 行可能只有 30 小时，你按「一个月」去除， 得到的日均收入会小 20 倍；按「一天」去除又可能高估。
而且更隐蔽的是：被截掉的那一段可能是它最赚钱的时期。 如果一个钱包在某个高收益阶段特别活跃，那一阶段产生的行数最多， 恰恰最容易被 5,500 的顶顶掉。你看到的是它的近况，不是它的巅峰。
这一条影响最大，因为排行榜是所有人抄作业的第一站。
/profit 这个字段是交易盈亏。而平台发的各种奖励和返利
是转账，不是交易 —— 它们不进这个字段。
后果是双向的：你会系统性地低估靠补贴吃饭的玩家（他们的排行榜数字可能很难看， 甚至是负的，实际却在稳定赚钱）；反过来，如果你把自己收到的补贴算进了「策略赚的钱」， 就会系统性地高估自己的策略。
这两类玩家的打法完全不同，而排行榜把它们混在了一起。补贴到底有几种、 分别怎么发，见 「四种返利」辨析。
就是 §一 那个翻车。规则很简单：
终身盈利是从开户累计到今天；当前持仓是此刻的快照。 一个是积分，一个是瞬时值，相除得到的东西没有物理含义。
还有一个同族的：某些「周转量」字段没有写明统计窗口。 窗口未知的数，不要拿去和任何有明确窗口的数做比值 —— 不知道分母就不要除，这是硬规矩。
做收款人普查时会遇到一个地址（0x2d507657…），
它每天在批次里收到 $60 万到 $92 万，但排行榜上没有对应的交易记录。
它显然不是一个普通玩家。任何按「人均」「中位数」「分布」做的统计， 必须先把它剔除，否则整张分布图都会被它一个拉歪。
口径声明我们只说这个地址会污染统计口径， 不对它做任何身份归因 —— 我们不知道它是谁，也没有去查。
clobRewards: [] 不等于这个盘没有奖励想找「有流动性奖励的盘」，最顺手的做法是查事件接口里的 clobRewards 字段。
但这个字段返回空数组时，推不出「这个盘没奖池」。
权威源是撮合层的抽样市场端点。我们照它全量拉过一次，
得到 8,631 个真正带有效费率的盘 —— 和按 clobRewards 筛出来的结果完全不是一回事。
盘的元数据里有「拿奖励要求的最小挂单量」「最大价差」这类字段。 它们存在，不代表这个盘真有钱发。它们只是配置模板的一部分。
判断「有没有奖励」只有一个可靠办法：去权威端点查，或者直接看链上有没有真的打过钱。
要把链上的转账全量枚举出来，得用 eth_getLogs。免费的公共节点在这件事上非常不友好：
| 节点 | 实测结果 |
|---|---|
| publicnode / polygon-rpc / ankr | 全拒（403 / 401 / 要 key） |
| 1rpc | 限额 |
| drpc | 能用，但必须带地址过滤 + 每次 ≤ 40 个区块 |
不带地址过滤的全链查询，任何区块档位都会被拒。 所以「把某个合约的全部事件拉下来」这件事，在免费档位上要拆成成千上万次小查询。
如果你不用现成的库、自己拼 JSON-RPC 请求，记得带 User-Agent 请求头 —— 否则会被静默拒绝。用库的人踩不到这个坑，因为库自带这个头。
「静默」是这里的关键词：它不会告诉你「缺 header」，它只是不给你数据。 这类失败最难查，因为看起来就像「链上没有这条记录」。
/rebates/current 这个端点，文档写着免鉴权就能查。实测返回 None，
参数形状我们没试出来。
不用在它身上耗时间：同样的信息可以从活动流里拿 —— 按记录的类型字段把收入拆开，转账类和交易类分别加总，得到的结果一样可靠，而且可核对。
另外有个端点确实能精确对账（按日按盘的收益明细），但它需要鉴权、只能查自己。 自己实盘之后可以用它做对账，做别人的普查用不上。
| 坑 | 说明 |
|---|---|
| 排行榜硬顶 50 名 | 翻页参数全部无效；100–200 名平台不暴露。想看长尾只能换路子 |
| 持有人索引有延迟 | 分钟级。单次快照不可靠，要跨快照取并集 |
| 批量发奖一批 400 笔 | 不是坑，是解析时必须知道的形状：奖励走批量转账，一笔交易里塞几百个收款人 |
| 配置里的费率字段 | 撮合配置里那两个「基础费率」显示的是原始配置值，不是实际费率，别拿它算账 |
把这八条抽象一层，它们全都是同一个错误：把接口给你的东西，当成了你想要的东西。
做法很便宜，一次就够：
① 数行数。如果返回的条数正好是某个整数（5,500、50、1,000）， 八成撞顶了，不是真的只有这么多。
② 看首尾时间戳。它覆盖的真实跨度是多少？和你以为的一样吗？
③ 找一个你已知答案的样本去验。拿一笔你自己的、或者链上能独立核对的记录， 看接口给的和真相对不对得上。
④ 空值要分清是哪一种空。「确实没有」和「这个端点不告诉你」 是两件完全不同的事，而它们返回的东西长得一模一样。
第 ④ 条是这一篇里最贵的一条。我们在别的地方为「把『查不到』当成『没有』」付过学费： 一次是把「结算后两侧都显示可赎回」当成真的可赎回，一次是把 「活动流里没有记录」当成「没有亏损」 —— 后者差了八倍， 全过程在 589 股无声蒸发。
这些接口不会骗你，它们只是回答了一个和你想问的略有不同的问题。 所以在拿任何返回值做除法之前，先问三句： 它覆盖多长时间？它包含哪些类型？它的「空」是哪一种空？
0x2d507657…，批次内每日收款 $60–92 万、排行榜无对应交易记录。
链上公开可查；本站不做身份归因。