What governance controls
The control mode decides who can update the token’s perp strategy. They can:
- activate or deactivate the requested strategy;
- replace the selected perpetual markets;
- change long and short directions;
- change equity allocations and reserve;
- change requested leverage within market limits.
These changes apply to the strategy only. The token, trading pair, vault, custody account, tax split, and profit split stay the same.
Fixed mode
In Fixed mode, the deployer chooses the first strategy and the vault follows the managed Fixed-mode update rules.
The creator and tokenholders do not manage the strategy in this mode.
Profile changes still pass normal portfolio validation and the global one-hour strategy-change cooldown.
Delegated mode
In Delegated mode, the creator chooses a manager at launch. That manager can update the strategy and transfer the role to another address.
The manager role can be transferred or recovered through its defined management paths.
A delegated manager controls strategy instructions only. It is not the owner of the strategy vault or Lighter custody account and cannot select an arbitrary principal-withdrawal recipient through the standard flow.
DAO mode
In DAO mode, tokenholders stake the launched token to propose and vote on strategy changes. A change is applied after the proposal passes and someone executes it.
The stake vault is non-transferable: staking creates voting weight, not a freely transferable receipt token. Voting eligibility is based on active stake and checkpointed balances. Stake has no lock period and can be withdrawn, while voting power becomes available from the next block.
Governance rules
- Voting period
- The amount of time support and oppose votes remain open.
- Proposal threshold
- Minimum share of snapshotted active stake required to create a proposal.
- Quorum
- Minimum participating vote weight relative to snapshotted active stake.
- Approval
- Required support share of participating support-plus-oppose votes.
The launch interface supports voting periods from one to fourteen days, proposal thresholds from 0.1% to 10%, quorum from 1% to 50%, and approval above 50% through 100%.
Default launch-form values are a four-day vote, 1% proposal threshold, 10% quorum, and 60% approval.
DAO proposal lifecycle
1. Create proposal
The proposer supplies the token, expected current profile version, requested active state, and complete replacement portfolio. The call must include the exact protocol proposal fee.
The proposal fee is read from protocol configuration, is capped by the contract at 0.01 ETH, and enters separate native-fee accounting in the protocol treasury.
Proposal eligibility is measured at the previous block. The proposer’s checkpointed stake must satisfy the threshold relative to total active stake at that snapshot.
2. Snapshot
The contract records the snapshot block, total active stake, expected profile version, portfolio hash, vote start, vote end, and governance rules. The proposer’s eligible weight is automatically recorded as a support vote.
3. Vote
Eligible stakers vote Support or Oppose while the proposal is active. Weight is the lower of the voter’s checkpointed snapshot weight and current stake. A voter can change their choice during the voting period.
If a voter reduces stake, the stake vault notifies the authority hub and reduces that voter’s active proposal weight when required.
4. Evaluate
After the voting period, a proposal succeeds only when participation reaches quorum and support reaches the approval threshold. A proposal that does not satisfy both rules is defeated.
5. Execute
Anyone can execute a successful proposal after voting and after the global strategy-change cooldown allows another profile update. Execution replaces the active portfolio and increments its version.
Execution is permissionless but not automatic. A successful proposal continues occupying the token’s proposal slot until someone executes it or it becomes stale.
Proposal states
| State | Meaning |
|---|---|
| None | The proposal ID does not exist. |
| Active | The voting period has not ended. |
| Defeated | Voting ended without satisfying quorum and approval. |
| Succeeded | Voting passed and the proposal may be executed. |
| Executed | The proposed portfolio became the active profile. |
| Stale | The proposal was invalidated or its expected profile version no longer matches. |
Profile versions and stale proposals
Every successful profile change increments a version number. Direct changes and DAO proposals include the version they expect to replace. If another change updates the profile first, the old request becomes stale.
DAO mode permits one active proposal slot per token. A valid active proposal blocks another. If its proposed portfolio becomes invalid under protocol configuration, the stale proposal can be invalidated and the slot reused.
Version checks prevent a proposal written for one strategy state from overwriting a newer state without being reconsidered.
Each proposal saves its voting rules when it is created. Later rule changes apply to future proposals rather than changing an active vote.
Strategy-change cooldown
Every applied profile change records its execution time. Another profile cannot be applied until one hour has passed. The cooldown applies to Fixed, Delegated, and DAO execution.
The cooldown limits rapid strategy replacement. It does not prevent the execution service from placing, cancelling, or reducing orders while following the same active profile.
Staking and withdrawal
DAO participants deposit the launched token into its stake vault. Stake creates checkpointed voting weight. Withdrawing returns the staker’s own deposited token and any supported stake-vault rewards; it does not withdraw strategy principal from the revenue router or Lighter.
Vote weight may be reduced when stake is withdrawn during an active proposal. This prevents a voter from retaining proposal influence after removing the stake that created that influence.
Stake-vault rewards come from dividends received by the pooled vault, not from strategy collateral. If whole-token rewards arrive while no tokens are staked, they remain undistributed until staking resumes; the first subsequent stake can become entitled to that undistributed amount under the contract’s accounting.