How DEX Governance Directs Liquidity Incentives
Decentralized finance markets are not evenly liquid. There are some trading pools out there that have a lot of trading going on and then there are other trading pools that aren't successful in having enough capital to carry out the swaps efficiently.
The location of liquidity incentives is dependent on DEX governance.
There are numerous protocols that employ governance tokens, vote-escrowed tokens, gauges or other methods to allow for participants to vote which pools are rewarded more. This establishes a relationship between the protocol economics, traders, and liquidity providers, and governance.
Knowing that helps to make sense of the different incentive allocations to various liquidity pools.
What are Liquidity Incentives?
Liquidity incentives are additional rewards offered to encourage people to supply assets to specific pools.
The liquidity provider is able to already profit from swaps trading fees. An incentive program is another source of rewards that is added on top of the rewards that can be earned.
The concept is simple:
More incentives → more interest from LPs → more liquidity → potentially better trading conditions.
Curve's gauge documentation describes this mechanism directly.Its gauges pay out rewards to liquidity providers, and governance voting decides on the allocation of certain emissions between the pools.
However, liquidity cannot be guaranteed to be productive by providing incentives. These are all important factors when it comes to trading demand, the composition of the pool, token volatility and rewards value.
What Is a Gauge?
A gauge is a smart contract that monitors liquidity positions helping to allocate rewards.
In a gauge-based system, a pool can have an associated gauge where liquidity providers stake their LP tokens.
The gauge can then:
- Track deposited LP tokens
- Record individual liquidity positions
- Receive allocations determined by governance
- Calculate reward distributions
- Handle claims and withdrawals
Dexlyn's documentation describes gauges in a similar way, with gauges managing LP staking and emission distributions based on voting outcomes.
It is important to understand that the gauge does not generate any trading demand. It offers the means to channel and allocate incentives.
How is it that some pools stack up more rewards than others?
One popular design is to replace governance tokens with vote-escrowed tokens.
The participants bind governance tokens for a certain duration and give themselves voting power. They'll be able to redistribute the voting power into liquidity pools or gauges.
The pools receiving more votes receive a larger share of available emissions.
Curve uses this model with veCRV. Its documentation states that eligible gauges receive CRV emissions according to their share of weekly gauge-weight votes.
The other protocols have similar structures, but have different names for the tokens and voting rules.
The key is that those who are in the governance process could have an impact on how new liquidity incentives are given.
Why Would Someone Vote for a Liquidity Pool?
There are several possible reasons.
A governance participant might hold liquidity in that pool and want to encourage more rewards for its LPs.
A project might want deeper liquidity for its token and encourage governance participants to support its pool.
Some traders might want to trade in liquid markets because the higher the liquidity, the less impact it will have on the price.
This brings in an incentive cycle:
Governance votes → pool receives emissions → LPs receive incentives → liquidity grows → trading conditions may improve → pool can generate more fees.
In both Curve and others, the incentive to provide liquidity can draw in deeper liquidity, or deeper liquidity can lead to better trading conditions.
What Are Vote Incentives?
Protocols and projects do not always rely only on governance participants' existing preferences.
A project may deposit additional rewards for voters who direct their voting power toward a particular pool.
It is often referred to as a vote incentive.
Suppose there is a project that desires greater liquidity with regards to its token. It could offer an additional reward to governance participants who vote for the relevant pool.
The project is effectively competing for governance attention.
This creates another market around liquidity allocation:
Projects compete for votes, while governance participants decide where their voting power goes.
Aerodrome's documentation describes a similar system in which projects can deposit voting incentives to attract votes toward specific pools.
How Does This Work on Dexlyn?
Dexlyn uses veDXLYN and gauges to connect governance voting with liquidity emissions.
Holding DXLYN will unlock to give veDXLYN. According to Dexlyn's documentation, veDXLYN provides voting power for directing emissions, governance participation, rebase-reward eligibility and boosted liquidity rewards.
Liquidity providers should provide liquidity, stake their LP tokens into a gauge and stay in a Voting pool to earn the emission rewards. Just increasing the liquidity is not sufficient for those emissions.
Dexlyn also separates emission rewards from incentive rewards. Emission rewards go to eligible liquidity providers based on voting outcomes, while additional incentive rewards can be deposited by third parties and distributed to voters who support an incentivized pool.
This distinction is useful because LP rewards and voting rewards are not necessarily the same thing.
Why Liquidity Incentives Can Change Over Time
Governance voting is conducted within periods (epochs). That means a pool receiving strong incentives this week may receive fewer rewards later.
Suppose three pools compete for the same emission budget.
| Pool | Vote Share | Emission Share |
|---|---|---|
| Pool A | 50% | 50% |
| Pool B | 30% | 30% |
| Pool C | 20% | 20% |
If voting changes during the next epoch, the distribution can change as well.
This means LPs should avoid treating an advertised APR as a permanent return.
Dexlyn's documentation describes weekly epochs and notes that voting power is applied during the active epoch.
Does More Voting Always Mean Better LP Returns?
Not necessarily.
A pool receiving a large share of emissions may also attract many liquidity providers.
Imagine Pool A receives twice the emissions of Pool B but has four times as much staked liquidity.
The additional emissions are spread across a larger group of LPs.
This is why LPs need to look beyond the headline emission rate. Pool liquidity, trading volume, fee generation, token prices and the number of competing LPs can all affect the result.
Dexlyn's own gauge strategy documentation notes that pools with higher vote share can receive more emissions, while competition from other staked LPs can affect rewards per LP.
What Should Traders and LPs Watch?
For liquidity providers, useful metrics include:
- Pool TVL
- Trading volume
- Trading fees
- Current emission allocation
- Number of staked LPs
- Token price volatility
- Incentive duration
- Governance vote share
- Concentrated-liquidity range, where applicable
Governance participants should also consider whether their voting choices support pools with actual trading demand rather than simply chasing the largest temporary reward.
For a liquid project, incentives need to be assessed relative to the cost of bringing in the capital and of the trading resulting from liquidity.
Governance Turns Liquidity Into an Allocation Decision
Voting is not the only way to participate in DEX governance.
In gauge-based systems, governance has an impact on the allocation of liquidity rewards. That allows token holders to have a say in the markets that will be given extra support.
The model connects several groups:
The incentives are allocated to the Governance Participants.
Those incentives are met by liquidity providers who provide capital.
Traders use the resulting liquidity.
Protocols and token projects can compete for liquidity through additional rewards.
This makes liquidity allocation part of the economic design of a decentralized exchange platform, rather than a fixed setting controlled by a single operator.