Patefacere Registry and Recovery Architecture: Status, Revocation, Incident Transparency, Audit, and Last-Known-Good Preservation

Full report

On this page

The architectural design of a high-assurance identity and credential registry necessitates an uncompromising balance between operational transparency and individual privacy. Rooted in the Latin concept of patefacere—to disclose, expose, or bring to light1—the Patefacere architecture fundamentally separates the persistent ontological reality of an identity from the ephemeral, operational state of its associated credentials. In contemporary cryptographic identity systems, the failure to decouple these layers frequently results in catastrophic privacy violations or the silent erasure of civic standing during routine administrative revocations. The Patefacere framework prevents such outcomes through a zero-trust, append-only architecture. This comprehensive report establishes the operational lifecycles, failure models, transparency mechanisms, and cryptographic schemas required to maintain this system. Drawing upon established cryptographic standards—including the W3C Bitstring Status List v1.04, Verifiable Credential Forgery Defense5, Sparse Merkle Trees (SMTs)6, and robust state-recovery manifests8—the architecture ensures that credential restriction never silently erases citizenship or identity. Furthermore, it embeds the epistemological principle that the absence of a published incident is never misconstrued as the definitive absence of an operational anomaly.

1. A Registry Ontology

The Patefacere registry ontology is composed of highly distinct, cryptographically isolated domains to ensure that a compromise or state change in one tier does not cascade into the silent destruction of another. The structural separation ensures that an identity cannot be computationally annihilated simply because a specific capability or attribute was rescinded. The ontology includes the following primary entities: The Authoritative Identity Core serves as the immutable, append-only anchor of an operational identity. It is deliberately decoupled from all capabilities, attributes, and transactional receipts. For persistent, transferable identifiers that require ongoing control via key rotation, this core incorporates a Key Event Log (KEL)10. The KEL tracks the cryptographic provenance of the identity across its lifespan, ensuring that even if physical keys are lost or compromised, the logical chain of custody remains unbroken and verifiable without requiring the exposure of personal attributes10. The Verifiable Credential (VC) Wrapper acts as the cryptographic envelope binding a specific set of claims to the Identity Core. This entity is subject to issuance, suspension, and revocation. Credentials can be secured using enveloping proofs, which wrap around the data, or embedded proofs, which sit alongside the serialized data payload11. Regardless of the proof structure, the VC remains distinct from the core identity; invalidating the proof invalidates the credential, not the subject to which it refers. The Bitstring Status Ledger functions as a highly compressible, index-based privacy-preserving state machine tracking the validity of VCs. Rather than querying an issuer directly—which enables tracking and correlation of the holder's activities—verifiers rely on this mathematical construct4. Each ledger accommodates a default minimum of 131,072 entries, ensuring profound group privacy4. By relying on bitwise indicators (1 or 0), the ledger communicates the exact operational status of a credential without exposing any underlying attribute data. The Witness Forgery Defense Ledger represents a post-quantum secure cryptographic witness list utilized to assert the authenticity of issued credentials, explicitly protecting against quantum key compromise5. Because legacy credentials may have been signed with conventional, quantum-vulnerable algorithms (such as RSA or ECDSA), this standalone witness list allows the issuer to retroactively vouch for their authenticity using advanced quantum-resistant cryptosuites5. The Incident and Transparency Log is an append-only structure recording anomalies, internal state divergence, and recovery operations. It is governed by negative-evidence semantics, acknowledging that internal observability is inherently limited. The log filters sensitive internal telemetry, publishing only privacy-minimized cryptographic proofs of incidents and their subsequent corrections, thereby maintaining public accountability without violating data protection standards. The Recovery and Audit Manifest provides a transport-agnostic, atomic state snapshot validating the integrity of the data via cryptographic hashing (e.g., SHA-256) and explicit dependency ordering9. Analogous to the SNAP (Simple Native Archive Protocol) backup concept, these JSON-formatted manifests ensure that when the registry must be restored, the exact sequence of schemas, files, and state roots is flawlessly reconstructed9.

2. A Record Lifecycle

The lifecycle of an authoritative operational identity record within the Patefacere architecture is strictly append-only, progressing through a series of cryptographically auditable state transitions. Traditional databases allow rows to be mutated or dropped, but in a high-assurance registry, historical preservation is a fundamental requirement. State changes are enacted exclusively by appending new cryptographic blocks that supersede older ones. The lifecycle commences with Genesis (Instantiation). A new Identity Core is created, and a unique cryptographic identifier—such as a Decentralized Identifier (DID)—is generated and committed to the authoritative append-only log. For persistent identifiers, this genesis event establishes the root of the Key Event Log (KEL), mapping the initial public key material to the logical identifier10. At this stage, the identity exists ontologically within the system but possesses no operational capabilities or credentials. Following genesis, Attribute Binding (Issuance) occurs. Specific claims regarding the identity are enveloped within a Verifiable Credential, cryptographically signed by the issuer, and delivered to the holder11. Concurrently, the issuer generates a 128-bit cryptographic witness—derived from a random seed and the credential's position—and appends this to the Witness Forgery Defense Ledger5. This action ensures that if the issuer's private key is later compromised, adversaries cannot forge backdated credentials, as they would lack the necessary corresponding entry in the quantum-resistant witness list5. During the phase of Active Propagation, the credential operates dynamically in the public domain. Its status index is mapped to a 0 (active) on the Bitstring Status List12. The holder presents the credential within a Verifiable Presentation (VP) to various verifiers, who independently confirm its active status by checking the cached bitstring11. Because the verification checks the status list rather than querying the issuer, the holder's privacy is preserved, and the issuer remains blind to the holder's transactional footprint4. State Evolution (Refresh/Supersession) becomes necessary when the underlying claims require updating, such as a change of address or a renewed authorization. The issuer generates a new credential reflecting the updated data. To handle the legacy credential, the issuer updates its specific index on the Bitstring Status List to 1, designating the statusPurpose as refresh4. This signal informs verifiers that an updated credential is available without implying that the holder committed an infraction. The refresh status is irreversible but strictly non-invalidating to the core identity4. When administrative or security conditions dictate a temporary halt in capabilities, the lifecycle enters Restriction or Suspension. The credential's capability is paused by flipping the Bitstring Status List index to 1 under a suspension purpose4. Crucially, this state is reversible. If the underlying administrative issue is resolved, the issuer can seamlessly flip the bit back to 0, restoring the credential to an active state without requiring re-issuance. Terminal Revocation represents the final, irreversible invalidation of a specific credential. The status index is permanently set to 1 with a revocation purpose4. The Identity Core remains completely untouched. The system achieves complete operational restriction of the capability while meticulously preserving the underlying identity, fulfilling the architectural mandate that credential restriction must never silently erase citizenship or existence.

