Governance

How Creek Governance Works

Creek Protocol uses CREEK tokens for decentralized governance, giving token holders the right to propose and vote on protocol changes. The system balances community participation with protocol security through a structured proposal process and integrated insurance fund staking.

All governance contracts are open-source and permissively licensed, allowing for community review and contribution to the protocol's development.

Proposal Lifecycle

Every proposal follows a standardized timeline designed to ensure thorough review and prevent rushed decisions:

Creation2-day Delay5-day Voting2-day Execution DelayImplementation

During the initial delay period, the community can review and discuss the proposal before voting begins. After voting concludes, a timelock period provides final security before implementation. Successful proposals have a 30-day execution window before they expire.

Staking for Governance Rights

To participate in governance, you must stake CREEK tokens into the Protocol Insurance Fund. This dual-purpose mechanism establishes your voting power while strengthening the protocol's financial backstop against market volatility.

Staking functions:

  • stakeToInsuranceFund(delegate_address) - Stakes all approved tokens

  • stakeAmountToInsuranceFund(delegate_address, amount) - Stakes specific amount

  • unstakeFromInsuranceFund(amount) - Withdraws staked tokens

The delegate_address can be your own address or another user's address if you want to delegate voting power. Unstaking during active votes maintains your voting power until voting concludes, with a standard 3-day cooldown period for withdrawals.

Staking benefits and risks: You earn base yield from 15% of protocol revenue plus additional yield from liquidation fees. Your voting power equals your staked amount. However, during extreme market conditions, up to 20% of staked value may be used for system stability, with losses distributed proportionally among stakers. Recovery rights apply to any future system surplus.

Creating Proposals

Eligibility requirements:

  • Minimum 50,000 CREEK tokens staked in Insurance Fund

  • Tokens staked for at least 3 days prior to submission

Proposal types can address parameter modifications, protocol upgrades, treasury utilization, external integrations, or emergency market responses.

Submission process: Use propose(actions) to submit executable contract calls, then describe(proposal_id, description) to provide comprehensive details including rationale and expected impact. For convenience, use propose_and_describe(actions, description) as a combined function.

The recommended approach involves drafting proposals on Creek's forum for community feedback, refining based on input, then submitting the final on-chain proposal with detailed documentation.

Voting Process

Creek implements simple majority voting with quorum requirements. Each staked CREEK token equals one vote, which can be cast "For" or "Against" using vote(proposal_id, for_vote) where the boolean parameter indicates your choice.

Voting weight calculation uses a 2-day smoothing period to prevent flash loan attacks: voting_weight = average(staked_tokens) over the smoothing period. You can check real-time voting metrics with get_proposal_stats(proposal_id).

Execution requirements:

  • Minimum 2,000,000 CREEK token quorum (2% of supply)

  • Simple majority (>50%) "For" votes

  • Completion of execution delay period

  • Execution within the 30-day window

Any address can trigger execution using execute(proposal_id, actions) once conditions are met, with actions matching the original proposal specification.

Governance Parameters

The system operates with these fixed parameters:

  • Proposal threshold: 50,000 CREEK tokens

  • Voting start delay: 2 days

  • Voting period: 5 days

  • Vote weight smoothing: 2 days

  • Quorum requirement: 2,000,000 CREEK tokens

  • Execution delay: 2 days

  • Execution window: 30 days

Proposers can cancel their proposals during the delay period using cancel(proposal_id) if errors are identified or circumstances change.

Emergency Governance

Creek incorporates tiered emergency response for critical security issues or extreme market events.

Guardian Multisig operates as a 5-of-7 multisig that can enact temporary emergency measures including pausing protocol functions, adjusting critical risk parameters, and implementing emergency oracle fallbacks. These measures are limited to 72 hours before requiring regular governance confirmation.

Recovery Mode activates automatically when system-wide collateralization falls below 150%, gold price drops more than 20% in 24 hours, or multiple oracle failures are detected. During Recovery Mode, minting gets restricted to higher collateralization ratios and liquidation thresholds are adjusted. Regular governance is required to exit Recovery Mode.

Decentralization Roadmap

Creek follows progressive decentralization through three phases:

Early Stage maintains team control over core protocol parameters to ensure security and optimize initial market conditions. Post-TGE Phase transfers governance authority to CREEK token holders for all protocol decisions. Full Decentralization achieves complete protocol sovereignty by the DAO with mature governance processes.

This governance structure ensures Creek can launch securely under experienced team guidance, then transition to community control once token distribution creates a robust governance foundation. The integrated Insurance Fund staking model aligns governance participants with protocol security while providing additional yield opportunities.

Last updated

Was this helpful?