Addendum to the Catalog.ID Whitepaper: Supersecret Recovery Kits

Last updated: 2026-10-16
Author: Roberto Bourgonjen
Copyright: © 2026 Roberto Bourgonjen. All rights reserved.
Applies to: Catalog.ID personal, organization, and delegate identities
Related sections: §3.2 Key Custody and Loss, §3.4 Key Bag and Device Access, §10 Registration Flow, §15
Companion document: Hybrid Cryptography Briefing

1. Rationale

Catalog.ID is a zero‑knowledge identity system. Private keys are generated client‑side and never leave the member's devices in plaintext. The supersecret (§3.4.3) is the only credential that can decrypt the key bag entries on a fresh device, and it is never transmitted to the server. As stated in §3.2, key loss without a backup is irrecoverable by design — a recovery mechanism that allowed a third party to restore a private key would defeat the trust model that makes the system worth using.

This property is correct, but it leaves a long tail of failure modes uncovered:

• The member writes down the supersecret on paper and the paper is destroyed (fire, water, theft, mislaid).
• The member stores it in a single password manager, which is then lost or corrupted.
• The member dies or becomes incapacitated without having communicated the supersecret to anyone.
• The member migrates between devices, loses access to all of them simultaneously, and discovers that the supersecret backup they trusted is no longer readable.

The §3.2 fallback path — re‑register with a fresh identity and ask the Operator to transfer the public profile — is acceptable for active members but is not a serious archival solution. It produces a new username, breaks pseudonymous continuity, requires the Operator to still be operating, and cannot recover claims that were never shared with anyone else.

This addendum specifies two related mechanisms:

1. the extended supersecret format (§2.5), ≈ 256 bits of entropy with per‑line checksums that keep manual entry tractable, which is what allows encrypted key bag bundles to be distributed abundantly without becoming offline brute‑force targets; and
2. the Recovery Kit — a member‑created, threshold‑protected, Operator‑independent backup of the supersecret that allows a member, or the parties the member designated, to reconstruct the supersecret and decrypt the key bag without trusting any single party and without requiring any Catalog.ID node to still be reachable.

Neither weakens the zero‑knowledge property of the system. The Recovery Kit does not introduce a server‑side escrow. The Operator never holds enough material to reconstruct the supersecret. Recovery remains a function of material the member chose to distribute, not a function of any service provider.

2. Definitions

2.1 Recovery Kit

A Recovery Kit is a printable, exportable, Operator‑independent backup of a Catalog.ID supersecret. It consists of:

• a set of Recovery Sheets — printable threshold shares, one full page each;
• an encrypted key bag bundle — the export of the encrypted key bag entries needed to restore the identity once the supersecret has been reconstructed;
• the kit entry — the recovery set's own randomness, held as one entry of the member's key bag and therefore encrypted under the supersecret itself, from which any sheet of the set can be printed again at any time (§4.1).

The sheets and the bundle are independent. The sheets can be reused across many bundles; the bundles can be refreshed without reissuing the sheets.

The kit entry is a key bag entry like any other: encrypted under the supersecret, never legible to the Operator, replicated by the same per‑entry synchronization, and carried inside every bundle. It has one restriction of its own (§17): it is never written to a device. Because the set's randomness is kept, a member who loses one sheet, or who wants to hand a custodian their sheet later and with proper instructions, prints that sheet again instead of reissuing the whole kit.

The kit's own non‑secret description — which recovery set the sheets belong to, the threshold profile, the bundle the kit was created against, when it was created and when it was last tested — is not a separate document. It is carried by the printed kit itself and by the server‑side kit record (§12).

2.2 Recovery Sheet

A Recovery Sheet is a printable representation of one threshold share of the supersecret, occupying one full page of the printed kit (§2.6). Each sheet carries enough metadata to identify the recovery set and validate the share, and a high‑error‑correction QR payload that encodes the share itself. A single sheet cannot reconstruct the supersecret. A valid quorum of distinct sheets can. A single sheet can, however, be checked for authenticity on its own (§6.4).

2.3 Share Type and Physical Copy

The system distinguishes a share type from a physical copy of that share type.

In a 2‑of‑3 kit, the share types are Sheet A, Sheet B, and Sheet C. The member may print Sheet A many times and place each copy in a different location — all those copies carry the same share. Recovery requires different share types, not a larger number of copies of the same share type. Multiple printed copies of one sheet type count as one type: they increase availability without changing the threshold.

2.4 Encrypted Key Bag Bundle

The encrypted key bag bundle is a self‑describing, portable export of the member's key bag (§3.4). It contains every encrypted key bag entry plus the non‑secret metadata required to decrypt them once the supersecret has been recovered:

The bundle is opaque ciphertext from the perspective of any party that does not hold the supersecret. AES‑256‑GCM authenticates each entry; tampering is detected at decryption.

The bundle is not secret in the same way as the plaintext key material. It is safe — and recommended — to store many copies in many places: on the member's devices, in cloud storage, with trusted family or friends, with the Operator, or with a notary or archive institution. Loss of all bundle copies is a separate, additive failure mode from loss of all Recovery Sheets. Both must survive for recovery to succeed.

The design principle is:

Make the encrypted key bag bundle abundant. Make the supersecret scarce and threshold‑protected.

2.5 Extended Supersecret Format

The §3.4.3 supersecret is the credential that ultimately decrypts every key bag entry — both the server‑stored entries replicated between nodes (§15.3) and the encrypted key bag bundles distributed by the member. Because the bundle carries its own Argon2id salt and parameters openly, any party who holds a bundle copy holds an offline brute‑force target. The strength of that target is exactly the strength of the supersecret behind Argon2id.

Argon2id's memory‑hardness raises the per‑guess cost and resists quantum parallelization (Grover yields only √k speedup over k machines, and each oracle query must coherently maintain the Argon2id memory state in superposition). For an artifact meant to be stored abundantly and to remain readable for decades, that is not enough on its own: the supersecret itself must carry a wide margin. Catalog.ID therefore uses an extended supersecret format, which is the format of the whitepaper's §3.4.3:

xxxx-xxxx-xxxC
xxxx-xxxx-xxxC
xxxx-xxxx-xxxC
xxxx-xxxx-xxxC