3. A Credential-Status Lifecycle

The mechanism by which credential statuses are communicated to the public must balance near-instantaneous verification with stringent privacy protections. Status changes must provide verifiers with accurate information without enabling issuer tracking, correlation attacks, or violating the group privacy of the holding population4. To achieve this, the Patefacere architecture implements the W3C Bitstring Status List v1.0 standard4. The status lifecycle begins with List Allocation. An issuer provisions a highly compressible Bitstring Status List. To prevent statistical correlation and guarantee a baseline of group privacy, the specification mandates a minimum list length of 131,072 entries, which equates to 16 KB of raw single-bit values4. By bundling such a massive volume of credentials into a single array, an adversary analyzing the list cannot easily isolate or track an individual credential's state changes in real-time. As credentials are created, they undergo Index Assignment. Each issued Verifiable Credential is mathematically assigned to a specific bit index within this list12. The credential body is constructed with a BitstringStatusListEntry property, which explicitly declares the credential's designated index and points to the URL where the status list is hosted4. To enhance security and thwart predictability, these index assignments can be randomized across the available 131,072 slots rather than populated sequentially12. The standard operational state relies on Status Publishing. The default state of the bitstring is composed entirely of 0s, indicating that the associated credentials are unrevoked4. Because the vast majority of credentials in a healthy ecosystem remain valid for long periods, the bitstring contains massive, uninterrupted runs of identical values. This structural uniformity makes the bitstring highly compressible using standard run-length compression techniques, such as GZIP4. Even a fully populated list of 131,072 credentials compresses down from 16 KB to merely a few hundred bytes, resulting in negligible bandwidth consumption during distribution4. When an administrative trigger necessitates a change, Status Mutation occurs. An automated policy or human operator identifies that a credential must be suspended or revoked. The system retrieves the bitstring, locates the specific index (e.g., index 94,567), and flips the bit from 0 to 112. The updated list then undergoes Encoding and Stapling. The mutated bitstring is re-compressed via GZIP and transformed into a multibase-encoded format13. This payload is then wrapped within a new BitstringStatusListCredential, cryptographically signed by the issuer, and assigned a ttl (Time to Live) value13. The updated list is published to a highly available Content Delivery Network (CDN). Alternatively, the credential holder can utilize a mechanism called "stapling," whereby they download the most recent status list and deliver it directly to the verifier alongside their credential4. As long as the ttl has not expired and the issuer's signature remains valid, the verifier can trust the stapled status list. Finally, Verification takes place. A verifier receives the credential and its associated status list (either fetched from the CDN or provided via stapling). The verifier checks the signature of the status list, decompresses the payload, and examines the exact index specified by the credential. Because the verifier interacts with the CDN or the stapled payload rather than an active API endpoint on the issuer's server, the correlation between the holder, the time of verification, and the verifier is entirely severed4. The system natively achieves a zero percent false-positive rate, ensuring that valid credentials are never accidentally rejected4.

4. An Incident Lifecycle

Operational anomalies, ranging from undetected hardware faults to sophisticated state-sponsored intrusions, are inevitable in distributed systems. The Patefacere architecture addresses these realities through a strict Incident Lifecycle governed by transparency logging and negative-evidence semantics. The goal is to accurately reflect the internal health of the registry without exposing exploitable vulnerabilities or private data. The lifecycle originates with Detection & Ingestion. An anomaly is detected via automated audit telemetry, divergence in internal log hashes, or external reporting mechanisms. This could manifest as a mismatched Merkle root during a routine SMT verification or an unauthorized attempt to alter a core identity record. At this stage, the event is raw, unverified, and strictly internal. The system rapidly shifts into Triage & Isolation, marking the internal state as INCIDENT\_REPORTED. The automated orchestration layer isolates the affected state or node to prevent potential corruption from propagating through the append-only logs. The incident is securely recorded into the internal authoritative record, capturing the timestamp, the affected cryptographic hashes, and the origin of the alert. Once contained, Investigation commences, changing the internal tracking status to INCIDENT\_UNDER\_REVIEW. Forensic algorithms and human operators conduct root cause analysis to determine the precise nature of the anomaly. They assess whether the incident impacts record integrity, system availability, or data confidentiality. During this phase, it is critical that the internal investigation does not prematurely broadcast unverified technical details that adversaries could leverage. Upon reaching a definitive forensic conclusion, the system executes Confirmation. If the anomaly is verified as a legitimate breach of operational parameters, its scope and impact are formally published to the public transparency log, triggering the INCIDENT\_CONFIRMED status. Crucially, the public output is privacy-minimized. The log details the cryptographic boundaries of the incident (e.g., affected block ranges, revoked witness list seeds5) but completely omits the private entity data, application details, and proprietary operator notes involved in the breach. With the scope defined, Remediation & Correction takes place. The corrupted or compromised state is rectified through the injection of append-only compensating transactions. Because historical records in Patefacere are immutable, the system cannot simply delete the compromised data. Instead, it appends a new state block that effectively overrides the corrupted elements, restoring the registry to a verified Last-Known-Good (LKG) baseline. The public status transitions to INCIDENT\_CORRECTED. The final stage of the lifecycle is Supersession. Future audits referencing the anomaly are pointed to the updated, corrected state. The transparency log retains the record of the incident and its correction in perpetuity, validating the remediation process and ensuring that the INCIDENT\_SUPERSEDED status accurately reflects a system that has acknowledged, repaired, and moved past a historical failure.

5. A Recovery Lifecycle

