Request for Comments (RFC)

The ZKS standard evolves through a formal Request for Comments (RFC) process.

RFCs are the mechanism by which changes, clarifications, or extensions to the ZKS standard may be proposed by the community.

When to Submit an RFC​

You should submit an RFC if you wish to propose:

• A modification or clarification to the ZKS definition or tenets
• A change to normative requirements or conformance criteria
• A new appendix, deployment model, or threat consideration
• A correction or ambiguity resolution in the existing specification

Editorial corrections and typographical issues may be handled via simple Pull Requests or Issues.

RFC Submission Requirements​

An RFC submission MUST include:

1. Problem Statement A clear description of the issue or limitation being addressed.

2. Proposed Change Precise specification text or structural modification.

3. Technical Rationale Explanation of how the proposal aligns with ZKS principles and threat model.

4. Backward Compatibility Impact Assessment of impact on existing implementations and compliance claims.

5. Security Considerations Explicit discussion of any new attack surfaces or mitigations.

RFCs that are vague, policy-based, or marketing-driven will be rejected.

How to Submit​

Preferred Method (Public)​

Submit a GitHub Issue or Pull Request in the zks-standard repository with the label RFC.

GitHub Repository

Alternative Method (Private)​

For sensitive security disclosures or private commentary, you may submit via email:

zks.working.group [at] zks-standard.org

Email Subject Line: [RFC] - Your Title Here

Review Process​

• RFCs are reviewed by the ZKS Working Group
• Technical feedback may be requested prior to acceptance
• Accepted RFCs are scheduled for inclusion in the next appropriate revision

Submission of an RFC does not guarantee acceptance.

ZKS is a community-developed technical standard. The RFC process ensures that changes are rigorous, transparent, and security-focused.