Proposal: Orderly Wind-Down of MUX Protocol with Pro-Rata Redemption of POL — and an Alternative Lean-Mode Path

Proposal
1

TL;DR

MUX’s protocol-owned liquidity (POL) is currently worth roughly $10M in blue-chip, redeemable assets (~71% WBTC, plus WETH, stables, sUSDe, AVAX, ARB), while the fully-diluted market value of MCB is ~$6–7M. That’s a structural ~1.5x–2x value gap between what tokenholders own on-chain and what the market is pricing.

Meanwhile, despite the V3 launch and the $1.55M FY24–25 / $1.25M FY25–26 development budgets:

  • TVL has flat-lined at ~$10M (PoL) for nine months (down ~86% from the Feb-2024 peak of ~$74.8M).
  • Daily trading volume is now under ~$1M. Recent fee-implied volume runs at ~$500–720k/day across all chains (vs. an implied ~$13M/day average during FY24–25).
  • Annualized protocol revenue is < $100k. Per DefiLlama, the trailing 30-day revenue runs at $3,896, which annualizes to ~$47k. The trailing 7-day annualizes to ~$39k. Total fees annualize to ~$158k, of which ~30% accrues to the protocol/holders.
  • Forum / governance cadence has slowed materially since October 2025 — no team-authored proposals in ~8 months.

Put differently: the FY25–26 budget cap of $1.25M is roughly 25–30x the protocol’s current annualized revenue. That is not a sustainable ratio under any reasonable interpretation.

This proposal asks the community to formally choose between two paths, with the goal of maximizing realized value for tokenholders and ending uncertainty:

  • Option A (Primary motion): Orderly wind-down + pro-rata redemption of POL to MCB / veMUX holders over a structured 90-day window.
  • Option B (Alternative motion): Lean-mode continuation with a hard-capped, vastly reduced annual budget, conditional KPIs, and an automatic redemption trigger if KPIs are missed.

Both options are intended to be constructive. The contributors who built MUX have shipped real product, the question is no longer about effort, it is about whether continuing to spend POL on operating expenses produces more expected value for tokenholders than returning that POL directly.

1. Why this proposal, why now

I want to be clear up front: this is not an attack on the team. MUX contributors have shipped meaningful work: V3 trading protocol, V3 portfolio pools, neutral mining vault, leveraged mining, 1-click trading, cross-margin, multi-chain aggregator integrations (GMX V1/V2, gTrade). The annual reporting cadence has been transparent, and treasury management has been responsible.

But three things have become hard to ignore:

1. Persistent value-to-treasury inversion. As of today (May 8, 2026), per DefiLlama, total POL/TVL across all chains is approximately:

Chain USD
Arbitrum ~$9.16M
Avalanche ~$0.42M
BSC ~$0.31M
OP Mainnet ~$0.20M
Fantom ~$0.001M
Total ~$10.1M

Asset composition (latest snapshot):

Asset USD % of POL
WBTC / WBTC.e / BTCB ~$7.24M ~71.7%
sUSDC ~$0.89M ~8.8%
WETH ~$0.79M ~7.8%
USDC / aUSDC ~$0.42M ~4.2%
sUSDe ~$0.23M ~2.3%
USDT / USDT0 ~$0.26M ~2.5%
DAI ~$0.10M ~1.0%
WAVAX, WBNB, ARB, OP, WFTM, BUSD, etc. ~$0.18M ~1.7%

This is, by any measure, clean, liquid, redeemable collateral — there is no illiquid long-tail bag here. Against that, MCB’s market cap is ~$5.2M and FDV is in the $6–7M range. Tokenholders currently own a claim on assets worth substantially more than the token price implies.

2. Diminishing returns on operating spend. The team’s own September 2025 budget post reports $4.692B in trading volume and $2.12M in protocol income for FY24–25 — a real, working business. But the curve has bent the wrong way since:

Metric FY24–25 (Sept 2024 – Aug 2025) Recent run-rate (last 30 days, May 2026) Change
Avg TVL ~$25M (peak ~$40M, end ~$10M) ~$10M −60%+
Avg daily trading volume ~$12.86M ($4.692B / 365) <$1M (fee-implied $500–720k/day) −92%+
Total fees (annualized) ~$2.1M+ in protocol income ~$158k −92%
Net revenue to protocol/holders (annualized) ~$2.12M ~$47k −98%
Annual operating budget $1.55M cap (drew $775k) $1.25M cap (FY25–26, in progress) —

(Volume figures are derived from DefiLlama-reported fees divided by MUX’s standard 0.075% open+close fee rate; revenue is DefiLlama’s dailyRevenue series annualized.)

V3 launched, a wave of features shipped, and the curve did not bend but sadly it inverted. Operating spend is now ~25–30x the protocol’s annualized revenue. With $1.25M of FY25–26 budget still being drawn against POL, the marginal dollar of dev/marketing spend is no longer demonstrably accretive and at the current revenue run-rate, the protocol is depleting POL roughly $1.2M+ faster per year than fees can replenish it.