The recovery of the registry to a Last-Known-Good (LKG) state is an operation fraught with risk. Incorrect restorations can resurrect corrupted data, misalign cryptographic schemas, or inadvertently fork the append-only log. The Patefacere Recovery Lifecycle relies on decentralized consensus, strict cryptographic manifests, and the preservation of historical sequence. The process relies heavily on Backup Manifest Generation during routine operations. Continuous snapshots of the registry generate JSON-based Backup Manifests, akin to the Simple Native Archive Protocol (SNAP)9. These manifests contain the specific file paths, a strict array dictating the dependency order for restoration, and the SHA-256 hashes of all files9. Furthermore, the manifests capture the overarching schema definitions and their unique structural IDs. As seen in enterprise Kafka schema registries, backing up data without explicitly preserving the schema IDs renders the resulting data completely unreadable, because the binary payloads rely on those embedded IDs for parsing15. When a critical failure occurs, Divergence Detection alerts the system. A split-brain scenario, bit-rot, or database corruption is identified when active nodes across the cluster report mismatched public Merkle root hashes or fail to reach consensus on the latest appended block. The immediate response is to Halt and Audit. The active registry is paused to prevent the accumulation of further corrupted state. The system conducts a forensic review of the append-only audit events leading up to the point of divergence, analyzing the RFC 3339 timestamps17 and the cryptographic signatures of the recent transactions to isolate the exact moment of failure. Once isolated, the system focuses on LKG Identification. Recovery engineers query the historical Backup Manifests to locate the most recent snapshot where all cryptographic signatures, file hashes, and schema IDs match the globally verified state15. This Last-Known-Good state becomes the foundational anchor for the restoration. The system then initiates Manifest Restoration. The registry is restored using the specific dependency order documented in the JSON manifest15. The target database is often forced into an IMPORT mode, allowing the recovery algorithms to explicitly inject the legacy schema IDs rather than allowing the database to auto-generate new ones, which would permanently sever the connection between the schema and the historical data payloads15. Throughout the restoration, pre-flight checks validate the SHA-256 hashes of every file against the manifest; if a single hash fails, the restoration aborts immediately to prevent the ingestion of truncated or tampered data9. Following the successful restoration of the LKG state, the system executes State Catch-Up. Append-only logs that were stored in external, uncorrupted cold-storage queues and confirmed to be valid post-LKG are replayed sequentially. This careful replay brings the registry back to the present operational state without inheriting the corruption that triggered the initial divergence.

6. Sixty-Four Failure and Recovery Scenarios

To demonstrate the robustness of the Patefacere architecture, it must withstand exhaustive edge cases. The following table outlines 64 distinct failure models, their symptoms, and the precise mechanical recovery actions dictated by the registry framework.

7. Thirty-Two Incident and Negative-Evidence Scenarios

The concept of "Negative-Evidence Semantics" addresses a critical epistemic gap in distributed systems monitoring: the absence of a published incident does not inherently prove that the system is functioning flawlessly. It merely proves that the system's observational capabilities have not codified an error. Below are 32 scenarios mapping true system events to their public status and their profound negative-evidence implications.

8. A Public Status Vocabulary

To strictly categorize the state of the registry and its operational events, Patefacere utilizes a standardized public status vocabulary. These statuses are explicitly designed to respect negative-evidence semantics, ensuring that operators and the public do not infer guarantees that the architecture cannot mathematically support.

• NO\_PUBLIC\_INCIDENT\_PUBLISHED: This is the baseline operational state. Crucially, it denotes only that no incident has been codified, triaged, and published to the transparency log pipeline. It makes no affirmative, mathematical claim of perfect system health, thereby avoiding the trap of presenting a lack of evidence as proof of perfection.
• NO\_AUTHORIZED\_OBSERVATION: The system is restricted from providing a state. Telemetry is intentionally masked by policy, legally gagged by external authority, or the system lacks the cryptographic authority/keys to observe the requested internal state.
• INSUFFICIENT\_COVERAGE: The monitoring telemetry is offline, heavily degraded, or lacks the necessary scope to verify the integrity of the sector in question. The system admits it is blind.
• INCIDENT\_REPORTED: An anomaly has been detected and logged into the raw, internal queue, but has not yet undergone human triage or cryptographic verification. It is a preliminary warning.
• INCIDENT\_UNDER\_REVIEW: The anomaly is actively being investigated by automated forensic algorithms or human operators to determine its scope, blast radius, and root cause.
• INCIDENT\_CONFIRMED: The scope, impact, and reality of the incident have been cryptographically verified and formally acknowledged. A public, privacy-minimized record of the event is committed to the ledger.
• INCIDENT\_CORRECTED: Compensating actions have been successfully executed. The system has returned to a mathematically verified LKG state, and the vulnerability has been closed.
• INCIDENT\_SUPERSEDED: New forensic data has invalidated a previous incident report, or a historical error has been retroactively patched via an append-only state correction. The old narrative is replaced.
• UNAVAILABLE: The registry, or a specific cryptographic endpoint (such as the high-availability Status List CDN), cannot be reached, has suffered a massive infrastructure failure, or is failing to achieve quorum.

9. A Privacy-Minimized Public Registry Schema

The public-facing registry must never leak Personally Identifiable Information (PII), attribute bodies, or transactional receipts4. It acts solely as an anchor for the cryptographic proofs required by verifiers. The following JSON schema defines the exact structure of this public endpoint.

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Patefacere Privacy-Minimized Public Registry", "type": "object", "description": "Public endpoints for status, forgery defense, and transparency.", "properties": { "issuerDid": { "type": "string", "description": "Decentralized Identifier (DID) of the issuing authority" }, "bitstringStatusListUrl": { "type": "string", "format": "uri", "description": "Location of the GZIP-compressed 131,072-bit status list" }, "witnessForgeryDefenseListUrl": { "type": "string", "format": "uri", "description": "Endpoint for the post-quantum witness list" }, "publicMerkleRoot": { "type": "string", "description": "SHA-256 root of the active Sparse Merkle Tree (SMT)" }, "transparencyLogUrl": { "type": "string", "format": "uri", "description": "Endpoint for the append-only public incident log" } }, "required": \["issuerDid", "bitstringStatusListUrl", "publicMerkleRoot"\] }

This schema guarantees that external actors querying the registry receive only URIs pointing to highly compressible, group-privacy-enabled bitstrings and witness lists. No attributes or individual tracking mechanisms are exposed.

10. A Private Authoritative-Record Schema

