Community Signer Expansion
Security-filtered plan for adding community members to the Safe signer set after community voting is live.
Status: Planned. The current 3-of-5 Safe model remains active until voting, eligibility, onboarding, rotation, and replacement rules are ready.
Governance Principle Planned
Signer seats are operational security roles. Community legitimacy matters, but candidates must first pass a practical security and reliability filter. The model is not pure whale voting and not pure random selection.
Design Goal
The expansion should reduce single-team dependency without introducing weaker controls. The practical risks are key compromise, inactive signers, whale capture, random unqualified signers, undisclosed conflicts, and slow emergency response.
- Security first — signer seats require secure wallet setup, transaction review discipline, and reachable operators.
- Community mandate — eligible candidates should be publicly nominated and voted on by the community.
- Staged expansion — move from 3-of-5 to 4-of-7 first; consider 5-of-9 only after one stable signer term.
Selection Model
| Stage | Action | Purpose |
|---|---|---|
| 1 | Eligibility filter | Confirm secure wallet setup, Safe readiness, contact reliability, and public duty acceptance. |
| 2 | Public nomination | Let the community see who is applying and why the candidate is aligned. |
| 3 | Community vote | Give the final signer mandate to holders and contributors through the governance process. |
| 4 | Security and conflict review | Filter compromised, hostile, conflicted, or unreachable candidates before onboarding. |
| 5 | Safe onboarding | Update owners and threshold through the documented governance and Safe process. |
| 6 | Term and rotation | Use fixed signer terms so community seats can refresh without destabilizing operations. |
| 7 | Emergency replacement | Define removal and replacement rules before community seats are added. |
Why Not Pure Whale Voting?
- Large holders can be aligned, but token amount alone can become plutocratic control.
- Freely transferable balances can move quickly and do not prove long-term responsibility.
- One entity can split holdings across wallets.
- A large balance does not prove Safe, calldata, or key-management competence.
Why Not Pure Random Selection?
- Randomness can select inactive or unprepared users.
- Signer duties require secure wallet setup, response discipline, and transaction review.
- Randomness is only acceptable inside a pre-qualified candidate pool.
Candidate Eligibility
| Requirement | Reason |
|---|---|
| Hardware wallet or equivalent secure signing setup | Reduces hot-wallet compromise risk. |
| Safe readiness | Signer must verify target address, calldata, value, and network before signing. |
| 24-48h response expectation | Prevents routine execution from stalling. |
| Reliable contact path | Signer must be reachable for coordination and incident review. |
| Conflict review | Filters hostile, compromised, or conflicted candidates. |
| Public acceptance of duties | Creates accountability before the community. |
| Alignment signal | Locked IFR, contributor work, lending, builder activity, or long holding history. |
Preferred Path
| Stage | Model | When | Rationale |
|---|---|---|---|
| Current | 3-of-5 | Active | Operational reliability while voting and onboarding rules are still being prepared. |
| First expansion | 4-of-7 | After community voting is live | Adds community seats without making execution too slow. |
| Mature expansion | 5-of-9 | After one proven term | Stronger decentralization once the process is battle-tested. |
4-of-7 Seat Mix
| Seat type | Count | Purpose |
|---|---|---|
| Core / protocol signers | 3 | Continuity, technical context, emergency execution. |
| Contributor / builder signers | 2 | Ecosystem execution and product context. |
| Community-elected signers | 2 | Community mandate and decentralization. |
5-of-9 Seat Mix
| Seat type | Count | Purpose |
|---|---|---|
| Core / security signers | 3 | Protocol continuity and security review. |
| Contributor / builder signers | 2 | Ecosystem representation. |
| Community-elected signers | 3 | Broader community mandate. |
| Independent security / guardian seat | 1 | Additional transaction review capacity. |
Safe Separation
- Treasury Safe: conservative expansion, highest qualification bar.
- Community / Grants Safe: can expand earlier and include more community seats.
- LP Reserve Safe: conservative, because liquidity actions affect market structure.
- Guardian Safe: optional cancel-only or emergency-only role, not treasury spending.
Voting And Rotation
- Locked IFR should count more than freely transferable IFR.
- Candidate eligibility comes before the vote.
- First community signer term should be 6 months; later terms can be 12 months.
- At least one community seat can rotate each term.
- Emergency replacement rules must exist before adding community signers.
Implementation Checklist
- Publish signer eligibility criteria.
- Define signer duties and removal conditions.
- Define voter eligibility: locked IFR, verified wallet, or other governance credential.
- Open candidate applications and nominations.
- Run a test Safe onboarding drill.
- Hold the community vote.
- Queue Safe signer update through governance.
- Execute after the required review or timelock path.
- Verify owners and threshold on Safe.
- Update docs, landing, wiki, and AI copilot knowledge.
Bottom line: community-democratic selection, security-filtered eligibility, staged threshold expansion, and documented rotation.