Skip to main content
The SaucerSwap decentralized autonomous organization (DAO) governs key aspects of the protocol: reward allocations, liquidity pool creation, tokenomics adjustments, and treasury management. Decisions are made collectively by community members holding SAUCE and xSAUCE.

​
Token-weighted voting

Votes are cast on-chain using the Hedera Consensus Service (HCS). You connect a wallet on the govern page, sign a voting message, and it is submitted to a designated topic ID. SaucerSwap retrieves your historical SAUCE and xSAUCE balances at a specified timestamp via the Hedera Mirror Node. You may vote multiple times, but only your final vote counts. Your voting power is your SAUCE balance plus your xSAUCE balance multiplied by the current SAUCE-per-xSAUCE conversion rate. Balances held inside liquidity pools are excluded. The conversion rate is the current SAUCE/xSAUCE exchange rate from the Infinity Pool.

​
Proposal lifecycle

Every change follows the same path: an RFC on the governance forum, then two on-chain votes.
1

Request for Comment (RFC)

Anyone can post a proposal idea on the SaucerSwap governance forum — no voting power required. The RFC stays open for discussion for at least 3 days and can be freely revised by the proposer. Nothing is on-chain yet.
2

Proposal vote

A proposer with at least 100k voting power submits the refined proposal on the govern page for a 2-day vote. The vote is multichoice, always includes a “No change” option, and snapshots account balances every minute. Passing requires a 5M voting power quorum and a majority.
3

Election vote

A passing proposal automatically advances to a final 2-day election, typically pitting the winning option against “No change”. Enactment requires a 15M voting power quorum and a majority.
If a proposal or election fails, a 2-week cooldown applies before the same RFC can be resubmitted, unless it undergoes a substantive change (as determined by SaucerSwap Labs). A resubmitted RFC restarts the standard 3-day commentary period.
Unsubstantive (cooldown still applies):
  • Before: creation of AAA/HBAR farm with 1% weight.
  • After: creation of AAA/HBAR farm with 0.75% weight.
Substantive (may resubmit immediately):
  • Before: creation of BBB/HBAR V2 pool; 1% LARI allocation of SAUCE.
  • After: creation of BBB/HBAR and BBB/USDC V2 pools; LARI campaign with 1,000 BBB per epoch split 50:50 across the pools for 5 epochs.

​
Governance scope

The DAO oversees:
  • V1 farm creation and amendment — new yield farms and adjustments to SAUCE and HBAR emissions for existing farms; see farm weights.
  • V2 pool creation — V2 pools are created permissioned by DAO vote to prevent liquidity fragmentation. New-pool proposals can specify both the swap fee tier and the split between LPs and BrewSaucer. The standard split is 5/6 to LPs and 1/6 to BrewSaucer; the DAO governs this setting for each pool. When enabled, the protocol share is 1/N, where N is an integer from 4 to 10 (6 is the standard setting).
  • LARI campaign creation and amendment — each proposal specifies campaign duration and token allocations per epoch; see LARI weights.
  • Tokenomics changes — significant changes to SAUCE tokenomics require DAO approval; see SAUCE tokenomics.
  • Treasury management — fee switches, HBAR staking reward allocation within protocol contracts, SAUCE buyback allocations, and management of treasury assets within SaucerSwap and other protocols.
Matters not specified here — particularly broader financial concerns — are managed by SaucerSwap Labs, which oversees the treasury to fund protocol development and DAO-related activities. Meta-governance matters are also controlled by SaucerSwap Labs for the time being.

​
Treasury flows and DAO-controlled contracts

The flows below describe the mechanism; the percentages within each splitter are DAO-adjustable, and per-week amounts vary with emissions and market conditions. For contract-by-contract detail, see Contract deployments; for transaction-level reporting, see DAO reporting.
  • Masterchef emissions (0.0.1077627) — mints SAUCE at the Phase 1 rate. The 5,000 base-reward points allocate 1,200 to V1 farms, 3,500 to LARI, and 300 to the DAO. The additive devcut goes through a separate splitter: 30% to burn and 70% to the existing non-staking recipients.
  • LARI distribution — designated SAUCE accumulates for distribution to eligible V2 liquidity providers at each epoch’s end. Published budgets appear in LARI weights.
  • Unified BrewSaucer — eligible V1/V2 fee-switch revenue, net V3 fees, and WHBAR native-staking rewards fund SAUCE buybacks. Purchased SAUCE is routed 40% to Mothership/xSAUCE, 30% to the Development Fund, 10% to burn, and 20% to the POL + Incentive Reserve.
  • Collection — V1’s protocol share is 1/6 of swap fees. V2 uses 1/6 by default, with the split governed per pool by the DAO. V3 first resolves maker rebates and applicable trader discounts. See contract deployments for collection and routing contracts.
The SAUCE emission reduction and Unified BrewSaucer proposal was ratified in election 6360. Phase 1 updates emissions and revenue routing. The later perpetuals-related allocation remains subject to the proposal’s Phase 2 activation conditions.

​
Proto-governance

Proto-governance — previously conducted in Discord using Planck Epoch Collectible (PEC) NFTs — was replaced by the on-chain token-weighted voting system described above.

​
Next steps

Governance forum

Read live RFCs or start one of your own.

DAO reporting

Transaction-level treasury reports.

Single-sided staking

Stake SAUCE for xSAUCE to increase your voting power over time.

Contract deployments

Verify every governance and treasury contract on HashScan.