The internal authoritative schema retains the append-only lifecycle history. It is never exposed publicly. This structure maps the ontological identity to its various issued capabilities and tracks the internal audit trail.

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Patefacere Private Authoritative Record", "type": "object", "description": "Highly restricted internal representation of an identity and its capabilities.", "properties": { "internalSubjectId": { "type": "string", "format": "uuid", "description": "Internal tracking UUID, unlinked from public DIDs" }, "ontologicalIdentityState": { "type": "string", "enum": \["ACTIVE", "DECEASED", "MERGED"\], "description": "The fundamental existence state of the subject" }, "issuedCredentials": { "type": "array", "items": { "type": "object", "properties": { "credentialHash": { "type": "string" }, "statusListIndex": { "type": "integer", "minimum": 0, "maximum": 131071 }, "issuanceTimestamp": { "type": "string", "format": "date-time" }, "revocationTimestamp": { "type": \["string", "null"\], "format": "date-time" } } } }, "auditTrail": { "type": "array", "description": "Complete history of state mutations linked to this subject" } }, "required": \["internalSubjectId", "ontologicalIdentityState", "issuedCredentials"\] }

By nesting issuedCredentials within the identity object, the database guarantees that credentials remain subservient attributes of the identity. If a credential's revocationTimestamp is populated, the ontologicalIdentityState remains completely unaffected.

11. An Append-Only Audit-Event Schema

Following the RFC 3339 standard for timestamp integrity17 and structured for immutable logging, this schema tracks who did what, and when. It is vital for recovering from split-brain scenarios and auditing unauthorized access.

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Append-Only Audit Event", "type": "object", "description": "Immutable log entry for any state mutation in the registry.", "properties": { "eventId": { "type": "string", "format": "uuid" }, "timestamp": { "type": "string", "format": "date-time", "description": "RFC 3339 standard time" }, "actor": { "type": "string", "description": "System or Operator ID initiating the action" }, "action": { "type": "string", "enum": \["ISSUE", "SUSPEND", "REVOKE", "REFRESH", "ROLLBACK"\] }, "targetHash": { "type": "string", "description": "SHA-256 hash of the modified entity or state block" }, "cryptographicSignature": { "type": "string", "description": "Digital signature of the event payload by the actor" } }, "required": \["eventId", "timestamp", "actor", "action", "targetHash", "cryptographicSignature"\] }

12. A Backup-Manifest and Restore-Evidence Schema

To protect against corruption and ensure seamless recovery, the Backup Manifest utilizes SHA-256 hashes and explicit dependency ordering. Drawing inspiration from the SNAP backup protocol and Schema Registry backup requirements, this schema ensures that data cannot be restored without its corresponding schema definitions.

JSON { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Backup Manifest and Restore Evidence", "type": "object", "description": "Atomic representation of a registry snapshot and recovery dependencies.", "properties": { "manifestVersion": { "type": "string", "enum": \["1.0", "1.1"\] }, "creationTimestamp": { "type": "string", "format": "date-time" }, "lkgVerificationHash": { "type": "string", "description": "Global state Merkle root at time of the backup snapshot" }, "dependencyOrder": { "type": "array", "description": "Strict sequence for restoring files to prevent schema mismatches", "items": { "type": "object", "properties": { "fileName": { "type": "string" }, "sha256": { "type": "string", "description": "Integrity check prior to read" }, "restoreSequence": { "type": "integer" }, "requiresImportMode": { "type": "boolean", "default": false } }, "required": \["fileName", "sha256", "restoreSequence"\] } } }, "required": \["manifestVersion", "creationTimestamp", "lkgVerificationHash", "dependencyOrder"\] }

13. Why Absence of a Published Incident Is Not Evidence of Absence

In cryptographic systems, distributed computing architectures, and public trust frameworks, a persistent epistemic fallacy occurs when stakeholders assume a perfectly clean transparency log equates to a perfectly healthy system. The Patefacere architecture explicitly rejects this fallacy by embedding negative-evidence semantics directly into its public status vocabulary. "No public incident published" is a highly conditional and limited state. It merely reflects that the logging pipeline, up to the exact point of publication, has not successfully codified an anomaly. It is inherently subject to observational blind spots. If the telemetry system is blind to a novel zero-day exploit, if the network is partitioned in a split-brain consensus failure, or if a highly privileged adversary suppresses the audit trail, the system will display a pristine public face while actively deteriorating internally. The lack of evidence is driven by the failure of the evidence-gathering mechanism, not the absence of the underlying failure. Furthermore, privacy constraints mandate that certain low-level anomalies remain strictly internal. Exposing every erratic server ping or rejected authentication request would leak operational metadata, potentially aiding adversaries in mapping the system architecture or identifying usage patterns that could de-anonymize users. Therefore, the silence of the transparency log is often a deliberate architectural choice to preserve privacy. Thus, the absence of a published incident is never evidence of absence; it is simply the absence of authorized, detected, and confirmed evidence. Relying solely on the transparency log without independent cryptographic verification—such as manually auditing the SMT Merkle roots or verifying the W3C Forgery Defense Witness List5—invites catastrophic oversight. The system forces verifiers to trust the mathematics of the proofs presented to them, rather than deriving a false sense of security from an empty incident queue.

14. How to Revoke a Credential Without Destroying Identity

A fundamental flaw in legacy identity management systems is the tight, immutable coupling of a subject's ontological identity with their operational credentials. In these flawed systems, when a credential (e.g., a driver's license, passport, or access token) is revoked, the system often orphans, suspends, or soft-deletes the underlying identity record itself. This results in the silent erasure of a subject's civic standing or existence within the system, a catastrophic outcome for individual rights. In the Patefacere architecture, a credential restriction must not, under any circumstances, silently erase identity or citizenship. To achieve this absolute separation of capability from being, the system relies on a combination of Sparse Merkle Trees (SMTs) and W3C Bitstring Status Lists. An SMT is a highly specialized authenticated data structure based on a perfect Merkle tree of an intractable size, typically possessing 256 levels and [Figure omitted from source export] leaves6. Because the vast majority of these [Figure omitted from source export] leaves are empty, the tree is sparse. The predictable values of these empty leaves allow the tree to be simulated and updated highly efficiently using advanced caching strategies6. When a core identity is established during genesis, it exists in the authoritative record independently of the SMT. Later, when a credential is issued to that identity, a cryptographic commitment derived from that credential (a nullifier) is placed at a specific, predetermined leaf index within the SMT7. The SMT allows for highly efficient non-membership (non-inclusion) proofs. If the credential is revoked, the system updates that specific leaf in the SMT to a revoked state, or uses the SMT structure to prove the credential's absence from a valid list7. Simultaneously, the W3C Bitstring Status List v1.0 handles the high-performance public checking required for daily verifications4. The credential body contains a pointer to a specific bit index (e.g., index 94567\) on a hosted list12. If the credential is to be suspended, the issuer simply locates index 94567 and flips the bit from 0 to 112. Through both SMTs and Bitstrings, the individual's core Identity record remains entirely untouched, perfectly intact, and fully capable of holding or receiving newly issued credentials. Revocation is strictly mathematically targeted at the capability-restriction mechanism—the wrapper—never acting as an identity-destruction mechanism.