• Four lines of twelve characters, displayed as three dash‑grouped clusters of four.
• Per line: eleven random characters drawn from the Catalog.ID non‑confusing base57 alphabet [a–z A–Z 2–9] excluding i, l, and O, followed by one checksum character as the last character of the third cluster.
• Total: 44 random characters + 4 checksum characters.
• Entropy: 44 × log₂(57) ≈ 256.65 bits, ≈ 128 bits effective under Grover, behind Argon2id memory‑hardness.

At ~128 effective bits behind Argon2id, the supersecret falls well beyond any reasonable doubt of 100‑year security against any combination of classical and quantum attack we can presently model. A bundle copy resting indefinitely in a custodian's archive is no longer an offline brute‑force target on any plausible timeline, regardless of who holds it.

Per‑line checksums for manual entry. The four checksum characters are not part of the cryptographic strength — they are a usability mechanism. When the member types the supersecret manually for cross‑device restore (§3.4.4), the client recomputes each line's checksum independently and reports which specific line is wrong. The member retypes only the affected twelve characters rather than re‑entering all forty‑eight. Each line checksum is a domain‑separated derivation:

line_checksum_i = first base57 symbol of SHA‑256(
    "Catalog.ID supersecret v2 line checksum" ||
    format_version ||
    alphabet_identifier ||
    line_number_i ||
    eleven_random_characters_for_line_i
)

The checksum is local to a line — it provides no information about the rest of the supersecret and is not treated as cryptographic security.

On paper the checksum characters carry no visual distinction. The supersecret prints as four uniform lines in a single ink, and the printed kit carries no explanation of the checksum mechanism. Legibility on a poor printer — where grey tints and colour tints are unreliable — and the absence of secret‑adjacent documentation on the credentials sheet both matter more than showing the member where the checksums sit. Verification is electronic instead: the client validates the input wherever the supersecret is typed, and the print step ends with a type‑back gate in which the member types one randomly chosen line back from the paper before the kit is finalized.

One secret, applied everywhere. Adding entropy to the supersecret itself strengthens every path simultaneously — server replicas in §3.4, bundles in §5, and any future ciphertext keyed off the supersecret. The member manages a single secret. A member who has memorized the supersecret and stashed a bundle can recover from the bundle alone, without first reassembling sheets. The cost is typing 48 characters instead of fewer on a fresh device, mitigated by the per‑line checksums.

2.6 Membership Kit

The physical carrier of everything above is the Catalog.ID Membership Kit — for an organization, the Catalog.ID Organization Membership Kit. It is a single print job holding the member's credentials, the Recovery Sheets, and the Catalog.ID Membership Agreement, produced when the account is created and reprintable afterwards from the member's own settings. Its structure is specified in §6.1.

Three kinds of sheet in the kit are not Recovery Sheets and play no part in the threshold construction:

• the credentials sheet, which carries the supersecret in full together with the account's login credentials; and
• the Account Unlock Sheet, present in personal and delegate kits, which restores login access: it unlocks a locked account and can optionally set a new password. Every use of it requires a one‑time code sent to the verified email address or phone number printed on the sheet; it cannot decrypt keys or data; it remains valid after use and after a lock; and issuing a new one invalidates its predecessor; and
• the Authenticator Key sheet, present in personal and delegate kits, which carries a TOTP secret as a QR code. Scanned into an authenticator app, it lets the member turn on an optional login code, a second factor at sign‑in; an organization account has none.

Throughout this addendum, Recovery Kit names the set of Recovery Sheets together with the encrypted key bag bundle, and Membership Kit names the printed package that carries it.

3. Core Design Principle

Catalog.ID may help create and maintain the recovery set, but the recovery set must be able to outlive Catalog.ID.

Therefore:

• The plaintext key bag is never transmitted to any Operator.
• The Recovery Kit reconstructs the supersecret, not the keys.
• The encrypted key bag bundle is opaque to anyone who does not hold the supersecret, and may be stored anywhere.
• No Catalog.ID node, Operator, foundation, notary, or custody provider is cryptographically required to participate in recovery.
• A valid quorum of distinct Recovery Sheets plus any one surviving encrypted key bag bundle is sufficient.

This is not a server‑side escrow system. It is a member‑controlled, threshold‑protected backup of the existing Catalog.ID supersecret, layered on top of the existing key bag (§3.4).

4. Threshold Construction

4.1 Algorithm

Recovery Sheets encode shares produced by Shamir's Secret Sharing (SSS) over GF(2⁸). The shared secret is the 44‑character random portion of the extended supersecret (§2.5), with dashes and per‑line checksums excluded — interpreted as 44 ASCII bytes:

shared_secret = supersecret_random_bytes
                (44 bytes, ASCII characters from the base57 alphabet)

The dashes are layout, not data, and the four per‑line checksums are deterministically derivable from the random characters, so neither needs to be split. Each byte of the 44‑byte shared secret is split independently with a fresh degree‑(k−1) polynomial whose constant term is the byte itself. Any k distinct (x, y) pairs reconstruct the byte via Lagrange interpolation; fewer than k pairs reveal nothing about the supersecret (information‑theoretic security).

The polynomials' non‑constant coefficients are drawn at random when the set is created and are then retained, in the kit entry (§2.1). A share is nothing more than the evaluation of the stored polynomial at the sheet's x‑coordinate, so the holder of the supersecret and of any copy of their key bag can re‑evaluate any sheet of the set, on any node, at any later date: that is what makes a set reprintable. A reissue is the opposite operation — a fresh draw of coefficients, producing a set that shares nothing with the old one (§9.5).

Retaining the coefficients has two normative consequences. First, the coefficients are bound to ONE secret: evaluating them again under a rotated supersecret would publish the exclusive‑or of the old and new secrets to anyone holding one old and one new sheet of the same index, which is why §5.3 requires a rotation to draw a new set rather than re‑use the stored one. Second, the coefficients plus a single Recovery Sheet reconstruct the supersecret, which is why §17 keeps the kit entry off devices.

A share is therefore a 44‑byte vector indexed by an x‑coordinate in the range 1..255. The recovery set never uses x = 0; that point would be the shared secret itself.

