Governance Process v2.0 — Aragon-Based Governance
Overview
This Constitution is a living document that will evolve alongside the development of the Cryptex DAO. This version (2.0) supersedes the previous governance framework and introduces Aragon-based onchain governance, the veLocker staking model, and two distinct voting processes — Keeper Governance (CIP) and Fast Track (CIPX).
Governance Principles
The Cryptex DAO adopts the following core principles, reflecting its governance philosophy:
- Decentralization — No single entity controls the protocol. Power is distributed among veCTX holders and delegates.
- Permissionless Participation — Any CTX holder may stake, delegate, and participate in governance without requiring approval.
- Accountability — All governance actions, votes, and proposals are recorded onchain and stored on IPFS for permanent, transparent reference.
- Transparency — Governance activity, including voting history and delegate participation, is publicly visible in the Aragon UI.
Longevity and Evolution
The primary goal of this process is to promote clarity and establish a straightforward yet resilient framework for conducting Cryptex governance. As conditions evolve, it may be necessary to adjust process parameters. Any such updates must be introduced through a formal CIP proposal and follow the procedures in place at the time the proposal is created.
Governance Platform
Cryptex governance is powered by Aragon, one of the most trusted and battle-tested onchain governance providers in DeFi. Founded in 2017, Aragon secures tens of billions of dollars across leading protocols including Lido (stETH), Curve, Morpho, and Taiko — with over eight years of operation and zero security incidents.
All governance, staking (veLocker), and rewards are accessible from a single dedicated page:
Governance Components
1. CTX Holders — The veLocker
Participation in Cryptex governance is powered by the veLocker, where CTX holders lock their tokens to earn vote-escrowed CTX (veCTX). veCTX is the source of both voting power and protocol rewards.
How It Works
- Stake CTX → Earn veCTX: Locking CTX into the veLocker grants veCTX, which determines your governance weight within the DAO.
- Voting power multiplier: The longer and more committed your stake, the more weight you carry — up to a 4x multiplier on both voting power and rewards. Maximum multiplier is reached after 98 days.
- Minimum lock period: CTX must be staked for at least 30 days before the exit process can begin.
- Exit / Withdrawal: When exiting, there is a 7-day waiting period. Voting power is removed the moment you queue your exit; tokens become available for withdrawal after 7 days.
Important: Staking and delegation must be completed before the first proposal is created. The delegate snapshot is taken at proposal creation time. Late stakers or delegators will not be counted for that proposal’s vote.
2. Delegates
After staking, CTX holders must delegate their veCTX to activate it for governance — either to themselves or to a Delegate (Keeper) of their choosing.
- Delegate profiles are automatically populated with ENS names and avatars in the Aragon UI.
- Governance activity — voting history and proposals created — is visible on each delegate’s profile.
- CTX holders who are unable to participate directly may delegate their voting and proposal rights to a Delegate of their choice, who will represent them in the governance process.
Governance Proposal Types
The Cryptex DAO may periodically submit proposals to decide on matters related to the future of the Cryptex protocol. There are four primary types of proposals:
- Treasury Transfers
- Changes to Governance Parameters
- R&D for New Products
- Protocol Upgrades
Governance Processes
Cryptex governance on Aragon runs two separate processes, each designed for a different type of decision.
Process 1 — Keeper Governance (CIP)
This is the primary governance path for general and significant decisions affecting the DAO, including treasury transfers, protocol upgrades, governance parameter changes, and new product R&D.
| Detail | Value |
|---|---|
| Process Key | CIP |
| Who can create proposals | Any veCTX staker (and Core Team Safe members) |
| How it passes | Requires an affirmative vote outcome by the end of the vote window |
| Vote duration | 5 days |
| Support threshold | 50% |
| Quorum | 3% of total veCTX supply (500,000 veCTX) |
Process 2 — Fast Track (CIPX)
This is a streamlined, optimistic path for routine or time-sensitive actions, such as core team funding and protocol upgrades. Proposals pass by default unless a veto succeeds during the review window.
| Detail | Value |
|---|---|
| Process Key | CIPX |
| Who can create proposals | Core Team multisig only |
| How it passes | Passes by default unless veto succeeds during the review window |
| Review (veto) window | 3 days |
| Veto threshold | 50% support + 1.5% quorum (250,000 veCTX) to succeed |
Proposal Drafting and Creation
Community Review Phase (Forum)
Prior to submitting a proposal onchain, authors are encouraged to publish a draft on the Cryptex forum for community review and discussion. A proposal must pass a temperature check, requiring at least three (3) endorsements from Verified Delegates on the Cryptex forum in order to be considered ready for the onchain voting phase.
Voting Cycles
Voting on proposals that have passed the temperature check takes place on either the first or third week of each month. Proposal drafts must therefore be published on the forum and receive their endorsements at any point during the previous month in order to be included in the next available voting cycle.
This mechanism serves two purposes: it keeps the number of active proposals manageable and predictable, and it gives delegates and token holders sufficient time to review proposals and prepare their votes in advance — improving participation across the board.
Onchain Proposal Creation (Aragon UI)
Once community consensus is reached, any eligible veCTX staker (or Core Team Safe member) may create a proposal directly through the Aragon UI using the guided proposal wizard:
- Title, summary & body: Set the proposal title, write a summary, and provide full body content with supporting links.
- IPFS storage: All proposal metadata is stored fully on IPFS for transparency and permanence.
- Onchain actions: Attach onchain actions using the action builder — build and bundle actions through the UI, import JSON files, or connect external applications via WalletConnect.
- Simulation: Simulate actions using Tenderly before submitting to verify everything works as intended.
Voting Phase
CIP — Keeper Governance Voting
Once a CIP proposal is created onchain, the voting period begins immediately and runs for five (5) days. Voting is conducted fully onchain through the Aragon UI.
| Parameter | Description | Value |
|---|---|---|
| Vote Duration | Length of the active voting window | 5 days |
| Standard Quorum | % of total veCTX supply that must participate | 3% (500,000 veCTX) |
| Support Threshold | Proportion of votes cast in favor required for approval | Simple majority (>50%) |
| Voting Approval | Votes For minus Votes Against | Must result in a positive number |
CIPX — Fast Track Veto Window
CIPX proposals are submitted by the Core Team multisig and enter a three (3)-day review window. The proposal passes automatically unless a sufficient veto is mounted during that period.
| Parameter | Description | Value |
|---|---|---|
| Review Window | Duration during which veCTX stakers may veto the proposal | 3 days |
| Veto Quorum | Minimum veCTX participation required for a veto to be valid | 1.5% (250,000 veCTX) |
| Veto Support Threshold | Proportion of veto votes needed to block the proposal | 50% |
Voting Guidance
The Governance Team will assist Delegates and CTX holders as needed to ensure they can complete the voting process. All voting takes place through the Aragon UI.
Execution Phase
Upon conclusion of the voting or review window, one of the following outcomes applies:
Onchain Execution (CIP / CIPX)
Approved proposals with attached onchain actions are executed automatically through the Aragon DAO smart contracts. No manual intervention is required.
Offchain Execution
Proposals that require offchain implementation (such as operational or strategic decisions) are implemented by the relevant stakeholders in accordance with the outcome of the vote.
If a CIP proposal fails to meet the approval threshold or quorum, it does not proceed and no action is taken. If a CIPX proposal’s veto threshold is met, the proposal is blocked and does not execute.
Governance Rewards
Rewards are claimed directly within the Aragon UI from a dedicated Rewards tab.
How Rewards Are Calculated
- Rewards are computed offchain and distributed via a Merkle proof-based claim mechanism.
- Reward amount depends on your veCTX voting power — higher commitment yields a higher multiplier and more rewards.
- Rewards are also tied to whether your delegate participated in Keeper Governance (CIP) votes. YES, NO, and ABSTAIN votes all count toward rewards.
- Fast Track (CIPX) veto votes do not count toward rewards, intentionally, to avoid incentivizing veto behavior.
- If there are no proposals in a given period, all participants receive full rewards for that period automatically.
Claiming Rewards
Rewards are claimed by signing an onchain transaction from the Rewards tab in the Aragon UI — simple and self-custodial. No third-party interaction is required.
Governance Parameters Summary
| Parameter | Description | CIP Value | CIPX Value |
|---|---|---|---|
| Vote / Review Duration | Length of active window | 5 days | 3 days |
| Quorum | Min. veCTX required to participate | 3% / 500k veCTX | 1.5% / 250k veCTX |
| Support Threshold | Votes required for approval / veto | >50% | >50% (veto) |
| Who Creates | Eligible proposal creators | Any veCTX staker | Core Team multisig |
| Execution | How approved proposals are enacted | Onchain / Offchain | Onchain (auto) |
All parameters above may be updated through a formal CIP proposal following the governance procedures described in this Constitution.
Appendix A — Cryptex Provider Accountability Standard (CPAS)
Purpose & Scope
The Cryptex Provider Accountability Standard (CPAS) establishes a straightforward, consistent reporting framework for all entities that receive funding from or operate on behalf of the Cryptex DAO — referred to throughout this section as Service Providers.
The CPAS is not designed to create bureaucratic overhead. Its purpose is simple: to ensure that the DAO, its token holders, and delegates always have timely, accurate, and actionable information about how DAO resources are being used and whether service commitments are being met. All reporting under the CPAS is public and submitted to the Cryptex forum.
Who Is a Service Provider?
A Service Provider is any individual, team, legal entity, or onchain organization that meets one or more of the following criteria:
- Receives recurring or milestone-based funding from the Cryptex DAO treasury.
- Operates under a mandate approved by a CIP or CIPX proposal.
- Controls or manages DAO assets, funds, or smart contract permissions on behalf of the DAO.
- Delivers products, services, or infrastructure that the DAO relies upon for its operations or revenue.
The CPAS currently applies to the following recognized Service Providers:
| Service Provider | Role | Primary Focus |
|---|---|---|
| Cryptex Finance LLC | Core Protocol & Operations | Protocol development, product R&D, contributor operations, and ecosystem growth. |
| Cryptex SubDAO | Revenue Generation & Treasury Management | Protocol Owned Liquidity Management and Yield Generation |
New Service Providers may be added to the CPAS scope through a standard CIP proposal. Removal or modification of an existing provider scope also requires a CIP.
Reporting Structure
Each Service Provider is required to submit two types of reports on a recurring basis: a Monthly Update and a Quarterly Review. These are designed to be complementary — the monthly keeps the community consistently informed while the quarterly provides the depth needed to evaluate performance and make strategic decisions.
Monthly Update — Light Reporting
Due by the 7th calendar day of the following month. Published on the Cryptex forum under the Service Provider’s dedicated thread.
| Section | What to Include |
|---|---|
| Work Completed | A concise summary of deliverables, milestones, or activities completed during the month. |
| Upcoming Plans | Key priorities and expected outputs for the next 30 days. |
| KPI Snapshot | A brief status update against the agreed KPIs: on track, at risk, or off track, with a one-line explanation where relevant. |
| Budget vs. Actuals | High-level summary: funds received, funds spent, and current balance. No line-item breakdown required for monthly reports. |
| Risk Flags & Blockers | Any issues, dependencies, or risks that may impact delivery or require DAO input. Leave blank if none. |
Quarterly Review — Deep-Dive Reporting
Due within 14 calendar days of the end of each quarter (Q1: Jan–Mar, Q2: Apr–Jun, Q3: Jul–Sep, Q4: Oct–Dec). Published on the Cryptex forum and presented in a community call where possible.
| Section | What to Include |
|---|---|
| Quarter Summary | Narrative overview of the quarter: what was accomplished, what was not, and why. |
| KPI Performance | Full review of all KPIs for the quarter, with trend data where available and commentary on variances. |
| Financial Report | Detailed budget vs. actuals breakdown: all income received from the DAO, expenditures by category, and ending balance. For the SubDAO: portfolio performance, revenue generated, and fund allocation. |
| Treasury / Fund Usage | Account of how DAO treasury funds were deployed or held during the quarter, including any significant transactions or reallocations. |
| Risk Assessment | Material risks identified during the quarter — operational, financial, technical, or external — and the steps taken or planned to address them. |
| Next Quarter Outlook | Forward-looking priorities, planned deliverables, resource requirements, and any governance actions the DAO should anticipate. |
| Governance Requests | Any upcoming CIP or CIPX proposals the provider expects to submit, with context on their purpose and timing. |
Provider-Specific Reporting Guidance
While the reporting structure above applies to all Service Providers, each provider’s KPIs and financial disclosures will reflect the nature of their mandate.
Cryptex Finance LLC
As the core protocol and operations provider, Cryptex Finance LLC’s reporting should focus on protocol health, product development progress, and operational efficiency.
- Protocol metrics: TVL, active users, protocol revenue, and product uptime.
- Development milestones: Features shipped, audits completed, and roadmap progress.
- Operational expenditures: Contributor costs, infrastructure, tooling, and third-party services, reported against the approved budget.
- Ecosystem activity: Partnerships, integrations, and community growth indicators.
Cryptex SubDAO
As the revenue-generating and active liquidity management provider, the SubDAO’s reporting should focus on capital performance, risk posture, and capital deployment.
- Portfolio performance: Returns generated during the period, compared to benchmarks or targets agreed with the DAO.
- Fund allocation: Breakdown of how treasury assets are deployed across strategies, protocols, or positions.
- Revenue report: Total revenue generated and distributed or retained during the period.
- Risk and exposure: Current risk profile of the portfolio, any concentration risks, and liquidity position.
- Realized and unrealized P&L: Clear disclosure of gains, losses, and unrealized positions.
Report Submission & Format
There is no mandatory format for reports. Providers may use the structure they find clearest and most appropriate for their context. However, all reports must:
- Be published publicly on the Cryptex governance forum under the provider’s designated thread.
- Use section headings that correspond to the categories defined in this standard, so reports are easy to navigate.
- Be written in plain language that a typical CTX holder can understand.
- Include all required sections. Sections with nothing to report should be marked “Nothing to report this period” rather than omitted.
The Governance Team may publish a lightweight report template on the forum to assist providers, but use of the template is optional.
Amendments to the CPAS
The CPAS is a living standard. Any aspect of this framework — including reporting cadence, required sections, or provider scope — may be updated through a standard CIP proposal. Changes to the CPAS follow the same governance procedures as any other protocol change.