System Definition

[Pol-Lanski]

After reviewing Carrot.eth, we got a lot of ideas on Liquidity Mining v2.

We need to formalize a sustainable system that lasts for a longer period of time and create specs requirement document.

We would need:

• [x] Design Objectives
• [x] Definition of the system
• [x] Modeling of the system
• [ ] Parametrization

[Pol-Lanski]

Current problem is we are spending 121K NODE weekly incentivising a liquidity that is fragmented between 2 markets and only in Ethereum.

Design Objectives:

1. The main objective is to attract liquidity for the NODE token. A liquid token is more attractive and can be more effectively used both in sources and sinks.
2. Goal based: it incentivises people to achieve a goal that is useful for the ecosystem. Currently we're incentivising pools that have low liquidity depth, resulting in high slippage. We want to be able to incentivise more the more useful is the liquidity pool.
3. Iterable and repeatable: We want to be able to change the parameters, adjust according to feedback and create new programs according to the emerging needs of the ecosystem.

Carrot.eth wasn't "repeatable". Because we want the rewards to be vested, we would need a different token for every iteration, which adds complexity.

What do we want to measure as a KPI?

• Depth of the pool in Ethereum
• Depth of the pool in Gnosis Chain
• Total staked NODE https://github.com/dappnode/liquidity-mining-v2/issues/4

Need a model for how much will be unlocked at any month and how much we should aspire to have locked

[Pol-Lanski]

Initial considerations/ideas:

• We have an Oracle that checks the metrics (KPIs) - checks the metric daily? Just at the end? It's the average for a period, so we need to keep checking every once in a while.
• We need to store this information off-chain? - We need a front-end for this --> Auditable with the Oracle Results.
• The Oracle provides the values and the DAO approves that this is the real result
• The user still needs to know what is their expected APR, and lock the liquidity somewhere (app.dappnode.io)
• The user shouldn't have to "unstake and stake again" in a new unipool for every iteration of the program
• We have to be flexible to distribute tokens from other types, in case we want to do a partnership with Swapr.eth.link and have extra incentives from other projects.

We will have:

1. 1 LP in Ethereum
2. 1 Governance staking in Ethereum
3. 1 LP in Gnosis Chain
4. 1 Governance staking in Gnosis Chain

BUT we should be flexible to add or remove some.

[Pol-Lanski]

LMv2 Project Definition:

Basic information:

• Liquidity Mining v2
• Kickoff Date: 31/05/22
• Authors: @Pol-Lanski @eduadiez @invocamanman @3alpha

Functional Description:

The LM is an improvement on the 1st LM program of the $NODE token.

Users will deposit their NODE together with another token in Liquidity Pools (probably Uniswap in Ethereum and Swapr or Honeyswap in Gnosis Chain), OR just NODE in a single-asset pool (we call this Governance Staking).

Users will receive rewards according to the fulfillment of KPIs. They will receive 0 rewards if a minimum threshold of liquidity pooled is not reached, will start to receive rewards when this minimum is reached, and will collectively receive a total of the reward pool if the maximum KPI is reached.

Example: - If the total liquidity pooled is below 250k denominated in USD, 0 rewards are distributed. Between 250k and 1M, the total amount of rewards are distributed so a bigger % of the total rewards is distributed the more liquidity there is, up to 100% of the reward pool distributed when 1M or above is reached.

In order to not be vulnerable to flash loan attacks or 1 block liquidity attacks, it needs to calculate an average of the liquidity over a period of time.

This calculation needs to be auditable, keeping proof of every point in time that will be used to calculate the final average that will determine the rewards, so it will need to store such data somewhere and make it available to users via a dedicated Front-End within app.dappnode.io

A guide regarding software design considerations like assumptions, dependencies, constraints, software requirements, objectives, and methodologies.

Design Considerations:

• We have an Oracle that checks the metrics (KPIs) - checks the metric daily? Just at the end? It's the average for a period, so we need to keep checking every once in a while.
• We need to store this information off-chain? - We need a front-end for this --> Auditable with the Oracle Results.
• The Oracle provides the values and the DAO approves that this is the real result? Is this necessary?
• The user still needs to know what is their expected APR, and lock the liquidity somewhere (app.dappnode.io)
• The user shouldn't have to "unstake and stake again" in a new unipool for every iteration of the program
• We have to be flexible to distribute tokens from other types, in case we want to do a partnership with Swapr.eth.link and have extra incentives from other projects.

Dependencies:

• Front-end - app.dappnode.io TODO

Constraints:

TODO

Software Requirements:

General:

• Solidity / Vyper
• Front end in Next.js

SCs:

• Unipool (link?)
• ?

Methodologies:

TODO

User interface design, end-user experiences, and user stories.

TODO

Development Milestones.

TODO

System architecture strategy & details

TODO

Testing & monitoring information that includes references to expert testing, the experiences of end users, and failure conditions.

TODO

Glossary.

LM = Liquidity Mining TODO

[DAppDanil]

[DAppDanil]

Updated scheme

https://excalidraw.com/#room=965376334a69311c37bb,Ivqc_J5u7yeRgFGV62C4bQ