πAudits
BitVault C4 audit: https://code4rena.com/reports/2025-04-bitvault Liquity V2 Audit (BitVault is a friendly fork of Liquity V2)
ChainSecurity - Core Protocol Audit Report, December 2024
Dedaub - Core Protocol Audit Report I, August 2024
Dedaub - Core Protocol Audit Report II, November 2024
Certora - Formal Verification, December 2024
Coinspect - Bold Core Smart Contract Audit, December 2024
Coinspect - Bold Governance Audit, January 2025
ChainSecurity -Governance Smart Contract Audit, January 2025
Dedaub - Governance Audit 1, August 2024
Dedaub - Governance Audit 2, November 2024
Dedaub - Governance Audit 3, January 2025
Recon - Liquity Security Review, October 2024
Liquity V2 Updates as of May 19, 2025
Pull Request 889: this fix removes the collateral compensation parameter in order to reduce the incentive that an attacker might have to trigger liquidation via redistributions of collateral instead of via the stability pool.
In BitVault's setup, opening a trove and borrowing bvUSD will be subject to whitelisting, and allowed parties will have to keep high Collateralization Ratio (> 150%), thus reducing the probability of liquidation events at all.
Furthermore, whitelisting is applied to liquidations as well, so we really donβt see this as an attack surface given liquidations will be carried out by known partners that donβt intend to manipulate the system for profit.
Pull Request 890 & 893: access control for addManager/removeManagers.
This fix introduces a shortcut on how managers (entities that can perform operations on behalf of a trove owner), are set. Specifically, a removeManager (an entity that can withdraw collateral/debt from the position) is now automatically assumed to be addManager (an entity that can add collateral/repay debt) as well.
This is purely a QOL update, before that, you would need to explicitly set both add and remove managers, with no different behavior.
Pull Request 891 - this fix allows that all troves in a branch can be closed. Before that wasnβt possible as at least 1 trove was supposed to stay always open in a branch.
This isnβt really an issue as it can be easily mitigated by having one position with minimal debt/collateral open to allow bigger branches to get closed.
Pull Request 895 - this fix add msg.sender to owner and ownerIndex params in the hashing function to determine the position troveId
As Liquity stated, this is purely informational and not a bug, as a check for colliding troveId when opening a trove existed already, so there is no risk of overwriting open positions.
Last updated