3. Governance cadence has slowed. The last team-authored proposal — “Reserve $1.25M From POL for Sept 2025 – Aug 2026 Budget” was posted September 3, 2025, received zero likes and one generic reply (Oct 26, 2025), and no new proposal threads have been opened since. That’s ~8 months of silence in the Proposal category. This is not a moral judgment: teams get tired, markets get cold, and quiet periods happen, but it is a data point the community should weigh when deciding whether continuing operating spend is the right use of POL.

Put bluntly: if the team is in maintenance mode (which is reasonable and rational), tokenholders deserve the choice to crystallize the value already in the treasury, rather than have it slowly amortized into ongoing OpEx with limited evidence of TVL or revenue acceleration.

2. Option A: Orderly Wind-Down + Pro-Rata POL Redemption (Primary Motion)

2.1 Principles

  • Redemption is for MCB and veMUX holders (and MUXLP holders for their own pool assets, which is mechanical and already in the contracts).
  • No haircut, no insiders-first. Pro-rata, on-chain, claimable by anyone holding eligible tokens at the snapshot block.
  • Liquidity is preserved during the wind-down so traders can close positions without slippage shocks.
  • Contributors are paid fairly for wind-down work. This proposal is not about clawing back compensation; it is about stopping future burn against POL.

2.2 Eligible redemption pool

The redemption pool is the entirety of MUX V2 + MUX V3 POL net of:

  1. Outstanding trader open-interest collateral (MUXLP back-stop) until positions are closed or migrated.
  2. A wind-down operating reserve (proposed: $400k, see §2.5).
  3. Any pending end-of-term contributor obligations (proposed: capped at $250k; see §2.5).

Initial estimate: ~$9.4M of $10.1M POL is available for direct redemption to tokenholders.

2.3 Eligibility and pro-rata math

  • Snapshot: taken at block B_snap, set 14 days after the on-chain Snapshot vote passes.
  • Eligible token base: circulating MCB + MCB-equivalent locked in veMUX (per existing veMUX accounting), minus tokens held by the DAO/contributor multisigs and any tokens held in protocol contracts (so the DAO does not redeem against itself).
  • Per-token claim = RedemptionPool / EligibleTokenBase, denominated in a basket that mirrors POL composition (WBTC / WETH / stables / sUSDe / sUSDC). Holders receive the basket pro-rata, not USD-denominated.

2.4 Mechanics & timeline

Phase Duration What happens
Discussion 14 days This forum thread; team feedback; refinements.
Snapshot vote 7 days veMUX vote on Option A vs. Option B vs. Reject.
Pre-redemption ramp 14 days New trade openings disabled on MUX V2/V3 native pools; trader notice via UI banner & socials.
Position close-out 30 days All open positions on MUX V2/V3 are closed or auto-settled at oracle TWAP; MUXLP holders redeem normally per existing contract.
Snapshot block T+65 days B_snap taken; eligible balances frozen.
Redemption window 90 days Holders call redeem() on a Merkle-claim contract, receive their basket.
Sweeper window 60 days Unclaimed assets remain claimable; reminder posts on socials.
Sunset T+215 days Any unclaimed POL after the sweeper window is sent to protocol contributors for their commitment and service to the protocol.

2.5 Wind-down operating reserve

Proposed cap: $400k. Scope:

  • 3 months of skeleton-crew contributor compensation for wind-down execution.
  • Final L1 audit of the redemption contract.
  • RPC, hosting, monitoring, and oracle costs through the redemption window.
  • Community comms / customer-support coverage for trader close-out.
  • Any one-time legal review of the wind-down structure.

Plus a contributor end-of-term cap of $250k for documented FY25–26 work already performed under the existing $1.25M budget that has not yet been drawn (i.e., this proposal does notretroactively modify the existing budget — it caps further draws).

Total carve-out from POL: $650k, leaving ~$9.4M for redemption.

2.6 Multisig / execution

  • Redemption is executed by a purpose-specific 4-of-7 multisig (“MUX Wind-Down Multisig”) composed of:
    • 2 current MUX core contributors,
    • 3 elected veMUX holders (ranked-choice vote at Snapshot stage),
    • 2 independent signers from external DAO ops collectives (e.g., StableLab, Karpatkey, Llama, or similar — community to nominate).
  • The multisig has no discretionary spending authority beyond the $650k carve-out and the redemption contract execution. Anything outside that scope requires a fresh Snapshot vote.
  • The redemption contract is immutable post-deploy and post-audit; no admin keys, no upgrade path, no rescue function on the redemption side.

