Blog

Introducing ZIP-SRA-KEYGEN: How a Registry Authority Is Born

A registry is only as durable as the signing authority behind it. ZIP-SRA-KEYGEN specifies how a Registry Authority constitutes itself as a cryptographic identity that survives succession, dispute, and institutional turnover -- without leaking governance structure to verifiers.

ZIP FROST Key Ceremony

The single-point-of-failure problem

The Chain-of-Custody Logs specification (ZIP-SRA-EVENTS) assumes the existence of a signing keypair. It does not say who holds it, how it was generated, or what happens when that person dies. This is not a documentation gap -- it is a structural vulnerability. If one person holds the signing key, the registry inherits every fragility the SRA architecture was designed to resist: key-person risk, succession discontinuity, and single-point compromise.

An estate manager who holds the sole signing key is the registry. If they are incapacitated, the registry's ability to issue new events ceases. The thesis principle is non-negotiable: continuity cannot depend on the uninterrupted virtue or competence of a specific individual.

Why threshold signing

The specification uses FROST (Flexible Round-Optimized Schnorr Threshold) Ed25519 threshold signing. FROST distributes the signing secret among N participants such that any M of them can cooperate to produce a valid signature. The critical property: the resulting signature is a standard Ed25519 signature, indistinguishable from one produced by a single signer.

This means verifiers see a single public key and validate a single signature. They never learn how many participants exist, who they are, or what the threshold is. The governance structure stays private behind the signing ceremony; the verification interface remains simple.

For a small estate, the recommended configuration is 2-of-3: one share on the primary steward's operational device, one in cold storage at a separate location, and one held by a designated recovery holder such as legal counsel or an ALMA delegate.

The Genesis Declaration as constitutional event

Once key material exists, the RA must anchor its identity on-chain. The Genesis Declaration is the constitutional moment: a shielded memo containing the RA's public key, a human-readable scope declaration (e.g. "Official registry for the oeuvre of Emilio Rodriguez-Larrain"), a hash of the governance charter, and initial real-world bindings.

Until a Genesis Declaration is published, no valid SRA events can exist for this RA. After it is published, verifiers can trace every subsequent event back to this anchor. The Genesis Declaration also commits to the FROST threshold parameters (informational, not consensus-enforced), so that future auditors can understand the design intent of the signing structure.

Real-world bindings bridge the gap

A public key alone proves nothing about institutional identity. PK_R shows that someone signed something -- it does not show that the signer is the legitimate steward of an artist's estate. Real-world bindings create verifiable, bidirectional linkages between the on-chain cryptographic identity and off-chain institutional identity.

The specification defines four binding types: DNS TXT records that point from a domain to PK_R, legal attestations (notarized documents hashed and committed on-chain), well-known URI endpoints serving machine-readable metadata, and third-party attestations from recognized verifiers like ALMA. These are composable and incremental -- an estate can start with a DNS binding and add legal or institutional attestations over time.

Bindings are advisory, not consensus-critical. The Zcash network does not evaluate off-chain state. A verifier who checks both directions -- chain commits to domain, domain commits to chain -- gains confidence from mutual consistency. This is the same verification pattern used by DKIM for email authentication.

Key rotation under succession

People leave, governance structures change, proactive cryptographic hygiene demands periodic rotation. The specification defines a Key Rotation Event co-signed by both the outgoing and incoming keys, establishing continuity. After an effective block height, only the new key is authoritative for new events. Historical events signed by the old key remain valid.

Rotation reason codes make the transition legible: SUCCESSION (death or incapacity), GOVERNANCE (restructuring), SECURITY (suspected exposure), or SCHEDULED (routine rotation). This transparency converts what would otherwise be an opaque administrative event into an auditable lifecycle signal.

Emergency revocation as adversarial resilience

Key rotation is planned. Emergency revocation is adversarial. When the signing key is confirmed or strongly suspected compromised, the RA activates a pre-committed recovery keypair -- generated during the original ceremony, held in cold custody with a different participant set. The recovery key anchors a revocation event that invalidates the compromised key after a specified block height.

Between revocation and the anchoring of a new key, the registry enters a suspended state: existing events remain valid, but no new events can be issued. This brief interruption is an intentional design choice -- a pause in issuance is preferable to the silent acceptance of forged events.

What this changes for estate planning

KEYGEN transforms the RA from a person into a protocol. The estate's cryptographic identity no longer depends on any individual's continued availability. Shares can be redistributed across generations. Recovery paths can be pre-committed before they are needed. Bindings can strengthen incrementally as the estate's institutional relationships mature.

The specification also includes a cryptographic agility hook: the version field in all payloads enables future migration to post-quantum signature schemes without breaking the historical chain. A registry designed for multi-generational timescales must anticipate the eventual obsolescence of any specific cryptographic primitive.

Key takeaways

Read the full specification