# ZKP compliance for 42 CFR Part 2 — substance use treatment privacy **URL:** \ **Category:** Technical Questions\ **Tags:** learning, best-practices, ecosytem\ **Created:** [May 13, 2026, 8:11am UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218 "2026-05-13T08:11:04Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![DR.Ecovery](https://avatars.discourse-cdn.com/v4/letter/d/48db29/32.png) [@DR.Ecovery](https://forum.midnight.network/u/DR.Ecovery)\ **Post date:** [May 13, 2026, 8:11am UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/1 "2026-05-13T08:11:04Z")
I’m building a check-in app for a drug recovery drop-in center using Midnight’s ZKP technology. 42 CFR Part 2 is a federal law that protects substance use treatment records — even stricter than HIPAA. It means you can’t disclose that someone is even a patient without their consent. My question: Can a Zero Knowledge Proof prove that someone checked in without revealing their identity or treatment status to anyone? Has anyone explored using Midnight for healthcare or sensitive data compliance use cases? Any guidance appreciated! ---
**Author:** ![nasihudeenJ](https://avatars.discourse-cdn.com/v4/letter/n/51bf81/32.png) [@nasihudeenJ](https://forum.midnight.network/u/nasihudeenJ)\ **Post date:** [May 13, 2026, 8:18am UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/2 "2026-05-13T08:18:13Z")
Welcome to the community, DR.Ecovery! This is a fascinating use case. The short answer is **yes**. This is exactly the kind of ‘selective disclosure’ Midnight is designed for. In a Midnight-based app, you can use a Zero Knowledge Proof to verify that a state transition occurred (e.g., ‘a valid patient checked in’) without revealing the underlying private data (the patient’s identity or status) on the public ledger. To an observer, the proof confirms the event is valid according to your rules, but the data remains shielded. Healthcare compliance is a major area of interest for the ecosystem. I’ll share this thread for our devrel team to see if we have specific compliance frameworks or similar projects to share. Looking forward to seeing how this develops! ---
**Author:** ![iano](https://yyz2.discourse-cdn.com/flex010/user_avatar/forum.midnight.network/iano/32/227_2.png) [@iano](https://forum.midnight.network/u/iano)\ **Post date:** [May 14, 2026, 12:05pm UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/3 "2026-05-14T12:05:32Z")
Yeah, this is the kind of application Midnight was designed for. Smart contracts have two states: public and private. Private state is stored locally. A hash of the private state is generated and stored in the public state. To validate the private state without exposing it, your contract will publish a zero-knowledge proof once the transaction is submitted, and the network validates this proof against the hash in the public state. ---
**Author:** ![nasihudeenJ](https://avatars.discourse-cdn.com/v4/letter/n/51bf81/32.png) [@nasihudeenJ](https://forum.midnight.network/u/nasihudeenJ)\ **Post date:** [May 15, 2026, 4:35pm UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/4 "2026-05-15T16:35:34Z")
Hi @DR.Ecovery! Following up on this after chatting with our team To give you a concrete path forward for the 42 CFR Part 2 “status anonymity” requirement, we recommend a two-layered architecture: ### 1. Anonymous Check-ins (The Membership Proof Pattern) To satisfy the rule that “even being a patient” is protected status, you can use a **Membership Proof + Nullifier**. This proves “I am _someone_ on the clinic’s list” without revealing _which_ leaf in the tree you are. **Example of how to implement this in Compact:** ```compact // 1. A private tree of all authorized patient commitments ledger patientTree: HistoricMerkleTree<32, Bytes<32>>; // 2. Prevent double-check-ins using a daily Nullifier ledger usedNullifiers: Set>; witness patientPath(): MerkleTreePath<32, Bytes<32>>; witness patientSecret(): Bytes<32>; export circuit checkIn(currentDate: Bytes<32>): [] { const path = patientPath(); const sk = patientSecret(); // Prove the user is in the patient tree without revealing their identity assert(patientTree.checkRoot(merkleTreePathRoot<32, Bytes<32>>(path))); assert(persistentHash>(sk) == path.leaf); // Use a nullifier (Secret + Date) to prevent identity tracking const nullifier = persistentHash>>([sk, currentDate]); assert(!usedNullifiers.member(nullifier), "Already checked in today"); usedNullifiers.insert(nullifier); } ``` ### 2. Confidential Record Storage (Off-chain Pattern) For the actual medical records (treatment notes), you shouldn’t store them on-chain. Instead, use a pattern of **Client-side Encryption + IPFS**. **The Storage Pattern:** ```compact struct DocumentRecord { contentHash: Bytes<32>, // Hash of the encrypted file for integrity storageCid: Opaque<"string">, // The IPFS/Arweave CID ownerCommitment: Bytes<32>, // Commitment of the patient who owns it isActive: Boolean } export ledger records: Map, DocumentRecord>; ``` **Workflow:** 1. **Encrypt Locally:** Use AES-256-GCM to encrypt the records on the provider’s device. 2. **IPFS:** Upload the encrypted blob to IPFS. 3. **Audit Trail:** Store only the CID and the hash on Midnight. This gives you a mathematical audit trail without ever exposing the patient’s data or status to the public ledger. ### Reference Resources We have a community-led reference project called **[midnight-doc-manager](https://github.com/Mackenzie-OO7/midnight-doc-manager)** that demonstrates this exact encryption-to-IPFS flow. It’s an excellent starting point for how to handle large, sensitive files while keeping the verification on Midnight. You can also find our official, maintained examples here: **[midnightntwrk repositories · GitHub](https://github.com/orgs/midnightntwrk/repositories)** Does this technical architecture align with your compliance requirements? We’d love to hear how your implementation goes! ---
**Author:** ![DR.Ecovery](https://avatars.discourse-cdn.com/v4/letter/d/48db29/32.png) [@DR.Ecovery](https://forum.midnight.network/u/DR.Ecovery)\ **Post date:** [May 31, 2026, 1:22am UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/5 "2026-05-31T01:22:27Z")
@nasihudeenJ — thank you, this is exactly what I needed. I already have a working capstone on the example-bboard repo (branch capstone/andres-chavez, PR open) with 6 Compact circuits and 13 passing tests. The current implementation uses the sealed owner pattern. Your Merkle tree + nullifier architecture is a direct upgrade path and I’m planning to implement it in Phase 2. A little context: I’m a self-taught developer who works at an overdose drop-in center in El Paso serving ~15,000 contacts per year. I built MANO to solve a real problem I see every day — staff re-asking participants the same sensitive demographic questions, no privacy guarantees, no way for participants to control their own data. I’m building this to pitch to leadership as a real implementation. The use case is genuine even if deployment isn’t confirmed yet. A few specific questions as I plan the Phase 2 upgrade: 1. Tree sizing — What depth should HistoricMerkleTree be for a clinic expecting ~500 enrolled participants? Is \<32, Bytes\<32\>\> right or overkill? 2. Enrollment circuit — Your example shows checkIn but not enroll. Is the pattern simply patientTree.insert(persistentHash(sk))? Does staff call enroll, or does the participant’s witness provide the leaf? 3. IPFS + Midnight together — For visit records, is it acceptable to store the Pinata CID in a separate database alongside the on-chain hash, or should the CID live on-chain inside the DocumentRecord struct? Happy to share more about the use case if it’s useful to the ecosystem. ---
**Author:** ![nasihudeenJ](https://avatars.discourse-cdn.com/v4/letter/n/51bf81/32.png) [@nasihudeenJ](https://forum.midnight.network/u/nasihudeenJ)\ **Post date:** [May 31, 2026, 7:14am UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/6 "2026-05-31T07:14:04Z")
@DR.Ecovery thank you for giving more context **Tree sizing:** `<32, Bytes<32>>` is overkill for ~500 enrolled. In Compact, `MerkleTree` / `HistoricMerkleTree` use depth `n` with capacity **2^n** leaves (max depth 32). For ~500, **`HistoricMerkleTree<10, Bytes<32>>`** (1024 leaves) is a comfortable fit; **`<9, …>`** (512) works if enrollment stays capped near 500. Prefer `HistoricMerkleTree` over plain `MerkleTree` if you enroll often `checkRoot` accepts proofs against prior roots after inserts, which matters when the tree keeps growing. Smaller depth = smaller circuits and faster proving. **Enrollment:** Yes pattern is essentially `patientTree.insert(persistentHash(sk))` (or `insertHash` with the same commitment). **Participant generates `sk` locally** and only shares the **commitment** with the clinic; staff never needs the secret. Typical split: - **`enroll`** staff-gated circuit (your existing admin/sealed pattern): takes disclosed commitment, inserts into tree. - **`checkIn`** participant witness supplies `sk` + Merkle path; circuit verifies `persistentHash(sk)` matches the leaf and records the nullifier. The participant (or your app) needs the **Merkle path** for their leaf after enrollment usually computed off-chain from tree state/indexer, then passed as a witness at check-in. Staff enrolls the commitment; participant proves membership at check-in. **IPFS + Midnight:** Encrypted blob on Pinata/IPFS is fine. For audit integrity, **anchor on-chain** in `DocumentRecord` — at minimum `contentHash` + `storageCid` (CID alone isn’t PHI if the blob is encrypted). A separate DB/cache for Pinata URLs is OK for app UX, but treat the **on-chain record as source of truth** ; the DB should mirror it, not replace it. If CID is only off-chain, you lose the tamper-evident link Midnight gives you. Happy to hear more, use cases like this help the ecosystem. Share how Phase 2 goes, and congrats again on the capstone progress. ---
**Author:** ![DR.Ecovery](https://avatars.discourse-cdn.com/v4/letter/d/48db29/32.png) [@DR.Ecovery](https://forum.midnight.network/u/DR.Ecovery)\ **Post date:** [May 31, 2026, 1:32pm UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/7 "2026-05-31T13:32:14Z")
@nasihudeenJ — this is exactly the clarity I needed, thank you. The depth-10 tree making sense for our scale is helpful — I hadn’t thought about proof size being tied to tree depth. And the enrollment split makes the trust model much cleaner: staff handles the commitment, participant proves membership without ever exposing their secret. That separation is actually a great story for our participants too. One thing I want to confirm before I start the Phase 2 upgrade: when the participant’s app computes the Merkle path off-chain from the indexer after enrollment, does that path need to be recomputed every time the tree grows (new enrollments), or is the path stable once the leaf is inserted? I’ll share how Phase 2 goes. This use case — anonymous check-in for a federally-regulated substance use program — feels like a strong real-world example of what Midnight is built for. Appreciate the support. ---
**Author:** ![nasihudeenJ](https://avatars.discourse-cdn.com/v4/letter/n/51bf81/32.png) [@nasihudeenJ](https://forum.midnight.network/u/nasihudeenJ)\ **Post date:** [May 31, 2026, 2:40pm UTC](https://forum.midnight.network/t/zkp-compliance-for-42-cfr-part-2-substance-use-treatment-privacy/1218/8 "2026-05-31T14:40:35Z")
Good question, **Leaf index is fixed** once enrolled, what changes as the tree grows is the **root** (and usually the path to the **current** root). With **`HistoricMerkleTree`** , `checkRoot` can accept proofs against **prior** roots, so an enrollment-time path isn’t automatically useless after new enrollments that’s why we recommended Historic over plain `MerkleTree`. In practice: store **`sk` + leaf index** (and commitment); before check-in, call `pathForLeaf(index, leaf)` on current contract state (indexer/app) and pass that as the witness. That’s the pattern in our [keeping-data-private](https://docs.midnight.network/concepts/how-midnight-works/keeping-data-private) docs. Re-fetching before each check-in is the simplest reliable approach even if historic roots could work in theory. Looking forward to more updates on this