This supplemental comment addresses technical standards for reserve attestation under GENIUS Act Sections 3 and 8(a). It recommends cryptographic reserve sufficiency proofs using Groth16 zk-SNARKs, temporal accumulator chain linking for tamper-evidence, a 35-day reserve freshness requirement tied to minting, atomic attestation generation with data lifecycle management, and recognition of on-chain proof verification.
ZKProva Inc.
Compliance Technology & Infrastructure
April 6, 2026
National Credit Union Administration
1775 Duke Street
Alexandria, VA 22314
Re: Docket No. NCUA-2026-0265; RIN 3133-AF69 — Notice of Proposed Rulemaking: Investments in and Licensing of Permitted Payment Stablecoins Issuers (GENIUS Act PPSI Licensing Framework for Federally Insured Credit Unions), 91 FR 6531 — Supplemental Comment on Reserve Attestation Technical Standards
Dear Members of the NCUA Board:
ZKProva Inc. previously submitted comments on this proposed rulemaking on April 4, 2026 (Tracking ID: mnk-icx3-0rd5) and April 6, 2026 (Tracking IDs: mno-0mc6-didw, mno-0qt5-kz5r). We submit this supplemental comment to address the technical standards that should govern reserve attestation — the mechanism by which PPSIs demonstrate that their outstanding stablecoin supply is backed one-to-one by qualifying reserves, as required by GENIUS Act Section 3 and Section 8(a).
ZKProva has developed GeniusComply (deployed at ppsiready.com), a production compliance testing infrastructure platform purpose-built for credit unions preparing for PPSI licensure. As part of this platform, ZKProva has built and deployed a reserve proof engine that generates Groth16 zero-knowledge proofs of reserve sufficiency, maintains a temporal accumulator chain linking monthly attestations cryptographically, and enforces reserve freshness requirements as a precondition to stablecoin minting. Our comments are informed by direct engineering experience with the technical challenges of proving 1:1 reserve backing in a verifiable, tamper-evident, and privacy-preserving manner.
GENIUS Act Section 3 requires monthly reserve attestation by a registered public accounting firm. The proposed rule references this obligation but does not specify: (a) what form the attestation should take beyond a CPA firm's opinion letter; (b) whether cryptographic proof of reserve sufficiency should be required or merely permitted; (c) how monthly attestations relate to each other over time — specifically, whether there should be a verifiable chain linking successive attestations; (d) how stale an attestation can be before it should block new stablecoin issuance; or (e) what reserve composition data must be captured and how it should be protected.
This lack of specification creates two risks. First, PPSIs may produce monthly attestations that are individually valid but collectively unverifiable — meaning that an examiner cannot determine whether the PPSI's reserve history has been retroactively altered. Second, without a freshness requirement linking attestation to minting, a PPSI could theoretically continue issuing stablecoins long after its last verified reserve attestation, undermining the 1:1 backing guarantee that is the foundation of the GENIUS Act's consumer protection framework.
We recommend that the final rule require — or at minimum recognize as best practice — the use of zero-knowledge proofs (specifically, Groth16 zk-SNARKs) for reserve sufficiency attestation. A Groth16 reserve sufficiency proof can demonstrate the following properties without revealing the underlying reserve composition to parties other than the CPA firm:
1. Total reserve value meets or exceeds outstanding supply. The proof verifies that the sum of all qualifying reserve assets is greater than or equal to the total outstanding stablecoin supply, satisfying the GENIUS Act's 1:1 backing requirement. The proof's public signals include a supply commitment that can be independently verified against on-chain supply data.
2. All reserve assets are eligible. The proof verifies each asset against an eligibility tree — a Merkle tree of qualifying asset types as defined by GENIUS Act Section 8(a) (U.S. currency, Treasury securities, repurchase agreements backed by Treasury securities, and other assets specified by the primary regulator). Assets not in the eligibility tree cannot contribute to the sufficiency calculation.
3. Concentration limits are enforced. The proof can verify that no single custodian holds a disproportionate share of reserves, mitigating counterparty risk. This is particularly important for credit union PPSIs, which may rely on a small number of custody providers.
4. The proof is compact and efficiently verifiable. A Groth16 proof is 260 bytes and can be verified in approximately 5 milliseconds, making it practical for both examiner verification and on-chain verification via smart contract (using the Ethereum EVM's BN254 pairing precompile at address 0x08).
The proof's public signals — which are visible to verifiers — should include: the accumulator root (a cryptographic commitment to the reserve composition), the supply commitment (binding the proof to a specific outstanding supply figure), the eligibility root (binding the proof to a specific set of qualifying asset types), and a sufficiency flag (a binary output confirming that reserves meet or exceed supply).
Individual monthly attestations are necessary but insufficient. The final rule should require that monthly reserve attestations be linked into a temporal accumulator chain — a sequence of cryptographic commitments in which each month's accumulator root is derived from the previous month's root combined with the current month's reserve data. This chain provides tamper-evidence: altering any historical attestation breaks the chain at that point and invalidates all subsequent links.
The accumulator chain should work as follows:
Genesis link: The first attestation uses a well-known domain separator (e.g., the SHA-256 hash of "GENIUS_ACT_RESERVE_ACCUMULATOR_V1") as its initial root.
Subsequent links: Each attestation's accumulator root is computed as:
root_n = SHA-256(root_{n-1} || SHA-256(reserve_hash || supply_hash || timestamp_hash))where reserve_hash is the hash of the sorted reserve asset composition, supply_hash is the hash of the outstanding supply figure, and timestamp_hash is the hash of the attestation timestamp.
Chain verification: An examiner can verify the chain by walking from the genesis link to the current attestation, recomputing each root and comparing it against the stored value. Any discrepancy indicates that the chain has been broken — either through data tampering or a gap in the attestation sequence.
The chain verification should also detect gaps — months where no attestation was produced. The final rule should require that PPSIs produce attestations for every calendar month without gaps. A gap in the chain should trigger an examination finding and, depending on severity, a supervisory action.
The final rule should establish a maximum age for reserve attestations beyond which new stablecoin minting is blocked. We recommend a 35-day freshness window: a PPSI should not be permitted to mint new stablecoins unless its most recent reserve attestation is no more than 35 calendar days old.
The 35-day window provides a 5-day buffer beyond the monthly attestation cycle, accommodating CPA firm processing time and end-of-month reporting delays while ensuring that no PPSI operates for more than one month without a current reserve attestation. If a PPSI fails to produce a timely attestation, its minting capability is automatically suspended until the attestation is completed — creating a self-enforcing compliance mechanism that does not require examiner intervention.
This freshness requirement should be enforced programmatically by the PPSI's token management system, not merely as a policy. The minting function should query the most recent reserve attestation timestamp and reject mint requests if the attestation is stale. This creates a verifiable audit trail: every successful mint operation is associated with a reserve attestation that was current at the time of minting.
The final rule should address the lifecycle of reserve data used to generate attestations. We recommend a three-phase process:
1. Ingestion. The PPSI uploads reserve asset data — including asset types and market values — through a secure, authenticated channel. The ingestion should be logged with a timestamp and the identity of the uploading party. The PPSI should support multiple data sources, including manual upload (for small credit unions), core banking system adapters (for automated ingestion from systems such as Symitar, Corelation, or DNA), and third-party aggregators (such as Plaid for account verification).
2. Attestation generation. The PPSI generates the Groth16 reserve sufficiency proof from the ingested data, computes the accumulator root linking to the prior month, and creates the attestation record.
3. Atomic cleanup. After successful attestation generation, the underlying reserve asset records should be deleted in the same database transaction. This ensures that raw reserve data — which may contain sensitive information about the PPSI's banking relationships and asset allocation — is not retained beyond the attestation period. If attestation generation fails, the transaction rolls back and the reserve data is preserved for retry. This atomic approach prevents both data orphaning (reserve data without an attestation) and attestation orphaning (an attestation without underlying data).
The attestation record itself — including the Groth16 proof, public signals, and accumulator root — should be retained for the full BSA five-year retention period, as it constitutes evidence of compliance with the GENIUS Act's reserve adequacy requirement.
For PPSIs that issue stablecoins on Ethereum-compatible blockchains, the final rule should recognize on-chain proof verification as an additional assurance mechanism. A Solidity smart contract can verify Groth16 proofs using the EVM's built-in BN254 elliptic curve pairing precompile (address 0x08), enabling any party — including members, counterparties, and regulators — to independently verify that the PPSI's reserve proof is valid without relying on the PPSI's own infrastructure.
On-chain verification should be encouraged but not initially required, as not all credit union PPSIs will operate on-chain infrastructure in the early stages of GENIUS Act implementation. However, the final rule should recognize on-chain verification as a valid and particularly robust form of reserve attestation evidence.
ZKProva has implemented the reserve attestation framework described above in production as part of the GeniusComply platform (ppsiready.com). Our implementation includes: a ReserveSufficiency Groth16 circuit (approximately 60,000-80,000 constraints) that verifies 1:1 backing with asset eligibility and concentration limit enforcement; a temporal accumulator chain with SHA-256 link computation and genesis domain separator; a 35-day freshness check enforced programmatically as a precondition to token minting; three reserve data ingestion adapters (manual upload, Symitar core banking, Plaid account linking); atomic attestation generation with transactional reserve data cleanup; and a Solidity ProofVerifier contract using the EVM pairing precompile for on-chain verification.
This implementation demonstrates that the standards recommended in this comment are technically achievable and can be deployed by credit union technology vendors using standard cryptographic libraries and database infrastructure.
We respectfully request that the NCUA include the following reserve attestation standards in the final rule:
Reserve attestation is the technical foundation of the GENIUS Act's consumer protection framework. The 1:1 backing requirement is only as strong as the mechanism used to verify it. Monthly CPA opinion letters are a necessary but insufficient assurance — cryptographic proofs provide mathematical certainty, temporal chains provide tamper-evidence, and freshness requirements ensure that attestation remains current. The standards recommended in this comment are technically proven, operationally deployed, and designed to give credit union members confidence that their stablecoins are fully backed at all times.
ZKProva Inc. welcomes the opportunity to provide technical demonstrations, implementation specifications, or testimony in support of these comments.
Respectfully submitted,
Viswanadha Pratap Kondoju
Founder & CEO
ZKProva Inc. (incorporation pending)
Disclaimer: This page is an informational archive of a public regulatory comment. It does not constitute legal advice. ZKProva Inc. is not a law firm and no attorney-client relationship is created. Not affiliated with, endorsed by, or sponsored by the NCUA, OCC, or U.S. Department of the Treasury.