Files
docs/apps/zen-docs/content/blog/zips-governance.mdx
zeekay dc8ff497e1 content(zen-docs): brand cleanup across blog posts and remove zenlm-models/ui packages
- Update blog/[slug]/page.tsx to use getAllSlugs() instead of getSortedPosts() for static params
- Sweep all blog MDX files to remove upstream model name references (brand policy compliance)
- Add new blog posts: 7680-dim-embeddings, agent-nfts, bitdelta-behavioral-compression, case-for-decentralized-science
- Delete gspo.mdx and qwen2.5-vl-32b.mdx (consolidated/removed content)
- Remove packages/zenlm-models and packages/zenlm-ui entirely
- Update lib/blog.ts, docs/server.ts, docs/browser.ts for blog infrastructure
- Update pnpm-lock.yaml after package removal
2026-03-01 16:07:08 -08:00

210 lines
6.7 KiB
Plaintext
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "ZIPs: Decentralized Governance for Open AI"
description: "How Zoo Improvement Proposals enable community-driven governance of open AI development."
date: "2024-05-20"
author: "Zach Kelling"
tags: ["Governance", "ZIPs"]
---
Since launching Zoo Labs Foundation, we’ve processed 47 Zoo Improvement Proposals (ZIPs). Today we share lessons learned and improvements to the governance process.
## The Case for Governance
AI development involves decisions that affect many stakeholders:
* What data should models train on?
* How should capabilities be released?
* What safety measures are required?
* How should resources be allocated?
These questions don’t have purely technical answers. They require value judgments. Centralized organizations make these judgments internally. We believe affected communities should participate.
ZIPs make governance explicit, transparent, and participatory.
## How ZIPs Work
### Proposal Types
ZIPs fall into several categories:
**Standard ZIPs** : Technical specifications
* Model architectures
* Training procedures
* Evaluation protocols
* API standards
**Process ZIPs** : Governance procedures
* Voting rules
* Working group charters
* Grant criteria
* Release policies
**Informational ZIPs** : Guidelines and recommendations
* Best practices
* Research directions
* Community standards
### Lifecycle
```
[Draft] -> [Review] -> [Vote] -> [Accepted/Rejected] -> [Implemented]
|
v
[Withdrawn]
```
**Draft** : Author creates proposal using template. Must include:
* Abstract (200 words max)
* Motivation (why this change?)
* Specification (precise details)
* Rationale (why this approach?)
* Backwards compatibility
* Security considerations
**Review** : Community discusses on forums and in working groups. Minimum 14 days. Author revises based on feedback.
**Vote** : Token holders vote. Quorum: 10% of circulating supply. Threshold: 66% approval for Standard/Process ZIPs, 50% for Informational.
**Implementation** : Approved ZIPs are implemented by relevant teams. Timeline specified in proposal.
### Example ZIP
**ZIP-23: Mandatory Safety Evaluations**
_Abstract_ : This ZIP requires all Zen models to pass standardized safety evaluations before release. It specifies evaluation benchmarks, minimum thresholds, and remediation procedures.
_Motivation_ : As Zen models become more capable, systematic safety evaluation ensures we catch potential harms before deployment…
[Full proposal at zips.zoo.ngo/zip-23]
## Lessons Learned
After 47 ZIPs, we’ve learned what works and what doesn’t.
### What Works
**Clear templates** : Structured templates reduce ambiguity. Authors know what to include. Reviewers know what to expect.
**Mandatory discussion periods** : Two weeks minimum prevents rushed decisions. Complex proposals often need longer.
**Working group pre-review** : Technical working groups review proposals before community vote. Catches errors and improves quality.
**On-chain voting** : Tamper-proof voting records. Clear outcome determination. Historical audit trail.
### What Doesn’t Work
**Low participation** : Early votes had <5% participation. We added delegation and reminders. Participation now averages 12%.
**Proposal complexity** : Some proposals tried to do too much. We now encourage smaller, focused ZIPs.
**Implementation lag** : Approved proposals sometimes stalled in implementation. We added accountability mechanisms.
**Voter fatigue** : Too many votes led to declining participation. We batch non-urgent votes monthly.
## Improvements for 2024
Based on experience, we’re upgrading the process:
### Conviction Voting
For resource allocation decisions, we’re piloting conviction voting:
* Tokens continuously signal preferences
* Conviction accumulates over time
* Proposals pass when conviction reaches threshold
This rewards sustained support over flash mobs.
### Optimistic Approval
Low-controversy changes use optimistic approval:
* Proposal published with 7-day objection period
* If no objection reaches threshold (5% of tokens), proposal passes
* If objection threshold reached, standard vote occurs
Reduces voting overhead for routine decisions.
### Working Group Autonomy
Working groups can approve changes within their scope without full vote:
* Changes must align with approved charter
* Community can override within 14 days
* Increases agility while maintaining accountability
### Reputation-Weighted Voting
We’re exploring reputation adjustments:
* Technical expertise weighted higher for technical ZIPs
* Contribution history affects weight
* Prevents pure plutocracy
This is controversial. ZIP-52 is the formal proposal for community decision.
## Governance Statistics
Metric| Q1 2024| Q2 2024
---|---|---
Proposals submitted| 18| 29
Proposals passed| 12| 21
Average participation| 8%| 14%
Average discussion length| 9 days| 16 days
Implementation rate| 75%| 92%
Participation and quality are improving.
## Notable ZIPs
Some highlights from our proposal history:
**ZIP-7** : Established the grants program criteria and evaluation process. Enabled $3M in grants.
**ZIP-15** : Required training data documentation for all Zen models. Now standard practice.
**ZIP-23** : Mandatory safety evaluations (discussed above). Caught two issues pre-release.
**ZIP-31** : Created the Infrastructure Working Group. Now maintains Training Gym.
**ZIP-38** : Approved Zen-2-70B training budget. Largest single resource allocation.
## Participating in Governance
### For Token Holders
1. **Stay informed** : Read proposals at zips.zoo.ngo
2. **Discuss** : Join forum discussions
3. **Delegate** : If you can’t follow closely, delegate to aligned representatives
4. **Vote** : Participate in votes that matter to you
### For Proposers
1. **Start with discussion** : Float ideas in forums before formal proposal
2. **Find co-sponsors** : Working group endorsement helps
3. **Be specific** : Vague proposals fail
4. **Engage with feedback** : Responsive authors succeed
### For Working Groups
1. **Pre-review proposals** : Catch issues early
2. **Provide expertise** : Technical analysis helps voters
3. **Implement promptly** : Approved proposals deserve attention
## Governance as Infrastructure
Good governance is invisible when working. Bad governance is obvious when failing. ZIPs provide structure that enables coordinated action while preventing unilateral capture.
As AI systems become more powerful, their governance becomes more important. We’re building the institutions for a future where AI development is genuinely participatory.
Join the conversation at zips.zoo.ngo.
* * *
_Zach Kelling is a co-founder of Zoo Labs Foundation._