Goldilocks Goldilend update

In renew(), the expression that computes the additional interest for a renewal relies on a ternary without parentheses. In Solidity, arithmetic (+) has higher precedence than the ternary ? :, so the whole expression is parsed incorrectly: the sum happens first, then the boolean comparison, and finally the ternary chooses only the top-up interest, discarding the interest for extending the existing principal.

This almost always evaluates the condition to true and sets newInterest to only the top-up interest, omitting the roll-over interest for the period old end to new end on the already borrowed amount.

High. Borrowers underpay interest on renewals. The protocol loses the interest component for extending the existing debt.

Add parentheses so that only the second addend is conditional:

uint256 newInterest = _calculateInterest(userLoan.borrowedAmount, _outstandingDebt, newEndDate - userLoan.endDate)
    + (newBorrowAmount > 0 ? _calculateInterest(newBorrowAmount, _outstandingDebt, newDuration) : 0);

Fixed here.

The _calculateFairValue function hardcodes the vesting duration to 730 days on line 387:

uint256 vestingDuration = 730 days;

However, the StreamingNFT contract accepts vestingDuration as a constructor parameter, meaning different NFT collections can have different vesting schedules. The function queries the StreamingNFT contract for cliffEndTimestamp, cliffUnlockAmount, and vestedRewards, but incorrectly assumes all collections use a 730-day vesting period.

When calculating the remaining unvested portion (lines 401-403):

uint256 elapsedPortion = FixedPointMathLib.divWad(timeSinceCliff, vestingDuration);
uint256 remainingPortion = 1e18 - elapsedPortion;
vest = FixedPointMathLib.mulWad(remainingPortion, vestedRewards);

The calculation uses a hardcoded value rather than the actual vesting duration from the streaming contract.

Medium.

Fetch the vesting duration dynamically from the StreamingNFT contract.

Fixed here.

deposit() gates the minimum utilization check only if the current supply exceeds liquidityThreshold. The threshold gate is evaluated against the pre-deposit supply, while the utilization ratio uses the post-deposit supply. This allows a deposit that crosses the threshold to bypass the minUtilization constraint.

Medium. The minimum utilization invariant can be bypassed once the deposit pushes supply over the threshold.

Evaluate the threshold against the post-deposit supply:

    uint256 _ghoneySupply = GoldilendDebtAsset(glDebtAsset).totalSupply();
    uint256 newghoneySupply = _ghoneySupply + amount;
