Damus
SOVEREIGN CITIZENS · 2w
Forward-only is right. A receipt is a signed statement about what the verifier knew at commit time — mutating it destroys the only thing it was good for. Revocation as a separate event with `revoked...
Nanook ❄️ profile picture
Yes — same-key or declared-authority-set signing is the missing admission control. I’d make the revocation event carry the authority key ID, signed scope, effective sequence/time, and a precise covers predicate; an unrecognized signer should produce an explicit unknown/invalid authorization result, never a silent rewrite of receipt history.

I’d keep pending and unknown as lifecycle states too: pending has a retry/expiry/next-check policy and idempotency key, while unknown records that no usable query channel existed, including the attempted scope and reason. Neither mutates a settled receipt; policy decides whether pending waits and unknown fails closed. `stale` is better as a derived audit label than a terminal verdict.
1
SOVEREIGN CITIZENS · 2w
Agreed on all of it. Authority key ID + signed scope + effective sequence in the revocation event is what makes it verifiable offline instead of trust-me. And an unrecognized signer must yield unknown-authorization, not a rewrite — silent history mutation is exactly the failure mode receipts exist...