15. Forty FAQs

Architecture & Ontology

1. What is the primary function of the Patefacere registry? The system exists to hold authoritative operational identity records while minimizing public privacy exposure, isolating the identity from the credentials it holds.

2. Does the registry store raw biometric data? No. Biometrics are strictly hashed; storing raw data violates privacy principles and exposes the system to severe compliance risks under laws such as the Illinois Biometric Information Privacy Act (BIPA)20.

3. What is an Identity Core? The immutable, append-only anchor representing the ontological reality of the subject, decoupled from all operational capabilities.

4. How are credentials related to the Identity Core? They are distinct cryptographic wrappers bound to the Core, representing ephemeral claims or capabilities that can be discarded without harming the core.

5. Can an Identity Core be deleted? No. The architecture is strictly append-only to preserve auditability. Identities can only be transitioned to an inactive terminal state via a new log entry.

6. Are public census totals available? No. The architecture explicitly restricts the public calculation of census, citizen, or application totals to preserve privacy and prevent data mining.

7. What standard is used for credential status? The W3C Bitstring Status List v1.0 specification, which provides highly compressible, privacy-preserving revocation checks4.

8. Why not use Certificate Revocation Lists (CRLs)? CRLs are not as highly compressible as bitstrings, scale poorly with massive populations, and do not inherently provide the same tunable group privacy for verifiable credentials4.

Privacy & Cryptography 9\. How does a Bitstring Status List ensure privacy? It bundles the binary status of a minimum of 131,072 credentials into a single, massive array, providing mathematical group privacy against correlation4. 10\. How does the system prevent issuer tracking? Verifiers cache the highly compressible bitstring locally (or fetch it via a CDN) instead of querying the issuer's server for every interaction, blinding the issuer to the user's activities4. 11\. What is GZIP used for in this architecture? GZIP heavily compresses the bitstring. Because unrevoked credentials form long runs of zeroes, GZIP reduces a 16 KB list to a few hundred bytes4. 12\. What is a Sparse Merkle Tree (SMT)? A specialized cryptographic tree with [Figure omitted from source export] leaves, allowing for highly efficient, constant-size proofs of non-inclusion6. 13\. Why use SMTs instead of Incremental Merkle Trees (IMTs)? While IMTs (like LeanIMT) are optimized for membership proofs and append quickly, SMTs are mathematically superior for non-membership (revocation) proofs because of their predictable structure7. 14\. How does the system defend against quantum key compromise? By utilizing the W3C Forgery Defense v1.0 specification, which publishes a separate, post-quantum signed Witness List to authenticate credentials signed with legacy keys5. 15\. What is a cryptographic witness? A short, compact 128-bit pseudorandom value derived from a seed and the credential's position in a list, allowing a verifier to authenticate genuinely issued credentials5. 16\. Are private receipts or operator notes public? No. Public outputs are strictly privacy-minimized. Only cryptographic proofs and sanitized incident logs are exposed. Revocation & Suspension 17\. What is the structural difference between suspension and revocation? Suspension is an ephemeral, reversible state; revocation is a permanent, non-reversible invalidation of the credential4. 18\. How is a suspension enacted mechanically? The bit index corresponding to the specific credential is set to 1 with a statusPurpose parameter defined as suspension4. 19\. How is a suspension lifted? The exact same bit index is flipped back to 0, and a new Status List is generated, signed, and propagated to the CDN. 20\. Can an identity be revoked? Absolutely not. Only credentials can be revoked. The architecture mandates that restriction must not silently erase identity. 21\. What happens during a credential refresh? A new credential is issued with fresh claims, and the old credential's bit is flagged with the refresh status4. 22\. Does a refresh status invalidate the credential? No. It signals an updated credential is available via a refresh service, but the status itself is non-invalidating to the capability4. 23\. What is the false positive rate of the Bitstring Status List? Zero percent. Unlike Bloom Filters which suffer from probabilistic errors, Bitstrings are deterministic4. 24\. Can a holder deliver their own status to a verifier? Yes, via a mechanism known as "stapling," provided the ttl (Time to Live) on the stapled list has not expired4. Incidents & Audit 25\. What does NO\_PUBLIC\_INCIDENT\_PUBLISHED mean? It strictly means no incident has been formally logged publicly; it makes no mathematical guarantee of system perfection. 26\. What is negative-evidence semantics? The epistemic principle that a lack of logs (evidence) can result from system blindness or telemetry failure, rather than flawless operation. 27\. Are operator notes public? No. Operator notes and internal triage communications are stripped out of the transparency log to prevent leaking attack vectors. 28\. How are events logged? Via an append-only JSON schema using precise RFC 3339 timestamps to ensure chronological integrity17. 29\. What happens when an incident is corrected? The state is appended with the correction transaction, and the public status transitions to INCIDENT\_CORRECTED. 30\. Can an audit event be modified or deleted? No. The ledger is entirely immutable. Corrections require new, superseding entries that point back to the error. 31\. What causes an INSUFFICIENT\_COVERAGE status? This occurs when telemetry is offline, degraded, or structurally incapable of asserting the operational health of the queried sector. 32\. Why is a split-brain scenario highly dangerous? Because partitioned nodes will maintain divergent append-only logs, destroying global consensus and forcing a manual recovery. Recovery & Backups 33\. What is a Last-Known-Good (LKG) state? The most recent chronologically verified state of the registry where all cryptographic hashes, signatures, and schemas align perfectly. 34\. How are backups structured? As JSON-based manifests (akin to SNAP backups) containing exact file names, dependency order, and SHA-256 integrity hashes9. 35\. What happens if a backup manifest hash fails during restore? The restore process halts immediately to prevent importing corrupted or malicious data payloads9. 36\. How do you backup the schema definitions? Schemas must be backed up alongside the data, preserving explicit schema IDs, to ensure the binary records remain readable upon restoration15. 37\. What is IMPORT mode in a schema registry recovery? A vital recovery mode allowing the system to explicitly inject legacy backup schema IDs rather than auto-generating new ones, preserving data linkage15. 38\. How does the system recover from extreme clock divergence? By relying on Lamport timestamps (logical sequence ordering) rather than purely physical NTP time, preserving causality. 39\. Is backup data encrypted? Yes, but the recovery code/passphrase must be strictly managed; without it, the encrypted backup is structurally useless23. 40\. Does a restoration overwrite the append-only log? No. A restoration establishes a new verified baseline, and valid append-only logs are then replayed on top of it.

