SaucerSwap V3 Launch Economics [RFC]

[Larry]

Title: SaucerSwap V3 Launch Economics

Author(s): SaucerSwap Labs

SaucerSwap Voting Interface: TBA

Related Discussions: N/A

Submission Date: May 15, 2026

---

Summary

This proposal establishes the launch economic framework for SaucerSwap V3 and updates protocol fee routing so that each source of value is routed according to the part of the protocol it supports.

V3 introduces a central limit order book with market-level maker/taker fees, maker rebates, xSAUCE fee discounts, and net-fee routing through BrewSaucer. Because V3 has a different incentive model than V1 and V2 AMMs, this proposal separates V1/V2-aligned flows from V3 net fees rather than forcing all sources through one blended routing framework.

Under the proposed structure, V1/V2 fee-switch flows and HBAR native staking rewards route primarily toward xSAUCE (i.e., SAUCE staking), burn, and V1/V2 liquidity incentives. V3 net fees route primarily toward xSAUCE, burn, and protocol development, reflecting that V3 liquidity incentives are funded directly through taker fees via maker rebates rather than through SAUCE emissions.

Source	xSAUCE	Development Fund	Burn	POL + Incentive Reserve
V1/V2 fee-switch flow + HBAR native staking rewards	50%	10%	10%	30%
V3 net fees	30%	60%	10%	0%
MasterChef devcut	Direct SAUCE allocation to xSAUCE staking pool / Mothership	-	-	-

Abstract

This proposal asks the DAO to approve five initial V3 markets, a two-tier maker/taker fee schedule, maker rebate safety clamps, xSAUCE fee discount tiers, and source-specific fee routing for V1/V2-aligned flows and V3 net fees.

The proposed initial V3 fee schedule is intentionally simple: non-stable markets are set at 12 bps taker / -0.20 bps maker, while stable-stable markets are set at 6 bps taker / -0.05 bps maker. Maker rebates are capped as a percentage of effective taker fees collected after xSAUCE discounts: 25% on non-stable markets and 10% on stable-stable markets.

V3 net protocol fees are calculated as taker fees collected minus maker rebates paid. Those net fees are converted into SAUCE through BrewSaucer and routed according to the V3-specific allocation framework. V1/V2 fee-switch flows and HBAR native staking rewards remain BrewSaucer-routed but follow a separate AMM-aligned allocation framework. The MasterChef devcut remains a direct xSAUCE staking allocation rather than a BrewSaucer-routed flow.

Current state and what changes

The current fee-routing framework is organized around the existing AMM stack. This proposal keeps the existing mechanisms recognizable, but makes routing source-specific so that each source of value supports the system it is economically closest to.

Component	Current treatment	Proposed treatment
V1/V2 fee-switch flows and HBAR native staking rewards	BrewSaucer-routed. Current baseline: 45.5% to xSAUCE, 30% to Development Fund, 24.5% to POL + Incentive Reserve (modeled as 12.25% Asset Expansion and 12.25% HBAR incentives), no burn.	BrewSaucer-routed using AMM-aligned allocation: 50% xSAUCE, 10% Development Fund, 10% burn, 30% POL + Incentive Reserve.
MasterChef devcut	Modeled as a direct xSAUCE staking allocation (30% of total), not as BrewSaucer-routed flow.	Unchanged. Direct xSAUCE staking allocation only.
V3 net fees	No current production routing because V3 has not launched.	BrewSaucer-routed using V3-specific allocation: 30% xSAUCE, 60% Development Fund, 10% burn.

Motivation

Alignment by source

V1/V2 and V3 should not be routed through the same downstream buckets by default. V1 and V2 are AMMs whose liquidity is still supported by MasterChef and LARI incentives. For those sources, the SAUCE recirculation loop is most directly tied to sustaining liquidity incentives and improving AMM market quality, especially post-emissions.

V3 is different. Its native launch incentive is the maker rebate, which is paid only when resting liquidity is filled and is funded directly from taker fees. Because V3 incentives are embedded in the order-book fee model itself, routing V3 net fees into a V1/V2-oriented incentive reserve is less aligned than routing those fees toward xSAUCE utility, supply discipline, and continued development of the V3 stack.

