selective-disclosure-and-compliance
Use when the agent must balance privacy with compliance on eERC — selective disclosure to auditors/regulators, proving facts without revealing everything, and designing a compliance model that keeps u
Files2
View on GitHubSKILL.mdskills/selective-disclosure-and-compliance/SKILL.md
GitHubSelective Disclosure & Compliance
Overview
"Private" and "compliant" are not opposites. eERC is built for selective disclosure: confidentiality for everyone by default, with controlled, authorized visibility for an auditor — without weakening privacy for non-audited flows. This skill is the design layer over [[eerc-auditor-compliance]].
Mechanisms
- Auditor selective decryption. Every operation encodes an auditor PCT, so a designated auditor can decrypt history via
auditorDecrypt(). Only the auditor can; other users still see nothing ([[eerc-auditor-compliance]]). - Per-user disclosure. A user can reveal their own balance/history by sharing decrypted values (or proofs of them) — they hold the decryption key ([[eerc-key-management]]).
- Rotatable auditors. Change the auditor without redeploying; rotation is forward-looking.
- Encrypted metadata for audit context. Attach invoice/reference data decryptable by the counterparty and auditor ([[eerc-encrypted-metadata]]).
Designing a compliance model
- Decide the auditor scope. Whole-contract auditor vs designated per-deployment. Document who holds the key and why.
- Minimize disclosure. Disclose to the auditor only; avoid making data public. Default to confidentiality.
- Data handling. Define retention/processing of decrypted data per jurisdiction (KYC/AML).
- On a private L1, combine with participant gating (KYC at the allowlist) for a defense-in-depth, regulator-friendly setup ([[combining-eerc-with-private-l1]], [[evergreen-institutional]]).
Privacy/compliance trade-off matrix
| Need | Approach |
|---|---|
| Regulator can audit all flows | contract auditor key |
| User proves solvency/balance to a third party | user-side disclosure of decrypted balance |
| KYC'd participants only | private L1 allowlists ([[l1-transaction-allowlist]]) |
| Confidential references for reconciliation | encrypted metadata |
Common Pitfalls
- All-or-nothing thinking. You don't have to make data public to be compliant — use the auditor channel.
- Over-disclosure. Granting broad access "to be safe" erodes the whole point.
- Assuming rotation re-grants history. It doesn't ([[eerc-key-management]]).
AI Agent Prompt
"Act as a compliance architect. Design a selective-disclosure model for my eERC deployment: who audits, what they can decrypt, how users self-disclose, and how it maps to my KYC/AML obligations without making data public."
References
See references/README.md (academy compliance + auditability, EncryptedERC AuditorManager).