An alternative direction for the DUST/USDC liquidity problem
I want to offer a different framing for RFC-06. The diagnosis in the original proposal is careful and the incident is real. My concern is that the remedies address the symptom (a depleted pool) while leaving the cause untouched, and that they cost the protocol more than a set of governance parameter changes that would address the cause directly. I am writing this to start a discussion, not to dictate an outcome.
(Numbers that i got when i researched)
The problems, stated with the actual numbers
-
Emission dependence. On this pool, daily LP income is approximately 1,454 USD in DUST emissions against approximately 105 USD in real swap fees. Roughly 93 percent of the yield is freshly printed DUST. Annualized, that is on the order of 530,000 USD of DUST printed for this single pool against roughly 38,000 USD of real fees earned.
-
Rented liquidity. The USDC side of the pool is now about 0.9 percent of the pool (3.96K USDC against 1.81M DUST). Pool TVL fell from 808K on Jun 25 to 455K, a decline of about 44 percent in a few days. The liquidity left because it was incentivized to be there, not because it was owned.
-
Reflexive design. The yield that justifies locking into veDUST is itself funded by emissions. When DUST falls, that yield falls with it, which weakens the incentive to lock at the exact moment selling pressure is highest. This is the loop that produces the incident, and it repeats unless the design changes.
These three points are the actual problem. A second pool, a temporary buyback, or a change to the fee number does not alter any of them.
Why RFC-06 does not resolve the cause
The Uniswap V3 split divides already thin liquidity across two venues, which makes execution on large sells worse rather than better, and it does not answer who supplies the USDC on either venue. The buyback and burn spends USDC and then destroys the DUST it buys, so the pool is no deeper afterward, and at the proposed size it mostly provides exit liquidity to the first sellers out. Reducing the veDUST share from 70 percent to 20 percent weakens the lock sink during a confidence crisis, which increases net selling. Each of these also carries cost: a new pool deployment, two incentive programs, and direct treasury spend.
The direction I propose, using only governance levers
The highest leverage fixes here are also the cheapest, because they are governance parameters and treasury allocation rather than new contracts. None of the following requires an audit or a new deployment.
-
Reduce DUST emissions on a managed path toward the level that real revenue can sustain. Emission rates are governance set. Lowering them reduces the sell pressure at its source and costs the protocol nothing. It also extends runway, since fewer tokens are printed.
-
Redirect protocol revenue into protocol owned liquidity instead of buyback and burn. Protocol revenue is already collected in real assets through the reserve factor and borrow interest. Supplying that as USDC and DUST into the existing pool deepens the bid with liquidity the protocol owns and does not withdraw under stress. This uses the existing pool and a treasury action, with no new contract.
-
Preserve the veDUST share and move it over time toward a claim on real revenue rather than emissions. This keeps the lock sink intact now and makes locking worthwhile even when the DUST price is falling, which is the long term fix for reflexivity.
On swap fees and the dynamic fee idea
The only attribute editable on the current pool is the flat swap fee, currently 1 percent, set through the delegate manager. Because it is symmetric, raising it taxes buys exactly as much as sells, and buys are what refill the USDC side. So the flat fee is not a useful lever for this problem in either direction.
A fee that charges only the destabilizing direction, that is, a surge on sells when the USDC side is depleted, is the correct mechanism and would compensate the liquidity providers who are currently absorbing the losses. It cannot be applied to the existing pool, because it requires a custom hook set at deployment, which means a new pool and an audit (probably). For that reason I am not proposing it as part of these low cost actions. It belongs in a separate decision about whether to redeploy the pool, and only if the governance levers above prove insufficient.