2.7 What happens to MUX/MCB the token

  • After the redemption window closes, MCB continues to exist as an ERC-20 but is functionally a residual claim on whatever (if anything) remains.
  • veMUX locking is disabled at B_snap. Existing veMUX positions are converted 1:1 to their MCB equivalent for the purpose of redemption math (per current vesting schedules), then the veMUX contract is paused.
  • The MUX aggregator front-end can be left online by anyone who wants to keep operating it — the smart contracts are open-source and routes to third-party perps DEXes do not require ongoing protocol team involvement.

2.8 What this is not

  • Not a rug, not a cash-grab. The mechanics are public, on-chain, and pro-rata.
  • Not retroactive, does not claw back any compensation already paid.
  • Not hostile to contributors, explicitly compensates them for the wind-down.
  • Not an exit-scam optimization, basket redemption avoids any MCB-pump-then-dump dynamic.

3. Option B: Lean-Mode Continuation (Alternative Motion)

For the community members and contributors who believe MUX still has product-market-fit upside (e.g., the Hyperliquid integration, a possible HIP-3 deployer route), this is the alternative.

3.1 Lean-mode budget

Replace the existing $1.25M FY25–26 budget cap with a $420k 12-month cap, allocated:

  • $300k development (1 senior smart-contract eng + 1 frontend/ops eng equivalent),
  • $80k infra / audits / bounty,
  • $40k marketing (lean — content + community ops only; pause paid KOL spend).

Any spend beyond the cap requires a fresh Snapshot vote.

3.2 KPI gates with automatic redemption trigger

Lean-mode is conditional on hitting two of the following three KPIs at the 6-month review (Nov 8, 2026):

  1. Average TVL ≥ $20M over a trailing 30-day window (i.e., 2x today’s level).
  2. Cumulative protocol fee revenue ≥ $500k during the lean-mode period.
  3. Hyperliquid integration shipped to mainnet with measurable volume routed (≥ $50M cumulative).

If ≤2 KPI is met at review, Option A executes automatically — no new vote required. The Wind-Down Multisig is pre-staged at lean-mode start and dormant until triggered.

3.3 Why this structure

This gives the team a clean, well-funded runway to prove the V3 + Hyperliquid thesis, while protecting tokenholders from open-ended OpEx burn against an asset base that already trades below liquidation value. It is the charitable version of the bet, it asks for proof of traction, not faith in it.

4. Indicative redemption math (Option A)

Numbers below use today’s snapshot. Final numbers will be set at B_snap.

  • POL available for redemption: ~$9.4M
  • Eligible MCB-equivalent supply (excluding DAO/multisig/contract holdings): assume ~3.8M (CoinGecko’s reported tradable supply; refined at snapshot)
  • Indicative per-token claim: ~$2.47
  • MCB price as of writing: ~$1.37 (mcap $5.2M / 3.8M ≈ $1.37)
  • Implied uplift: ~80% over current spot

Even under conservative assumptions (haircut for outstanding obligations, larger ineligible balance at snapshot), the redemption uplift is meaningfully positive vs. the current market. This is the entire point: there is more value in the contracts than in the token, and the gap has persisted.

5. Risks & open questions (please push back)

I want this proposal to be sharpened by community pushback. Specific open questions:

  1. Trader fairness: Is a 30-day position close-out window enough? Do MUXLP holders need a longer redemption tail to avoid an LP run?
  2. Aggregator user impact: What happens to retail traders who only know MUX as a front-end? Is there a hand-off path (e.g., redirect to GMX/gTrade) that minimizes user disruption?
  3. Contributor obligations: Is the proposed $250k end-of-term cap correct? Should we ask contributors for a public proof-of-work / final delivery scope first?
  4. Tax treatment: Token redemptions can have surprise tax consequences in some jurisdictions. Should we ship a clear FAQ + community-tax-counsel review as part of the wind-down?
  5. Lean-mode KPIs (Option B): Are the thresholds (TVL $20M / $500k revenue / $50M Hyperliquid volume) the right ones? Suggestions welcome.

6. Acknowledgements

To the MUX core team, jean, dumbird and contributors: thank you for years of work, for shipping V3, for transparent reporting, and for stewarding this treasury responsibly through a brutal market cycle. This proposal exists because you’ve kept the assets safe — the optionality to choose between continuing and returning value is itself a product of careful stewardship.

The intent here is not to relitigate decisions or assign blame. The intent is to give holders a structured, dignified choice at a moment when the math has clearly inverted and the protocol’s growth narrative has stalled. Whichever option the community chooses, this is a much better situation to be in than most DeFi projects of similar vintage.

7. Next steps

  1. Discussion (this thread): 14 days of community input. I will incorporate concrete revisions.
  2. Snapshot draft: post the formal Snapshot multi-choice vote (Option A / Option B / Reject) at the end of discussion.
  3. Vote: 7-day veMUX-weighted vote.
  4. Execute per the timeline in §2.4 or §3.1 depending on outcome.

Looking forward to the conversation. If anyone has better numbers, better mechanics, or better KPI suggestions, please post them here. The strongest version of this proposal is whatever the community converges on.

Appendix: Sources