Consider Admin Role for Contract-Wide Settings #98
Description
Description:
The security audit (AUDIT.md) recommends considering an admin role for contract management. Currently, each resource (bill, goal, policy, split) is owned by a user address with no contract-wide superuser. An admin could be useful for: pausing all operations in an emergency, setting global caps (e.g. max goals per user), migrating or upgrading contract logic, or rotating keys. This issue does not require implementation; it asks for a short design note or ADR that defines what an “admin” can do and how it interacts with existing owner-only functions, so that a future implementation has clear scope and security boundaries.
Requirements
Design document should cover:
- Who is the admin: Deployer address, multi-sig, or configurable address stored at deploy/init.
- Capabilities: List of allowed admin actions (e.g. pause, unpause, set_max_goals_per_user, set_emergency_withdraw_enabled). Explicitly state what the admin cannot do (e.g. cannot spend or transfer user funds, cannot change a resource’s owner without a defined process).
- Interaction with owners: Whether admin can override owner-only functions (e.g. force-unlock a goal in emergencies) and under what conditions. If admin can pause, whether owners can still read data.
- Rotation and revocation: How to change the admin address and whether there is a timelock or multi-sig requirement.
- Per-contract vs global: Whether each contract (remittance_split, savings_goals, bill_payments, insurance) has its own admin or a single admin for the whole suite.
Deliverable:
- A short design note (or ADR section) in the repo (e.g. in docs/ or as comments in a design file) describing the above. No code changes required in this issue.
Acceptance Criteria
- Design note or ADR exists describing admin role, capabilities, and interaction with owner-only functions.
- Future implementers can use it to implement admin features without scope creep.