V3 requires ongoing development, not only incentives

The long-run value of V3 depends on continued development of order-book infrastructure: market-maker tooling, API reliability, routing, execution quality, analytics, integrations, and future products such as perpetuals. A higher V3 Development Fund allocation therefore serves as a source-specific reinvestment channel for the infrastructure that makes V3 useful and competitive.

At the same time, this proposal reduces the Development Fund allocation from V1/V2 fee-switch flows and HBAR native staking rewards. Those sources are more directly connected to AMM liquidity sustainment, so the routing is shifted toward xSAUCE, burn, and POL + Incentive Reserve rather than development funding. This keeps V1/V2-generated value closer to the liquidity programs that support V1/V2 volume.

xSAUCE and burn remain protocol-wide

xSAUCE and burn apply cleanly across both source categories. In addition to being a fee-capture token, xSAUCE connects SAUCE to protocol usage by giving traders and market makers fee discounts. Burn provides a predictable supply-discipline mechanism. Both are appropriate for V1/V2-aligned flows and V3 net fees.

Specification & Rationale

1. Initial V3 market slate

This proposal approves the following initial V3 markets. Note that additional V3 markets must be approved through governance before listing.

Market	Category
HBAR-USDC	Non-stable
WETH-USDC	Non-stable
WBTC-USDC	Non-stable
SAUCE-USDC	Non-stable
USDT0-USDC	Stable-stable

2. Launch maker/taker fee schedule

This proposal approves a two-tier launch fee schedule:

Market category	Taker fee	Maker fee	Maker rebate cap
Non-stable markets	12 bps	-0.20 bps	25% of effective taker fees collected
Stable-stable markets	6 bps	-0.05 bps	10% of effective taker fees collected

The non-stable tier is designed to bootstrap liquidity across the core V3 launch book while preserving protocol economics. The stable-stable tier uses lower fees because stable convergence markets are more sensitive to fee drag and should function as efficient conversion rails.

The maker rebate safety clamp is applied after xSAUCE discounts. On the non-stable tier, assuming a 10% weighted-average xSAUCE discount, the protocol collects 10.80 bps of effective taker fees and caps maker rebates at 2.70 bps. The proposed -0.20 bps launch rebate is materially below that cap. On the stable-stable tier, the protocol collects 5.40 bps of effective taker fees and caps maker rebates at 0.54 bps. The proposed -0.05 bps launch rebate is also materially below the cap.

On a weighted basis, the launch market mix implies an 11.73 bps average taker fee and a 10.36 bps weighted-average V3 net fee after a 10% weighted-average xSAUCE discount.

3. xSAUCE fee discount tiers

This proposal approves the following launch xSAUCE discount tiers. The USD equivalents use an xSAUCE price assumption of $0.025 for the fee-tier table.

Tier	xSAUCE threshold	USD equivalent at $0.025	Discount
1	10,000	$250	5%
2	50,000	$1,250	10%
3	250,000	$6,250	15%
4	1,000,000	$25,000	20%
5	5,000,000	$125,000	30%
6	10,000,000	$250,000	40%

The discount percentages preserve the Hyperliquid-style curve while adapting thresholds to SaucerSwap’s smaller current staking base and actual xSAUCE holder distribution. The upper tiers remain scarce without being structurally unreachable.

xSAUCE discounts apply to the market’s baseline fee schedule. If the taker fee is positive, xSAUCE reduces what the taker pays. If the maker fee is positive, xSAUCE reduces what the maker pays. If the maker fee is negative, xSAUCE increases the maker’s rebate, subject to the maker rebate safety clamp.

4. Source-specific routing

This proposal approves source-specific routing for BrewSaucer-routed flows. The MasterChef devcut is not BrewSaucer-routed and remains a direct xSAUCE staking allocation.

Source	xSAUCE	Development Fund	Burn	POL + Incentive Reserve
V1/V2 fee-switch flow + HBAR native staking rewards	50%	10%	10%	30%
V3 net fees	30%	60%	10%	0%
MasterChef devcut	Direct to xSAUCE	-	-	-

