Inspiration
The protocol design was inspired by the Chainlink Feed Registry, an on-chain registry that maps existing token contract addresses to Chainlink Price Feeds. As a result, smart contracts can fetch data from any Chainlink Price Feed through a single universal registry contract, drastically reducing the integration effort of creating hybrid smart contract applications.
This idea of a registry could be also applied for a DeFi liquidity provision. Registry of market makers that post their prices (quotes) for a different range of requested quantities.
So, any person (taker) can come to this registry and execute desirable order. Then, on top of this registry, place a router with the search for the optimal deal so that any user can come and execute the desired order. As a result, for the end-user, the interface will not differ from the usual Uniswap, however, market makers will be able to be much more flexible in managing their risk and capital efficiency, which in turn gives the end-users the best pricing for all kinds of tokens.
What it does
Conditional liquidity protocol with parametric input, where the users can place limit orders as one-sided payoff curves with price as a function of requested quantity. This function can also include any configurable parameters (logic), such as volatility range, buy/sell ratio, etc. For example, traders can place an order that will be valid only if realized volatility over the past 1h was <=5%.
That custom logic stores as a separate smart contract, called order templates, the logic of which can be used by anybody for placing new conditional orders, by specifying template-id and passing desirable price function as a parameter.
How we built it
The core contract is Registry, which stores all Pairs and Templates. To create a new Pair or order template user needs to call the correspondent factory function, which will push the newly created contract to the Registry. After this, anybody could use this template to place a new conditional order for a certain pair of tokens by specifying a link to the template.
Each pair is a separate contract, which stores orders (positions) that were placed for this pair and TWAP price accumulator.
Note that by order we call a liquidity position, which could be also a kind of liquidity provisioning strategy, as in the Uniswap V3, where after the partial sale of one of the tokens, this token will automatically move to the opposite side and participate in the liquidity provision.
Once the order was placed, its owner receives an NFT that represents his ownership for this conditional order and this position is automatically indexed by the router and in turn by the off-chain optimal pathfinder.
Challenges we ran into
Custom price functions
Accomplishments that we're proud of
Modular architecture, parametric input for desirable price functions.
What we learned
NEAR and Aurora
What's next for Liqui
We will look for market makers to provide liquidity in our protocol.

Log in or sign up for Devpost to join the conversation.