On reconstruction, the client recomputes the four line checksums and reassembles the 48‑character display form, then proceeds into the standard §3.4.4 device setup flow exactly as if the member had typed the supersecret manually.

4.2 Share Payload

Each Recovery Sheet encodes the following payload in its QR code. The wire format predates the printed vocabulary and keeps its own historical field names — the magic CIRC and the field card_label below are the format, and implementations depend on them:

The MAC is not a secret authenticator on the supersecret itself — SSS is information‑theoretic and requires no MAC for confidentiality. Its purpose is integrity of the printed sheet: it allows a recovery or verification client to detect a transcription error, a tampered print, or a sheet belonging to a different recovery set, before attempting reconstruction.

The per‑set verification key is generated at kit creation and is included in the payload of every sheet, so that any single sheet can be verified on its own, with no other sheet and no accompanying document present (§6.4). Including it does not weaken security: a single sheet's integrity check is unrelated to the secrecy of the supersecret.

The first eight bytes of payload_mac, as 16 uppercase hexadecimal characters in four groups of four, form the sheet fingerprint printed on the sheet itself (§6.2).

4.3 Why SSS

Shamir's Secret Sharing is the standard answer for this problem and has the properties this kit requires:

• Information‑theoretic. Below the threshold, an attacker who breaks every cryptographic primitive in the system still learns nothing about the supersecret from the shares they hold.
• Independent of the underlying cryptography. SSS is unaffected by progress against ML‑KEM, ML‑DSA, AES, or any other primitive Catalog.ID may adopt. The kit's threshold guarantee is a separate, additive layer.
• Small share size. Each share is the same size as the secret. A 44‑byte supersecret portion produces 44‑byte shares, which fit comfortably in a QR code carrying high error correction.
• Mature. Reference implementations exist in every relevant language; the failure modes are well understood; the protocol does not need to be invented.

5. Encrypted Key Bag Bundle

5.1 Relationship to §3.4 Key Bag Entries

The bundle is an export format for the same encrypted key bag entries described in §3.4. No new encryption is introduced. Each entry is an AES‑256‑GCM ciphertext keyed by Argon2id(supersecret, salt, params), with the same key ID and key index that identify the entry in the server replica. A bundle exported today and decrypted in 2050 reconstructs the same plaintext private keys provided the supersecret and the bundle's Argon2id parameters survive.

Each bundle uses a fresh per‑bundle salt, distinct from the §3.4.3 account salt. Reusing the account salt would let an attacker who captures both a bundle and a server‑side ciphertext amortize Argon2id work across the two; a fresh salt forces the attacker to pay the work twice. The supersecret carries enough entropy (§2.5) that even one such attack is infeasible — the fresh salt is defense in depth, not the load‑bearing protection.

Account blobs ride the bundle unchanged. The bundle also carries the member's account blobs — the per‑account opaque documents modules keep under the member's identity. These are not re‑encrypted under the bundle key. Each stays exactly as the server stored it: AES‑256‑GCM under a key derived from the account's derive root, which is itself an ordinary key bag entry the bundle already carries. One supersecret therefore opens the bag, the bag yields the root, and the root re‑derives every blob key. Re‑encrypting them would buy nothing — the whole file is already opaque without the supersecret — and would introduce a second encryption path that could disagree with the live one about how a blob key is derived. The section is required even when empty: a bundle carrying no blob section would restore a member's identity while silently discarding their application state, which is the loss the section exists to prevent. Restoring never overwrites a blob the account already holds; the live copy is newer than any snapshot by definition.

Bundles and server replicas are therefore symmetric in their cryptographic structure: same supersecret, same Argon2id, same AES‑256‑GCM, only the salt differs. A member who has memorized the supersecret can decrypt a bundle directly without involving the sheets. The sheets exist to recover the supersecret when memory and all written backups have failed.

5.2 Self‑describing

The bundle is self‑describing. It contains the format version, the algorithm identifiers for each entry, the Argon2id salt and parameters, the full key chain metadata (so chain‑walking decryption per §3.3 still works after multiple rotations), and a bundle fingerprint that ties it to a specific Recovery Kit. A future Catalog.ID client should be able to open a bundle without external metadata — the bundle is the unit of preservation.

5.3 Refresh Without Reissuing Sheets

The supersecret is the durable secret. The encrypted key bag bundle is a transient artifact that captures the key bag at a point in time. Whenever the member adds a key, rotates a key after compromise (§3.3), or onboards an organization key chain, they may export a fresh bundle. Each new bundle uses a fresh argon2id_salt and gets a new bundle_fingerprint, but is decrypted by the same supersecret and therefore by the same Recovery Sheets.

recovery_kit_2026
  ├─ Sheets: A, B, C  (split supersecret S)
  ├─ Bundle v1 (fingerprint F1, salt s1) — first export, after registration
  ├─ Bundle v2 (fingerprint F2, salt s2) — exported after adding xrpl_master
  ├─ Bundle v3 (fingerprint F3, salt s3) — exported after key rotation
  └─ Bundle v4 (fingerprint F4, salt s4) — exported after an account blob changed

All four bundles open with the same supersecret S, reconstructed from any two of {A, B, C}, or supplied directly by the member if S is still remembered. The kit record (§12) tracks the most recent bundle fingerprint, so a recovery client can warn that a bundle is older than the newest one known — but old bundles remain decryptable; they simply represent older snapshots of the key bag.

Recovery Sheets must be reissued only when the supersecret itself changes. A supersecret rotation is a kit re‑creation event, not a bundle refresh, and invalidates previously printed sheets.

Re‑creation is a requirement, not a convenience. Since §4.1 retains the polynomial coefficients, a rotation could in principle re‑evaluate the stored set under the new secret, and must not. With the coefficients unchanged, the exclusive‑or of an old and a new share at the same index is the exclusive‑or of the old and new secrets, so anyone holding one sheet from each set learns the new supersecret from the old one. A rotation therefore draws a fresh set, records it as a new generation of the kit entry, and marks the previous generation superseded; the previous generation is retained and never printed from.

5.4 Bundle Storage Guidance

Members are encouraged to store the bundle redundantly:

- the member's own devices
- cloud storage (Dropbox, iCloud, OneDrive, ...)
- a USB drive or other offline medium
- the Catalog.ID Operator
- a foundation, notary, or archive institution
- trusted friends or family

Because the bundle is opaque ciphertext, abundance is the goal. Loss of all bundle copies is irrecoverable even if the Recovery Sheets survive — the sheets reconstruct the supersecret, not the encrypted key material.

This is symmetric with replication between nodes (§15): every Catalog.ID node already holds a full replica of the encrypted key bag entries and the Argon2id salt, so as long as a single node survives, the bundle is implicitly available through that node's replica. The exported bundle is the additional layer that makes the kit independent of Catalog.ID's continued existence.

6. Recovery Sheets

6.1 The Printed Kit and the Sheet

A Recovery Sheet is one A4 page of the Membership Kit (§2.6). The kit is produced as a single print job, and its pages are meant to be separated immediately afterwards and distributed, laminated, sealed in envelopes or filed away individually. The visual layout is fixed — no Operator branding overrides it.

The order of the kit.

1. Cover — the kit's title, the account id, the account type and, for an organization, the organization and domain rows, and the version stamp.
2. Introduction — what the kit contains and what each sheet is for, written for a reader with no prior context; a table of contents with page numbers; and, when the kit carries the Membership Agreement, the statement that using anything from the kit implies consent to that agreement, naming the pages on which it is printed.
3. Sheets — the credentials sheet; then, in a personal or delegate kit, the Account Unlock Sheet and the Authenticator Key sheet; then one Recovery Sheet per share type, each occupying a full page.
4. Extra copies — additional copies of a sheet type, printed as separate sheets immediately after the recovery sheets. A copy is footed with its sheet type and copy number rather than a page number, so that the numbering of the master set stays intact and the owner keeps a first‑generation original of every sheet to duplicate from later. The copies are what custodians receive; a kit printed at registration has at least one copy of every sheet type.
5. The Membership Agreement, printed last in small type and numbered as part of the kit.

What every sheet carries. Because the pages are separated, each must stand on its own as a Catalog.ID document: every sheet — copies included — carries the full letterhead, and beneath it the account header (account id, account type, and the organization, domain and role rows where they apply, plus a version stamp, which is the time this page was PRINTED). The set's own creation time is carried separately, inside the QR payload's created_at (§4.2), and it is that value — not the version stamp — that the verification page reports as the kit's creation. The header continues without a gap into a contact row naming the account's verified email address and phone number, so that a custodian who has only this page can tell whose sheet they are holding; an organization account has neither and prints none. Where the kit carries the Membership Agreement, the sheet ends with a single consent line naming the agreement's page range.

The recovery sheet itself. Its title states the sheet type and its position in the set — Account Recovery Sheet A (1 of 3). A Purpose row names the custodian role or the place the sheet is meant for, as the member assigned it at kit creation. The QR (§6.2) dominates the page, and to its right stands the sheet's type letter, a single very large glyph in that type's colour: one colour per share type, the only colour the kit permits, chosen so that the letter stays legible when the page comes out of a greyscale printer. The QR is the only machine‑readable symbol on the sheet.

The explanation on the member's own sheets is written for a reader with no prior context, such as an heir or an executor:

• everything in Catalog is encrypted, and the Operator cannot decrypt it;
• the sheets exist for the emergency in which the account holder no longer has the keys, or has died;
• any k of the n sheets, brought together, reconstruct the account holder's supersecret — this sheet alone reconstructs nothing;
• the same sheets also recover the decryption keys from an offline encrypted key‑backup file (on a USB drive, in cloud storage, or with a custodian) when no Catalog.ID node can be reached at all (§15, step 2) — so recovery does not depend on the service surviving;
• the handling guidance names which other sheet types must be brought together with this one — "bring it together with any one of sheets B or C".

Two hand‑fill lines follow on the member's own sheets, completed by pen: In an emergency, contact and Where the other sheets are. No sheet is printed as a map of the others.

Copies for custodians. Custodians receive copies (§6.1, item 4); the member keeps the originals. A copy carries the same share and the same QR, but its text is written for the custodian: that they hold the sheet so the account can be recovered if its credentials are lost or its holder can no longer act; that it is one of n sheets of which k recover the account, and reveals nothing alone; to keep it like a passport and not copy, photograph or scan it; to hand it over only to the account holder or, if they cannot act, to the person named on it; which other sheets a recovery brings it together with; and that they may be asked once a year to check it at the verification page. A copy has the In an emergency, contact line and no Where the other sheets are line, so a custodian knows whom to call without holding a map to a quorum (§9.6).

Under the QR, a single verification line gives the address of the node's verification page and the sheet's fingerprint — "Verify this sheet at ‹node host›/recovery — fingerprint XXXX-XXXX-XXXX-XXXX" — falling back to naming the member's home node when the printing client does not know the host it should print. The fingerprint is printed once, here: a custodian who has opened that page can see at a glance that it is describing the sheet in their hand. The fingerprint identifies the PRINTOUT, not the set. A sheet reprinted from the same set (§4.1) carries the same share and the same set id, and combines with sheets printed years earlier — but it is stamped with its own print's bundle fingerprint, so its MAC and therefore these sixteen characters differ. Nothing may compare the fingerprints of two sheets, or a sheet's fingerprint against a stored value; the check the verification page performs is of a sheet against itself.

The governing principle for the page is that it prints what a single custodian can act on, and nothing else.

6.2 QR Encoding

The QR code is the primary machine‑readable carrier of the share. It is not a convenience feature on top of a textual representation:

• QR Model 2 with error correction level H (≈ 30 % redundancy) is the default for archival sheets. Level Q is acceptable for short‑lived test prints.
• Module size is conservative — at least 0.6 mm per module on the printed page, with a wide quiet zone. In practice the QR is given most of the width of the sheet, comfortably above that archival floor, so that it scans on the first attempt from a cluttered, ageing inkjet print held at an awkward angle.
• The payload is binary‑encoded (byte segment), not base64‑wrapped, to keep the module count low.
• A human‑readable sheet fingerprint — the first 8 bytes of payload_mac as 16 uppercase hexadecimal characters in four groups of four, XXXX-XXXX-XXXX-XXXX — is printed on the verification line under the QR, for comparison against what the verification page reports (§6.4). Eight bytes put the birthday bound for two colliding fingerprints at the order of 2³² sheets.
• The QR is the only machine‑readable symbol on the sheet. It is self‑verifying: the payload carries the per‑set verification key and the MAC computed under it (§4.2), and the verification page refuses a payload whose MAC fails. A second symbol, such as a barcode of the fingerprint, would add redundancy rather than assurance.

