Description
This proposal asks the community to decide whether the original Lightchain AI core team should keep limited emergency powers after launch — and, if so, what form those powers should take.
These powers would only be used in rare cases such as fixing critical bugs, halting attacks, or restarting the network if it stops.
The goal is to balance security and decentralization during the early phases of Lightchain AI.
Options
1. No — Full Decentralization from Launch
- No special permissions after deployment.
- All fixes or updates must go through DAO governance.
- Maximum decentralization, but slower emergency response.
2. Yes — Time-Limited Emergency Role (e.g., 6 months)
- The core team keeps limited emergency permissions for a short, fixed period.
- Powers expire automatically after the set duration.
- Allows fast action during the initial rollout, then full decentralization.
3. Yes — Only for Technical Failures (Security Patches or Halted Chain)
- The team can act only for verified technical emergencies.
- Cannot change parameters, governance rules, or economic settings.
- Provides a safety valve while maintaining community trust.
4. Yes — Until the Community Votes to Remove Powers
- The team keeps limited emergency control until the DAO explicitly votes to revoke it.
- Offers long-term protection but relies on sustained trust.
5. Yes — Managed by a Multisig Emergency Council
- Control is held by a 3-of-5 multisig (e.g., Gnosis Safe) instead of any single entity.
- Purpose: handle emergency actions like cancelling malicious or buggy proposals.
- Capabilities:
- Can call emergency cancel functions (e.g., stop queued execution).
- Cannot execute arbitrary actions or modify governance settings.
- Adds collective security, transparency, and clear scope limits.
Resolution Criteria
The option with the most votes will decide whether and how emergency powers are structured after mainnet launch — whether fully decentralized, time-limited, or managed by a multisig council.