Problem
Every withdrawal today requires a fresh proof generated at the moment of withdrawal (frontend/src/lib/prover.ts, contracts/pool/src/lib.rs withdraw). There is no way to pre-authorize a bounded, repeating payout (e.g. a subscription or scheduled disbursement) without the user manually generating and submitting a new proof every single time.
Why it matters
Recurring payments are a common real-world money-movement pattern (subscriptions, payroll, allowances); forcing manual re-proving for every occurrence makes DShield unusable for that entire category of use case, and proof generation is expensive enough client-side that automating it naively (e.g. a stored script re-running the prover unattended) has real UX and security tradeoffs worth designing deliberately.
Scope
circuits/shielded_pool/src/main.nr (or a new circuits/recurring/src/main.nr): a proof that authorizes a bounded series of payouts (e.g. "up to N withdrawals of at most X, no more than once per period") from a single note, rather than one-shot spend authority.contracts/pool/src/lib.rs: new withdraw_recurring entrypoint that tracks how much of a recurring authorization has been consumed and enforces the period/amount bounds on each call, revocable by the note owner.frontend/src/lib/notes.ts, prover.ts: witness generation and local tracking for recurring authorizations.- New
frontend/src/app/recurring/page.tsx: setup UX (recipient, amount, period, total occurrences) and a management view to revoke an active authorization.
frontend/src/app/api/relay-withdraw/route.ts (or a new scheduled route): trigger each occurrence's withdrawal at the right time without requiring the user to be present.- Contract tests: an authorization can't be exceeded in amount or frequency, and revocation immediately stops further withdrawals.
docs/THREAT_MODEL.md: document what a compromised recurring-authorization secret exposes (bounded, repeated withdrawal vs. today's single-note full-balance exposure).
Acceptance criteria
- A user can pre-authorize a bounded recurring withdrawal that executes on schedule without a manual proof-generation step each time.
- The authorization cannot be used to withdraw more than its configured amount/frequency bounds, and is immediately revocable.
Problem
Every withdrawal today requires a fresh proof generated at the moment of withdrawal (
frontend/src/lib/prover.ts,contracts/pool/src/lib.rswithdraw). There is no way to pre-authorize a bounded, repeating payout (e.g. a subscription or scheduled disbursement) without the user manually generating and submitting a new proof every single time.Why it matters
Recurring payments are a common real-world money-movement pattern (subscriptions, payroll, allowances); forcing manual re-proving for every occurrence makes DShield unusable for that entire category of use case, and proof generation is expensive enough client-side that automating it naively (e.g. a stored script re-running the prover unattended) has real UX and security tradeoffs worth designing deliberately.
Scope
circuits/shielded_pool/src/main.nr(or a newcircuits/recurring/src/main.nr): a proof that authorizes a bounded series of payouts (e.g. "up to N withdrawals of at most X, no more than once per period") from a single note, rather than one-shot spend authority.contracts/pool/src/lib.rs: newwithdraw_recurringentrypoint that tracks how much of a recurring authorization has been consumed and enforces the period/amount bounds on each call, revocable by the note owner.frontend/src/lib/notes.ts,prover.ts: witness generation and local tracking for recurring authorizations.frontend/src/app/recurring/page.tsx: setup UX (recipient, amount, period, total occurrences) and a management view to revoke an active authorization.frontend/src/app/api/relay-withdraw/route.ts(or a new scheduled route): trigger each occurrence's withdrawal at the right time without requiring the user to be present.docs/THREAT_MODEL.md: document what a compromised recurring-authorization secret exposes (bounded, repeated withdrawal vs. today's single-note full-balance exposure).Acceptance criteria