InfiniteZero Protocol Proposals (IZPs) are how changes to the InfiniteZero protocol are proposed, discussed and agreed. An IZP is a design document: it describes a change, explains why it is needed, and records how the community reached its decision.
The process is modelled on Ethereum's Improvement Proposals (EIP-1). IZPs were previously called DIN Protocol Proposals (DPPs).
InfiniteZero is governed by social consensus, not coin voting.
- Discussion comes first. Most proposals are settled in the open: people raise concerns, the author revises, and the proposal moves forward once no substantive objections remain. This is rough consensus, not unanimity.
- Voting is a last resort. A vote is held only when there is a dispute, or a question that can't be settled by discussion. How disputes are settled, and who takes part, is being defined in IZP-1.
- Tokens don't buy control of the rules. Holding tokens gives no say over protocol rules. Validators, who have stake at risk, may have a stake-weighted say in disputes over network economics, as proposed in IZP-1.
- Anyone can take part. You don't need permission, tokens or a title to propose or comment.
- Exit is always possible. All InfiniteZero code is open source. If the community rejects a direction, anyone can fork.
Editors don't judge whether a proposal is a good idea. They check that it is complete, clearly written and follows this process.
When a discussion needs wider or more structured input, we may use tools such as Polis, which maps where people agree and disagree, or gov4git, which records votes transparently in Git. These are options, not requirements.
| Category | Covers |
|---|---|
| Core | Protocol rules: smart contracts, training rounds, scoring, slashing, rewards, and security and privacy mechanisms |
| Interface | Standards for working with InfiniteZero: CLI and SDK behaviour, APIs, data formats, model packaging and node communication |
| Economics | Network economic parameters: fees, emissions, stake requirements, reward splits and penalties |
| Meta | How InfiniteZero is governed and run: this process, governance, the treasury and the Foundation |
| Informational | Guidelines, research and best practice that don't change the protocol |
Core and Interface IZPs need a reference implementation before they can become Final.
Idea → Draft → Review → Last Call → Final
| Status | Meaning |
|---|---|
| Idea | Not yet an IZP. Discuss it first in DevNet Discussions or on Telegram to test interest and find collaborators. |
| Draft | Merged into this repository and open for discussion and changes. |
| Review | The author considers it ready and asks for wider review. |
| Last Call | The final review window, normally 14 days. A substantive objection sends it back to Review. |
| Final | Agreed. Only corrections are made after this point. |
| Living | Kept up to date indefinitely, such as a process document. |
| Stagnant | No activity for 6 months while in Draft or Review. The author, or anyone else, can revive it. |
| Withdrawn | Withdrawn by the author. The number is not reused. |
| Rejected | The community decided not to proceed. The reasons are recorded in the IZP. |
A Final IZP is an agreement, not a deployment. Changes reach the network through the normal release process in DevNet.
- Discuss the idea first in DevNet Discussions or on Telegram.
- Open a discussion issue in this repository titled
IZP discussion: <title>. The conversation about your proposal lives there. - Write your IZP using the template below, in a file named
IZP-<number>.md. Use the next free number in the IZP Index; an editor confirms it during review. - Open a pull request that adds your IZP and its row in the IZP Index. If you aren't a maintainer, fork this repository first.
- An editor checks it and merges it as Draft. Discussion continues on the issue.
- Move it forward. When it is ready, open a pull request that updates its status.
- Authors write the IZP, gather feedback, keep it up to date, and record the objections raised and how they were resolved.
- Editors check format and completeness, confirm numbers, and merge status changes. They don't decide on merit. Until community editors are appointed, the core maintainers act as editors.
- The community is anyone who reads, comments on, tests or reviews a proposal.
# IZP-<number>: <Title>
| | |
| :--- | :--- |
| **Description** | One sentence on what this proposes |
| **Authors** | Name (@github-handle) |
| **Discussions-To** | Link to the discussion issue |
| **Status** | Draft |
| **Category** | Core / Interface / Economics / Meta / Informational |
| **Created** | YYYY-MM-DD |
| **Requires** | (Optional) Numbers of IZPs this depends on |
## Abstract
A short summary of the proposal, in about 200 words.
## Motivation
The problem this solves, and why it matters now.
## Specification
Exactly what changes. For Core and Interface IZPs, enough detail for someone to implement it.
## Rationale
Why this design, which alternatives were considered, and which objections were raised and how they were resolved.
## Backwards Compatibility
What this changes for existing participants, contracts and tools, and how to migrate. Write "None" if nothing changes.
## Security Considerations
The risks this introduces or removes: attacks, failure modes, privacy and economic manipulation. Required for every IZP.
## Reference Implementation
(Optional while in Draft; required before Final for Core and Interface IZPs.) Links to code, pull requests or tests.
## References
(Optional) Related IZPs, research and documents.- IZP Index: every proposal and its status
- DevNet: the protocol's code
- DevNet Discussions: ideas and questions
- White Paper
- Telegram
Questions about the process? Open an issue.