May 5, 2021
Hey everyone! Welcome to our monthly newsletter where we share updates regarding Liquity and our ecosystem on a regular cadence.
If you’d like these sent directly to your inbox, sign up for the mailing list on our website.
After the activation of the redemption mechanism, borrowers trying to open or adjust existing Troves have been facing frequent out-of-gas errors.
It’s a complex issue, so we will describe it in more detail in the future, but here’s the TLDR: Liquity’s smart contract stores Troves in a linked list in order of least collateralized to most collateralized, and when you adjust your Trove it has to figure out where to re-insert it in the list.
The out-of-gas issue arose because we had clusters building up in various places making it difficult for frontends to estimate gas properly. This was because the initial version of the frontend Launch Kit allowed users to specify their collateral and debt (including the Liquidation Reserve and the Borrowing Fee). Paired with a human penchant for “nice” or “round” numbers (e.g. a collateral of 10 ETH and a debt of 10,000 LUSD), this has led to clusters of Troves with the exact same collateral ratio as shown here:
Recently we pushed a frontend fix to the Launch Kit to address this. From now on, when creating/adjusting a Trove, users will enter the amount they want to borrow, rather than the total debt they need to pay back. This creates variance in the total debt, and therefore avoids a Trove from being inserted into a big cluster. We’re currently looking into a longer term solution and we’ll provide more information when it’s ready.
Note that this issue is not “exploitable” by an attacker, since users are free to select a collateral ratio in a lesser “dense” region of the sorted list. It’s also not an issue with the core Liquity protocol, but an issue in gas estimation for transactions.
Bingen has created a migration tool that makes it easy to migrate LQTY balances to a new deployment of Liquity. The migration tool takes a snapshot of all circulating, locked, and staked LQTY tokens and allows to verifiably and seamlessly mirror the balances in the newly deployed system.
Having the migration tool ready enables us to move quickly if immediate action becomes necessary, e.g. in an emergency situation due to a critical bug. Furthermore, we could use it to migrate to a new version as part of a regular update that may become relevant in the future. The PR for the migration tool can be found here and is still subject to code review.
The team has been working to complete our subgraph implementation, adding missing features like support for the frontend tags. The subgraph gives frontends an easy way to access user data and basic stats, including the change history for Troves, Stability deposits and stakes. It is complemented by a middleware library lib-subgraph serving as an interface between frontend and the subgraph itself.