5. POL + Incentive Reserve deployment

The POL + Incentive Reserve allocation applies only to V1/V2 fee-switch flows and HBAR native staking rewards. Under this proposal, it is intended to support V1 and V2 liquidity incentives, but should remain a flexible DAO-controlled bucket for broader V1/V2 liquidity support. This includes farm rewards, LARI rewards, HBAR incentive routing, and other liquidity programs the DAO may approve over time.

Use	Share of AMM-aligned BrewSaucer flow	Implementation
SAUCE incentives	15%	Retained as SAUCE and distributed to V1 pools as farm rewards and V2 pools as LARI rewards through the existing incentive systems.
HBAR incentives	15%	Converted to HBAR on a per-epoch basis, then distributed to V1 pools as farm rewards and V2 pools as LARI rewards through the existing incentive systems.
Total POL + Incentive Reserve	30%	All POL + Incentive Reserve funds support V1/V2 liquidity incentives and are additional to current MasterChef SAUCE emissions.

The exact pool-level distribution should follow the DAO-approved farm and LARI incentive weights in effect for each epoch unless governance approves a separate allocation. This keeps the routing framework explicit while preserving the existing governance process for pool-level incentive weights.

Governance-Controlled Parameters

• V3 market creation.

• Market-level maker and taker fee tiers.

• Maker rebate parameters and maker rebate safety clamps.

• xSAUCE fee discount tiers and eligibility thresholds.

• Source-specific BrewSaucer routing percentages for V1/V2-aligned flows, HBAR native staking rewards, and V3 net fees.

• Burn allocation.

• POL + Incentive Reserve deployment rules and pool-level incentive weights.

Model Impact

Figures below are volume-normalized rather than forecast-driven. They do not require voters to accept a specific 2026 or 2027 volume path. They show how the proposed framework behaves per unit of realized routed value or trading activity. Realized outputs will scale with actual volume, source mix, buyback execution, xSAUCE tier uptake, market-maker behavior, and future governance decisions.

Routing impact per $100K of BrewSaucer-routed value

The table below is the cleanest way to read the proposed source-specific routing. It applies to BrewSaucer-routed value after conversion into SAUCE. HBAR native staking rewards are included with V1/V2-aligned flows because they pass through BrewSaucer; the MasterChef devcut is not BrewSaucer-routed and remains a direct xSAUCE staking allocation.

Source	xSAUCE	Development Fund	Burn	POL + Incentive Reserve
V1/V2 fee-switch + HBAR native staking rewards	$50.0K	$10.0K	$10.0K	$30.0K
V3 net fees	$30.0K	$60.0K	$10.0K	$0
MasterChef devcut	Direct to xSAUCE	-	-	-

For V1/V2-aligned flows, the 30% POL + Incentive Reserve allocation is intended entirely for V1/V2 liquidity incentives: 15% retained as SAUCE incentives and 15% converted to HBAR incentives. The exact pool-level distribution follows DAO-approved farm and LARI weights for each epoch unless governance approves a separate allocation.

Volume-normalized fee impact per $100M of realized trading volume

For trading-fee-driven sources, the same mechanics can be expressed per $100M of realized volume. V1 uses a 30 bps gross swap fee with a 1/6 protocol cut (5.00 bps). V2 uses the current 16.505 bps implied effective fee rate with the same 1/6 protocol cut (about 2.75 bps). V3 uses the modeled 10.36 bps weighted-average net fee after the 10% weighted-average xSAUCE discount and maker rebates.

Source	Routed value per $100M volume	xSAUCE	Development Fund	Burn	POL + Incentive Reserve
V1 volume	$50.0K	$25.0K	$5.0K	$5.0K	$15.0K
V2 volume	$27.5K	$13.8K	$2.8K	$2.8K	$8.3K
V3 volume	$103.6K	$31.1K	$62.2K	$10.4K	$0

xSAUCE APR sensitivity