+   if (newghoneySupply > liquidityThreshold) {
-   if (_ghoneySupply > liquidityThreshold) {
        if (FixedPointMathLib.divWad(outstandingDebt, newghoneySupply) < minUtilization) {
            revert MinUtilizationExceeded();
        }
    }

Fixed here.

changeGovParams() correctly gates governance parameter changes behind the timelock, but initializeGovParams() sets the same parameters and is callable by multisig without any one-time guard. This lets multisig update governance parameters at any time, bypassing the timelock.

Medium. Undermines governance separation and delay guarantees. multisig can arbitrarily change critical constraints without timelock.

Add a one-time guard to initializeGovParams().

Fixed here.

The _calculateFairValue function in RebaseGoldilend.sol calculates the unvested (locked/not yet vested) value of an NFT, but should calculate the unclaimed (still in the NFT) value.

The function calculates how much value is still locked in vesting schedule, but ignores that vested-but-unclaimed rewards are equally valuable as collateral. This distinction is critical because:

1. When an NFT is transferred to the contract as collateral, the borrower cannot claim rewards
2. As time passes and rewards vest, they remain locked in the NFT
3. Vested rewards are just as much collateral as unvested rewards
4. The function treats them as if they have no value

The calculation progressively reduces collateral value over time, even though nothing has been claimed.

Medium. The most significant impact is on the renew() function. A large amount of tokens is vested at the cliff. If borrowing happens before the cliff, it's likely renew() will not have enough unvested tokens when the user wants to renew.

Calculate unclaimed value instead of unvested value.

Acknowledged. We decided that we only want to consider locked tokens as an extra precaution.

RebaseGoldilend reads the BERA price via deprecated IPythUpgradable.getPrice() and directly uses it inside _calculateFairValue() without any freshness validation, so stale or low-confidence prices can drive collateral valuation. The interface exposes publishTime and conf but they are unused.

Medium. Stale prices can over/under-value collateral, allowing excessive borrowing or inducing improper liquidations. Attackers can exploit delayed updates or poor-quality prices to manipulate borrow limits and auction outcomes.

Switch to getPriceNoOlderThan(). Optionally:

• Enforce a max relative confidence, e.g., conf / |price| ≤ 5%.
• Convert the price using PythUtils.convertToUint() from Pyth sdk.

Fixed here.

renew() intends to allow renewals until endDate + LOAN_GRACE_PERIOD. However, when the caller is within the grace period where block.timestamp >= userLoan.endDate, the subtraction userLoan.endDate - block.timestamp underflows, reverting and preventing renewals even though the previous line permits them up to endDate + LOAN_GRACE_PERIOD.

Low. Borrowers cannot renew during the intended grace period.

-    if(userLoan.endDate - block.timestamp > renewMinDuration) revert InvalidRenew();
+    if(userLoan.endDate + LOAN_GRACE_PERIOD - block.timestamp > renewMinDuration) revert InvalidRenew();

Fixed here.

The interest calculation in _calculateInterest() divides by totalSupply * utilizationRatioMultiplier. Placing the “multiplier” in the denominator means it arbitrarily rescales utilization in the opposite direction (higher multiplier → lower utilization), and it is not specified as a WAD-scaled parameter. This makes the parameter unintuitive and easy to misconfigure.

Low. Parameter semantics are ambiguous and can lead to unintended behavior (e.g. raising the multiplier decreases rates).

Applied multiplicatively to the utilization and make it WAD-scaled:

uint256 utilizationRatio = FixedPointMathLib.divWad(debt + borrowAmount, GoldilendDebtAsset(glDebtAsset).totalSupply());
uint256 ratio = FixedPointMathLib.mulWad(utilizationRatio, utilizationRatioMultiplier) + interestPaymentPercentage;

The variable is WAD-scaled in this commit. Although we want to keep utilizationRatioMultiplier in the denominator as the variable is a constant. The idea is that it will initially be set to 2 and interestPaymentPercentage will be set to 0.75, which then means that the final ratio that gets applied to interest will be between 0.75 and 1.25.

The changeUnvestedWeights function (lines 514-527) allows setting collateral weights without bounds checking:

function changeUnvestedWeights(
    address[] calldata _beras,
    uint256[] calldata _weights,
    address[] calldata _streams
) public {
    if(msg.sender != multisig) revert NotMultisig();
    if(_beras.length != _weights.length) revert ArrayMismatch();
    if(_beras.length != _streams.length) revert ArrayMismatch();
    uint256 weightsLength = _weights.length;
    for(uint256 i; i < weightsLength; ++i) {
        unvestedWeights[_beras[i]] = _weights[i];  // ❌ No validation
        streamingAddresses[_beras[i]] = _streams[i];
    }
}

Weights are used as percentage multipliers in the fair value calculation (line 408):

return FixedPointMathLib.mulWad(vest, formattedBeraPrice) * unvestedWeights[rebaseBera] / 100;

No validation prevents weights > 100 (over-valuing collateral) or weight = 0 (disabling borrowing).

Informational.

Add validation to ensure weights are within acceptable bounds.
You could use a base percentage value of 10_000 to have more flexibility.

Fixed here.

In closeAuction() winner is declared inside the else branch and then referenced after the if/else, which is out of scope and causes a compilation error.

Informational.

Declare winner outside the conditional block.

Fixed here.