Multi-collateral to prevent liquidity & Single point of failure

Hey all!
I didn’t go through all the previous discussions on this topic, but I read Discord, and wanted to share it here as well for visibility.

The recent incident seems to be linked to vulnerability in the lAAVE code, which in turns exploited another weakness of the lUSD: its low liquidity & single point of failure.

It thinks this shows how important it would be for the product to have multi collateral, I.e to be able to use other well known stable coins.

If we had such mechanism, what would have been the impact of the current incident? Would it bring any new potential security challenges?

Let’s use this thread to brainstorm!

1 Like

Hi Wushu, thanks for your input and this new topic.
Yes I’m in favour of multi collateral, I’m not sure what the security implications would have been had we already had multi collateral in place but I sure think its a solution to the afore mentioned issues with the old lusd.
What would be the issue with using a stable coin in place of lusd to re-boot the dapps, if we are just putting to bed the old lusd the hacker would not be able to influence the protocol or would they?

Hi everyone,

It’s great to see some activity here. Rather than being a weakness, the low liquidity of the lUSD pool might have spared us from even greater losses. This pool was utilized to exchange the exploited tokens for other cryptos, which could then be cashed out. The more liquidity present, the more severe the potential damage could have been.

One significant improvement that the Multi Collateral update brings is its ability to use collaterals other than LINA to secure the debt pool. This means there could potentially be more liquid tokens backed by less volatile collaterals, such as BTC and ETH. However, this wouldn’t have had a positive impact in the context of the recent exploit, as the attacker was able to mint an infinite number of liquid coins that then bloated the debt pool.

Moving forward, the team must prioritize enhancing internal processes to ensure that such incidents don’t recur. I believe the team already places a high emphasis on security. The incident wasn’t due to a leak of private keys, and Multi Sig wallets are utilized to secure updates. The attacker cleverly inserted a few malicious lines of code into the mint method of the lAAVE smart contract prior to its deployment. Even with close scrutiny, this would have been difficult to spot since it merely replicated a previously used process with a changed address. There are algorithms to defend against this kind of attack, and it’s crucial for the team to continuously seek ways to fortify and secure the liquid asset adding process.

I’m unable to see other methods to guard against future breaches of this nature. If anyone has suggestions or insights, please share them with us.

Best regards!


Thanks for your input Pho.
The only other method I can think of is the security/ due diligence in the recruitment process of the Devs and or other Linear employees.
Easier said than done, particularly in the world of Dev’s and blockchain I imagine but still, a necessary consideration none the less. Good recruitment is key to any successful business.
I believe we are partnered with WorkX to assist in recruitment?
Where did the rogue Dev come from? All questions we can perhaps look at in the aftermath reports.