The xSAUCE APR impact scales directly with the amount routed to staking. Assuming a $10.0M xSAUCE staking TVL, each $100K of annualized xSAUCE rewards contributes approximately 1.00% APR. The direct MasterChef devcut remains additive to this staking stream and does not pass through BrewSaucer.

Annualized xSAUCE allocation	Implied APR at $10.0M xSAUCE TVL
$100K	1.00%
$250K	2.50%
$500K	5.00%
$1.0M	10.00%

V1/V2 liquidity incentive APR sensitivity

The POL + Incentive Reserve allocation affects the Reward APR component only. Fee APR, Stader APR, xSAUCE APR, and other APR components are not changed by this routing proposal. The sensitivity below shows the Reward APR impact if an annualized reward allocation is directed to a given pool group.

Annualized reward allocation	V1 active farm pools ($6.07M liquidity base)	V2 LARI-rewarded pools ($24.28M liquidity base)
$100K	+1.65% Reward APR	+0.41% Reward APR
$250K	+4.12% Reward APR	+1.03% Reward APR
$500K	+8.24% Reward APR	+2.06% Reward APR

Actual pool-level APR changes will depend on the DAO-approved incentive weights in effect for each epoch and on the liquidity base at the time rewards are distributed.

Burn output sensitivity

The burn is modeled at 10% of BrewSaucer-routed value from V1/V2 fee-switch flows, HBAR native staking rewards, and V3 net fees. The direct MasterChef devcut is not part of burn routing. The table below uses the model burn conversion assumption of $0.020 per SAUCE. Annual mint is based on 2.3254 SAUCE/sec (emissions plus devcut), equal to approximately 73.3M SAUCE per year, and circulating supply is assumed at 898M SAUCE as of May 15, 2026.

Annualized burn value	SAUCE burned at $0.020	Offset of annual mint	Inflation reduction vs 898M supply	Net deflationary?
$100K	5.0M	6.8%	0.56 pp	No
$500K	25.0M	34.1%	2.78 pp	No
$1.0M	50.0M	68.2%	5.57 pp	No
>$1.47M	>73.3M	>100.0%	>8.17 pp	Yes

Net deflationary status is reached only if SAUCE burned exceeds SAUCE minted during the relevant period. The burn therefore acts first as an issuance offset and supply-discipline mechanism; whether it becomes net deflationary depends on realized routed value and SAUCE price at the time of burn execution.

Pros

• Establishes clear launch parameters for V3 rather than leaving order-book economics undefined.

• Uses a simple two-tier fee model that is easy to implement, explain, and govern.

• Introduces maker rebates to support early order-book liquidity while keeping rebates tied to actual fills.

• Applies safety clamps to prevent maker rebates from overwhelming collected taker fees.

• Gives xSAUCE direct protocol-level utility through trading fee discounts and rebate boosts.

• Uses source-specific routing so V1/V2-aligned flows support AMM liquidity while V3 net fees support V3 development, xSAUCE, and burn.

• Adds a predictable burn allocation across BrewSaucer-routed sources.

• Keeps V1/V2 liquidity incentives funded through a clear SAUCE/HBAR reward path in addition to current MasterChef SAUCE emissions.

• Creates a durable development funding path for V3 infrastructure, market-maker tooling, API improvements, and future products such as perpetuals.

Cons

• Source-specific routing is more complex than a single blended allocation framework.

• V3 net fees do not directly fund the POL + Incentive Reserve under this structure, so AMM incentive support depends primarily on V1/V2 fee-switch flows and HBAR native staking rewards.

• The V3 Development Fund allocation will require periodic governance review to ensure it remains aligned with product execution and protocol needs.

• Maker rebates may attract low-quality or self-referential activity if monitoring and anti-abuse controls are insufficient.

• The proposed non-stable taker fee may be too high for some markets if market quality or routing depth does not materialize quickly.

• The xSAUCE tier schedule may require adjustment if participation concentrates too quickly or if top-tier eligibility remains too thin.

• Market-level assumptions are based on projections and should be reassessed once real V3 trading data is available.

Voting Options

YES - Approve