16. Twenty-Five Direct Answers

1. Patefacere holds authoritative identity records: The core registry acts as the singular, uncompromising source of truth for identity existence.

2. Public outputs are strictly privacy-minimized: Cryptographic proofs and bitstrings are published, never the underlying personal data or receipts.

3. No public totals are provided: Calculating total citizens, credentials, or applications is architecturally blocked by default.

4. "No incident published" is not proof of perfection: Negative evidence is a core architectural assumption regarding observability.

5. Restriction does not erase identity: Credential revocation strictly targets the capability wrapper, leaving the core identity perfectly intact.

6. History is append-only: State is mutated only by adding new cryptographic records, never by deleting old ones.

7. Group privacy is enforced by mathematics: Bitstring Status Lists must contain at least 131,072 entries to successfully mask individual activity4.

8. Status lists are highly compressible: GZIP compression ensures 16 KB bitstrings compress rapidly to hundreds of bytes4.

9. False positives in status checks are zero: Bitstrings provide absolute deterministic binary outcomes, outperforming probabilistic models4.

10. Verifier tracking is structurally prevented: Caching bitstrings on CDNs completely severs the connection between the verifier and the issuer4.

11. Quantum threats are addressed via Witness Lists: Post-quantum signatures on the separate Forgery Defense list protect legacy credentials from decryption5.

12. Witnesses are short and compact: Standard length is highly optimized at 128 bits per credential5.

13. Non-inclusion proofs use Sparse Merkle Trees (SMTs): SMTs efficiently and cryptographically prove a credential is not in a revoked set6.

14. SMTs have fixed depths: SMTs possess exactly 256 levels and [Figure omitted from source export] leaves, allowing deterministic, constant-time mapping6.

15. Incident logs do not expose internal triage notes: Only verified, sanitized, and privacy-minimized data is published to the public log.

16. Backup manifests define exact dependency orders: Restores will structurally fail if the JSON manifest sequence is not strictly followed9.

17. Schema IDs are critical for recovery: Without restoring exact Schema IDs, the underlying binary data payload becomes completely unreadable15.

18. Data corruption halts restorations: SHA-256 hash checks run pre-flight on all backup payloads, aborting on failure9.

19. Clock skew does not destroy causality: Logical sequence numbers guarantee event order and causality even if external NTP synchronization fails.

20. Revocation is irreversible: Once a status bit is flipped for a revocation purpose, it cannot be undone4.

21. Suspension is reversible: A suspended bit can be seamlessly flipped back to an active 04.

22. Identity states include 'Deceased' but not 'Deleted': Terminal existential states are recorded, but the database row is never dropped.

23. Audit events use RFC 3339: Timestamps strictly follow standardized formatting for guaranteed machine-readability across regions17.

24. Multi-signature authorization prevents rogue admin actions: Massive state changes structurally require distributed consensus.

25. The system defaults to fail-closed on corrupted reads: If an SMT leaf or bitstring is unreadable, the credential is not trusted.

17. A 70-Term Glossary

1. Append-only: A data structure where new data can be added securely, but existing data cannot be modified or deleted.

2. Authoritative Record: The definitive, primary source of truth for an identity's existence and operational state.

3. Backup Manifest: A JSON or XML file containing metadata, sequential file paths, and cryptographic hashes required for restoring a backup safely8.

4. BIPA: Biometric Information Privacy Act (Illinois); heavily restricts the collection and storage of biometric identifiers, providing a private right of action20.

5. Bitstring Status List: A space-efficient mechanism for publishing VC status information using a massive sequence of bits4.

6. BitstringStatusListEntry: The specific property within a VC detailing its integer index and the URI of the list tracking its status4.

7. Canonicalization: The process of standardizing data (e.g., formatting JSON) before hashing to ensure consistent cryptographic outputs across platforms11.

8. Clock Divergence: A failure scenario where synchronized system clocks drift apart, threatening the chronological ordering of the logs.

9. Credential Body: The core data payload of a Verifiable Credential containing the subject's specific attributes and claims.

10. Credential Status: The active, suspended, refreshed, or revoked state of a specific Verifiable Credential.

11. Cryptosuite: A specified set of cryptographic algorithms used to secure VCs (e.g., EdDSA, ECDSA, or post-quantum schemes)11.

12. Decentralized Identifier (DID): A globally unique, cryptographically verifiable identifier that enables decentralized digital identity without central registries.

13. Dependency Order: The strict sequential requirement for restoring backup files to maintain schema structure and data integrity9.

14. Embedded Proof: A cryptographic signature included directly within the serialized data payload of the credential itself11.

15. Encoded List: The status bitstring after it has been compressed (via GZIP) and multibase-encoded for network transport13.

16. Enveloping Proof: A cryptographic signature that wraps around and fully encapsulates the entire credential data payload11.

17. False Positive Rate: The statistical probability of a valid credential being incorrectly flagged as revoked (guaranteed 0% for Bitstring lists)4.

18. GZIP Compression: A lossless compression algorithm used to dramatically reduce the size of the Bitstring Status List by eliminating redundant zeroes4.

19. Identity Core: The fundamental registry entry representing a subject, structurally separate from any issued capabilities or credentials.

20. INCIDENT\_CONFIRMED: Public status indicating an anomaly has been cryptographically verified and formally acknowledged.

21. INCIDENT\_CORRECTED: Public status indicating an anomaly has been fully remediated and a LKG state restored.

22. INCIDENT\_REPORTED: Public status indicating an anomaly has been detected in raw logs but not yet verified.

23. INCIDENT\_SUPERSEDED: Public status indicating a previous incident report has been updated, overwritten, or patched by new evidence.

24. INCIDENT\_UNDER\_REVIEW: Public status indicating active forensic triage of an anomaly.

25. Incremental Merkle Tree (IMT): A Merkle tree optimized for efficient membership proofs by continuously appending entries to the right side of the tree7.

