Skip to main content
Central voting, gauge-management, and emissions-routing contract for Ramses. The current implementation is address-based, not NFT-based. Voting power comes from VoteModule.balanceOf(owner), and votes are stored per owner address and per weekly period.

Core Functions

vote

Casts or recasts votes for owner into the next weekly period. The raw weights array is normalized against the owner’s current VoteModule balance, so it does not need to sum to a fixed constant. The call can be made by:
  • owner
  • An approved delegate/admin recognized by VoteModule
  • AccessHub

reset

Clears owner’s votes for the upcoming period.

poke

Recasts the owner’s last vote weights using the owner’s current voting power. This is how balance changes in VoteModule are propagated into the stored next-period vote weights.

distribute

Advances emissions and distributes them to a specific gauge. For CL gauges, this flow also triggers protocol-fee collection from the pool through FeeCollector.

createGauge / createCLGauge

Governance-only gauge creation entrypoints for legacy and concentrated-liquidity pools.

claimIncentives / claimClGaugeRewards / claimRewards

Helpers for collecting fee-distributor incentives and gauge rewards.

Key Concepts

  • Votes are recorded for getPeriod() + 1, not the current period.
  • vote() internally clears prior next-period votes before writing the new allocation.
  • FeeDistributor balances are keyed by owner address, which is why Voter deposits and withdraws vote weight there during vote() and reset().
  • distribute() coordinates both emissions and fee routing, making it one of the central weekly-maintenance flows in the system.
  • Whitelisting, gauge lifecycle changes, reward-validator configuration, and other privileged actions are gated through governance and AccessHub.