LP-0003: LP Governance Framework

Abstract

The Lux Proposal (LP) system is the primary mechanism for proposing, discussing, and implementing changes to the Lux Network. This document defines the governance process, LP types, lifecycle stages, and community participation guidelines.

Motivation

A clear, transparent governance process enables:

Open participation: Anyone can propose changes
Rough consensus: Decisions through technical merit and community support
Implementation focus: Working code over documentation
Transparency: All processes are public

Specification

What is an LP?

A Lux Proposal (LP) is a design document providing information to the Lux community, describing a new feature, process, or environment change. LPs are the primary mechanism for proposing major new features, collecting community input on an issue, and documenting design decisions.

LP Types

Standards Track

Technical specifications that require implementation:

Core: Consensus, network rules, protocol changes
Networking: P2P protocols, network layer specifications
Interface: APIs, RPC specifications
LRC: Application standards (tokens, NFTs, DeFi)
Bridge: Cross-chain protocols and interoperability

Informational

Guidelines, best practices, and general information:

Design patterns
Implementation guides
Educational content

LP Lifecycle

Draft --> Review --> Last Call --> Final
            |            |
        Withdrawn    Stagnant

Status Definitions

Status	Description
Draft	Initial submission, work in progress, open to major changes
Review	Editors reviewing, community feedback, implementation in progress
Last Call	Final 14-day review period, no substantial changes
Final	Accepted, implementation deployed, no further changes
Stagnant	No activity for 6+ months, can be revived
Withdrawn	Author abandons proposal, can be adopted by new champion
Superseded	Replaced by newer LP, historical reference only

Submission Process

1. Pre-Proposal Discussion

Before submitting an LP:

Discuss on forum.lux.network
Gauge community interest
Refine the idea
Find collaborators

2. Draft Submission

Create your LP:

cd ~/work/lux/lps
make new  # Interactive wizard

Submit via Pull Request:

File: LPs/lp-draft.md
PR number becomes LP number
Editors assign LP number
Rename to lp-N.md

3. Editor Review

LP editors check for:

✅ Technical soundness
✅ Proper formatting
✅ Complete required sections
✅ Clear specification
✅ No duplication

Note: Editors review form, not merit. Community decides value.

4. Community Feedback

Gather consensus through:

GitHub discussions
Forum posts
Community calls
Implementation testing

5. Implementation

Build reference implementation:

Prove feasibility
Test in production-like environment
Document edge cases
Multiple implementations preferred

6. Activation

Final LPs activate via:

Hard fork (consensus changes)
Soft fork (backward-compatible)
Opt-in adoption (application standards)

LP Requirements

Required YAML Frontmatter

---
lp: <number>
title: <short descriptive title>
description: <one sentence>
author: <Name (@github)>
discussions-to: <URL>
status: Draft|Review|Last Call|Final
type: Standards Track|Meta|Informational
category: Core|Networking|Interface|LRC|Bridge
created: <YYYY-MM-DD>
---

Required Content Sections

Abstract (~200 words overview)
Motivation (why this LP is needed)
Specification (technical details)
Rationale (design decisions)
Backwards Compatibility
Test Cases (required for Standards Track)
Reference Implementation (optional but recommended)
Security Considerations
Copyright (must be CC0)

LP Editors

Responsibilities

Review LP submissions for completeness
Assign LP numbers
Merge accepted proposals
Maintain LP repository
Enforce formatting standards

Current Editors

Lux Core Team (@luxfi)

Becoming an Editor

Editors are selected based on:

Long-term contribution to LPs
Technical expertise
Availability and commitment
Community trust

Governance Principles

Open Participation

Anyone can:

Submit an LP
Comment on proposals
Implement specifications
Vote through participation

Rough Consensus

Decisions made through:

Technical merit
Community support
Working implementations
No formal voting

Reference Implementations

Show, don't tell:

Code speaks louder than words
Working code proves feasibility
Multiple implementations show adoption

Transparency

All processes are public:

GitHub for tracking
Forums for discussion
Open meetings for decisions

Special Processes

Emergency Proposals

For critical security issues:

Private disclosure to core team
Fast-tracked review (24-48 hours)
Coordinated deployment
Public disclosure after fix

Breaking Changes

Hard forks require:

Extended discussion period (3+ months)
Multiple implementations
Network-wide coordination
Comprehensive testing

LRC Standards

Application-level standards need:

At least 2 independent implementations
Production testing
Community adoption
ERC compatibility (where applicable)

Tools and Resources

LP Repository

GitHub: github.com/luxfi/lps
Documentation: lps.lux.network
Discussions: github.com/luxfi/lps/discussions

Commands

make new           # Create new LP
make validate      # Validate LP
make validate-all  # Validate all
make check-links   # Check links
make update-index  # Update index
make pre-pr        # Pre-PR checks

Rationale

The LP process is modeled after Ethereum's EIP system, which has proven effective for decentralized protocol governance. Key design choices:

Numbered proposals: Enables stable references and citations
Status lifecycle: Prevents premature finalization while allowing progress
Editor review: Ensures quality without gatekeeping ideas
Community consensus: Final authority rests with stakeholders, not editors

Backwards Compatibility

This LP establishes the governance framework. It does not break any existing processes.

Security Considerations

Emergency LP process ensures rapid security response
Private disclosure protects users during fix development
Editor review prevents malicious proposals

LP Governance Framework