Liquity is a project that has been fascinating me for a while — its product is simple, works well, and its use in DeFi is evolving in an interesting manner. Before getting into this post, two things need to be mentioned. 1) Liquity’s smart contracts are immutable and CANNOT be changed at the moment. The only way would be to create a set of v2 contracts and have those exist simultaneously. 2) Liquity’s LQTY is NOT a governance token. There is no governance; however, it does act as an instrument to capture some value from product usage. Thus, the thoughts below cannot be considered nor implemented at all for the current state of Liquity. Rather, they can serve as helpful discussion points for v2, if that is still something the team is actively pursuing and open to.

Background

Liquity is a decentralized borrowing protocol that offers interest-free loans (in the form of LUSD) against ETH. While it is architected similar to MakerDAO, some key differences exist: 0% interest rates, immutable and decentralized protocol management, higher capital efficiency, and a robust peg mechanism for a simple user experience. Some comments on its functionality:

• Users deposit ETH into a vault (called trove) and take out a loan for any time horizon they wish, as long as the ETH is above the 110% collateral ratio. Unlike other debt protocols, liquidation is completely algorithmic, thus being more efficient and simpler. A minimum debt of 2,000 LUSD must be taken out

• Due to having no supply-side on the protocol level, Liquity can support 0% interest rates. MakerDAO cannot do so since it needs the interest revenue to control DAI price

A great test of Liquity’s mechanisms occurred on the May 19th market crash, where Liquity efficiently managed liquidations of under-collateralized debt positions. Out of all the stablecoins during this crash, Liquity’s LUSD was one of the best at maintaining as close to the peg as possible.

One last thing to mention — the core team had a dual focus when setting up Liquity: creating a robust, efficient debt protocol and offering best-in-class decentralization. Liquity doesn’t have a central frontend, instead setting up paid partnerships with other frontends (i.e. Zerion) to prevent a central point of failure. Driving this strategy is a comprehensible and trustless SDK that makes it easy for frontends to plug into Liquity’s functionality.

Liquity’s BD: Frontend acquisition

Currently, LQTY is used for frontend user cost of acquisition (“CAC”). Liquity protocol gives LQTY rewards to the frontend operators proportional to their respective TVL versus the entire network. The operators are entitled to distribute as much of these rewards as they want to their users as kickbacks.

While this in great in theory, it reflects a DeFi 1.0 approach to BD. The problem with this is that using the LQTY to fund CAC increases dilution and creates sell pressure for the token. This would be acceptable if the value driven from the frontend acquisition more than paid for this; however, I think that this is not the case. Liquity has been distributing significant LQTY tokens without getting much TVL growth at all:

• Since May 2021, circulating supply has grown quite strongly from 2.79m to 13.8m. On the other hand, TVL has gone from ~$3b up to $4.5b (mid-May) down to $2.47b

• This is effectively destructive to LQTY value. Ideally, there should be a better BD strategy more suitable to LQTY interests and accretive to the tokenomics behind LQTY

Potential Proposal

While the problem is evident, coming up with a solution is definitely tougher, and I am very open to community discussion on how to achieve this. That being said, one (very) theoretical way would be to finance some of the frontend acquisition through LUSD. How could this be done?

1. The Liquity community and team would need to work with lending protocols to allow for LQTY to be used as collateral. Given the LUSD proposal on Aave as well as the great track record with Fei-Rari, the Liquity community has some relationships it can flex to start conversations

2. This is where the strategy gets innovative (or riskier, frankly). Assuming one can get these lending markets accepting of LQTY, I propose that the Liquity treasury take out a loan using LQTY as collateral (interesting connection to my prior post on levering DAOs). The terms would be ultra conservative with a high collateralization ratio

3. Using the loan (denominated in ETH ideally), Liquity would proceed to take out loans on its own protocol to obtain LUSD, which it then uses to finance a percentage of the CAC. Over time, the treasury can pay back the loan / manage its debt load through its accrued fees from other staked LQTY in the treasury (or, and we are getting very theoretical here, a staked version of its original LQTY collateral)

What does an idea like this do? Drives greater use of Liquity + avoids LQTY dilution and sell pressure.

Risks & Friction

The idea above is not perfect at all… Firstly, there is significant friction to getting LQTY up as collateral. It would be hard to navigate the governance process for collateral acceptance just given the history of other protocols doing so as well as potential concerns with LQTY’s past volatility. The best option is probably some type of pool on Fuse.

Secondly, this idea assumes that Liquity is financing very profitable CAC. What happens if that LUSD is just pummeled into wasteful frontends that lack longevity? The Liquity treasury would accumulate a lot of debt with lower probabilities of paying it off without eating up treasury value. The success of the idea hinges on good BD that yields revenues to then pay off the debt.

Thirdly, would this be able to be conducted in an automated manner? Even after assuming the team wanted to include something like this in a v2, it would have to be smart contract code (unless they do move to a DAO model). Making this executable in an invulnerable way is very (and possibly too complex). The lack of a DAO also makes the whole treasury concept semi-void.

Conclusion

There definitely is a flaw in how frontend acquisition and growth is funded assuming that the goal is to make LQTY a valuable and well structured token. The proposal I gave is just a high level series of thoughts and has its risks/complications — this is just one of many ways to approach the issue and there are definitely other interesting approaches out there. However, all of this is effectively just an enjoyable brainstorm session if the team and community are not behind creating a better v2. If they are, then the frontend acquisition strategy is definitely something to work on.

Disclosure:* This blog series is strictly personal/ educational and is not investment advice nor a solicitation to buy or sell any assets. It does not represent any views from where the author is working — all views, opinions, and arguments are the author’s. Please always do your own research.*