Liqwid Core Team – Solution for Proposal 00.2

Liqwid Core Team – Solution for Proposal 002


1. The Eligibility and selection process.

1.1 Eligibility criteria.

1.2 Selection process.

2. LQ allocation.

2.1 Allocation method.

2.1.1 Allocation keys and data source.

2.1.2 Illustrative examples for an allocation.

2.2 Voting workflow and process to select the DEXes.

After having read your comment on the Liqwid Governance for the Proposal 002, here is the proposal of the Liqwid Core Team.

Introduction to the DEX Incentive Framework

As we have seen recently, Total-Value-Locked (TVL) on DEXes may evolve quickly (e.g. Minswap getting a higher TVL than Sundayswap quickly after its launch), but we also acknowledge that at this stage, nothing is certain in DeFi (e.g. Minswap avoiding through the support of WingRiders the potential risk of a massive hack). Currently, more than 20 DEXes have plans to launch on Cardano and the overall competition within DEXes, and within the AMM and Order-book DEXes will be fierce.

Therefore in the light on these massive upcoming changes happening in the Cardano DEXes space, the 002 Proposal seeks to determine the adequate governance framework to allocate and implement these DEX incentives.

The purpose of a Decentralized Exchange (DEX) incentive is to support the development of LQ pools within selected DEXes, that demonstrated already a large market traction and/or are supported by the LQ community. This incentives should also serve the development of the Liqwid’s ecosystem and promotes the interoperability of DEXes with Liqwid.

DEXes will be selected through a community vote after they passed the eligibility criteria. We can foresee that once DEX aggregator or Yield aggregator are working within the Cardano DeFi space, the Community could expand the eligibility criteria.

The Eligibility and selection process

Eligibility criteria

An eligible DEX must have the following criteria to participate in the selection process:

  • Being governed by a DAO
  • Having at least 50% of the tokens sold in public sale and/or distributed to the community over time
  • Being open source
  • Being audited
  • Having minimum 3 months of lifetime
  • Having minimum USD 50 millions of Total-Value-Locked (sum of TVL for all the assets on the application)

Selection process

  • The LQ incentive program lasts 3 months and is renewed every 3 months for every DEX.
  • 2 weeks before the end of the program, a DAO vote is performed to select the DEXes for the next quarter.
  • Every 3 months, up to 5 DEXs are selected.

LQ allocation

LQ tokens are allocated depending on the total amount of selected DEXes, and the TVL of the LQ/ADA pool per DEX, in average during the last 30 days before the voting date. Also, a fixed numbers of LQ is set through an allocation method (see below) for every DEX.

Allocation method

A total of 4% of the total LQ supply (840’000 LQ tokens) is allocated for the DEX incentives during a period of three years period. It represents 280’000 LQ tokens per year, and 70’000 LQ tokens per quarter.

Allocation is done based on the numbers of DEXes the community voted for and the total TVL (only LQ/ADA pair) that the selected DEXes have compared to each other’s. The TVL is calculated only for the LQ/ADA pair during the last month before the vote to determine the rank of the DEX and its related incentive.

Proposed allocation per DEX and per TVL

Allocation keys and data source

Illustrative examples for DEXes allocation

Assumption: All the selected DEXes here below had already their eligibility criteria checked before vote.

The selected DEXes must have received at least 50.01% of the voting LQ, otherwise it is a direct decline.

Only the 5 best voting scores are taken to select the DEXes. Then, the ranking is done for the DEXes depending on the LQ/ADA TVL.

EXAMPLE 1 – 7 DEXes are eligible
List of eligible DEXes subject to a vote - Illustrative data -


List of eligible DEXes subject to a vote - Illustrative data -


  • If only 1 DEX obtains a voting score over 50.01%, then the second best voted DEX is drafted and considered as selected. The LQ incentives are split over these 2 DEXs (the voted and the drafted one), where the drafted DEX is being automatically considered as Rank 2.
  • If no DEX obtains a voting score over 50.01%, then no LQ incentive is distributed for the quarter.
  • If more than 5 DEXes are receiving a voting score over 50.01%, the 5 DEXes with the highest voting scores are selected.

Voting workflow and process to select the DEXes

Two weeks before the vote, everyone can propose a DEX and document why this DEX is eligible.


  1. Any user submitting a DEX for eligibility shall also document how the LQ rewards will be distributed to the LQ/ADA liquidity providers, if the DEX is selected.

  2. Implementation costs of the LQ/ADA incentives are the responsibility of the proposed DEX.

  3. Eligibility criteria will be reviewed by the Core Team for the first vote, including the feasibility of the IT implementation.

  4. Once the DEXes are selected, the following vote happens:

Example for the selection of 5 DEXes out of 7

  • 7 questions will be asked on the Agora Module, e.g. “ Do you vote for DEX Alpha” to be selected for the DEX incentives?”, “ Do you vote for DEX Beta” to be selected for the DEX incentives?”, etc.
  • The Agora vote will count the LQ tokens vote and the DEXs having received the biggest LQ votes will be selected, see Section Allocation method for further information.

Interesting. So that means that currently no DEX is eligible for incentives.

As DEXes begin their open sourcing, we also need to determine which kind of “open source” this proposal is talking about.

Is it fully open source, where every part of the DEX is open, or is it partial, where just a small part of it is open source (pool contracts, but batchers closed) (like Minswap). Is it a business open source, where a company (or DAO) owns the license (Uniswap V3). Or is it open source, where anyone can fork it and develop on top of it (ErgoDEX)?

I like this proposal as it discourages the current trend of teams having their code closed source to try and keep the competitive advantage. However. One thing I would change is that instead of a hard cap of 50m, we should be flexible and make it in terms of the total TVL of the ecosystem. Maybe 20% or 15%.

I would also say that this should not be put to a vote until enough feedback is gathered so that this is not rushed. And that the “voting score” part would need to be polished. Maybe we should create a framework on how voting will be done first before this Proposal is passed to a vote? There’s currently a lot of things up in the air currently in terms of how voting power is allocated, and I would prefer that it is polished before we continue with this proposal.