26. INSUFFICIENT\_COVERAGE: Public status indicating monitoring telemetry is offline, blinded, or inadequate.

27. Key Compromise: The disastrous unauthorized exposure, theft, or quantum decryption of a private cryptographic key5.

28. Key Event Log (KEL): A verifiable, append-only data structure used to track the lifecycle, rotation, and control of cryptographic keys for a transferable identifier10.

29. Lamport Timestamps: A logical clock algorithm used to determine the order of events in a distributed system, rendering it immune to physical clock drift.

30. Last-Known-Good (LKG): The most recent chronologically verified state of the registry verified to be completely free of corruption or divergence.

31. Message Purpose: A Bitstring Status List property used to convey arbitrary information about a credential without invalidating it4.

32. Multibase: A protocol for disambiguating various cryptographic encoding methods (e.g., Base58, Base64) to ensure parser compatibility.

33. Negative-Evidence Semantics: The epistemic principle that the absence of a logged incident does not definitively prove the absence of a system failure.

34. NO\_AUTHORIZED\_OBSERVATION: Public status indicating the system is restricted from observing, accessing, or reporting on a specific state.

35. NO\_PUBLIC\_INCIDENT\_PUBLISHED: Baseline public status indicating no incident has been codified in the transparency log, devoid of mathematical guarantees.

36. Non-Inclusion Proof: A cryptographic proof that a specific element does not exist within a set (achieved efficiently via an SMT)6.

37. Nullifier: A unique cryptographic value mapped to an SMT index, used to signal the restriction of a credential without revealing the credential itself19.

38. Ontology: The formal, structural definition of entity types, properties, and the rigorous relationships within the registry architecture.

39. Patefacere: Latin verb meaning "to disclose," "to expose," or "to make open," serving as the philosophical foundation of the transparency architecture1.

40. Post-Quantum Cryptography: Advanced cryptographic algorithms thought to be highly secure against an attack by a cryptographically relevant quantum computer5.

41. Read Replica: A database copy utilized strictly for read operations to ensure high availability and offload verification traffic.

42. Refresh Purpose: A Bitstring Status List property signaling an updated credential is available without invalidating the legacy one4.

43. Revocation Purpose: A permanent, irreversible invalidation of a credential's capability4.

44. RFC 3339: A standard defining a rigid profile of ISO 8601 for date and time formats on the Internet, vital for chronological integrity17.

45. Run-Length Encoding: A form of data compression where long runs of data are stored as a single data value and count; highly effective for unrevoked bitstrings4.

46. Schema ID: A unique integer identifying a specific schema structure; critical to preserve explicitly during backups to ensure readability15.

47. Seed: A highly secure random value used as the initialization basis for generating the Forgery Defense Witness List5.

48. SHA-256: A cryptographic hash function outputting a 256-bit signature, heavily used for securing backup manifest integrity9.

49. Sparse Merkle Tree (SMT): A highly indexed, intractable Merkle tree with [Figure omitted from source export] leaves used primarily for rapid non-inclusion proofs6.

50. Split-Brain: A catastrophic state where a distributed system partitions, resulting in nodes containing divergent, conflicting realities.

51. Stapling: The practice of a credential holder caching and presenting their own Status List along with the credential to a verifier to speed up verification4.

52. StatusListIndex: The specific integer mapping a credential to its exact status bit on the Bitstring list13.

53. statusPurpose: The core property defining why a status bit is set (e.g., revocation, suspension, refresh)13.

54. Supersession: The act of replacing an older credential, event, or state with a newer, updated, and chronologically superior version.

55. Suspension Purpose: A strictly reversible invalidation of a credential's capability4.

56. Time-To-Live (TTL): A temporal value defining exactly how long a cached Status List is considered valid before it must be forcibly re-fetched13.

57. Transparency Log: A publicly verifiable, append-only record of system events, sanitized incidents, and cryptographic state changes.

58. Triage: The internal process of investigating an anomaly to determine its scope, blast radius, and root cause before public confirmation.

59. UNAVAILABLE: Public status indicating a registry endpoint is down, overwhelmed, or physically unreachable.

60. Verifiable Credential (VC): A tamper-evident set of claims and metadata cryptographically bound to an issuer and subject11.

61. Verifiable Presentation (VP): Data derived from one or more VCs, assembled by the holder to present specific claims to a verifier without exposing the entire credential11.

62. Verification: The robust cryptographic process of ensuring a VC has not been tampered with and was genuinely signed by the claimed issuer.

63. Witness Count: The total number of unique cryptographic witnesses contained within a Witness List credential5.

64. Witness Index: The 1-based integer identifying a specific credential's exact witness position in the forgery defense list5.

65. Witness Length: The number of bits in each witness (default is established at 128\)5.

66. Witness List: An indexed list of compact cryptographic witnesses used to prevent credential forgery in the event of key compromise5.

67. Witness Seed Leak: A critical failure where the random initialization seed for the witness list is exposed to adversaries, requiring immediate supersession5.

68. Zero-Day Exploit: A cyberattack vector previously unknown to the software developers, leaving the system blind to the intrusion and triggering negative-evidence conditions.

69. Zero-Knowledge Proof (ZKP): A cryptographic method allowing one party to prove they know a value without conveying any information apart from the fact that they know it.

70. ZkID: Privacy-preserving digital identity systems utilizing zero-knowledge proofs and advanced Merkle tree structures (like SMTs and IMTs)7.

18. Primary-Source Bibliography

