HCHFToken Manual Review Findings

HCH-01M: Inefficient Auto-Renewal Period

Type	Severity	Location
Language Specific		HCHFToken.sol:L58

Description:

The period in which the contract's rent will auto-renew is inefficient as it is not a whole time unit (i.e. X days).

Impact:

Due to the imprecise renew period of 8_000_000 presently defined, it might be difficult to properly synchronize funding the HCHFToken account to pay for its rent.

Example:

Copy
58token.expiry = createAutoRenewExpiry(address(this), 8000000);

Recommendation:

We advise the defaultAutoRenewPeriod as defined in the SafeHTS contract to be utilized which is equivalent to 7_776_000, ensuring that the auto-renewal period cycles every 90 days in accordance to the Hedera blockchain limitation.

Alleviation (04618e407bddce5b22e9cadd787fd3334bd3afe6):

The auto-renewal period has been configured to 7_776_000 per our recommendation, optimizing the system's rent efficiency.

HCH-02M: Insecure Subtraction of Balances

Type	Severity	Location
Mathematical Operations		HCHFToken.sol:L169

Description:

The referenced subtraction performed will be unchecked due to the pragma version of the codebase.

Impact:

Although unlikely, any reduction of the address(this) balance will not be handled and will result in an overflow. While the transaction will properly revert in such a case, we still advise the overflow to be handled distinctly from the treasury-related error.

Example:

Copy
168if (
169    !((_balanceOf(address(this)) - balance) ==
170    amount)
171) revert('The smart contract is not the treasury account');

Recommendation:

We advise it to be safely performed by utilizing the SafeMath::sub function as exposed by the uint256 data type.

Alleviation (04618e407bddce5b22e9cadd787fd3334bd3afe6):

The codebase employs the SafeMath::sub function albeit using non-standard syntax (i.e. directly invoking the library function).

While the exhibit is addressed, we advise the using SafeMath for uint256 syntax to be employed increasing the legibility of the code.

HCH-03M: Inexistent Bypass of Authorization

Type	Severity	Location
Logical Fault		HCHFToken.sol:L77-L80, L82-L85, L87-L90

Description:

The original LUSD token implementation permitted the relevant parties to bypass approvals by performing a direct burn or transfer operation in the HCHFToken::burn, HCHFToken::sendToPool, and HCHFToken::returnFromPool functions, however, the HCHF implementation requires an approval due to the usage of the underlying HTS token system.

Impact:

A functional discrepancy can be observed between the HLiquity implementation and its Liquity equivalent whereby an extra authorization is required for interpool movements.

Example:

Copy
77function burn(address _account, uint256 _amount) external override {
78    _requireCallerIsBOorTroveMorSP();
79    _burn(_account, _amount);
80}
81
82function sendToPool(address _sender, address _poolAddress, uint256 _amount) external override {
83    _requireCallerIsStabilityPool();
84    _transfer(_sender, _poolAddress, _amount);
85}
86
87function returnFromPool(address _poolAddress, address _receiver, uint256 _amount) external override {
88    _requireCallerIsTroveMorSP();
89    _transfer(_poolAddress, _receiver, _amount);
90}

Recommendation:

We advise this trait to be evaluated, and different balance transfer mechanisms to be utilized such as burn and mint operations that would not require authorization if setup correctly.

Alleviation (04618e407bddce5b22e9cadd787fd3334bd3afe6):

The Swisscoast team evaluated this trait and has opted to acknowledge it, considering the surplus approvals required to not be disruptive for users and system contracts alike.

As such, we consider this exhibit acknowledged.

HCH-04M: Inexistent Acceptance of Native Funds

Type	Severity	Location
Logical Fault		HCHFToken.sol:L58

Description:

The HCHFToken will set itself as responsible for auto-renewing its rent, however, it is not capable of accepting native funds (HBAR) to fund the rent during its auto renewal.

Impact:

When rent is enabled for smart contracts on the Hedera blockchain, the HCHFToken will be unable to pay its rent and thus may become disabled unless special mechanisms are used to transfer funds to the contract directly.

Example:

Copy
53IHederaTokenService.HederaToken memory token;
54token.name = _NAME;
55token.symbol = _SYMBOL;
56token.treasury = address(this);
57
58token.expiry = createAutoRenewExpiry(address(this), 8000000);
59
60IHederaTokenService.TokenKey[] memory keys = new IHederaTokenService.TokenKey[](1);
61keys[0] = getSingleKey(KeyType.SUPPLY, KeyValueType.INHERIT_ACCOUNT_KEY, bytes(""));
62
63token.tokenKeys = keys;
64
65(int responseCode, address createdTokenAddress) =
66                    HederaTokenService.createFungibleToken(token, 0, _DECIMALS);

Recommendation:

We advise the contract to have an HCHFToken::receive function introduced, permitting it to be funded with the necessary funds to auto-renew its rent.

Alleviation (04618e407bddce5b22e9cadd787fd3334bd3afe6):

The Swisscoast team clarified that the account responsible for paying the contract's rent is distinct from its contract instance and attached to the same account ID.

It is possible to fund the account directly without executing code on its contract counterpart effectively funding rent costs without a receive function in the contract involved.

We consider the exhibit invalid in light of this information and thus have marked it as nullified.