Consider Rate Limiting for High-Volume Scenarios #99
Description
Description:
The audit recommends adding rate limiting for high-volume scenarios to reduce the risk of spam, DoS, or resource exhaustion. Before implementing, the team should document where and how rate limits would apply so that future work has a clear design. This issue asks for a design note that identifies which operations to limit, the limits (e.g. per address per day), and a high-level implementation approach (e.g. counter per address + time window), without requiring code changes.
Requirements
Design document should cover:
- Scope: Which contracts and which functions (e.g. create_goal, create_bill, create_policy, initialize_split, pay_bill). Whether read-only functions (get_goal, get_unpaid_bills) are limited or excluded.
- Limits: Proposed numeric limits (e.g. max 50 goals per user, max 100 create_bill calls per address per 24h). Rationale (gas, storage, or abuse prevention).
- Granularity: Per-address, per-contract-instance, or global. Time window (sliding vs fixed day).
- Implementation approach: Storage layout (e.g. map from (address, window_id) to count). How to bump TTL for rate-limit entries. When to reset or decay the counter. Whether to use ledger timestamp or a separate clock.
- Whitelist: Whether certain addresses (e.g. admin, treasury) are exempt and how that is configured.
- User impact: How frontends should handle rate-limit errors (retry-after, backoff) and whether the contract returns a clear error or panic.
Deliverable:
- A short design note in the repo (e.g. docs/ or design/) describing the above. No implementation required in this issue.
Acceptance Criteria
- Design note exists describing rate-limit scope, limits, granularity, and implementation approach.
- Future implementers can add rate limiting without re-deciding policy in code.