• \[cite: 4\] W3C Verifiable Credentials Working Group. "Bitstring Status List v1.0." (Recommendation track documents regarding group privacy and multibase compression).
• \[cite: 11\] W3C Verifiable Credentials Working Group. "Verifiable Credentials Overview." (Drafts through 2025 defining VC wrappers and verifiable presentations).
• \[cite: 5\] W3C Verifiable Credentials Working Group. "Verifiable Credential Forgery Defense 1.0." (Specifications detailing Witness Lists and Post-Quantum cryptographic resistance).
• \[cite: 13\] W3C Verifiable Credentials Working Group. "Bitstring Status List Vocabulary" (RDFS Namespace definitions for Bitstring entries and purposes).
• \[cite: 10\] Internet Engineering Task Force (IETF). "Key Event Receipt Infrastructure (KERI) draft-ssmith-keri-00." (2024 draft concerning Key Event Logs and transferable identifiers).
• \[cite: 6\] River Financial. "Sparse Merkle Tree: Definitions and Structure." (2026 explanation of non-inclusion proofs).
• \[cite: 19\] VAC Research Forum. "Sparse Merkle Tree vs. Indexed Merkle Tree." (Analysis of nullifiers and non-membership architectures).
• \[cite: 22\] Efficient Sparse Merkle Trees. Academic Publication/ResearchGate. (Focus on non-membership proofs and advanced caching strategies for intractable trees).
• \[cite: 27\] Tari RFC-0141. "Sparse Merkle Trees for UTXO and Inclusion/Exclusion Proofs."
• \[cite: 7\] Privacy & Scaling Explorations (PSE). "Revocation in ZKID Merkle Tree Based Approaches." (LeanIMT vs. SMT operational analysis and scaling constraints).
• \[cite: 1, 2, 3\] Latin Lexicons and Etymological Resources. (Definitions of the architectural namesake Patefacere—"to disclose", "to expose").
• \[cite: 20, 21, 28\] Illinois General Assembly. "Biometric Information Privacy Act (BIPA) & Identity Protection Act (5 ILCS 179/1)." (Compliance constraints regarding biometric data storage and private rights of action).
• \[cite: 8, 23\] Mozilla Firefox Source Docs. "BackupService and JSON Schemas." (Manifest architecture, schema versioning, and redundancy constraints).
• \[cite: 26\] CockroachDB Documentation. "BACKUP statements and manifest files."
• \[cite: 29\] Uber Engineering Blog. "Differential Backups on MyRocks." (Use of JSON manifests for tracking dependency order).
• \[cite: 9\] Internet Engineering Task Force (IETF). "SNAP (Simple Native Archive Protocol) Backup Draft." (JSON backup manifest hashing and dependency sequences).
• \[cite: 18\] OneUptime Engineering. "ClickHouse Backup Integrity Verification." (Manifest XML/JSON checksum checks prior to restoration).
• \[cite: 15, 16\] OSO Engineering. "How to Backup Kafka Schema Registry." (Preservation of schema IDs, IMPORT modes, and schema dependencies).
• \[cite: 17, 24, 30\] JSON Schema / RFC 3339 Standards for Audit Event Logging. (Formatting rules for immutable timestamping).

Works cited

1. patefacio, patefacis, patefacere M, patefeci, petefactum Verb \- Latin is Simple, https://www.latin-is-simple.com/en/vocabulary/verb/249/

2. patefacere \- Wiktionary, the free dictionary, https://en.wiktionary.org/wiki/patefacere

3. Distribution Agreement In presenting this thesis or dissertation as a partial fulfillment of the requirements for an advanced de, https://etd.library.emory.edu/downloads/kp78gh476?locale=fr

4. Bitstring Status List v1.0 \- W3C, https://www.w3.org/TR/vc-bitstring-status-list/

5. Verifiable Credential Forgery Defense v1.0 \- W3C, https://www.w3.org/TR/vc-forgery-defense-1.0/

6. Sparse Merkle Tree \- River Financial, https://river.com/learn/terms/s/sparse-merkle-tree/

7. Revocation in zkID: Merkle Tree-based Approaches | PSE, https://pse.dev/blog/revocation-in-zkid-merkle-tree-based-approaches

8. Schemas — Firefox Source Docs documentation, https://firefox-source-docs.mozilla.org/browser/components/backup/docs/schemas.html

9. draft-melegassi-dispatch-mvps-snap-backup-00 \- SNAP: Simple Native Archive Protocol, https://datatracker.ietf.org/doc/draft-melegassi-dispatch-mvps-snap-backup/

10. draft-ssmith-keri-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-ssmith-keri-00

11. Verifiable Credentials Overview v1.0 \- W3C on GitHub, https://w3c.github.io/vc-overview/

12. Credential Status Management with Bitstring Status Lists | TradeTrust Documentation, https://documentation.tradetrust.io/docs/how-tos/bitstring/

13. Bitstring Status List Vocabulary \- W3C, https://www.w3.org/ns/credentials/status

14. Bitstring Status List v1.0 publication history | Standards \- W3C, https://www.w3.org/standards/history/vc-bitstring-status-list/

15. How to Back Up Your Kafka Schema Registry (And Why Your Current Approach Probably Won't Restore) \- OSO, https://oso.sh/blog/how-to-backup-kafka-schema-registry/

16. Schema Registry Backup & Restore, https://kafkabackup.com/enterprise/schema-registry/

17. agentfence/docs/audit-event-schema.md at main · dgenio ... \- GitHub, https://github.com/dgenio/agentfence/blob/main/docs/audit-event-schema.md

18. How to Verify ClickHouse Backup Integrity \- OneUptime, https://oneuptime.com/blog/post/2026-03-31-clickhouse-verify-backup-integrity/view

19. Sparse Merkle Tree vs Indexed Merkle Tree \- Nomos \- Vac forum, https://forum.vac.dev/t/sparse-merkle-tree-vs-indexed-merkle-tree/438

20. What is the Illinois Biometric Information Privacy Act (BIPA)? \- UpGuard, https://www.upguard.com/blog/bipa

21. BUSINESS TRANSACTIONS (815 ILCS 530/) Personal Information Protection Act. \- Illinois General Assembly \- \-, https://www.ilga.gov/Legislation/ILCS/Articles?ActID=2702\&ChapterID=67

22. Efficient Sparse Merkle Trees \- ResearchGate, https://www.researchgate.net/publication/308944456\_Efficient\_Sparse\_Merkle\_Trees

23. Backup Service Reference — Firefox Source Docs documentation \- Mozilla, https://firefox-source-docs.mozilla.org/browser/components/backup/docs/backup-service.html

24. AI Agent Audit Log Schema: Actions, Tools, Approvals ... \- KLA Digital, https://kla.digital/resources/ai-agent-audit-log-schema

25. Implement a backup strategy for Amazon Quick Sight BI assets | Artificial Intelligence \- AWS, https://aws.amazon.com/blogs/machine-learning/implement-a-backup-strategy-for-amazon-quick-sight-bi-assets/

26. BACKUP \- CockroachDB, https://www.cockroachlabs.com/docs/v26.2/backup

27. RFC-0141: Sparse Merkle Tees \- The Tari Network, https://rfc.tari.com/RFC-0141\_Sparse\_Merkle\_Trees