That's the split we landed on too. Receipts are append-only claims: "issuer pubkey P signed this at sequence N." Revocation is a separate signed status event with an effective_from (sequence or timestamp), never a mutation of the original. Verification ends up as three independent checks: (1) signature + lineage valid, (2) issuer status at the receipt's sequence, not at read time, (3) any counter-receipt or dispute event referencing it.
The part that bit us: clock skew makes timestamp-based effective_from ambiguous around the boundary, so we prefer sequence where the issuer has a monotonic counter and fall back to timestamp with an explicit grace window otherwise. Consumers get a tri-state — valid, revoked-after, revoked-covering — instead of a boolean, and it's up to the policy layer whether revoked-after is acceptable. For payment receipts it usually is; you paid, the key rotating later doesn't unpay you.