A grouped textual fallback (e.g., bech32 or base58 chunks) may be printed alongside the QR for catastrophic scanner unavailability, but the design assumes the QR will be readable in any reasonable future environment. QR is a 30‑year standard with implementations on every camera‑equipped device; it is the right archival format for this purpose.

6.3 Tampering and Replay

A sheet carries no authority to mutate Catalog.ID state. Even if a sheet is photographed, copied, or republished, an attacker still needs k − 1 other sheet types to reconstruct anything. The MAC on the share payload protects only against accidental corruption — it is keyed to the recovery set, not to a member secret, and a sufficiently sophisticated attacker who has obtained one sheet can produce a syntactically valid forged sheet. This does not matter, because that attacker still does not hold a quorum.

6.4 Single‑Sheet Verification

Any single Recovery Sheet can be verified on its own — without the other sheets, without the bundle, and without the account holder present. The share payload carries the per‑set verification key and the MAC computed under it (§4.2), so the cryptographic part of the check is self‑contained; the node contributes only the question of currency.

The custodian opens the verification page at the address printed on the sheet and scans the QR. The page:

• checks the payload's shape and verifies its MAC under the verification key the payload carries;
• displays the sheet fingerprint, computed from the bytes actually scanned, so the custodian can compare it against the fingerprint printed on the sheet's verification line and know that page and payload belong together;
• names the account the sheet belongs to; and
• confirms with the node that the sheet's recovery set is the account's current kit. A reissued kit supersedes every sheet of the set it replaces, and a custodian holding a superseded sheet should learn that at a quiet moment rather than during an emergency.

Verification never reconstructs anything. A page that could reconstruct from a single sheet would contradict the threshold. The check proves that the sheet is a structurally sound, unaltered share of the named recovery set, and that the set is still the one that matters — which is the entire set of questions a lone custodian can usefully ask.

7. Default Profile: 2‑of‑3 Recovery Kit

The recommended default is 2‑of‑3. The client creates three distinct share types:

Sheet A — Personal circle      (family, close friends)
Sheet B — Institutional        (foundation, notary, archive)
Sheet C — Owner reserve        (member's own safe)

Any two distinct sheet types reconstruct the supersecret. No single type does:

A + B → recovery possible
A + C → recovery possible
B + C → recovery possible
A | B | C alone → no recovery

Multiple physical copies of any one type are independent of the threshold:

A1, A2, A3 — three sealed copies of Sheet A in three locations
             (still only counts as one share type)

This profile is a deliberate compromise:

• High availability. The member can lose any single share type entirely — through fire, an unresponsive custodian, or a deceased family member — and still recover.
• Low collusion surface. Two parties chosen from disjoint social circles must collude (or be compromised together) to reconstruct.
• Easy to explain. Three sheets are easy to inventory, easy to place, and easy to verify in a fire drill.

8. Higher‑Assurance Profiles

The 2‑of‑3 profile is the default. Catalog.ID also supports (k, n) configurations for members or organizations that want a different trade‑off:

3‑of‑5 Recovery Kit               typical for organization identities
5‑of‑9 Archive Recovery Kit       typical for cultural/archive institutions
7‑of‑13 High‑Security Kit          for unusual high‑value cases

Higher k raises the bar against collusion at the cost of recovery availability — more parties must be reachable simultaneously. The same sheet‑copy semantics apply: copies of a share type increase availability but do not change the threshold.

For organization identities (§3a), the 3‑of‑5 profile is recommended. Typical distribution:

Sheet A — owner delegate's personal custody
Sheet B — second owner delegate's personal custody
Sheet C — organization's notary or registered agent
Sheet D — an outside foundation or trusted custody provider
Sheet E — sealed in the organization's archive

Any three of the five reconstruct the organization's supersecret, supporting recovery scenarios after death, departure, or disagreement among individual owners.

9. Distribution Patterns

Distribution is the member's decision. Three reference patterns are provided, followed by the profiles the client recommends and the rules that govern copies and coordination.

9.1 Self‑Custody

All share types are held by the member, in physically and administratively separated locations:

Sheet A → home safe
Sheet B → bank safe deposit box
Sheet C → second residence or sealed testament file

This is the simplest Operator‑independent model. The risk is that recovery after death or incapacity depends on heirs knowing both that the kit exists and where to find at least two distinct sheets.

9.2 Personal + Institutional Custody

Mixed personal and institutional storage gives multiple legitimate recovery paths:

Sheet A → multiple copies among close family
Sheet B → a foundation, notary, or licensed custody provider
Sheet C → the member's own archive

Recovery routes:

family + foundation
family + owner reserve
foundation + owner reserve

This is the recommended pattern for active creative members whose archives may need to outlive them.

9.3 Estate or Archive Recovery

For long‑term archive purposes, the member places at least one share type with a party who is structurally likely to be reachable after the member's death — an executor, a notary, a foundation, an archive institution, or a legal representative. Who is expected to release which sheet, and under which conditions, belongs in the member's own legal documents (§12), where it carries legal force.

9.4 Recommended Profiles

The client offers the patterns above as named profiles. A profile fixes the threshold and proposes a purpose and a number of copies for each sheet:

These are recommendations, not constraints. Purposes and copy counts stay editable before printing, and the holder may of course write anything by hand on the printed sheets afterwards. Personal, with notary is the recommended profile for an individual, Large organization for an organization. The registration wizard preselects none of them: the member chooses a profile before continuing.

9.5 Copies

Additional copies of one sheet type carry the identical share and count as one sheet type (§2.3). They protect availability — an inner circle need not depend on one person being reachable — and they never lower the threshold or grant the group any power one copy would not have granted. They do widen exposure: each copy is one more place the share can be stolen from. Keep the count small.

When a sheet is lost. Reissuing the kit — a fresh set (§4.1) — does not disable the lost sheet, and nothing can: the old set's sheets still combine among themselves, wherever they are. A reissue is a remedy only in the case where fewer than k sheets of the old set have gone missing AND every surviving old sheet can be collected and destroyed. Once that is done the lost sheet stands alone below the threshold and is useless, and the new set goes out in its place. If a quorum of the old set is out of reach, the supersecret must be treated as exposed and the remedy is a rotation (§5.3), not a reissue. If the loss is simply that a custodian no longer has their copy, the cheaper answer is to print another sheet of the same set (§4.1) and hand it over; nothing already distributed is disturbed.

Copies protect availability, never confidentiality. If the concern is a custodian acting badly rather than being unavailable, the answer is the threshold, not more copies. Giving several friends distinct sheet types instead would let them recover together without the notary or the owner's own sheet — a different trust model, to be chosen deliberately or not at all.

9.6 The Coordinator, Not a Map

Sheets do not print where the other sheets are. The member's own sheets have a hand‑fill line for the other sheets' whereabouts; a custodian's copy does not, and carries only the line naming whom to contact in an emergency (§6.1). The intended use is that the emergency contact on every copy is the coordinator, typically the notary or the attorney, who alone knows the full whereabouts. A custodian then knows whom to call without holding a map to a quorum.

9.7 Threshold Recovery Is Not Multisignature

Threshold recovery reassembles the supersecret once, in one place, and whoever ran it holds the identity from then on — including any linked XRPL accounts. After any recovery the supersecret should be rotated and the kit reissued, because the people who combined the sheets now know it. Ongoing, per‑transaction control is a different instrument: it belongs to XRPL multisign, which is configured independently of the kit.

10. Optional Compartments

A single key bag is the simplest case and is sufficient for most members. Catalog.ID may also support multiple key bag compartments, each with its own supersecret and its own Recovery Kit. Different compartments may carry different risk profiles:

Identity Compartment   — attr_encrypt, msg_encrypt
Archive Compartment    — content/blob root keys
Wallet Compartment     — xrpl_master, future Bitcash keys

This allows a member to share recovery access for the Identity Compartment with family while keeping the Wallet Compartment under stricter or different custody — for example, a 3‑of‑5 kit distributed among institutional custodians only.

Wallet keys must not be included in a general‑purpose Recovery Kit by default. Their inclusion requires explicit member selection, an explicit warning at kit creation, and a separate compartment if the member chooses to use one.

11. Hybrid Cryptography Compatibility

The Recovery Kit is unaffected by the hybrid cryptography migration described in the Hybrid Cryptography Briefing. The reasoning is structural:

1. The Recovery Sheets split the supersecret, not the keys.
2. The supersecret derives a symmetric AES‑256‑GCM key, which is post‑quantum‑resilient under any plausible model.
3. Whether the key bag entries decrypted by that AES key contain ML‑KEM private keys, X25519 + ML‑KEM hybrid pairs, or any future combination is opaque to the Recovery Kit.

When Catalog.ID adopts hybrid keys, the encrypted key bag bundle simply gains additional entries (the X25519 and Ed25519 components). The sheets continue to reconstruct the same supersecret. Existing Recovery Kits remain valid through the hybrid migration without reissuance.

12. The Kit Record and the Kit's Non‑Secret Description

A Recovery Kit needs a non‑secret description of itself: what it is, which recovery set its sheets belong to, what the threshold is, which bundle it was created against, when it was made and when it was last tested. That description is not a separate document to be printed, stored and kept in step with the kit. It is distributed across three carriers, each of which already reaches the party that needs it:

• The introduction pages of the printed kit (§6.1) explain in plain language, and without assuming prior context, what the kit contains, what each sheet is for, what a quorum is, and what a holder should do in an emergency — including the warning that any quorum of distinct sheets reconstructs the supersecret and therefore opens any compatible bundle. This is what an heir or an executor reads first.
• The sheets themselves carry the account, the sheet type and its position in the set, the purpose the member assigned, the contact row, the verification address and the sheet fingerprint. That is everything a single custodian needs in order to act, and nothing that maps the quorum (§6.1, §9.6).
• The server‑side kit record holds the recovery‑set id, the threshold profile, the current bundle fingerprint, and the creation and last‑tested timestamps. It contains no share and no secret. It exists to drive the reminders and the fire‑drill bookkeeping of §14, and to answer the currency question of §6.4. For an organization the record lives on the organization's own account and is read and written through an organization‑scoped endpoint by an owner or admin delegate.

The kit record and the kit entry of §2.1 divide the description between them. The entry is authoritative for what the set IS — its coefficients, its set id, its verification key, its threshold and its sheet purposes — and only the member can read it. The record is authoritative for what the NODE says about the set: whether it is the current one, when the kit was last fire‑drilled, and which bundle is the newest. The node cannot read the entry and therefore cannot derive any of that from it; the member cannot answer the currency question for a custodian who holds no session. The record is also repairable from the entry: a print of the active set reconciles it, so a record that was never written, or that names a superseded set, corrects itself the next time the member prints a sheet.

Custodians are named nowhere in the kit unless the member writes them in by hand. Beneficiary designations, release conditions and after‑death instructions belong in the member's own legal documents — a testament, a notarial file, a foundation custody file — where they carry legal force; the kit does not attempt to be that document, and a member who needs one should make one.

A party who holds one sheet type, the kit's introduction pages, and the whole of the kit record still cannot unlock anything. This is the intended property.

13. Custody Services

The Catalog.ID Operator, or a foundation, notary, archive institution, or licensed custody provider, may offer a custody service for one or more share types and/or encrypted key bag bundles. Such a service must be framed narrowly:

The custodian stores a sealed Recovery Sheet or an encrypted key bag bundle. The custodian does not possess enough material to unlock the member's identity, and cannot acquire it without the member voluntarily providing a quorum.

Reasonable custody offerings include:

• sealed physical storage of one sheet type;
• storage of an encrypted key bag bundle;
• periodic confirmation that the sealed item is still in custody — which the custodian can perform against the sheet alone, without breaking the seal on anything else, through single‑sheet verification (§6.4);
• return of the sealed item upon identity verification of the member;
• release to a designated executor or beneficiary under member‑specified conditions;
• paid long‑term archival storage.

A custody service must not be marketed as account recovery. Marketing or contractual language that suggests the custodian can recover the account misrepresents the cryptographic reality and is misleading — recovery is a function of the threshold distribution, not the custodian.

14. Testing and Fire Drill

Recovery Kits decay silently. Sheets fade, custodians move, bundles get lost. The system therefore provides explicit fire drill functions and prompts members to use them.

14.1 Bundle Availability Test

The client verifies that at least one current encrypted key bag bundle is reachable and matches the most recent fingerprint recorded in the kit record (§12). This is a sanity check that the object the sheets are intended to unlock still exists.

For this test to mean anything, the record's bundle fingerprint follows the bundles the member actually takes: every successful bundle export, including one from the account settings, records its fingerprint on the kit record.

14.2 Single‑Sheet Integrity Test

The member scans one sheet. The client verifies:

• the recovery set ID matches the kit record;
• the share index is in range and matches an expected share type;
• the bundle fingerprint matches a known bundle;
• the payload MAC verifies under the per‑set verification key;
• the share is syntactically valid.

This does not reconstruct the supersecret. It only proves that the sheet is a structurally valid share of the named recovery set.

The same test, less the comparisons against the member's own records, is what the verification page of §6.4 performs for a custodian who holds nothing but the sheet. A custodian can therefore run this drill on their own sheet, at any time, without involving the member.

14.3 Quorum Recovery Test

The member assembles a valid quorum (e.g., Sheet A and Sheet B in a 2‑of‑3 kit) and a current bundle. The client:

1. Reconstructs the 44‑byte random portion of the supersecret in process memory only and recomputes the four line checksums to assemble the 48‑character display form.
2. Derives the AES key via Argon2id with the bundle's salt and parameters.
3. Decrypts each entry and verifies the AES‑256‑GCM authentication tag.
4. Reports success or failure per entry.
5. Zeroizes the supersecret and any derived material before returning to the UI.

A successful quorum test is the strongest evidence that the kit will work in a real recovery event. The client should remind the member periodically:

It has been 12 months since you last tested your Recovery Kit.
Verify that at least one encrypted key bag bundle is reachable and that
at least two distinct sheet types are still readable and accessible.

14.4 Organization Kits

An organization's Recovery Kit protects the organization's supersecret — the credential that opens the organization's key bag, not any delegate's personal one. Two things follow.

An organization has no bundle file of its own: its kit is printed as sheets, and there is no separate export for a delegate to carry to the drill. Its quorum test therefore reconstructs the organization supersecret from the assembled sheets and verifies it against the organization's key bag as held by the node — the same ciphertext a real recovery would have to open, and the same failure it would have to survive.

An organization is never a switchable identity, so neither the drill nor a kit reissue happens "as the organization". Both run in the Organization workspace, under the session of an owner or admin delegate, and the outcome is recorded on the organization's kit record (§12). The same threshold rules apply as for a personal kit: a delegate who holds one sheet holds nothing, and a quorum of delegates who combine their sheets holds the organization.

15. Recovery Flow

The end‑to‑end recovery flow uses the same code paths as a normal cross‑device restore (§3.4.4). The Recovery Kit only changes how the member arrives at the supersecret in the first place.

1. Member acquires the supersecret.

   ├─ Path A — supersecret remembered or read from a written backup:
   │     The member types the 48‑character extended supersecret directly.
   │     The client validates each line's checksum on entry and reports
   │     any line that fails the check, prompting only that line for retype.
   │
   └─ Path B — supersecret reconstructed from Recovery Sheets:
         The member assembles a valid quorum of Recovery Sheets.
         The client scans each sheet's QR, reconstructs the 44‑byte random
         portion via SSS, recomputes the four line checksums, and assembles
         the 48‑character display form.

2. Client obtains an encrypted key bag bundle.
   ├─ from a surviving Catalog.ID node — replication between nodes (§15.3)
   │   copies §3.4 entries to every node, so any one node is sufficient;
   └─ from a member‑held bundle file (USB, cloud, custody) when no
       Catalog.ID node remains operational.

3. Client derives the AES‑256‑GCM key:
   AES_key = Argon2id(supersecret, salt, params)

4. Client decrypts each key bag entry.

5. Client proceeds into the standard §3.4.4 device setup:
   ├─ choose which keys to import to this device
   ├─ choose a PIN, no PIN, or no local storage
   └─ generate a new deviceEncryptionKey

6. Member is logged in. Their existing Catalog.ID identity is
   restored — same username, same key chain, same claims.

The reconstructed supersecret is held in process memory only and zeroized after step 3. Path A and Path B converge at step 2: from there on the recovery flow is identical, and identical to a normal first‑time login at a new device. The Recovery Sheets are needed only when the member can no longer produce the supersecret by any other means — which is exactly the failure mode the kit is built for.

16. Security Properties

The Recovery Kit provides the following properties, in addition to those already provided by the base system:

1. Operator independence. Recovery requires no Catalog.ID node and no Operator action — provided a quorum of sheets and any one bundle survive.
2. Information‑theoretic threshold protection. Below the threshold, the held shares reveal nothing about the supersecret. This holds against any computational attacker, including any future quantum attacker.
3. Bundle abundance with adequate root entropy. The encrypted key bag bundle is keyed off Argon2id(supersecret) where the supersecret carries ≈ 256 bits of entropy (≈ 128 bits effective under Grover) on top of Argon2id memory‑hardness. Offline brute‑force against a captured bundle copy is infeasible on any plausible classical or quantum timeline.
4. Refresh without reissuing sheets. The bundle can be regenerated as the key bag evolves; the sheets remain valid as long as the supersecret is unchanged. Each refresh uses a fresh per‑bundle Argon2id salt to prevent cross‑bundle and bundle‑vs‑server work amortization.
5. Copy redundancy without threshold dilution. Multiple physical copies of one share type increase availability without lowering the threshold.
6. Archival durability. A printed, laminated sheet with a high‑error‑correction QR has a realistic readable lifespan measured in decades.
7. Verifiable in isolation. A custodian can confirm that the single sheet they hold is intact, belongs to the account named on it, and is still current, without a quorum, without the member, and without learning anything about the supersecret (§6.4).
8. Member sovereignty. Distribution is the member's decision. No party can be inserted into the recovery path without the member explicitly placing a sheet with them.
9. Estate compatibility. The kit is designed for orderly recovery after death or incapacity, not only for self‑recovery.
10. No new attack surface on the server. The Operator gains no new ability to decrypt the key bag. The Recovery Kit is created and reconstructed entirely client‑side.
11. One secret, not two. The member manages a single supersecret. Bundles and server replicas are protected by the same credential, with only the per‑bundle salt differing — making rotation, audit, and reasoning about the trust model substantially simpler.
12. Reprintable. Any sheet type of an existing set can be printed again from the supersecret and any copy of the key bag, without issuing a new set and without disturbing a single sheet already in a custodian's hands. Distribution therefore need not happen at the moment of creation: the printed kit can be kept whole as the member's own copy, and sheets handed out afterwards, one at a time, with the instructions each custodian needs. Reconstruction is unaffected — a sheet printed at registration and a sheet of another type printed years later carry shares of the same polynomials and combine normally.

17. Risks and Warnings

The Recovery Kit is powerful in both directions. Any quorum of distinct sheet types can reconstruct the supersecret and therefore open any compatible bundle — including a bundle the rightful member did not authorize the quorum to open. The user interface must communicate this clearly:

Do not store different sheet types in the same physical place.
Do not give different sheet types to the same person unless you intend
   that person to be able to unlock the key bag.
Do not photograph all sheet types into the same cloud account.
Do not email images of all sheet types to yourself.
Do keep multiple copies of the encrypted key bag bundle.
Do not assume the sheets alone are sufficient — they are not.
Do test the kit at least annually.

Two things these rules do not forbid, and one they do.

The whole kit may be produced in a single print job. The quorum‑in‑one‑artifact concern targets durable files that hold a quorum — a scan, a photo library, a saved document. A print job creates no such file: what leaves the printer is a stack of paper, and the operative control is that the member separates the sheets immediately afterwards and places each with its custodian.

The recovery sheets need not be kept apart from the rest of the kit. The credentials sheet carries the full supersecret in any case, so separating the recovery sheets from the pages they were printed with protects nothing. The separation that matters is between sheet types: give each custodian a copy of one sheet type, and keep the originals in the member's own secure storage.

The kit entry is never held on a device. The entry of §2.1 lives in the key bag on the node and inside every bundle, and nowhere else: unlike every other key bag entry, it is not replicated into a device's local key storage. The reason is arithmetic — the stored coefficients plus a single Recovery Sheet reconstruct the supersecret — and the principle is that a device holds an account's keys, not the root that opens them. Copying it to a device would also buy nothing, since printing a sheet needs the supersecret in any case.

Printing the kit to a file, rather than to paper, should be avoided. It re‑creates exactly the durable quorum‑bearing artifact the first rule is about, and it does so on a device that is far more likely to be backed up, synchronized and shared than a sheet of paper is. The kit creation flow asks for a physical printer, and the member should give it one.

A carelessly distributed kit is a quiet single point of failure. The member should treat the sheets collectively the way they would treat the keys to their home: distributed only where they would be willing for the recipient to enter, and only in combinations they have actively chosen.

18. Relationship to §3.2 Key Loss Recovery

Section 3.2 of the Catalog.ID whitepaper describes a fallback path for members who have lost the supersecret entirely: re‑register, prove identity through validated channels, and request that the Operator transfer the public profile to the new identity. This path remains available and unchanged.

The Recovery Kit is an additional, stronger, member‑created fallback. The two paths cover different failure modes:

Every account receives a Recovery Kit at registration. The §3.2 path remains the safety net for a member who can produce neither the supersecret nor a quorum of sheets.

19. Relationship to the Whitepaper

The Recovery Kit is part of Catalog.ID's registration and account settings, and the whitepaper relates to it as follows:

• §3.2 — "Key loss without a backup is irrecoverable by design" remains true. A Recovery Kit is a backup of the supersecret in the sense intended by §3.2: members who hold a quorum of sheets or a remembered supersecret, plus a bundle or a live node, have a backup, and recovery succeeds.
• §3.4 — The key bag entry format is unchanged. The encrypted key bag bundle is an export of §3.4 entries, not a separate cryptographic construct.
• §3.4.3 — The supersecret has the four‑line, 48‑character extended format of §2.5, with its per‑line checksums.
• §3.5 — The whitepaper summarizes the Recovery Kit and refers to this addendum for the full specification.
• §10 — Registration prints the supersecret on the credentials sheet of the Membership Kit, as four uniform lines with no visual marking of the checksum positions (§2.5), and ends the print step with the type‑back gate. Every registration creates a Recovery Kit: the member chooses a profile (§9.4), and the client creates the kit and prints its sheets, with at least one copy of each for custodians, as part of the Membership Kit (§2.6, §6.1). The encrypted key bag bundle is exported afterwards from the account settings, which remind the member to do so (§14).
• §15 — Replication between nodes (§15.3) copies encrypted key bag entries to all nodes. The Recovery Kit makes recovery independent of that replication. The two layers are complementary.

The Operator is permitted but not required to offer custody services for Recovery Sheets or encrypted key bag bundles (§13). When it does, the relationship is contractual and disclosed; it does not alter the cryptographic trust model.

20. Summary

• What it protects. The supersecret: the 48‑character credential that decrypts a member's key bag. Losing it, with no device holding the keys, would otherwise make the identity unrecoverable.
• How. At registration the supersecret is split into a small set of Recovery Sheets, typically three, of which any two reconstruct it. One sheet alone reveals nothing.
• Who holds what. The member keeps the original sheets and gives copies to people they trust, such as a relative or a notary. Each custodian can check their own sheet at any time.
• What else is needed. The sheets recover the supersecret, not the keys. Recovery also needs the encrypted key bag, from any Catalog.ID node or from a bundle the member exported and stored.
• Why it is safe. Nothing is held in escrow: the Operator never has enough material to reconstruct the supersecret, and recovery works even if the Operator, or Catalog.ID itself, no longer exists.