Approve the initial V3 market slate, governance-controlled V3 market creation, launch maker/taker fee schedule, maker rebate clamps, xSAUCE discount tiers, and source-specific fee routing. V1/V2 fee-switch flows and HBAR native staking rewards will route 50% to xSAUCE, 10% to Development Fund, 10% to burn, and 30% to POL + Incentive Reserve. V3 net fees will route 30% to xSAUCE, 60% to Development Fund, and 10% to burn. MasterChef devcut remains a direct xSAUCE staking allocation.

NO - Reject

Reject the proposed V3 launch tokenomics framework. Existing V1/V2 routing remains unchanged, and V3 launch market parameters, xSAUCE discount tiers, source-specific routing, burn allocation, and V3 fee routing would require a new governance proposal.

ABSTAIN

Abstain from voting on this proposal.

Appendix A - Initial V3 Market Matrix

Market	Taker	Maker	Net fee after 10% avg xSAUCE discount
HBAR-USDC	12 bps	-0.20 bps	10.60 bps
WETH-USDC	12 bps	-0.20 bps	10.60 bps
WBTC-USDC	12 bps	-0.20 bps	10.60 bps
SAUCE-USDC	12 bps	-0.20 bps	10.60 bps
USDT0-USDC	6 bps	-0.05 bps	5.35 bps

Appendix B - xSAUCE Discount Tiers

Tier	xSAUCE threshold	USD equivalent at $0.025	Discount
1	10,000	$250	5%
2	50,000	$1,250	10%
3	250,000	$6,250	15%
4	1,000,000	$25,000	20%
5	5,000,000	$125,000	30%
6	10,000,000	$250,000	40%

Appendix C - Routing Summary

Source	Bucket	Share
V1/V2 fee-switch + HBAR native staking rewards	xSAUCE	50%
V1/V2 fee-switch + HBAR native staking rewards	Development Fund	10%
V1/V2 fee-switch + HBAR native staking rewards	Burn	10%
V1/V2 fee-switch + HBAR native staking rewards	POL + Incentive Reserve	30%
V3 net fees	xSAUCE	30%
V3 net fees	Development Fund	60%
V3 net fees	Burn	10%
MasterChef devcut	Direct xSAUCE staking allocation	Unchanged

[yo_click]

Strong proposal overall. Thank you for the transparency and thoughtful design.

The maker rebates, xSAUCE tiered discounts, and 10% burn are all excellent. One small suggestion on the V3 net fee routing: increasing the xSAUCE staker allocation from 30% to 40-45% would further strengthen long-term holder alignment and accelerate the buyback flywheel.

With V3 expected to drive the majority of future volume, a higher direct reward to stakers (who have been here since V1) would make the tokenomics even more attractive for the exact users providing liquidity via limit orders. The Dev Fund would still receive a healthy 45-50%, which feels more than sufficient for perps and future development.

Just wanted to float this as a potential improvement.

Looking forward to June mainnet!

[Wojak]

First, real appreciation to the Labs team for the depth and transparency of this proposal. The level of detail — source-by-source routing logic, sensitivity tables, modeled emissions offset trajectory, explicit ratios and worked examples — sets a high bar for governance proposals on Hedera and gives the community a real foundation to engage with. Several pieces of this are genuinely strong work:

• The xSAUCE fee modifier design is excellent. Tying staking directly to trader unit economics gives SAUCE protocol-level utility it has never had before. This is exactly the kind of mechanism that turns governance tokens into productive assets.

• Maker rebates funded directly from taker fees (rather than from emissions or a separate incentive reserve) is the right architectural decision. It ties incentives to real trading activity and avoids the wash-volume trap that has hurt other CLOB launches.

• The universal 10% burn across all BrewSaucer-routed flows** is a meaningful upgrade from the current baseline and a good long-term supply-discipline signal.

• Decoupling V3 incentives from the V1/V2 reserve** prevents V3 from cannibalizing AMM liquidity programs as it ramps.

• The modeled path to fee-driven sustainment** (~94.7% emissions coverage by 2027 in the baseline case) is a credible roadmap to reducing inflation dependency.

