This note records the verified fixes from the latest security review pass. It is intentionally narrow: only issues confirmed against the current repository were patched as code. Items that require a larger governance or cryptographic migration remain documented rather than overstated.
- Reported issue: the demo helper used
sha256(vote || salt || voter). - Current protocol invariant:
sha256(vote_byte || salt_32 || proposal_pubkey_32 || voter_pubkey_32). - Fix:
tests/demo.tsnow includes the proposal pubkey in every demo commitment. - Regression:
scripts/verify-security-remediation.tschecks the demo helper and generated call sites.
- Reported issue:
cancel_proposalv1 could cancel a voting proposal after commits/reveals. - Fix: the v1 instruction keeps the same ABI but now enforces the same safety invariant as the strict path: proposal status is
Voting, current time is beforevoting_end, andcommit_count == 0 && reveal_count == 0. - Regression:
tests/private-dao.tsadds a cancellation-after-commit rejection test.
- Reported issue: token payout execution accepted a generic token interface without an explicit support check.
- Fix: token execution paths now require the token program to be either SPL Token or Token-2022 before parsing accounts or making the token CPI. The program still preserves support for both token programs.
- Reported issue: legacy confidential payout execution deserialized optional companion accounts when
lamports > 0. - Fix: optional REFHE and MagicBlock companion accounts must be owned by the PrivateDAO program before deserialization and status checks.
- Reported issue: the Realms voter-weight record expiry was very short.
- Fix: expiry now uses
VOTER_WEIGHT_EXPIRY_SLOTS = 10_000instead of an inline100, reducing operational churn while keeping bounded freshness.
- Reported issue:
isqrtused native-width addition. - Fix: the Newton step now performs the intermediate addition in
u128.
- Reported issue: proposers could create
zk_enforcedreceipts and enablezk_enforcedmode even though the public policy described this path as authority-controlled. - Fix:
verify_zk_proof_on_chainnow allows proposers to recordparallelreceipts only.zk_enforcedreceipts require the DAO authority, and proposal activation ofzk_enforcedmode is authority-only.
- Reported issue: a
zk_enforcedreceipt could be stored without any verifier program boundary, making the mode look stronger than the evidence attached to it. - Fix:
zk_enforcedreceipts now requireverifier_program: Some(pubkey), and receipt validation rejectszk_enforcedreceipts that do not carry that boundary.
PrivateDAO currently defines quorum as a reveal-participation threshold over committed votes. That is a product/governance design choice, not silently changed in this patch because changing it would reinterpret existing proposals. Stronger denominator snapshots remain a separate policy/versioning path.
The strict V2 path already distinguishes threshold-attested evidence from true cryptographic verifier CPI. This patch does not claim a new verifier CPI integration. The current security posture remains: threshold attestation is operational enforcement; true cryptographic verification requires a verifier program/source-verifiable receipt path.
Use:
npm run verify:security-remediationThis gate checks the concrete remediation patterns above and is included in the broader validation flow.