GOVERNANCE WHITEPAPER · v1.0
Governance Whitepaper
Decentralized Governance Framework — For Informational Purposes Only
Version 1.0 · September 2026 · Felix Ecosystem Foundation
Table of Contents
PART I: GOVERNANCE PHILOSOPHY
1.1 Core Principles
1.2 Governance Vision
1.3 Progressive Decentralization
PART II: GOVERNANCE STRUCTURE
2.1 Governance Architecture
2.2 Governance Flow
2.3 Key Components
PART III: GOVERNANCE TOKENS
3.1 FLEXE Token — Governance Token
3.2 FLXV Token — Utility Token
3.3 Token Utility Comparison
PART IV: PROPOSAL PROCESS
4.1 Proposal Lifecycle Overview
4.2 Step 1: Idea & Community Discussion
4.3 Step 2: Sentiment Analysis (Temp Check)
4.4 Step 3: Formal Proposal (ARFC Equivalent)
4.5 Step 4: On-Chain Voting (AIP Equivalent)
4.6 Step 5: Implementation & Execution
PART V: VOTING MECHANISM
5.1 Off-Chain Voting (Snapshot)
5.2 On-Chain Voting
5.3 Voting Power Calculation
5.4 Delegation
PART VI: GOVERNANCE ROLES
6.1 Proposers
6.2 Voters
6.3 Delegates
6.4 Delegators
6.5 Contributors
6.6 Service Providers
6.7 Guardians
6.8 Stewards
PART VII: PROPOSAL FRAMEWORKS
7.1 Protocol Parameters Framework
7.2 New Collateral Framework
7.3 Feature Changes Framework
7.4 Treasury Management Framework
7.5 Governance Policies Framework
PART VIII: SECURITY & EMERGENCY MECHANISMS
8.1 Timelock
8.2 Emergency Guardians
8.3 Parameter Validation
8.4 Multi-Sig Controls
8.5 Progressive Decentralization
PART IX: ADMINCONTROLLER — GOVERNANCE IMPLEMENTATION
9.1 Overview
9.2 Governance-Controlled Parameters
9.3 Security Features
PART X: COMPARISON WITH INDUSTRY STANDARDS
10.1 Comparison with Aave Governance
10.2 Comparison with MakerDAO
10.3 Comparison with Uniswap
10.4 Comparison Summary
PART XI: FREQUENTLY ASKED QUESTIONS
11.1 General Governance Questions
11.2 Proposal Questions
11.3 Voting Questions
11.4 Token Questions
11.5 Security Questions
PART XII: COMPLETE SUMMARY
12.1 Summary Table
12.2 Final Message
12.3 Legal Disclaimer
PART I: GOVERNANCE PHILOSOPHY
1.1 Core Principles
The Felix Ecosystem is transitioning toward a community-governed model where token holders participate in key protocol decisions. This ensures the ecosystem evolves in alignment with community interests while maintaining security and stability.
| Principle | Description |
|---|
| Decentralization | Progressive reduction of central control over protocol parameters |
| Transparency | All governance proposals and votes are publicly accessible |
| Community-Driven | Token holders vote on proposals that shape the ecosystem |
| Security-First | Multi-layered safeguards prevent malicious or reckless changes |
1.2 Governance Vision
| Aspect | Vision |
|---|
| Short-Term (2026-2027) | Establish governance foundation with active community participation |
| Medium-Term (2027-2028) | Progressive decentralization of key protocol parameters |
| Long-Term (2028+) | Fully community-governed ecosystem with minimal central oversight |
1.3 Progressive Decentralization
Felix follows a progressive decentralization approach:
| Phase | Central Control | Community Control |
|---|
| Phase 1 — Foundation | High | Low |
| Phase 2 — Expansion | Medium | Medium |
| Phase 3 — Global Growth | Low | High |
| Phase 4 — Leadership | Minimal | Full |
PART II: GOVERNANCE STRUCTURE
2.1 Governance Architecture
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ │
│ FELIX GOVERNANCE ARCHITECTURE │
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ COMMUNITY FORUM (Discourse.org) │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Idea Submission │ │ │
│ │ │ • Community Discussion │ │ │
│ │ │ • Feedback & Refinement │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ SNAPSHOT VOTING (Off-Chain) │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Sentiment Analysis (Temp Check) │ │ │
│ │ │ • Formal Proposal Review (ARFC Equivalent) │ │ │
│ │ │ • FLXV / FLEXE Token Weighted Voting │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ ON-CHAIN GOVERNANCE │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Formal Submission │ │ │
│ │ │ • On-Chain Voting │ │ │
│ │ │ • Timelock (3 Days) │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ ADMINCONTROLLER EXECUTION │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Parameter Updates │ │ │
│ │ │ • Feature Implementation │ │ │
│ │ │ • Contract Upgrades │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────┘
2.2 Governance Flow
| Step | Component | Description |
|---|
| 1 | Community Forum | Idea submission and community discussion |
| 2 | Snapshot (Off-Chain) | Sentiment analysis and formal review |
| 3 | On-Chain Governance | Formal submission and binding vote |
| 4 | Timelock | 3-day delay for critical changes |
| 5 | AdminController | Implementation of approved proposals |
2.3 Key Components
| Component | Function |
|---|
| Community Forum | Discourse.org — Proposal discussion and refinement |
| Snapshot | Off-chain voting platform for sentiment analysis |
| Governance Token | FLEXE — Voting power and proposal creation |
| AdminController | Smart contract for parameter management |
| Timelock | 3-day delay for critical parameter changes |
| Multi-Sig | Emergency controls and administrative functions |
PART III: GOVERNANCE TOKENS
3.1 FLEXE Token — Governance Token
The FLEXE token is a pivotal element in the governance structure of the Felix ecosystem.
| Feature | Detail |
|---|
| Token Name | FLEXE |
| Purpose | Governance and collaboration incentive |
| Voting Platform | Snapshot.org |
| Staking Requirement | Required for certain governance actions |
FLEXE Token Utilities
| Utility | Description |
|---|
| Governance Voting | Vote on proposals affecting the ecosystem |
| Forum Access | Stake FLEXE to participate in community forum |
| Proposal Creation | Required to submit certain proposals |
| Collaboration Incentive | Used in Proof-of-Collaboration (PoCol) mechanism |
3.2 FLXV Token — Utility Token
While FLXV is primarily a utility token, it also provides governance capabilities.
| Feature | Detail |
|---|
| Token Name | Felix Value Token |
| Symbol | FLXV |
| Network | BNB Smart Chain (BEP-20) |
| Total Supply | 1,500,000,000 |
| Governance Role | Secondary voting power |
FLXV Governance Utility
| Utility | Description |
|---|
| Staking Governance | Staked FLXV provides voting power |
| Ecosystem Participation | Active participants gain governance weight |
| Delegation | FLXV holders can delegate voting power |
3.3 Token Utility Comparison
| Feature | FLEXE | FLXV |
|---|
| Primary Purpose | Governance | Utility |
| Voting Power | ✅ Primary | ✅ Secondary |
| Proposal Creation | ✅ Required | — Limited |
| Staking Requirement | ✅ Yes | — No |
| Ecosystem Access | ✅ Governance | ✅ Full Ecosystem |
| Rewards | — No | ✅ Staking Rewards (15% monthly) |
PART IV: PROPOSAL PROCESS
4.1 Proposal Lifecycle Overview
┌─────────────────────────────────────────────────────────────────────────────────────────┐
│ │
│ PROPOSAL LIFECYCLE │
│ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ STEP 1: IDEA & COMMUNITY DISCUSSION │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Community Forum (Discourse.org) │ │ │
│ │ │ • Proposals include: Title, Description, Rationale │ │ │
│ │ │ • Certain participants may need to stake tokens to propose │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ STEP 2: SENTIMENT ANALYSIS (TEMP CHECK) │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Snapshot.org Off-Chain Vote │ │ │
│ │ │ • Non-binding community sentiment │ │ │
│ │ │ • Duration: 3 Days │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ STEP 3: FORMAL PROPOSAL (ARFC EQUIVALENT) │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Detailed proposal with technical specifications │ │ │
│ │ │ • Service provider review and feedback │ │ │
│ │ │ • Snapshot.org Formal Vote │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ STEP 4: ON-CHAIN VOTING (AIP EQUIVALENT) │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Formal on-chain submission │ │ │
│ │ │ • Binding vote via Governance contracts │ │ │
│ │ │ • Quorum and vote differential requirements │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────────────────────────────┐ │
│ │ STEP 5: IMPLEMENTATION & EXECUTION │ │
│ │ ┌───────────────────────────────────────────────────────────────────────────┐ │ │
│ │ │ • Timelock (3 Days) │ │ │
│ │ │ • AdminController execution │ │ │
│ │ │ • Community notification │ │ │
│ │ └───────────────────────────────────────────────────────────────────────────┘ │ │
│ └─────────────────────────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────────────────────────┘
4.2 Step 1: Idea & Community Discussion
| Requirement | Detail |
|---|
| Platform | Discourse.org Community Forum |
| Eligibility | Community members (observer view for non-members) |
| Staking Requirement | Certain participants may need to stake FLEXE tokens |
| Proposal Components | Title, Description, Rationale, Implementation Plan |
Discussion Phase Activities
| Activity | Description |
|---|
| Community Feedback | Members discuss, critique, and provide suggestions |
| Q&A | Clarification on proposal details |
| Refinement | Proposal adjusted based on feedback |
4.3 Step 2: Sentiment Analysis (Temp Check)
| Feature | Detail |
|---|
| Platform | Snapshot.org |
| Type | Off-chain, non-binding vote |
| Duration | 3 Days |
| Voting Weight | Token holdings + engagement history |
| Purpose | Gauge community sentiment before formal proposal |
Sentiment Analysis Metrics
| Metric | Description |
|---|
| Support Score | Calculated based on upvotes and downvotes |
| Engagement Score | Based on comments and discussion depth |
| Threshold Criteria | Predefined levels for progression to formal proposal |
4.4 Step 3: Formal Proposal (ARFC Equivalent)
| Feature | Detail |
|---|
| Platform | Snapshot.org |
| Type | Off-chain, formal review |
| Duration | 3-5 Days |
| Requirements | Detailed technical specifications, impact analysis |
Proposal Components
| Component | Description |
|---|
| Proposal Title | Clear, descriptive title |
| Problem Statement | Issue being addressed |
| Solution | Proposed changes |
| Technical Specifications | Implementation details |
| Impact Analysis | Effects on protocol, users, and ecosystem |
| Timeline | Implementation schedule |
4.5 Step 4: On-Chain Voting (AIP Equivalent)
| Feature | Detail |
|---|
| Platform | Governance Contracts |
| Type | On-chain, binding vote |
| Duration | As defined per proposal |
| Quorum | Minimum participation required |
| Vote Differential | Required margin for approval |
On-Chain Submission Requirements
| Requirement | Detail |
|---|
| Metadata | Stored on IPFS |
| Contract Payload | Executable logic |
| Proposer | Sufficient proposal power |
| Gas Cost | Paid by proposer |
4.6 Step 5: Implementation & Execution
| Step | Detail |
|---|
| Timelock | 3-day delay for critical parameter changes |
| Execution | AdminController executes approved changes |
| Notification | Community notified of outcomes |
| Monitoring | Ongoing monitoring of implemented changes |
PART V: VOTING MECHANISM
5.1 Off-Chain Voting (Snapshot)
Off-chain votes are used to measure community sentiment during the early stages of proposal development (Temp Checks and Formal Reviews).
| Feature | Detail |
|---|
| Platform | Snapshot.org |
| Type | Off-chain, non-binding |
| Duration | 3 Days |
| Gas Cost | Free (no transaction fees) |
| Voting Power | Token holdings + engagement history |
5.2 On-Chain Voting
On-chain voting is required for formal proposal approval and implementation.
| Feature | Detail |
|---|
| Platform | Governance Contracts |
| Type | On-chain, binding |
| Duration | As defined per proposal |
| Gas Cost | Paid by voter |
| Voting Power | Token holdings |
5.3 Voting Power Calculation
| Factor | Weight | Description |
|---|
| Token Holdings | Primary | FLXV / FLEXE token balance |
| Historical Contributions | Bonus | Active participation history |
| Engagement History | Bonus | Consistent community engagement |
5.4 Delegation
| Feature | Detail |
|---|
| Purpose | Allow token holders to delegate voting power |
| Delegation Type | Joint or separate delegation |
| Delegates | Entrusted with voting power by community members |
| Delegators | Community members who delegate voting power |
PART VI: GOVERNANCE ROLES
| Role | Feature | Requirement | Responsibility |
|---|
| Proposers | Submit governance proposals | Sufficient proposal power (FLEXE tokens) | Present clear, well-structured proposals |
| Voters | Vote on proposals | FLXV / FLEXE token holdings | Participate in governance decisions |
| Delegates | Vote on behalf of delegators | Entrusted by community members | Act in the best interest of delegators |
| Delegators | Delegate voting power to delegates | FLXV / FLEXE token holdings | Choose delegates wisely |
| Contributors | Engage in working groups, bounties, grants | Active community participation | Maintain and improve the ecosystem |
| Service Providers | Provide essential services (Risk, Security, Development) | Auditors, developers, risk managers | Maintain protocol safety and functionality |
| Guardians | Execute limited emergency protections | Multi-signature wallet | Protect protocol against emergencies |
| Stewards | Manage specific protocol parameters | GHO parameters, risk parameters | Streamline governance with delegated authority |
PART VII: PROPOSAL FRAMEWORKS
7.1 Protocol Parameters Framework
| Parameter | Description | Governance Control |
|---|
| MCR | Minimum Collateralization Ratio | ✅ Yes |
| CCR | Critical Collateralization Ratio | ✅ Yes |
| SPYield | Stability Pool Yield | ✅ Yes |
| InterestRouter | Interest distribution mechanism | ✅ Yes |
| PriceFeed | Oracle price feed contract | ✅ Yes |
| MaxDebtCap | Maximum total debt allowed | ✅ Yes |
7.2 New Collateral Framework
| Step | Description |
|---|
| 1 | Community discussion on proposed asset |
| 2 | Risk assessment by service providers |
| 3 | Formal proposal (ARFC) |
| 4 | On-chain vote (AIP) |
| 5 | Implementation via AdminController |
7.3 Feature Changes Framework
| Step | Description |
|---|
| 1 | Idea submission and community discussion |
| 2 | Technical specification and review |
| 3 | Formal proposal and vote |
| 4 | Implementation with timelock |
7.4 Treasury Management Framework
| Step | Description |
|---|
| 1 | Treasury allocation proposal |
| 2 | Community discussion and refinement |
| 3 | Formal vote |
| 4 | Execution of approved allocation |
7.5 Governance Policies Framework
| Step | Description |
|---|
| 1 | Governance policy proposal |
| 2 | Community discussion |
| 3 | Formal vote |
| 4 | Implementation |
PART VIII: SECURITY & EMERGENCY MECHANISMS
8.1 Timelock
| Feature | Detail |
|---|
| Purpose | Provide user reaction window for critical changes |
| Duration | 3 Days |
| Applicability | Contract upgrades and critical parameter changes |
8.2 Emergency Guardians
| Feature | Detail |
|---|
| Purpose | Execute limited emergency protections |
| Authorization | Multi-signature wallet |
| Scope | Emergency-only actions |
8.3 Parameter Validation
| Feature | Detail |
|---|
| Purpose | Ensure critical invariants are maintained |
| Validation | CCR > MCR and CCR > SCR |
| Implementation | AdminController contract |
8.4 Multi-Sig Controls
| Feature | Detail |
|---|
| Purpose | Administrative rights management |
| Implementation | Multi-signature wallets |
| Signers | Community-elected signers |
8.5 Progressive Decentralization
| Feature | Detail |
|---|
| Purpose | Planned reduction of central administrative control |
| Timeline | Phased over 2-4 years |
| Goal | Full community governance |
PART IX: ADMINCONTROLLER — GOVERNANCE IMPLEMENTATION
9.1 Overview
The Felix Protocol uses an AdminController contract to manage governance-driven changes to protocol parameters. This contract enforces critical security measures to protect users.
9.2 Governance-Controlled Parameters
| Parameter | Description | Governance Control |
|---|
| MCR | Minimum Collateralization Ratio | ✅ Yes |
| CCR | Critical Collateralization Ratio | ✅ Yes |
| SPYield | Stability Pool Yield | ✅ Yes |
| InterestRouter | Interest distribution mechanism | ✅ Yes |
| PriceFeed | Oracle price feed contract | ✅ Yes |
| MaxDebtCap | Maximum total debt allowed | ✅ Yes |
| New Collateral | Adding new collateral types | ✅ Yes |
9.3 Security Features
| Feature | Description |
|---|
| Timelock | 3-day delay for contract upgrades and critical parameter changes |
| Parameter Validation | Ensures CCR > MCR and CCR > SCR (critical invariants) |
| Multi-Sig Control | Administrative rights managed via multi-signature wallets |
| Progressive Decentralization | Planned reduction of central administrative control |
PART X: COMPARISON WITH INDUSTRY STANDARDS
10.1 Comparison with Aave Governance
| Feature | Aave DAO | Felix Governance |
|---|
| Governance Model | Decentralized DAO | Community-driven DAO |
| Proposal Platform | Discourse.org | Discourse.org |
| Voting Platform | Snapshot + On-chain contracts | Snapshot.org |
| Governance Token | AAVE, stkAAVE, aAAVE | FLEXE |
| Voting Power | Token balances + delegation | Token holdings + engagement history |
| Off-Chain Voting | ✅ Temp Checks, ARFCs | ✅ Sentiment Analysis |
| On-Chain Voting | ✅ AIP stage | ✅ On-chain Governance |
| Cross-Chain Voting | ✅ Storage proofs (v3) | — |
| Timelock | 1-7 days | 3 days |
| Emergency Guardians | ✅ 2 Multisigs | ✅ Multi-sig controls |
| Stewards | ✅ GHO and Risk stewards | ✅ AdminController |
10.2 Comparison with MakerDAO
| Feature | MakerDAO | Felix Governance |
|---|
| Governance Model | Executive Voting + Polls | Proposal-based |
| Voting Platform | On-chain + Off-chain | Snapshot.org |
| Governance Token | MKR | FLEXE |
| Emergency Powers | Emergency Shutdown | Emergency Guardians |
| Risk Management | Risk Teams | Service Providers |
10.3 Comparison with Uniswap
| Feature | Uniswap | Felix Governance |
|---|
| Governance Model | Governor Bravo | Custom Governance |
| Proposal Threshold | 2.5M UNI | FLEXE-based |
| Voting Period | 3 days | 3-5 days |
| Timelock | 2 days | 3 days |
| Emergency Powers | Guardian | Multi-sig Guardians |
10.4 Comparison Summary
| Feature | Aave | MakerDAO | Uniswap | Felix |
|---|
| Governance Model | DAO | DAO | Governor Bravo | Community DAO |
| Proposal Platform | Discourse | Discourse | Discourse | Discourse |
| Voting Platform | Snapshot + On-chain | On-chain + Off-chain | On-chain | Snapshot |
| Governance Token | AAVE | MKR | UNI | FLEXE |
| Timelock | 1-7 days | 24 hours | 2 days | 3 days |
| Emergency Powers | ✅ Yes | ✅ Yes | ✅ Guardian | ✅ Yes |
| Delegation | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Yes |
PART XI: FREQUENTLY ASKED QUESTIONS
11.1 General Governance Questions
Q1: What is the Felix Governance Model?
Felix uses a community-driven DAO model where FLEXE token holders vote on proposals affecting the ecosystem. Governance is structured with off-chain sentiment analysis and on-chain binding votes.
Q2: Why does Felix need governance?
Governance ensures the ecosystem evolves in alignment with community interests, maintains security through collective oversight, and enables progressive decentralization.
Q3: Who can participate in governance?
Anyone holding FLXV or FLEXE tokens can participate in governance voting. Certain actions may require staking FLEXE tokens.
11.2 Proposal Questions
Q4: How do I submit a proposal?
Proposals are submitted on the Discourse.org Community Forum with a clear title, description, rationale, and implementation plan. Certain proposals may require FLEXE token staking.
Q5: What types of proposals can be submitted?
| Category | Examples |
|---|
| Protocol Parameters | MCR, CCR, interest rates |
| New Collateral | Adding new collateral types |
| Feature Changes | Modifying ecosystem mechanics |
| Treasury Management | Fund allocation |
| Governance Policies | Changes to voting mechanisms |
Q6: How long does the proposal process take?
The full process typically takes 1-2 weeks from idea to implementation, including discussion, off-chain voting, on-chain voting, and timelock.
11.3 Voting Questions
Q7: How do I vote?
Voting is conducted on Snapshot.org for off-chain votes and via governance contracts for on-chain votes.
Q8: What is the voting power based on?
Voting power is based on: Token holdings (FLXV / FLEXE), Historical contributions, and Engagement history.
Q9: Can I delegate my voting power?
Yes. Token holders can delegate their voting power to delegates who vote on their behalf.
11.4 Token Questions
Q10: What is the difference between FLXV and FLEXE?
| Token | Purpose |
|---|
| FLXV | Utility token — staking, rewards, ecosystem access |
| FLEXE | Governance token — voting, proposal creation |
Q11: How do I get FLEXE tokens?
FLEXE tokens are distributed through ecosystem participation and collaboration incentives.
Q12: Can I stake FLEXE?
Yes. Staking FLEXE is required for certain governance actions, such as proposal submission.
11.5 Security Questions
Q13: What security mechanisms are in place?
- ✅ 3-day timelock for critical changes
- ✅ Multi-signature wallet for administrative controls
- ✅ Parameter validation (CCR > MCR > SCR)
- ✅ Progressive decentralization
- ✅ Third-party audits (Dedaub)
Q14: What happens if a malicious proposal passes?
The 3-day timelock provides a window for community reaction. Emergency Guardians can also execute limited emergency protections.
Q15: How does progressive decentralization work?
Felix is gradually reducing central administrative control over time, with full community governance as the ultimate goal.
PART XII: COMPLETE SUMMARY
12.1 Summary Table
| Feature | Detail |
|---|
| Governance Model | Community-driven DAO |
| Proposal Platform | Discourse.org |
| Voting Platform | Snapshot.org |
| Governance Token | FLEXE |
| Utility Token | FLXV (secondary voting) |
| Voting Power | Token holdings + engagement history |
| Off-Chain Voting | ✅ Sentiment Analysis (3 days) |
| On-Chain Voting | ✅ Binding votes |
| Timelock | 3 days |
| Emergency Guardians | ✅ Multi-sig controls |
| Service Providers | Risk, Security, Development |
| Stewards | AdminController |
| Proposal Frameworks | 5 categories |
| Security Audits | Dedaub |
| Progressive Decentralization | ✅ Phased over 2-4 years |
12.2 Final Message
◆
Final Message
"Felix Governance — A Community-Driven Future
Progressive Decentralization:
Phase 1: Foundation (High Central Control)
Phase 2: Expansion (Medium Central Control)
Phase 3: Global Growth (Low Central Control)
Phase 4: Leadership (Full Community Governance)
Governance Tokens:
FLEXE: Primary governance token
FLXV: Utility token with secondary voting power
Proposal Process:
Idea & Community Discussion (Discourse)
Sentiment Analysis (Snapshot — 3 days)
Formal Proposal (Snapshot — 3-5 days)
On-Chain Voting (Binding)
Implementation (Timelock — 3 days)
Security Mechanisms:
3-day timelock · Multi-sig emergency guardians · Parameter validation · Third-party audits · Progressive decentralization
Join Felix Governance — Shape the Future of the Ecosystem."
12.3 Legal Disclaimer
IMPORTANT LEGAL DISCLAIMER
This document is for INFORMATIONAL PURPOSES ONLY.
No Responsibility: Felix Ecosystem, its affiliates, team members, and representatives shall NOT be responsible or liable for any governance decisions made based on this document, any financial losses incurred, any interpretations or misunderstandings, any legal/financial/regulatory consequences, or any errors/omissions.
No Advice: This document does NOT constitute financial advice, investment advice, legal advice, tax advice, an offer to sell securities, or a solicitation to buy securities.
Risk Warning: Participating in governance carries risks, including but not limited to: Loss of staked tokens, Protocol vulnerabilities, Malicious proposals, Regulatory uncertainty.
Forward-Looking Statements: This document contains forward-looking statements that involve risks and uncertainties. Actual results may differ materially from those projected.
Independent Research: Users are strongly encouraged to conduct their own independent research before participating in governance.
Acknowledgment: By reading this document, you acknowledge and agree that you have read, understood, and accepted this disclaimer. You agree that you are solely responsible for your own governance decisions.