The overall framework is the right shape. My feedback is on the specific V3 net fee allocation (30% xSAUCE / 60% Development Fund / 10% Burn), where I think some targeted modifications would significantly strengthen the proposal’s holder alignment without compromising Labs’ ability to execute on V3. I want to walk through the reasoning and propose specific amendments.

The core concern is how Dev Fund SAUCE flows through the system.

One piece of the mechanics I’d like the proposal to address explicitly is what happens to Dev Fund SAUCE after BrewSaucer routes it. V3 net fees come into BrewSaucer in a mix of tokens (HBAR, USDC, WETH, WBTC, SAUCE) and get converted to SAUCE on the open market — that’s the buyback leg. The 60% Dev Fund allocation then receives that bought-back SAUCE. But Labs has real-world operating expenses — engineering salaries, infrastructure costs, audit firms, legal, market-maker partnerships — supposedly that can’t be paid in SAUCE? So the realistic flow is: SAUCE bought on open market → transferred to Dev Fund → sold back to market for USDC/HBAR → converted to fiat for opex, is that correct? The buyback pressure and the sell pressure largely offset each other in this case and so would provide no real net positive effect for the $SAUCE token. I think there needs to be more detail provided here for the proposed plan for the $SAUCE from the Dev Cut. V2 dev cut $SAUCE has seen a large amount of sell pressure negatively impacting the chart, and so id like to see V3 avoid this.

In practice, this means only ~40% of V3 net fees (the 30% xSAUCE share that stays in the staking contract + the 10% burn) produce durable holder value. The other 60% is a recycling loop. As V3 volume scales, the sell pressure suppoaedly scales proportionally with the buyback pressure.

This isn’t a criticism of Labs needing funding — V3 is a major build and the team deserves to be well-resourced. It’s a question of how much of V3’s success accrues to holders vs. flows through to operational expenses, and whether the proportions can shift as V3 matures and the launch-phase capital intensity decreases.

The Hyperliquid benchmark:

The proposal positions V3 explicitly against Hyperliquid and dYdX, so it’s worth looking at how Hyperliquid handles this same question — because it’s the clearest case study in DeFi of a CLOB DEX whose token has become a top-tier asset which has helped the trading platform become the market leader given the $HYPE token plays a material role in the platform mechanics.

• 97–99% of trading fees fund the Assistance Fund, which buys HYPE on the open market.

• HYPE held by the Assistance Fund is permanently burned (formalized by validator vote in December 2025).

• 100% of HIP-1 spot listing auction fees → HYPE buyback.

• 99% of HLP fees → Assistance Fund.

• The HYPE-denominated portion of HYPE-USDC spot fees is burned directly.

• The Hyperliquid Labs team is self-funded — no VC, no team fee allocation, no insider cut.

Result: HYPE accrues roughly $65M/month in holder-aligned value, the Assistance Fund has accumulated over $1B+ in HYPE, and the token has been one of the strongest performers in the sector.

I’m not suggesting SaucerSwap replicate Hyperliquid’s exact model — the funding histories are different and Labs realistically needs operating revenue from the protocol. But the gap between “~99% to holders/burn” - $HYPE and “40% to holders/burn” - $SAUCE is large, and worth narrowing meaningfully if $SAUCE is going to compete at the tier the proposal is targeting. The competitive benchmark Labs has chosen is itself a strong argument for more holder-aligned routing.

Proposed amendment: milestone-gated step-down

Rather than a flat allocation, I’d propose a phased schedule that gives Labs strong launch-phase funding while committing to a glide path toward holder alignment as V3 matures:

| Phase | Trigger | Dev Fund | xSAUCE | Burn | POL + Incentive Reserve |

Launch | V3 mainnet live, months 0–12 | 30% | 55% | 10% | 5% |

Phase 2 | V3 security audit published + perps mainnet live | 10% | 70% | 15% | 5% |

Steady state | $5B cumulative V3 volume OR 24 months post-launch, whichever first | 5% | 75% | 15% | 5% |

A few design notes:

