Batch Management Rounding Error can cause debt from being forgiven to a Trove and charged to the Batch

mediumRecon Audits

Impact

This finding opens up the precondition to a bigger exploit

The code in scope presents truncation in 2 key parts of the code base:

When updating batch shares:

https://github.com/liquity/bold/blob/a34960222df5061fa7c0213df5d20626adf3ecc4/contracts/src/TroveManager.sol#L1747-L1749

solidity📋
                    batchDebtSharesDelta = currentBatchDebtShares * debtIncrease / _batchDebt;

When computing the debt that a Trove owes:

https://github.com/liquity/bold/blob/a34960222df5061fa7c0213df5d20626adf3ecc4/contracts/src/TroveManager.sol#L932-L933

solidity📋
            _latestTroveData.recordedDebt = _latestBatchData.recordedDebt * batchDebtShares / totalDebtShares;

Combining these two opens up to the 2 following impacts:

• Small debt increase amounts result in no minting of shares, meaning that the debt is being socialized to all Batch Debt Share holders
• Individual Trove debts rounding down leads to locking in the forgiven debt to other Batch Depositors, this can be used to rebase Batch Shares

Further Considerations for risk

As discussed with the Development Team, the inaccuracy from the divisor can grow over time, meaning that the impact of the finding could be made worse once enough interest has accrued

Mitigation

I am still researching this finding

I currently would recommend adding a post-operation checks that asserts that the _latestTroveData.entireDebt matches the pre-computed debt