HLiquity Implementation Security Audit

Audit Report Revisions

Audit Overview

We were tasked with performing an audit of the Swisscoast codebase and in particular their HLiquity Implementation module.

The HLiquity codebase represents a Liquity fork with modifications to be made compatible with the Hedera blockchain and specifically their special native token Hedera Token Service (HTS).

To achieve this compatibility, the following contracts have been ported over from the official Hedera blockchain libraries in a one-to-one manner:

• HederaTokenService.sol
• ExpiryHelper.sol
• HederaResponseCodes.sol
• KeyHelper.sol

Additionally, a KeysLib.sol contract has been introduced that presumably implements Hedera-specific logic, however, it remains unutilized within the codebase and was marked as such.

Beyond the new contracts introduced for Hedera-related functionality, the system updated its PriceFeed implementation to integrate with the Pyth network and Supra network oracles instead of the Chainlink and Tellor networks respectively.

We identified a flaw in the Pyth network integration and specifically how validation is performed, an issue with how decimals are normalized in the Supra network integration, and a common issue across both oracles that led to price measurements being reported with double the intended accuracy.

To note, the original Liquity system was pricing ETH in relation to USD whereas the HLiquity system prices HBAR in relation to CHF. Accuracy throughout the system has been reduced to 8 decimals to accommodate for the fact that the Hedera native token does not have 18 decimal places.

As a final note, we would like to specify that mentions of "ETH" have not been replaced with "HBAR" which we consider incorrect, as there is no concept of "ETH" within the HLiquity system.

We advise the Swisscoast 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 Swisscoast team iterated through all findings within the report and provided us with a revised commit hash to evaluate all exhibits on.

We evaluated all alleviations performed by Swisscoast and have identified that all non-informational exhibits have been either alleviated or directly acknowledged.

The following informational findings remain either partially or improperly addressed and should be revisited: LBE-01S, HLQ-03M, GPL-02C, PFD-01C

Additionally, clarifications have been introduced to the following exhibits that may prompt a follow-up action even if they have been alleviated / acknowledged: HLQ-04M, HLQ-05M, HCH-02M

Over the course of the audit engagement, an additional issue was discovered by the HLiquity team in relation to their Supra integration and a business requirement was misrepresented in the codebase in relation to front-end rewards.

Specifically, the SupraCaller improperly tracked timestamps as the Supra system represents them in milliseconds whilst the EVM uses seconds. This has been properly alleviated via a millisecond divisor (1_000) imposed on the timestamp yielded by the Supra system.

In relation to the business requirement change, a flaw was identified whereby a transaction would revert if a front-end was attached to a deposit that has not associated itself with the rewarded token. This would only happen if the depositor specified a misconfigured front-end tag and as such is not expected to be normal operation.

The codebase was updated to implement a try-catch mechanism to distribute funds instead of pushing them, avoiding the payment of front-end rewards if the front-end is unable to receive them.

Ignoring the front-end reward may result in the Community Issuance to issue funds at a different rate than expected. We advise the funds meant for the front end to be issued and sent to the depositor instead if the transaction fails, or the front-end tag to be associated with the token at the withdrawer's expense which is a one-time cost that should not impact user experience significantly.

Post-Audit Conclusion (30f7253f63)

The Swisscoast team re-assessed the remaining exhibits that were partially alleviated in the audit report, and proceeded to either fully alleviate or acknowledge them.

Additionally, the last chapter's recommendation of our previous post-audit conclusion was heeded, incorporating a change in the StabilityPool issuance mechanism which will now issue front-end rewards to the depositor if the distribution to the front-end address fails.

We consider all outputs of the audit report properly consumed by the Swisscoast team, with no further remediative actions expected in relation to the audit.

Audit Synopsis

Severity	Identified	Alleviated	Partially Alleviated	Acknowledged
	3	2	0	1
	40	37	0	3
	3	2	0	1
	5	5	0	0
	2	2	0	0

During the audit, we filtered and validated a total of 6 findings utilizing static analysis tools as well as identified a total of 47 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