Launch phase still routes 30% to the Dev Fund. This is a very substantial funding stream during the most capital-intensive period — audits, market-maker onboarding, API buildout, perps R&D.

Phase transitions are gated on objective milestones, not calendar dates. This protects against the schedule outrunning execution and gives Labs control over when transitions occur by tying them to deliverables.

Steady-state 5% Dev Fund is still meaningful operating revenue at large platform volumes. At the proposal’s modeled volume scenarios, this remains a multi-hundred-thousand-dollar-per-year stream, and Labs continues to receive MasterChef devcut as a separate revenue source.

5% to POL + Incentive Reserve at all phases preserves DAO optionality for liquidity programs and protocol-owned liquidity that maker rebates alone can’t fund.

Burn scales to 15% at steady state, which combined with the higher xSAUCE share crosses the ~$1.47M annualized burn threshold from the proposal’s own sensitivity table — making SAUCE meaningfully deflationary against MasterChef emissions, not just offset.

This structure gives Labs everything it needs at launch while signaling clearly to the market that SaucerSwap’s tokenomics will mature toward holder alignment as V3 succeeds. That signal itself is valuable — it’s the kind of commitment that attracts long-term xSAUCE stakers and gives the token a thesis beyond near-term yield. Ultimately i think trying to get as close as possible to the $HYPE model will yield the best result for the platform as well as native token holders - this is something that seriously needs to be considered.

Additional asks

Development Fund treasury policy. Even setting aside the allocation size, the proposal is silent on how Labs converts Dev Fund SAUCE to fiat. Mature DAO treasuries (Uniswap, Arbitrum, Optimism) all publish explicit treasury policies because opaque sell behavior creates uncertainty that gets priced into the token. I’d ask the proposal specify:

- A maximum daily/weekly sell rate as a percentage of trailing 7-day average SAUCE volume (e.g., 5% of ADV per 24-hour window).

- A preference for OTC sales over open-market sales above a defined size threshold.

- A quarterly transparency report disclosing Dev Fund inflows, outflows, balances, and operational expenditures.

- A minimum hold period on newly received Dev Fund SAUCE before liquidation is permitted.

These are standard practices, would let holders model actual sell pressure, and cost Labs effectively nothing beyond reporting overhead.

Perpetuals scope. The proposal implies perpetuals will inherit the V3 routing framework but doesn’t state this explicitly. Given that perps are likely to become SaucerSwap’s largest revenue source over time (Hyperliquid’s perps generate roughly 10–20x their spot revenue), the DAO needs explicit clarity on whether perps are covered by this RFC or will require a separate proposal. If they’re covered, the milestone-gated step-down becomes especially important; if they’re separate, that should be stated so the community can plan around a future perps RFC.

xSAUCE tier framing. Smaller point, but the discount curve’s upper tiers (5 and 6, requiring $125K–$250K of xSAUCE at modeled prices) are professional market-maker tiers rather than broad retail utility. This mirrors Hyperliquid’s structure and is fine as a market-maker incentive, but the proposal’s messaging could be clearer that most retail stakers will experience a 5–10% discount ceiling. Honest framing here protects against expectations mismatches later.

Summary of requested changes

1. Replace the flat V3 routing with the three-phase milestone-gated schedule above with a fairer fee structure that strengthens the tokenomics of the native $SAUCE and $XSAUCE token which will ultimately drive the success of the platform much like the $HYPE token has done for Hyperliquid.

2. Write the phase transition triggers (audit publication, perps mainnet live, cumulative volume threshold) into the proposal itself.

3. Allocate 5% of V3 net fees to POL + Incentive Reserve across all phases.

4. Add an explicit Development Fund treasury policy: sell-rate cap, OTC preference, transparency reporting, hold periods.

5. Clarify whether perpetuals are governed by this RFC or require a separate proposal.

6. Reframe xSAUCE tier messaging to accurately reflect the retail vs. market-maker split.

None of this should be read as opposition to V3 or to Labs being well-funded — V3 is the most important thing SaucerSwap has built, the team has earned the runway to execute it well, and the overall direction of the proposal is right. The amendments above are about making sure the framework that ships at launch is one SaucerSwap can be proud of in two years, when V3 is mature, perps are live, and SAUCE is being compared head-to-head with HYPE and DYDX on tokenomics quality.

