3Jane - Moneymarket

The JANE burn mechanism has some flaws that lead to an unfair and gameable process.

The burn mechanism relies on a snapshot of the borrower’s balance taken only at the time of the first burn in MarkdownController.burnJaneProportional(). Any JANE received after the snapshot is not incorporated into the target burn, causing systematic under-penalization.

MarkdownController.burnJaneProportional() and MarkdownController.burnJaneFull() relies on the transfer freeze mechanism to prevent borrowers from moving their JANE tokens during default. However, once transfers are globally enabled, borrowers can transfer their JANE tokens to other addresses before entering delinquent/default status, effectively avoiding the penalty mechanism.

The penalty does not consider debt magnitude. Two borrowers with equal JANE balances but very different outstanding debts accrue the same burn curve, which is not proportional to credit risk contribution.

Medium. The burn mechanism is not fair and can be gamed.

If the intention is to prevent bad actors farming jane and then defaulting, consider to implement one of the following:

• Replace liquid JANE emissions with a non-transferable, vesting reward token (e.g. veJANE) and have the penalty mechanism burn unvested veJANE. Upon entering delinquent/default status, immediately stop vesting and farming. Take a deterministic snapshot at the state transition, and optionally scale the penalty by outstanding debt for better fairness.
• Allow burning not yet claimed JANE with the function that helps burn unclaimed JANE from the RewardsDistributor using a Merkle proof.

Acknowledged, but will not fix immediately. In the short run, JANE will be non-transferable. We will come up with a better mechanism in the longer term.

Users can repeatedly call cancelCooldown() and startCooldown() to reset their cooldown timer while maintaining shares in an active cooldown state. This allows them to keep shares "ready for withdrawal" without any opportunity cost, effectively bypassing the intended cooldown period protection.

1. No restriction on restarting cooldown: Users can call startCooldown() multiple times, with each call overwriting the previous cooldown state and resetting cooldownEnd to block.timestamp + cooldownPeriod.

2. Shares continue earning yield: Shares placed in cooldown remain as normal sUSD3 shares and continue earning yield from the USD3 strategy. There is no penalty or opportunity cost for having shares in cooldown.

3. Strategic timing advantage: A user can repeatedly call startCooldown() every few days to maintain a rolling cooldown window. When they actually want to withdraw, they only need to wait from their most recent startCooldown() call.

Medium. By allowing cooldown restarts, users can maintain "withdrawal readiness" at all times without opportunity cost.

Implement a snapshot mechanism where shares in cooldown don't earn new yield but are still exposed to losses:

Key principle:

• If share price increases during cooldown → user only gets the snapshotted value (no yield gains)
• If share price decreases during cooldown → user is affected by losses (first-loss protection still works)

1. Update the UserCooldown struct to include snapshotted assets:

struct UserCooldown {
    uint64 cooldownEnd;        // When cooldown expires
    uint64 windowEnd;          // When withdrawal window closes
    uint128 shares;            // Shares locked for withdrawal
    uint256 snapshotAssets;    // Asset value when cooldown started (NEW)
}

1. Modify startCooldown() to snapshot the current value.
2. Update availableWithdrawLimit() to use minimum of snapshot and current value.
3. Update cancelCooldown to burn shares to maintain the same number of underlying.

Notes:
When a user withdraws with the snapshot mechanism and the share price has increased:

1. User receives snapshotAssets (lower than current value)
2. But shares are burned from the total supply
3. The difference between the current share value and the snapshotted value remains in the contract
4. This immediately increases the price per share for remaining users

Acknowledged, but will not fix in the current release. We will fix in a subsequent release.

The USD3 contract enforces a minimum commitment period to prevent users from withdrawing immediately after depositing. However, the implementation stores only the depositTimestamp and dynamically calculates the commitment end time by reading minCommitmentTime() from the ProtocolConfig. Since minCommitmentTime() reads from ProtocolConfig, any changes to this parameter will retroactively affect all existing depositors.

Low.

Store the commitment end timestamp directly instead of recalculating it dynamically.

Acknowledge.

The _preTransferHook() function in USD3 enforces commitment period restrictions but does not validate whitelist requirements when whitelistEnabled is true. This allows whitelisted users to transfer their USD3 shares to non-whitelisted addresses, effectively bypassing the whitelist access control.

Low

Add whitelist validation to _preTransferHook() when whitelist is enabled.

Acknowledged, will not fix. Whitelist will be disabled soon, and whitelisting can be removed in a future release.

Claimed event docs state the third parameter is:

