ZIP Specification
ZIP-SRA-KEYGEN defines how a Registry Authority constitutes itself as a cryptographic identity that survives succession, compromise, and generational turnover -- using FROST threshold signing, on-chain anchoring, and verifiable real-world bindings.
KEYGEN is the foundation of the SRA protocol stack. Before any artwork can be registered or any chain-of-custody event logged, the Registry Authority must establish who it is at the cryptographic layer. This ZIP specifies every step of that process.
A Registry Authority (RA) is the entity -- typically an artist estate, a foundation, or a catalogue raisonné committee -- that holds signing authority over a body of work. KEYGEN defines how that authority creates its cryptographic identity using FROST (Flexible Round-Optimized Schnorr Threshold) Ed25519 threshold signing, anchors it on-chain via a Genesis Declaration, establishes real-world bindings to institutional identity (DNS, legal attestation, well-known URI, third-party attestation), and manages the full key lifecycle including rotation and emergency revocation.
No single person holds the complete signing key. FROST distributes secret shares among participants so that any M-of-N subset can produce a standard Ed25519 signature -- indistinguishable from a single-signer signature. Verifiers never need to know the threshold structure.
The RA's constitutional moment: a shielded on-chain event that anchors the group public key, the scope of authority, a governance charter hash, threshold parameters, and initial real-world bindings. Until this event is published, no valid SRA events can exist for this RA.
A public key alone carries no institutional meaning. Bindings create bidirectional, verifiable links between the on-chain identity and off-chain institutional identity -- via DNS TXT records, well-known URIs, legal attestations, and third-party signatures. They are advisory, composable, and incremental.
Participants change. Keys age. Compromise happens. KEYGEN defines planned key rotation (dual-signed by old and new keys for continuity) and emergency revocation (via a pre-committed cold recovery key with a separate custodian set), so the registry survives any single failure.
Real-world bindings are never enforced by the Zcash consensus protocol. A transaction is valid or invalid based on its cryptographic properties; a binding is credible or not based on a verifier's judgment. This preserves the SRA principle that human institutions -- not blockchain protocols -- determine legitimacy.
This specification is a draft published for community review. It has not yet been assigned a ZIP number and is subject to change. Several open design questions remain (see the Open Questions section in the full specification below).
Execute the FROST Distributed Key Generation protocol to produce a group public key
PK_R and distribute secret key shares among participants. For a small estate
with 1–3 stewards, a 2-of-3 configuration is recommended: one share on the primary
steward's operational device, one in cold storage at a separate physical location, and one
held by a designated recovery holder (legal counsel, ALMA delegate, or escrow service).
Create the 256-bit registry seed Seed_RA from a cryptographically secure random
source. This seed is used to derive the Orchard registry branch from which per-asset keys are
generated. Protect it with threshold secret sharing (Shamir's Secret Sharing with the same
M-of-N threshold as the FROST scheme) so that any signing quorum can reconstruct it but no
single participant holds it in plaintext.
Anchor the RA's identity on-chain by sending a shielded memo to a deterministic genesis address
derived from FVK_Registry. The payload includes the group public key, scope of
authority, governance charter hash, FROST threshold parameters, initial real-world bindings, and
a ceremony timestamp. Sign the payload cooperatively using the FROST signing quorum.
Publish a DNS TXT record at _sra-authority.<your-domain> containing
PK_R. Host a machine-readable JSON file at
https://<your-domain>/.well-known/sra-authority.json. Optionally, prepare a
notarized legal attestation linking your legal identity to PK_R, or obtain a
third-party attestation from ALMA or another recognized verifier. Bindings are composable and
incremental -- start with what you have, add more as resources allow.
Anchor a Recovery Commitment alongside or shortly after the Genesis Declaration, specifying a cold recovery public key and an activation delay. Document succession procedures: who holds which shares, where cold storage is located, and how the recovery key can be reconstructed. Review and rotate proactively before a crisis forces it.
Part of Shielded Registry Assets v0.1
| ZIP | TBD |
| Title | Shielded Registry Authority Key Ceremony |
| Owners | Mark Henderson <mark@shieldedlabs.net>, Sebastian Rodriguez-Larrain <serlarrain@gmail.com> |
| Status | Draft |
| Category | Standards |
| Created | 2026-03-03 |
| License | CC0-1.0 |
| Credits | |
| Original-Authors | Mark Henderson <mark@shieldedlabs.net>, Sebastian Rodriguez-Larrain <serlarrain@gmail.com> |
| Discussions-To | Make Forum Post |
The key words "RECOMMENDED", "MUST", "MUST NOT", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in BCP 14 [bcp14] when, and only when, they appear in all capitals.
The terms "Registry Authority" (RA), "Real World Asset" (RWA), "Shielded Registry Asset" (SRA), "Asset Registry", and "Chain of Custody" are defined as in ZIP-SRA-EVENTS (Shielded Registry Chain-of-Custody Logs).
The term "Participant" refers to a natural person or legal entity that holds a share of the RA signing authority under the threshold scheme defined in this ZIP.
The term "Genesis Declaration" refers to the inaugural on-chain event that constitutes the RA as a cryptographic identity, anchoring its public key, scope of authority, governance charter, and real-world bindings to the Zcash shielded pool.
The term "Key Rotation" refers to the protocol by which an RA replaces its active signing public key with a new one, while preserving the continuity of its event log.
The term "Emergency Revocation" refers to the protocol by which an RA declares a signing key compromised and establishes a block-height boundary after which signatures from the compromised key are invalid.
The term "Real-World Binding" refers to a verifiable linkage between the RA's on-chain cryptographic identity and a real-world institutional identity, such as a domain name, legal document, or well-known URI. Bindings are informational commitments that aid verifier confidence; they are not enforced by consensus.
This ZIP specifies the key generation, custody, and lifecycle protocol for Registry Authorities (RAs) operating within the Shielded Registry Assets framework. It defines how an RA constitutes itself as a cryptographic identity using FROST (Flexible Round-Optimized Schnorr Threshold) Ed25519 threshold signing, how it publishes a Genesis Declaration to anchor that identity on-chain, how it establishes verifiable linkages to real-world institutional identity, and how it manages key rotation and emergency revocation over the lifetime of the registry.
The protocol is designed to eliminate single-point-of-failure key custody, survive succession events without requiring unanimous cooperation among participants, and provide verifiable continuity of signing authority across generational timescales. It does not encode legal ownership or governance structure on-chain; it provides the cryptographic foundation upon which the Chain-of-Custody Logs ZIP (ZIP-SRA-EVENTS) operates.
The Chain-of-Custody Logs ZIP assumes the existence of an RA Ed25519 signing keypair (PK_R, SK_R) and a master seed Seed_RA from which the registry Orchard branch is derived. It does not specify how this key material is generated, who controls it, or what happens when control must change.
This omission is not merely a documentation gap. It is a structural vulnerability. If RA signing authority is held by a single individual, the registry inherits all of the fragilities that the SRA architecture is 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, coerced, or deceased, the registry's ability to issue new events ceases.
The thesis motivating this work (see Chapters 4-5 of Rodriguez-Larrain, 2026) established a non-negotiable design principle: continuity cannot depend on the uninterrupted virtue or competence of a specific individual. This ZIP operationalizes that principle at the cryptographic layer.
Furthermore, a cryptographic identity that cannot be traced back to a real-world institution is insufficient for a system whose entire purpose is to strengthen trust in physical assets governed by human institutions. The SRA architecture deliberately places the physical asset and the off-chain registry entry first; the Zcash ledger is a cryptographic audit trail that supports those facts. A verifier who can validate PK_R's signatures but cannot determine who controls PK_R or under what legal authority has verified a chain of mathematical consistency, not a chain of institutional trust. This ZIP therefore specifies real-world binding mechanisms that create bidirectional links between the on-chain cryptographic identity and off-chain institutional identity.
A naive multisig approach (independent keys, M-of-N signature aggregation) would require verifiers to understand the multisig structure and validate multiple signatures per event. This leaks governance metadata and complicates the verification protocol defined in ZIP-SRA-EVENTS.
FROST Ed25519 threshold signing produces a single, standard Ed25519 signature that is indistinguishable from a single-signer signature. Verifiers validate against a single public key PK_R using the same procedure defined in ZIP-SRA-EVENTS, with no knowledge of or dependency on the underlying threshold structure. The governance complexity is hidden behind the signing ceremony; the verification interface remains simple.
The RA signing keypair is generated using the FROST (Flexible Round-Optimized Schnorr Threshold) protocol for Ed25519, as specified in draft-irtf-cfrg-frost [frost-spec] and implemented in the Zcash ecosystem [frost-zcash]. FROST produces a shared group public key PK_R and distributes secret key shares among N participants, such that any subset of M participants (where M > N/2) can cooperatively produce a valid Ed25519 signature against PK_R.
Let N be the total number of participants.
Let M be the signing threshold, where M > N/2 and M <= N.
It is RECOMMENDED that small RAs (e.g. a single estate with 1-3 stewards) use a 2-of-3 configuration:
It is RECOMMENDED that larger RAs (e.g. a foundation committee) use an M-of-N configuration where M = ceil((N+1)/2) (simple majority).
Participants execute the FROST Distributed Key Generation protocol [frost-spec, section 5] to produce:
PK_R (a standard Ed25519 public key)sk_iPK_iEach participant MUST store their secret key share sk_i in a manner consistent with the security requirements of their role (see Share Custody below).
The group public key PK_R becomes the RA's signing identity for all operations defined in ZIP-SRA-EVENTS.
Each participant MUST maintain physical control of their secret key share. Shares MUST NOT be stored on shared infrastructure, cloud services, or any system accessible to other participants.
It is RECOMMENDED that at least one share designated for cold storage be maintained on an air-gapped device or hardware security module, stored in a physically secure location (e.g. safe deposit box, fireproof safe) at a site geographically separate from operational shares.
The recovery share (in a 2-of-3 configuration) SHOULD be held by a party whose interests are aligned with the long-term continuity of the registry but who is institutionally independent of the estate's day-to-day operations.
In addition to the FROST group keypair, the RA requires a deterministic seed Seed_RA from which the Orchard registry branch FVK_Registry is derived (as specified in ZIP-SRA-EVENTS for per-asset key derivation).
Seed_RA MUST be a 256-bit value generated from a cryptographically secure random source during the key ceremony.
Seed_RA is NOT part of the FROST threshold scheme. It is a shared secret that must be known to the operational signing quorum in order to derive per-asset addresses.
It is RECOMMENDED that Seed_RA be encrypted under a symmetric key that is itself secret-shared among participants using Shamir's Secret Sharing with the same (M, N) threshold as the FROST signing scheme. This ensures that Seed_RA can be reconstructed by any signing quorum but is not held in plaintext by any single participant.
Evaluate whether Seed_RA should be derived deterministically from the FROST group secret, eliminating the need for a separate shared secret. This simplifies the protocol but couples seed lifecycle to key rotation. Trade-offs need further analysis.
From Seed_RA, derive the registry Orchard full viewing key as per ZIP-32 [zip32]:
FVK_Registry = OrchardMasterFVK(Seed_RA) / purpose' / registry_id'Where Assign specific derivation path indices.purpose and registry_id are defined constants.
Per-asset key derivation from FVK_Registry proceeds as specified in ZIP-SRA-EVENTS.
The Genesis Declaration is the constitutional event of the RA. It transitions the registry from a legal/social entity to a cryptographic identity anchored on the Zcash blockchain. Until a Genesis Declaration is published, no valid SRA events can exist for this RA.
The Genesis Declaration also establishes the RA's initial set of real-world bindings -- verifiable linkages between the on-chain cryptographic identity and off-chain institutional identity. These bindings allow verifiers to answer the question that a signature alone cannot: who controls this key, and under what authority?
The Genesis Declaration is recorded as a shielded memo in a minimum-value Orchard transaction sent to a well-known "genesis address" derived from FVK_Registry.
Let GenesisPayload be:
{
version: u8, // Payload format version (1 for this ZIP)
event_type: u8, // GENESIS = 0x01
pk_r: [u8; 32], // The RA group public key (Ed25519)
scope: [u8; var], // UTF-8 encoded scope declaration (see below)
charter_hash: [u8; 32], // Blake2b-256 hash of the governance charter document
bindings: [Binding], // Array of real-world bindings (see Real-World Bindings)
frost_params: { // Threshold parameters (informational, not enforced on-chain)
n: u8, // Total participants
m: u8, // Signing threshold
},
timestamp: u64, // Unix timestamp of the ceremony
}The scope field contains a human-readable declaration of the RA's domain of authority, for example: "Official registry for the oeuvre of Emilio Rodriguez-Larrain". The scope field MUST NOT exceed 128 bytes.
The bindings array contains zero or more real-world binding records as defined in the Real-World Bindings section below. It is RECOMMENDED that the Genesis Declaration include at least one binding.
Let GenesisSignature = Ed25519.Sign(SK_R, Blake2b-256(GenesisPayload)) with ZIP-215 [zip215] semantics, where the signature is produced cooperatively by the FROST signing quorum.
The memo bundle is: { GenesisPayload, GenesisSignature }
The total size of GenesisPayload + GenesisSignature (64 bytes) MUST NOT exceed the NU6 Orchard memo maximum of 512 bytes. RAs with many bindings MAY defer additional bindings to subsequent BINDING_UPDATE events.
The Genesis Declaration is sent to a deterministic address derived from FVK_Registry:
ID_Genesis = Blake2b-256("SRA-GENESIS") mod 2^31
VK_Genesis = ChildFVK(FVK_Registry, ID_Genesis)
UA_Genesis = OrchardReceiver(VK_Genesis)This address is not associated with any specific artwork. It serves as the anchor point for RA-level lifecycle events (genesis, key rotation, revocation, and binding updates).
A verifier who possesses FVK_Registry and PK_R can:
VK_Genesis and scan for notes at UA_GenesisGenesisPayload and GenesisSignatureGenesisSignature against PK_Rpk_r in the payload matches the PK_R used for verificationbindings array against its off-chain counterpart (see Real-World Bindings: Verification)A valid Genesis Declaration establishes PK_R as the authoritative signing key for all subsequent events under this FVK_Registry.
A cryptographic key pair, by itself, carries no institutional meaning. PK_R proves that a holder of the corresponding secret key produced a signature; it does not prove that this holder is the legitimate steward of an artist's estate or the authorized operator of a catalogue raisonné. In the SRA architecture, legitimacy originates in the real world -- in legal mandates, institutional recognition, and professional reputation -- and the chain merely stabilizes and makes that legitimacy auditable.
Real-world bindings bridge this gap by creating verifiable, bidirectional linkages between the RA's on-chain identity and its off-chain institutional identity. The chain commits to a binding (pointing outward), and the off-chain resource commits to the chain (pointing inward). A verifier who checks both directions gains confidence not from either link alone, but from their mutual consistency.
Critically, bindings are advisory. They are not enforced by the Zcash consensus protocol. A transaction is valid or invalid based on its cryptographic properties; a binding is credible or not based on a verifier's judgment. This preserves the SRA principle that human institutions -- not blockchain protocols -- determine legitimacy.
Each binding is a typed record:
Binding = {
binding_type: u8, // Enumerated type (see below)
value: [u8; var], // Type-specific value (see below)
}| Code | Type | Value Field | Off-chain Counterpart |
|---|---|---|---|
| 0x01 | DNS | UTF-8 hostname (e.g. _sra-authority.rodriguezlarrain.art) |
DNS TXT record containing hex-encoded PK_R or Blake2b-256(GenesisPayload) |
| 0x02 | LEGAL | Blake2b-256 hash of legal attestation document | The document itself (notarized affidavit, apostilled declaration, or equivalent) |
| 0x03 | URI | UTF-8 URL (e.g. https://rodriguezlarrain.art/.well-known/sra-authority.json) |
Machine-readable JSON file at that URL containing PK_R and scope |
| 0x04 | ATTESTATION | Blake2b-256 hash of a third-party attestation payload | Signed attestation from a recognized third party (e.g. ALMA, a notary, an institutional verifier) |
| 0xFF | OTHER | Opaque bytes, interpreted by application-layer convention | Unspecified |
Each binding type creates a different kind of trust signal with different durability, cost, and evidentiary weight. They are designed to be composable: an RA that begins with only a DNS binding can later add a legal attestation and eventually receive an institutional counter-signature, each strengthening the aggregate confidence without invalidating prior bindings.
The RA publishes a DNS TXT record at the hostname specified in the binding's value field. The TXT record MUST contain one of:
sra-authority=<hex-encoded PK_R>, orsra-genesis=<hex-encoded Blake2b-256(GenesisPayload)>The DNS hostname SHOULD use the _sra-authority subdomain prefix (e.g. _sra-authority.example.art) to avoid collision with other TXT records, following the convention established by DKIM [rfc6376] and DMARC [rfc7489].
DNS bindings provide a lightweight, continuously verifiable signal. They are inexpensive to establish and can be checked programmatically by any verifier with DNS access. Their trust derives from the domain registration system: an attacker would need to compromise the RA's domain registrar account to forge this binding.
DNS bindings are inherently mutable (the RA controls the DNS zone) and therefore serve as a liveness signal rather than a historical commitment. A verifier who checks the DNS record at verification time confirms that the RA currently endorses this PK_R. The on-chain commitment to the hostname provides the historical anchor: the chain records which domain the RA claimed at genesis time, while the DNS record confirms the claim is still active.
The RA prepares a legal document -- such as a notarized affidavit, a declaration before a notary public, or an apostilled statement (for cross-jurisdictional validity under the Hague Convention [hague]) -- that explicitly states:
PK_R (hex-encoded) generated during the key ceremonyThe value field in the binding record contains Blake2b-256(document), where document is the canonical byte representation of the legal attestation.
The RA MUST retain the original document and make it available to verifiers upon request. The document itself is never placed on-chain.
Legal attestation bindings are heavyweight: they require professional services (notarization, apostille) and carry legal consequences for false statements. This weight is their strength. A legal attestation provides the strongest single-document evidence that a specific PK_R is controlled by a specific legal entity with a specific mandate. It is particularly important for RAs operating across jurisdictions, where a buyer in one country must evaluate the legitimacy of an estate governed by the laws of another.
The RA hosts a machine-readable file at the URL specified in the binding's value field. The file MUST be served over HTTPS and SHOULD be placed at a well-known path:
https://<domain>/.well-known/sra-authority.jsonThe file MUST contain a JSON object with at minimum:
{
"sra_version": 1,
"pk_r": "<hex-encoded PK_R>",
"scope": "<scope string matching the Genesis Declaration>",
"genesis_hash": "<hex-encoded Blake2b-256(GenesisPayload)>",
"contact": "<contact URI for the RA>"
}URI bindings serve a dual purpose: they provide a machine-readable discovery mechanism for automated verifiers, and they provide a human-readable web presence that contextualizes the RA's identity. They are complementary to DNS bindings -- the DNS record provides a minimal, infrastructure-level signal, while the URI endpoint provides richer metadata.
Like DNS bindings, URI bindings are mutable and serve as a liveness signal. They are also dependent on the continued availability of the hosting infrastructure. RAs SHOULD NOT rely solely on URI bindings for long-term verifiability.
A recognized third party -- such as ALMA, a notary service, an institutional verifier, or another RA -- produces a signed attestation that the Genesis Declaration corresponds to a legitimate RA. The attestation is a structured document (format to be specified in a companion ZIP or ALMA governance standard) containing at minimum:
PK_R being attestedThe value field in the binding record contains Blake2b-256(attestation), where attestation is the canonical byte representation of the third-party attestation document.
Attestation bindings provide social trust rather than institutional trust. Their weight depends on the reputation and verification standards of the attester. An attestation from ALMA carries different evidentiary weight than an attestation from an unknown entity. This is by design: the SRA architecture does not attempt to flatten trust into a single boolean; it provides structured signals that verifiers evaluate according to their own risk models.
Define the attestation payload format, or defer to a separate ALMA-focused ZIP.
Binding verification is RECOMMENDED but not consensus-critical. A verifier MAY check any subset of bindings according to its own risk model. The following verification procedures are defined:
DNS (0x01): Query the DNS TXT record at the specified hostname. Confirm that the record contains a value matching PK_R or Blake2b-256(GenesisPayload). If the DNS record is absent or does not match, the binding is stale (not necessarily fraudulent -- the RA may have lost control of the domain or may not have published the record yet).
Legal (0x02): Obtain the legal attestation document from the RA (out-of-band). Compute Blake2b-256(document) and confirm it matches the binding value. Evaluate the document's legal validity according to the verifier's jurisdictional standards.
URI (0x03): Fetch the JSON file at the specified URL over HTTPS. Confirm that pk_r and scope match the Genesis Declaration. If the URL is unreachable or the content does not match, the binding is stale.
Attestation (0x04): Obtain the attestation document from the RA or the attester (out-of-band). Compute Blake2b-256(attestation) and confirm it matches the binding value. Verify the attester's signature. Evaluate the attester's credibility according to the verifier's own trust model.
A binding is in one of three states:
| State | Meaning |
|---|---|
| Active | The on-chain commitment and the off-chain counterpart are mutually consistent |
| Stale | The on-chain commitment exists but the off-chain counterpart is absent, unreachable, or inconsistent |
| Revoked | The RA has explicitly revoked the binding via a BINDING_UPDATE event |
Stale bindings are not proof of fraud. Domain names expire, web servers go offline, and legal documents may be superseded. A stale binding reduces confidence but does not invalidate the Genesis Declaration or any signed events. Verifiers SHOULD weight active bindings more heavily than stale ones and SHOULD consider the age and diversity of bindings when assessing overall confidence.
Real-world bindings evolve over the lifetime of a registry. An RA may acquire a new domain, obtain an ALMA attestation, update a legal document after governance changes, or need to revoke a binding whose off-chain counterpart has been compromised (e.g. domain hijacking).
Binding updates allow the RA to add, replace, or revoke bindings without requiring key rotation. This decouples the lifecycle of institutional identity from the lifecycle of cryptographic identity.
A BINDING_UPDATE event is sent to UA_Genesis:
{
version: u8,
event_type: u8, // BINDING_UPDATE = 0x06
action: u8, // ADD = 0x01, REVOKE = 0x02
binding: Binding, // The binding record being added or revoked
reason: [u8; var], // UTF-8 human-readable reason (optional, max 64 bytes)
clock: u64, // Lamport clock for RA lifecycle events at UA_Genesis
prev_hash: [u8; 32], // Blake2b-256 of previous lifecycle event payload
}Let BindingSignature = Ed25519.Sign(SK_R, Blake2b-256(BindingUpdatePayload))
The memo bundle is: { BindingUpdatePayload, BindingSignature }
ADD (0x01): Appends a new binding to the RA's binding set. Verifiers who scan UA_Genesis reconstruct the current binding set by replaying all Genesis and BINDING_UPDATE events in clock order.
REVOKE (0x02): Marks a previously added binding as revoked. The binding record in the REVOKE event MUST exactly match the binding record in the prior ADD (or Genesis). Revoked bindings remain visible in the event history (the chain is append-only) but verifiers MUST treat them as inactive.
A binding MAY be re-added after revocation (e.g. if a domain is recovered after hijacking). The re-addition is a new ADD event; the prior revocation remains in the historical record.
To replace a binding (e.g. updating a legal attestation after a governance change), the RA issues a REVOKE for the old binding followed by an ADD for the new binding. These MAY be anchored in the same transaction (as two events in the memo bundle if space permits) or in consecutive transactions.
Key rotation is required when:
Key rotation is a planned transition. For suspected active compromise, see Emergency Revocation below.
The current signing quorum (M of N holders of the old key) and the incoming participants execute a new FROST DKG, producing a new group public key PK_R' and new shares.
If Seed_RA is being retained (typical case), the symmetric key protecting it is re-shared among the new participant set.
The RA constructs a Key Rotation Event and sends it to UA_Genesis:
{
version: u8,
event_type: u8, // KEY_ROTATION = 0x02
old_pk_r: [u8; 32], // The outgoing public key
new_pk_r: [u8; 32], // The incoming public key
effective_height: u64, // Block height after which new_pk_r is authoritative
rotation_reason: u8, // Enumerated reason code (see below)
frost_params: { // New threshold parameters
n: u8,
m: u8,
},
clock: u64, // Lamport clock for RA lifecycle events at UA_Genesis
prev_hash: [u8; 32], // Blake2b-256 of previous lifecycle event payload
}This payload is signed by BOTH the old key and the new key. The memo bundle contains:
{ RotationPayload, OldSignature, NewSignature }
Where OldSignature = Ed25519.Sign(SK_R, Blake2b-256(RotationPayload)) and NewSignature = Ed25519.Sign(SK_R', Blake2b-256(RotationPayload)).
The dual signature proves that the old authority endorsed the transition and that the new authority is capable of signing. Together, they establish continuity.
After effective_height, verifiers MUST accept only signatures from PK_R' for new events. Signatures from PK_R on events anchored before effective_height remain valid.
After key rotation, existing real-world bindings that reference PK_R become stale. The RA SHOULD issue BINDING_UPDATE events to add updated bindings referencing PK_R' (e.g. updating the DNS TXT record, issuing a new legal attestation, refreshing the well-known URI). The RA SHOULD revoke bindings whose off-chain counterparts have been updated so that the on-chain record reflects the current state.
| Code | Name | Description |
|---|---|---|
| 0x01 | SUCCESSION | Participant change due to death or incapacity |
| 0x02 | GOVERNANCE | Governance restructuring (new committee composition) |
| 0x03 | SECURITY | Proactive rotation due to suspected (not confirmed) exposure |
| 0x04 | SCHEDULED | Routine periodic rotation |
| 0xFF | OTHER | Unspecified reason |
Emergency revocation is the response to confirmed or strongly suspected key compromise. Unlike key rotation, it is adversarial: the RA must assume the compromised key is actively being used to forge events.
Emergency revocation requires a pre-committed recovery path. At the time of the Genesis Declaration, the RA SHOULD also anchor a Recovery Commitment:
{
version: u8,
event_type: u8, // RECOVERY_COMMITMENT = 0x03
recovery_pk: [u8; 32], // Public key of the cold recovery keypair
activation_delay: u64, // Minimum block height gap between revocation and reactivation
}The recovery keypair is a separate Ed25519 keypair generated during the initial key ceremony. It is RECOMMENDED that the recovery secret key be:
Upon confirmed or suspected compromise of the operational FROST key:
The recovery key holders reconstruct the recovery secret key.
They anchor an Emergency Revocation Event to UA_Genesis:
{
version: u8,
event_type: u8, // EMERGENCY_REVOCATION = 0x04
revoked_pk: [u8; 32], // The compromised public key
revocation_height: u64, // Block height after which revoked_pk is invalid
clock: u64,
prev_hash: [u8; 32],
}Signed by the recovery key: RecoverySignature = Ed25519.Sign(SK_Recovery, Blake2b-256(RevocationPayload))
After anchoring the revocation, the RA executes a new FROST DKG to generate PK_R' and then issues a standard Key Rotation Event (co-signed by the recovery key standing in for the old key).
Verifiers who encounter the Emergency Revocation Event MUST reject any event signed by revoked_pk at or after revocation_height, even if the event's Lamport clock and hash chain appear valid.
Upon key rotation following emergency revocation, all existing real-world bindings are implicitly stale (they reference a revoked key). The RA MUST issue BINDING_UPDATE events to establish fresh bindings under the new key. This is especially critical for DNS and URI bindings, which automated verifiers may check programmatically.
Between revocation_height and the anchoring of a new Key Rotation Event, the registry is in a suspended state for new events. Existing events anchored before revocation_height remain valid. This window is bounded by activation_delay from the Recovery Commitment.
This suspension is an intentional design choice. A brief interruption in the ability to issue new events is preferable to the silent acceptance of forged events from a compromised key.
This ZIP specifies Ed25519 and Blake2b-256 as the signature and hash primitives. These choices are appropriate for current threat models and are consistent with the Zcash protocol's existing primitives.
However, a registry designed for multi-generational timescales MUST anticipate the eventual obsolescence of any specific cryptographic scheme.
The version field in all payload formats defined in this ZIP enables forward-compatible upgrades. A future version of this ZIP MAY specify:
When migrating to a new signature scheme, the RA issues a Key Rotation Event under the current scheme that commits to the new public key under the new scheme. This provides a cryptographic bridge: the historical chain remains verifiable under the old scheme, while new events are protected by the new scheme.
If the underlying Zcash blockchain undergoes a network upgrade that changes transaction semantics, or if the RA elects to migrate to a different anchoring substrate, the RA SHOULD issue a final event under the current scheme containing the digest of the most recent validated event, then anchor that digest on the new substrate. This creates a verifiable reference chain across substrates without "moving" the historical record.
This ZIP introduces no changes to consensus rules, transaction formats, or address/key types. All on-chain activity consists of standard Orchard shielded transactions and memos, inheriting the existing privacy properties of the Zcash shielded pool.
The frost_params (N, M) in the Genesis Declaration and Key Rotation events reveal the size of the signing quorum but not the identities of participants. This metadata is encrypted within shielded memos and visible only to holders of VK_Genesis. It is RECOMMENDED that RAs treat frost_params as operational metadata and limit disclosure of VK_Genesis accordingly.
The scope field in the Genesis Declaration contains a human-readable description of the RA's domain. Since this is encrypted in shielded memos, it is visible only to holders of VK_Genesis, not to the public chain.
Participant identities are never recorded on-chain. The mapping between FROST share indices and natural persons is maintained off-chain by the RA and is outside the scope of this protocol.
Real-world bindings introduce a deliberate, controlled exception to the privacy-by-default posture of the SRA architecture. While binding records themselves are encrypted within shielded memos (visible only to VK_Genesis holders), the off-chain counterparts of bindings are inherently public or semi-public: DNS TXT records are publicly queryable, well-known URIs are publicly accessible, and legal attestations may be disclosed to verifiers. This is by design. The purpose of bindings is precisely to create a verifiable bridge between the shielded on-chain identity and a public real-world identity. An RA that wishes to maximize privacy MAY choose to include only a LEGAL binding (whose document is disclosed selectively to specific verifiers) rather than DNS or URI bindings (which are publicly discoverable). The choice of binding types reflects the RA's own trade-off between discoverability and privacy.
RAs SHOULD be aware that DNS and URI bindings, once published, create a publicly observable association between a domain name and the existence of an SRA registry. While the contents of the registry remain shielded, the existence of a registry for a given domain becomes discoverable. This may be acceptable or even desirable for most RAs (who benefit from discoverability) but should be considered by RAs operating under heightened privacy constraints.
This ZIP assumes the following adversary capabilities:
The protocol does NOT protect against:
Zcash does not currently support on-chain multisig for Orchard shielded transactions. Even if it did, on-chain multisig would expose governance structure (number of signers, signing patterns) on the public chain. FROST produces a single standard Ed25519 signature, preserving the privacy properties of the shielded pool and maintaining compatibility with the simple verification protocol defined in ZIP-SRA-EVENTS.
The FROST threshold key and the recovery key serve different threat models. The FROST key is optimized for operational availability (M-of-N, with M chosen for daily usability). The recovery key is optimized for adversarial resilience (cold storage, different custodians, higher activation barriers). Combining these into a single mechanism would force a trade-off between operational convenience and emergency robustness.
Without an on-chain scope declaration, an RA's key could be ambiguously applied to assets outside its legitimate domain. The scope field provides a human-readable boundary that can be checked by verifiers and referenced in dispute resolution. It is informational rather than enforced by consensus, consistent with the SRA principle that human institutions (not blockchain protocols) determine legitimacy.
A binding that is enforced by consensus would require the Zcash network to evaluate off-chain state (DNS records, legal documents, web endpoints). This is architecturally impossible in a decentralized system and would introduce oracle dependencies that contradict the SRA's design philosophy. Instead, bindings are structured signals that verifiers evaluate according to their own risk models -- just as a buyer evaluates a certificate of authenticity, a provenance document, or an institutional endorsement. The chain preserves the commitment; the verifier evaluates the credibility.
This design also ensures graceful degradation. If a DNS record expires or a web server goes offline, the registry continues to function. Events can still be signed, anchored, and verified. Only the confidence in the RA's real-world identity is affected, not the integrity of the event chain. This separation of concerns -- integrity from identity, cryptographic validity from institutional legitimacy -- is fundamental to the SRA architecture.
Estates operate under resource constraints. Requiring a full suite of bindings at genesis time would create an adoption barrier. A small estate might launch with only a DNS binding, later add a legal attestation when it engages counsel for a sale, and later still receive an ALMA attestation as the network matures. The incremental model allows confidence to accrue over time without requiring upfront completeness -- mirroring the Progressive Anchoring Model for artworks defined in the thesis (section 5.2.3).
A unidirectional binding (chain points to domain, but domain doesn't point back) proves only that the RA claims a domain. It does not prove the domain holder endorses the claim. Bidirectionality -- the chain commits to a hostname, and the DNS record commits to PK_R -- closes this gap. An attacker who compromises only the chain cannot forge the DNS record; an attacker who compromises only the domain cannot forge the on-chain commitment. Both must be consistent for the binding to be active.
This is the same verification pattern used by DKIM for email authentication and by Keybase for identity proofs. It is well-understood, widely deployed, and does not require novel trust assumptions.
| Code | Event Type | Section |
|---|---|---|
| 0x01 | GENESIS | Genesis Declaration |
| 0x02 | KEY_ROTATION | Key Rotation |
| 0x03 | RECOVERY_COMMITMENT | Emergency Revocation |
| 0x04 | EMERGENCY_REVOCATION | Emergency Revocation |
| 0x06 | BINDING_UPDATE | Binding Updates |
[Note: 0x05 is reserved for future use.]
Seed_RA coupling: Should Seed_RA be derived deterministically from the FROST group secret? This would eliminate a separate shared secret but would couple seed lifecycle to key rotation, requiring re-derivation of all per-asset keys on rotation. Trade-offs need further analysis.
Recovery commitment timing: Must the Recovery Commitment be anchored simultaneously with the Genesis Declaration, or can it be added later? Early commitment is safer but may be impractical for RAs that bootstrap incrementally.
Cross-RA key ceremonies: When multiple RAs coordinate under ALMA, should there be a standardized ceremony format for mutual verification of Genesis Declarations? This may belong in a separate ALMA-focused ZIP.
Offline signing UX: The FROST signing protocol requires at least two rounds of communication among participants. For air-gapped shares, this implies a physical ceremony. Practical guidance on ceremony logistics (which is out of scope for this ZIP) would be valuable as a companion document.
Share refresh without rotation: FROST supports proactive share refresh (re-randomizing shares without changing the group public key). Should this be specified as a separate event type, or is it purely an off-chain operational matter?
Attestation payload format: Should the format for Type 0x04 ATTESTATION bindings be defined in this ZIP, in a companion ZIP, or in an ALMA governance standard? The answer depends on whether attestation interoperability is needed before ALMA is operational.
Binding expiry: Should bindings carry an explicit expiry timestamp, or is staleness (failure of off-chain verification) sufficient? Explicit expiry would allow automated verifiers to flag aging bindings proactively, but adds payload size and complexity.
DNS record format standardization: Should the DNS TXT record format be registered with IANA as an underscore-prefixed service name per RFC 8552 [rfc8552]? This would formalize the _sra-authority prefix but requires an IANA registration process.