Protocol Implementation Security Audit

Audit Report Revisions

Audit Overview

We were tasked with performing an audit of the Tren Finance codebase and in particular their Protocol Implementation module.

The system implements a variant of the Liquity system incorporating several changes to the core system, including but not limited to:

• Upgradeability employed across all system contracts
• All pool implementations (ActivePool, CollSurplusPool, etc.) combined into a single TrenBoxStorage contract
• EIP-20 support of any decimals
• Flash-loan capabilities for acquiring debt tokens and repaying Tren boxes
• A redemption softening system
• Re-configurability of multiple system components beyond their original premise

We consider the introduction of upgradeability throughout the system to increase the level of centralization present within the system, and we advise the Tren Finance team to exercise utmost caution when managing upgradeability as well as owner-related functionality.

Over the course of the audit, we identified several vulnerabilities with significant impact to the overall system stemming from the unique approach the Tren Finance team has taken in adapting the original Liquity codebase.

While certain features introduced by the Tren Finance team can be rectified to behave as expected, we believe that some are inherently insecure and should be stripped entirely such as the redemption softening system as it significantly undermines the purchasing power of the debt token within the Tren Finance system.

We advise the Tren Finance team to closely evaluate all minor-and-above findings identified in the report and promptly remediate them as well as consider all optimizational exhibits identified in the report.

Post-Audit Conclusion

The Tren Finance team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on.

In addition to the alleviation of the exhibits we identified over the course of the audit, the Tren Finance team identified a potential issue with how a Tren Box closure is executed.

Specifically, it was possible to configure the debt repayment call with a specific value to cause the Tren box to remain open albeit with 0 debt.

A conditional within the BorrowerOperations::repayDebtTokens function was updated to accommodate for such a case, thereby addressing the issue and causing it to no longer manifest.

We evaluated all alleviations performed by Tren Finance and have identified that certain exhibits have not been adequately dealt with. We advise the Tren Finance team to revisit the following exhibits: LTR-04C, TRN-02M, PFD-05M, PFD-04M, PFD-06M, PFL-01M, ACT-01M, ACT-03M, SPL-01M, FLN-01M, BOS-01M, STR-01C, LTR-01S, ACT-01S, ACT-02S, TBO-02C

Post-Audit Conclusion (73b9546eb9)

The Tren Finance team supplied us with a follow-up commit hash as well as document that details the remediative actions their team has taken in addressing the exhibits that remained open as outlined above.

We evaluated all follow-up remediations as well as document responses and have observed that exhibit PFD-06M and ACT-03M remain open whereas the acknowledgement of BOS-01M is insufficient.

Additionally, we have proposed an increased-security remediative action for PFD-05M that we believe the Tren Finance team should apply as well.

Post-Audit Conclusion (13f0ca88ab)

The Tren Finance team provided us with another commit hash to evaluate remediations for the aforementioned four exhibits that remained open in the previous iteration of the codebase.

We validated that all four issues have been adequately addressed except for the follow-up remediative action of PFD-05M which the Tren Finance team may acknowledge.

Audit Synopsis

Severity	Identified	Alleviated	Partially Alleviated	Acknowledged
	2	2	0	0
	41	32	1	8
	6	5	0	1
	9	7	0	2
	6	6	0	0

During the audit, we filtered and validated a total of 12 findings utilizing static analysis tools as well as identified a total of 52 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they can introduce potential misbehaviours of the system as well as exploits.

Total Alleviations

The list below covers each segment of the audit in depth and links to the respective chapter of the report:

• 🎯 Scope
• 💻 Compilation
• 🔍 Static Analysis
• 👁️ Manual Review
• 🖋️ Code Style