Governance

Governance power in Helix is derived from the following assets held on Base:

1

HLX

The native governance token.

2

stHLX

HLX staked in the protocols safety module.

3

hHLX

The hToken representation of HLX supplied to the Helix liquidity pool

Each token holder has two distinct governance powers:

Proposal

Determines the ability to submit proposals.

Voting

Used to vote for or against active proposals

These powers can be delegated to another address. Delegation allows token holders to participate in governance indirectly while maintaining custody of their assets. Delegates may be DAOs, individuals, or organizations trusted by the community to vote on their behalf. The Helix governance process follows a structured, on-chain lifecycle:

1

Proposal Creation

A user with sufficient proposal power creates a new proposal by interacting with the Governance contract. Proposals must include the execution logic, which is deployed to the PayloadsController.

2

Voting Delay

A short cooldown period (configured as coolDownBeforeVotingStart) gives participants time to review the proposal before voting begins.

3

Voting Period

During the active voting window (votingDuration), token holders vote by submitting their choice onchain. Votes are tallied in real time, and governance thresholds (such as quorum and vote differential) are enforced automatically.

4

Vote Closure and Validation

Once voting ends, the outcome is finalized. If the proposal meets success conditions, it moves to the queue.

5

Proposal Queuing

Approved proposals are queued in the PayloadsController contract, where they are subject to a timelock. This delay provides an additional layer of transparency and protection against governance abuse.

6

Proposal Execution

After the timelock expires, any address may trigger execution by calling executePayload(). The payload is then routed to the appropriate Executor contract, which performs the specified logic (e.g., updating parameters, listing assets, changing admin roles).