Re-attestation Under Primitive Change
The protocol does the migration. The holder does not.
Problem
When the proof system migrates from Phase 1 to Phase 3, what happens to existing compliance attestations issued under Phase 1?
Solution
A protocol-level re-attestation primitive. The protocol does the migration.
The holder's account state — sufficient to derive the property the attestation claimed — is preserved on chain. When the proof system migrates, the protocol provides a re-attestation transaction type that consumes the Phase 1 attestation and produces a Phase 3 attestation against the same property of the same state. The holder does not have to participate. The protocol does the migration.
Discussion
Without re-attestation, the migration costs every holder a re-issuance event. With it, the migration is mechanical for everyone except the validators running it.
The re-attestation primitive depends on the protocol having retained sufficient encrypted state to re-derive the property under the new proof system. This is a non-trivial design requirement and constrains what kinds of attestations can be supported. The cookbook is explicit about the constraint.
See Also
- § 3.2 · Proof Systems — the migration this primitive is built around
- § 2.4 · Durability — why re-attestation is the property and not a feature