Commit-reveal timelock preventing early tally decryption by the key holder

[Ehonrie]

Difficulty: Research-Required
Category: Feature

Context: Even with a single key holder, nothing today technically prevents decrypting votes before the voting period ends — the private key works identically regardless of proposal state. A verifiable delay function (VDF) or contract-enforced commit-reveal timelock would make early decryption cryptographically infeasible rather than merely a social/UI convention.

// dapp/src/utils/voteTimelock.ts (new)
export interface TimelockedKey {
  puzzle: string; // VDF input / time-locked encryption of the private key
  unlockLedger: number;
}

export async function deriveTimelockedPrivateKey(
  puzzle: TimelockedKey,
  currentLedger: number,
): Promise<string> {
  // !todo: Research VDF-based time-lock encryption (e.g. Rivest-Shamir-Wagner style,
  //        or a Soroban-ledger-anchored commit-reveal alternative if a true VDF is
  //        infeasible client-side) so the private key cannot be derived before
  //        get_anonymous_voting_config's voting-end ledger.
  // !todo: Must define what happens if currentLedger < puzzle.unlockLedger (fail closed,
  //        not with a leaked partial key).
  // !todo: Must integrate with contract_dao.rs's ProposalVotingTime (401) error semantics
  //        so on-chain and off-chain timelock enforcement agree.
  // !todo: Reference: Boneh et al., "Verifiable Delay Functions" (2018); Rivest, Shamir,
  //        Wagner, "Time-lock puzzles and timed-release Crypto" (1996).
  throw new Error("Not implemented");
}

What contributors need to know:

• Problem: no timelock mechanism exists — get_anonymous_voting_config and ProposalVotingTime (401) in errors.rs only gate voting/contract actions, not the mathematical ability to decrypt.
• Related code: contract_dao.rs, errors.rs, crypto.ts.
• Suggested approach: evaluate whether a true VDF is practical given Soroban/browser constraints, versus a simpler "ledger-anchored commit-reveal" where the contract itself won't release a needed piece of key material until the unlock ledger — the latter may be far more tractable and worth proposing as the actual deliverable.
• Acceptance criteria: a design doc comparing both approaches with a recommendation, plus a working proof-of-concept for the recommended one demonstrating decryption is infeasible before the unlock condition.

[luhrhenz]

hello maintainer, i am a full stack developer , can i be assigned this issue?