I’d vote YES on a version of this proposal that incorporates the milestone-gated step-down and treasury policy. Happy to discuss any of the specific numbers or triggers — the goal here is to find a structure that works for Labs, for the DAO, and for long-term SAUCE and xSAUCE holders. Thanks again to the team for putting this forward.

[DeFiMike]

Great proposal and appreciate the level of detail in the modeling, this is clearly well thought out.

A couple of observations as someone who recently entered the Hedera ecosystem from other chains and is actively providing liquidity in V2:

On the routing table transparency in the V3 net fees routing breakdown, the $10K burn allocation appears to be missing from the dollar figures in the per $100K table (showing only $30K xSAUCE + $60K Development Fund = $90K). Minor presentation point but worth clarifying for community members reading the numbers.

On investor return alignment looking at the volume normalized table, V3 generates significantly more routed value per $100M than V1 or V2, which is great for the protocol. However from a liquidity provider and token holder perspective, 60% of that going to the Development Fund means V3 actually returns less proportionally to the community than V1 and V2 do. For a protocol asking LPs to migrate toward V3 mechanics, is there a plan to revisit that split once V3 infrastructure costs stabilize post launch?

On the xSAUCE discount tiers the jump from Tier 1 ($250) to Tier 2 ($1,250) is a 5x capital increase for only 5% additional discount. For mid level participants trying to build meaningful positions, is there consideration for an intermediate tier in that range?

Looking forward to seeing V3 go live in June.

DeFi Mike

[Larry]

Appreciate the detailed writeups, @DeFiMike @Wojak @yo_click. I think you touched on several fair points.

First, the V3 Development Fund share is meant to fund V3 through protocol economics rather than adding a separate interface fee on the trade page. V3 will require ongoing work across infrastructure, APIs, market-maker support, analytics, integrations, and future products like perpetuals. We arrived at the 60% share through modeling the cost of this work.

It’s also worth noting that, because the V1/V2 Development Fund share is being reduced from 30% to 10%, the initial effect is still a net increase in fees flowing to xSAUCE, burn, and POL + Incentive Reserve, and a net decrease in fees flowing to development. That changes only if V3 proves successful and reaches significant adoption.

That said, I hear the point on xSAUCE alignment. Our current thinking is to keep the launch split in place, but add a required review once we have live V3 data. At that point, the DAO can make a more informed decision on whether to increase the V3 xSAUCE allocation while preserving enough runway for continued V3 development. I agree a hard review gate is a good addition, and we can tighten the proposal language around that.

I’d also clarify that perpetuals should receive their own governance treatment rather than being silently covered by this RFC.

On POL + Incentive Reserve, I don’t think that allocation fits V3 as cleanly as it fits V1/V2. The AMMs rely on token emissions for liquidity incentives, so routing part of those fees back into incentives creates a closed loop. V3 incentives are already built into the CLOB through maker rebates funded from taker fees.

Finally, on the $100K table: the V3 row should read as $30K to xSAUCE, $60K to the Development Fund, and $10K to burn. If that wasn’t obvious, I’ll tighten the formatting.

[yo_click]

@Larry I appreciate the clarification on the Development Fund’s role and the modeling behind the 60% allocation. I’m glad to see the hard review gate after live V3 data, that’s a smart addition and gives the DAO a clear path to increase the V3 xSAUCE allocation once we have real volume numbers.

Looking forward to V3 and reading the perpetuals RFC hopefully sooner than later!

[DeFiMike]

@Larry Thanks for the detailed response Larry and for addressing the formatting on the $100K table, that clears up the confusion.

The hard review gate once live V3 data is available makes sense and feels like the right approach. Making that call with real numbers rather than projections is the responsible way to handle it.

Appreciate the clarification on perpetuals needing their own governance treatment as well. That was one of the things that felt a bit open ended in the original proposal.

Looking forward to seeing V3 go live in June.