Skip to content

[High] Design a community treasury-spending governance process for the protocol-fee treasury contract #302

Description

@james2177

Description: Issue #37 (implementing an on-chain protocol-fee treasury contract) explicitly scopes out "any specific spending-allocation policy... that's a protocol-governance/community decision this issue's mechanism should support, not dictate." This issue is that follow-on: design the actual community process for deciding how accumulated treasury funds get spent — approval thresholds, proposal format, reporting cadence — that issue #37's timelock/multisig mechanism would then technically enforce.

Problem Statement & Context: SECURITY.md already flags "Protocol fees" as an Asset at Risk and notes a compromised admin key "can redirect future fees and slashes," but even a perfectly secure, uncompromised treasury is only as trustworthy as the process governing its outflows — a treasury contract with a timelock and no community input on what gets approved during that timelock window is technically safer but not more legitimate. Issue #37's own scoping note is explicit that this is a "protocol-governance/community decision," making it a natural, directly-cited Drips Wave governance deliverable rather than an invented one.

Scope & Acceptance Criteria:

Implementation Guidelines:

  1. Key files: issue Document the DstAllowlistEnabled-off-by-default decision for mainnet launch #37's treasury-contract scope and design notes, SECURITY.md (Protocol fees as an Asset at Risk — the trust context this process must strengthen, not just formalize on paper), issue Add a lightweight aggregate health-check view #112's RFC process (for consistent proposal-discussion norms across all of this repo's governance processes).
  2. Explicitly address the failure mode where treasury inflows grow faster than a community has established process maturity to responsibly allocate them — a conservative default (e.g., funds accrue with no spending authorized) until this process is actually adopted and tested is a reasonable, documented starting stance.
  3. Edge cases: define a process for time-sensitive spending needs (e.g., funding an urgent security audit) that can't wait for a full RFC period — an expedited-but-still-multisig-gated path, distinct from pause()'s emergency exception, should be explicitly named.
  4. Testing: not applicable in the traditional sense — validate by drafting one realistic sample spending proposal (e.g., funding a security audit) through the full documented process and confirming every step is unambiguous.

Definition of Done:

Resources: SECURITY.md, issue #37's treasury-contract scope, docs/114-multisig-admin-design.md

Complexity: High (200 points)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions