The ugly part in SIGN is not proving a wallet qualified. It is what happens when a live TokenTable row is wrong after claims are already open.
The row is published. The amount is set. The claim path works. Then the mistake surfaces: the beneficiary mapping is off, the wallet rotated, or the row should never have pointed there at all.
Weak systems handle that by lying. They overwrite the row and act like the replacement was always the truth.
The sequence I care about in SIGN is harsher and much more revealing. The wrong row is discovered. Freeze hits that row. The published table version stays replayable. An authorized delegated correction or revocation is recorded. A replacement destination is written. Then the claimant who could open the claim yesterday comes back today and finds the path gone.
Now support has to answer from the record, not from memory. Here was the live row. Here was the freeze. Here was the correction authority. Here was the replacement destination.
That is the pressure line for me in SIGN. Can one bad payout row be fixed without erasing the exact sequence that explains why the claim changed?