NEP-000: NEP Process

Abstract

This document establishes the governance framework for Netrun Enhancement Proposals (NEPs). It defines how protocol modifications progress from initial concept through community review to network deployment, ensuring transparent and structured evolution of the Netrun metaprotocol.

Community NEP submissions will be enabled following the mainnet launch.

Motivation

As a Bitcoin metaprotocol, Netrun requires a rigorous process to evaluate changes that may affect network security, fungibility guarantees, and cross-chain interoperability. This framework ensures all stakeholders can participate in protocol governance while maintaining the security standards expected of Bitcoin-anchored systems.

Specification

Proposal Categories

• •Core: Changes to consensus rules, transaction validation, or cryptographic primitives.
• •Interface: Modifications to APIs, RPC methods, or client specifications.
• •Meta: Process changes, governance updates, or documentation standards.
• •Informational: Design guidelines, best practices, or ecosystem recommendations.

Status Lifecycle

Status Definitions

• •Idea: Initial concept shared for preliminary feedback before formal submission.
• •Draft: Proposal is being authored with complete specification and rationale.
• •Review: Proposal is undergoing technical and security evaluation by core contributors.
• •Accepted: Proposal has passed review and is approved for implementation.
• •Deferred: Proposal is valid but postponed due to timing or resource constraints.
• •Implementation: Active development is underway with testnet deployment planned.
• •Final: Proposal is fully implemented and deployed on mainnet.
• •Withdrawn: Proposal has been retracted by its author or rejected during review.

1. Submitting a Proposal

Goal: Transform an idea into a well-structured proposal ready for community review.

1. Discuss the concept in community channels to gauge initial interest and identify potential concerns.
2. Fork the NEPs repository and create a new branch using the naming convention nep-XXX-short-title.
3. Copy the template file and fill in all required sections: motivation, specification, security considerations, and backward compatibility.
4. Submit a pull request with the NEP in Draft status.
5. Address feedback from editors on formatting and completeness before advancing to Review.

2. Review Process

Goal: Ensure proposals meet technical standards and align with protocol values.

1. Core contributors evaluate technical feasibility and implementation complexity.
2. Security reviewers assess potential attack vectors and risk mitigation strategies.
3. Community members provide feedback on usability and ecosystem impact.
4. Authors must respond to all substantive comments and update the proposal accordingly.
5. A minimum review period of 14 days applies to all Core proposals.

3. Acceptance Criteria

A proposal may advance to Accepted when:

1. Technical specification is complete and unambiguous.
2. Security review has concluded with no outstanding critical concerns.
3. Backward compatibility implications are fully documented.
4. Reference implementation exists or a clear implementation path is defined.
5. Consensus among core contributors has been reached.

4. Implementation Guidelines

Goal: Translate accepted proposals into production-ready code.

1. Implementation must follow the specification exactly; deviations require NEP amendments.
2. Comprehensive test coverage is required, including edge cases identified during review.
3. Documentation updates must accompany code changes.
4. Testnet deployment precedes mainnet activation with a minimum observation period.

5. Amendments and Updates

Modifications to Final NEPs require:

1. A new NEP that explicitly supersedes or extends the original.
2. Clear documentation of changes and migration requirements.
3. The same review process as new proposals, with additional scrutiny on breaking changes.