/// @param totalClaimed The total amount the user has claimed after this claim
event Claimed(address indexed user, uint256 amount, uint256 totalClaimed);

However, the emission passes totalAllocation instead of the updated user total claimed.

Informational.

Emit the updated cumulative user total claimed[user] after state updates:

emit Claimed(user, claimable, alreadyClaimed + claimable);

Addressed in PR#86

getClaimable() returns the user’s uncapped delta totalAllocation - claimed[user] but ignores the global cap based on maxClaimable - totalClaimed. The cap is only enforced during _claim(), where the amount is reduced to the remaining global cap.

Informational.

Change getClaimable() to apply the cap:

function getClaimable(address user, uint256 totalAllocation) external view returns (uint256) {
    if (maxClaimable == 0 || totalClaimed >= maxClaimable) return 0;

    uint256 alreadyClaimed = claimed[user];
    uint256 uncapped = totalAllocation > alreadyClaimed ? totalAllocation - alreadyClaimed : 0;

    uint256 remaining = maxClaimable - totalClaimed;
    return uncapped > remaining ? remaining : uncapped;
}

Acknowledged.

The variable is being cast to its own type

File: src/CreditLine.sol

218: IERC20(marketParams.loanToken).approve(address(MORPHO), cover);

CreditLine.sol#L218

File: src/irm/adaptive-curve-irm/AdaptiveCurveIrm.sol

189: return (coeff.wMulToZero(err) + WAD).wMulToZero(int256(_rateAtTarget));

AdaptiveCurveIrm.sol#L189

File: src/usd3/USD3.sol

713: uint256 newSlotValue = (currentSlotValue & mask) | (uint256(trancheShare) << 32);

USD3.sol#L713

Informational

Simplify the code by removing the unnecessary cast.

fixed PR#88

The identifier is imported but never used within the file.

File: src/CreditLine.sol

8: import {EventsLib} from "./libraries/EventsLib.sol";

CreditLine.sol#L8

File: src/MorphoCredit.sol

18: import {IMorphoRepayCallback} from "./interfaces/IMorphoCallbacks.sol";

27: import {MathLib, WAD} from "./libraries/MathLib.sol"; // (WAD)

MorphoCredit.sol#L18, MorphoCredit.sol#L27

File: src/irm/adaptive-curve-irm/AdaptiveCurveIrm.sol

11: import {ConstantsLib} from "./libraries/ConstantsLib.sol";

16: import {IAaveMarket, ReserveDataLegacy} from "./interfaces/IAaveMarket.sol"; // (ReserveDataLegacy)

AdaptiveCurveIrm.sol#L11, AdaptiveCurveIrm.sol#L16

File: src/usd3/sUSD3.sol

4: import {
5:     BaseHooksUpgradeable, IERC20, IMorphoCredit, IProtocolConfig, IStrategy, Math, SafeERC20, USD3
6: } from "./USD3.sol"; // (SafeERC20)

src/usd3/sUSD3.sol#L4

Informational

Remove unused import to improve code quality

fixed PR#88

The following setters are missing events:

• CreditLine
  setOzd(), setMm(), setProver(), setInsuranceFund()

• MorphoCredit.sol
  setHelper(), setUsd3()

Informational

Consider if an event is missing and add it if needed.

Ack, will not fix. We don't have bytecode headroom in MorphoCredit and CreditLine is immutable and already deployed

CreditLine.settle() accepts an assets parameter that should represent the assets to settle. However, the function always settles the full position and optionally repays using cover, which is passed directly without capping it to assets while it should be capped to the borrower’s actual outstanding debt.

Informational.

Compute the borrower’s current debt and cap cover to that amount. Remove assets from the signature to avoid ambiguity.

Acknowledged, but will not update. CreditLine is already deployed and non-upgradeable. This doesn't rise to the level of an issue that warrants redeployment.

A function already exists to wrap USDC into WASUSDC; it's used as part of repay, but not for full replay.

File: Helper.sol
144:         IERC20(USDC).safeTransferFrom(msg.sender, address(this), usdcNeeded);
145:         IERC4626(WAUSDC).deposit(usdcNeeded, address(this));
// Can be replaced by
144:         _wrap(msg.sender, usdcNeeded);

Helper.sol#L144-L145

Informational

Update the code to remove duplication.

fixed PR#88

NatSpec comment in sUSD3.availableDepositLimit() states the subordination ratio is enforced relative to USD3 total supply, but the implementation uses market debt as the base.

Informational.

Update comments to reflect debt-based subordination enforcement.

fixed PR#88