Maple Finance

Description

In MapleAaveV3Strategy, there are two places where passing an extremely small asset amount (ie. a few wei) to Aave V3 functions would cause a revert:

(1) fundUnderlyingStrategy() only checks that assetsIn_ is non-zero before supplying it to Aave:

require(assetsIn_ > 0, "MAV3S:FUS:ZERO_ASSETS");
// ...
IAavePoolLike(aavePool_).supply(fundsAsset_, assetsIn_, address(this), referralCode);

As described under "Very small supplies can revert" in Finding #1, Aave converts the supplied assets into scaled aTokens. If a very small positive assetsIn_, such as a few wei, converts to zero scaled units, Pool.supply() reverts.

Consequently, a sufficiently small call to fundUnderlyingStrategy() reverts instead of funding Aave. This is unlikely during normal operation because strategy funding amounts should be materially larger than the rounding threshold, and a failed call can be retried with a larger amount.

(2) _harvestAndWithdraw() adds accrued fees to the requested withdrawal and calls Aave whenever the sum is non-zero:

(uint256 delegateFee_, uint256 protocolFee_) = _currentAccruedFees(_currentTotalAssets(aaveToken));
uint256 totalToWithdraw_ = assets_ + delegateFee_ + protocolFee_;
if (totalToWithdraw_ != 0) IAavePoolLike(aavePool).withdraw(fundsAsset_, totalToWithdraw_, address(this));

In Aave V3.4 and earlier, a positive withdrawal reverts when its conversion to scaled units produces zero. This behavior is described under "Ways Pool.withdraw() can revert" in Finding #1.

This can realistically occur when _harvestAndWithdraw(0, address(0)) is used only to accrue fees shortly after the previous accrual. In that case, yieldAccrued_ and the resulting fees can be only a few wei, making totalToWithdraw_ non-zero but too small to burn any scaled aTokens.

The fee-only path is called by fundUnderlyingStrategy(), setStrategyDelegateFeeRate(), and setStrategyProtocolFeeRate(). All three functions are temporarily unavailable until enough additional fees accrue for the scaled withdrawal amount to become nonzero.

The affected deployment surface is limited: of the three identified V3.4-and-earlier markets, two are frozen. The notable remaining market is Aave Horizon, which initially forked Aave V3.3.

Recommendation

Both issues can be fixed operationally.

(1) can be avoided if the operator only performs strategy deposits above a minimum threshold.

(2) will never occur as long as MapleAaveV3Strategy is only used for Aave v3.5+ markets.

Maple: Acknowledged our keeper will have minimums set for deposits and withdrawals alongside this AaveV3 pools we have planned to use are on v3.7.

Cantina: Acknowledged.

Description

In MapleSkyStrategy, availableToWithdraw() converts all sUSDS held to fundsAsset via one previewRedeem() call, and then subtracts the accrued fees:

uint256 currentTotalAssets_ = _currentTotalAssets(psm_, savingsUsds_);uint256 psmPocketLiquidity_ = IERC20Like(fundsAsset).balanceOf(IPSMLike(psm_).pocket());
uint256 grossAvailable_ = _min(currentTotalAssets_, psmPocketLiquidity_);
(uint256 delegateFee_, uint256 protocolFee_) = _currentAccruedFees(currentTotalAssets_);uint256 totalFees_ = delegateFee_ + protocolFee_;
if (grossAvailable_ > totalFees_) availableToWithdraw_ = grossAvailable_ - totalFees_;

However, withdrawals from Sky in the strategy are performed individually. For example, withdrawFromUnderlyingStrategy() performs three separate withdrawals:

1. In _accrueFees(), withdraw the delegate fee
2. In _accrueFees(), withdraw the protocol fee
3. Withdraw assets_

ERC-4626 withdraw() rounds required shares upward. Rounding the delegate fee, protocol fee, and principal separately can consume up to two more sUSDS share units than rounding their aggregate once. Thus, withdrawing the exact value returned by availableToWithdraw() could revert due to insufficient sUSDS shares.

For example:

• Assume:
  • The strategy holds 1,000,000 sUSDS
  • Sky's sUSDS <> USDS exchange rate is 1.05 USDS per sUSDS
  • The delegate fee is 1,000 USDS and the protocol fee is 500 USDS
• previewRedeem(1,000,000e18) returns 1,050,000 USDS.
• availableToWithdraw() therefore returns 1,050,000 - 1,000 - 500 = 1,048,500 USDS.
• Executing withdrawFromUnderlyingStrategy() with assets_ = 1,048,500e18 requires three separately rounded share amounts:

delegate: ceil(1,000e18 / 1.05)       =        952.380952380952380953 sUSDSprotocol: ceil(500e18 / 1.05)         =        476.190476190476190477 sUSDSprincipal: ceil(1,048,500e18 / 1.05)  =    998,571.428571428571428572 sUSDS                                            --------------------------------total:                                  1,000,000e18 + 2 sUSDS

The strategy owns only 1,000,000e18 sUSDS, so the split withdrawals require 2 more share units and withdrawFromUnderlyingStrategy() reverts.

Recommendation

The simplest fix is operational - avoid withdrawing exactly availableToWithdraw() when calling withdrawFromUnderlyingStrategy(). Under normal operation, this shouldn't occur since a single pool will usually not own all assets in a strategy deployed under the strategy manager.

Otherwise, refactor the strategy to perform fee and asset withdrawals together, in a single call to sUSDS.withdraw(), similar to MapleAaveV3Strategy._harvestAndWithdraw().

Maple: Fixed in commit 7fe9bdb.

Cantina: Verified, assets and fees are now withdrawn from Sky in a single call.

Description

There are two ways in which MapleSkyStrategy operations could be blocked due to changes in the configuration of psm_ by Sky governance, which are currently not checked for.

fundUnderlyingStrategy() relies on sellGem() to reject a halted tin

DssLitePsm.sellGem() reverts if tin == type(uint256).max:

function sellGem(address usr, uint256 gemAmt) external returns (uint256 daiOutWad) {    uint256 tin_ = tin;    require(tin_ != HALTED, "DssLitePsm/sell-gem-halted");    daiOutWad = _sellGem(usr, gemAmt, tin_);}

fundUnderlyingStrategy() checks whether tout is set to type(uint256).max, but does not perform the equivalent check for tin before calling sellGem():

require(IPSMLike(psm_).tout() != type(uint256).max, "MSS:FUS:PSM_HALTED");
// ...
uint256 usdsOut_ = IPSMLike(psm_).sellGem(address(this), assetsIn_);

Therefore, if tin is set to type(uint256).max in the PSM, deposits in MapleSkyStrategy are blocked.

This does not create a liveness issue. The revert propagates through the wrapper and prevents the strategy from being funded, which is the desired behavior.

A caged DaiJoin would allow deposits but prevent withdrawals

_withdraw() calls the PSM wrapper's buyGem() function without checking the liveness of the legacy DaiJoin:

sharesBurned_ = IERC4626Like(savingsUsds_).withdraw(requiredUsds_, address(this), address(this));
require(ERC20Helper.approve(usds, psm_, requiredUsds_), "MSS:W:USDS_APPROVE_FAIL");
IPSMLike(psm_).buyGem(destination_, assets_);

UsdsPsmWrapper.buyGem() calls legacyDaiJoin.exit(), which requires DaiJoin.live == 1:

function exit(address usr, uint wad) external {    require(live == 1, "DaiJoin/not-live");    vat.move(msg.sender, address(this), mul(ONE, wad));    dai.mint(usr, wad);    emit Exit(usr, wad);}

In contrast, the wrapper's deposit path calls legacyDaiJoin.join(), which does not check live. If DaiJoin.cage() were called without also halting the PSM, the strategy could continue accepting deposits while all withdrawals would revert.

Recommendation

For the second issue, a possible fix would be to block deposits when withdrawals are not possible, by adding a DaiJoin.live == 1 check in fundUnderlyingStrategy().

Maple: Fixed in commit e25a820.

Cantina: Verified, the recommended fix was implemented. availableToWithdraw() now also returns 0 when live != 1.

Description

setFallbackTout() only rejects type(uint256).max (L244-L258), while LitePSM itself only accepts a tout up to WAD (DssLitePsm L288). During a halt, _gemForUsds() computes to18ConversionFactor * (WAD + fallbackTout) (L459-L464). That overflows for large values, for example type(uint256).max - 1.

assetsUnderManagement() and unrealizedLosses() then revert. That makes MaplePoolManager.totalAssets() revert (L474-L482), which blocks deposits and withdrawals in every pool attached to the Strategy Manager. The Maple Sky docs mention that fallbackTout exists so that AUM doesn't revert during a halt, and Pool Manager invariant C mentions that totalAssets() never reverts. Smaller values above WAD don't revert, but they aren't valid LitePSM fees and only misvalue the position.

Recommendation

Add require(fallbackTout_ <= 1e18), matching LitePSM.

Maple Finance: Fixed in commit badb46e.

Cantina Managed: Verified the fixes, fallbackTout now has a cap of WAD.

Description

removeStrategyManager() only requires assetsOf(address(this)) == 0 (L217), which the docs describe as the pool's position being zero. assetsOf() rounds down, so it is also zero when the pool still holds dust shares, or when the strategy's AUM is zero after a full write-off.

After removal those shares still exist, but they are no longer counted in the pool's totalAssets().

Recommendation

Consider requiring the pool’s share balance to be zero, however with this mitigation it should be ensured strategy removal is not blocked. Otherwise, document this as a known issue.

Maple Finance: This is acknowledged and by design. Whilst it may be possible for a Pool to have shares in a strategy and assetsOf() rounds down to 0 this is required for us to be able to remove strategies without being blocked over if we checked for shares to be zero as well. It is valid for a strategy have a loss leading to shares being worthless and needing to be removed from a Pool.

Cantina Managed: Acknowledged.

Overview

This document covers Aave V3.0.x through V3.7. It assumes that a strategy:

• supplies underlying assets through Pool.supply();
• holds aTokens to earn interest;
• withdraws through Pool.withdraw(); and
• uses aToken.balanceOf(address(this)) to value its position.

Check the implementation deployed on the target market. Aave markets can be upgraded at different times, so the repository's latest version may not match a particular deployment.

Version summary

V3.0.x refers to the final generation in the archived aave-v3-core repository. V3.1 and later refer to aave-v3-origin.

Rounding rules

V3.0.x-V3.4: round half up

These versions round each conversion to the nearest integer. An exact half rounds up.

scaled amount minted on supply  = roundHalfUp(amount * RAY / index)visible aToken balance           = roundHalfUp(scaled balance * index / RAY)scaled amount burned on withdraw = roundHalfUp(amount * RAY / index)

See the V3.4 scaled mint and burn code and WadRayMath.rayDiv().

V3.5-V3.7: explicit rounding

RAY = 1e27
scaled amount minted on supply  = floor(amount * RAY / index)visible aToken balance           = floor(scaled balance * index / RAY)scaled amount burned on withdraw = ceil(amount * RAY / index)

See V3.5 TokenMath.

Supply can mint a different amount of visible value

Applies to: V3.0.x-V3.7, with different rounding behavior.

Do not assume:

aToken balance increase == supplied amount

Measure the balance change if the exact result matters.

Very small supplies can revert

Applies to: V3.0.x-V3.7, with different thresholds and errors.

The V3.5-V3.7 rule is stricter. For example, when the index is just above 1e27, supplying one smallest unit produces zero shares in V3.5-V3.7. Under half-up rounding, it normally still produces one share until the index is greater than about 2e27.

Partial withdrawals can change the aToken balance by a different amount

Applies to: V3.0.x-V3.7, with different rounding behavior.

Do not assume:

aToken balance decrease == withdrawn amount

This matters most for very small withdrawals. Batch withdrawals where possible.

Withdrawing everything

Applies to: V3.0.x-V3.7. The implementation changed in V3.5.

Passing type(uint256).max to Pool.withdraw() requests the user's entire position.

See the V3.4 full-withdraw path and the V3.5 full-withdraw path.

Calling withdraw(aToken.balanceOf(user)) in the same state should also burn the full scaled balance in all reviewed versions.

balanceOf() rounding

Applies differently across versions.

Scaled accounting remains exact. If a strategy must never overstate assets on an older deployment, it should not assume that the old balanceOf() result is a lower bound.

Other integration pitfalls

First supply may enable collateral

Applies to: V3.0.x-V3.7, but collateral eligibility changed.

A first supply can automatically mark the asset as collateral when the asset is eligible for the user's current configuration.

See the V3.6 automatic-collateral changes and the V3.7 isolated-eMode rules.

V3.5 also fixed an older collateral-flag edge case. In V3.0.x-V3.4, a partial withdrawal could round to all remaining shares without clearing the collateral flag because the requested amount was not equal to the previously calculated visible balance. V3.5-V3.7 clear the flag based on whether the scaled balance is actually zero after the burn.

If the same strategy address has Aave debt, withdrawals may be blocked by health-factor or LTV-zero rules. A dedicated supplier strategy should normally avoid borrowing from the same address.

Raw aToken-contract balance is not always Aave liquidity

Applies differently across versions.

IERC20(asset).balanceOf(aToken)

V3.1 introduced optional virtual accounting. V3.4 made it active for every reserve. See the V3.1 design and V3.4 virtual-accounting change.

For V3.4-V3.7, the physical balance should normally be at least the virtual balance. This is one of the Pool's invariants.

No built-in slippage arguments

Applies to: V3.0.x-V3.7.

Pool.supply() and Pool.withdraw() do not accept minimum-share or maximum-share arguments.

If the strategy needs this protection, it can measure balances before and after the call and revert when the result is outside its allowed range. Reverting the strategy transaction also reverts the Aave operation.

Ways Pool.supply() can revert

Aave validation and rounding errors

Configured Aave component failure

Applies to: V3.0.x-V3.7.

Supply can also revert if:

• the interest-rate strategy reverts;
• the incentives or rewards controller reverts while handling the aToken mint;
• the aToken or variable-debt token implementation is broken or misconfigured; or
• an upgrade introduces incompatible behavior.

V3.4 made the standard rewards controller and several other addresses immutable, but external component calls can still fail.

Ways Pool.withdraw() can revert

Aave validation and rounding errors

A frozen reserve does not block withdrawals in any reviewed version.

For a dedicated supplier strategy with no Aave debt, the health-factor and LTV errors should not occur.

Not enough accounted liquidity

Applies to: V3.0.x-V3.7, but the liquidity source changed.

This can happen even when aToken.balanceOf(strategy) is large enough, because aToken balance is a claim and not a promise that all underlying cash is currently available.

Configured Aave component failure

Applies to: V3.0.x-V3.7.

Withdrawal can also revert if:

• the interest-rate strategy reverts;
• the incentives or rewards controller reverts while handling the aToken burn;
• the aToken or variable-debt token implementation is broken or misconfigured; or
• an upgrade introduces incompatible behavior.

Description

MapleStrategyManager.fundStrategyManager() records the strategy's AUM before funding and uses it to calculate the shares minted for the deposit:

uint256 totalAssetsBefore_ = assetsUnderManagement();
IPoolManagerLike(poolManager_).requestFunds(underlyingStrategy_, assetsIn_);
uint256 assetsDeposited_ = IUnderlyingStrategyLike(underlyingStrategy_).fundUnderlyingStrategy(assetsIn_, data_);uint256 sharesMinted_    = _convertToShares(assetsDeposited_, totalAssetsBefore_);

_convertToShares() only checks if totalShares is zero:

function _convertToShares(uint256 assets_, uint256 totalAssets_) internal view returns (uint256 shares_) {    uint256 totalShares_ = totalShares;
    if (totalShares_ == 0) return assets_;
    shares_ = assets_ * totalShares_ / totalAssets_;}

Assume a MapleStrategyManager has the following state:

• totalShares != 0
• The underlying strategy has an unrealized loss greater or equal to 100% of AUM

If it realizes that loss, assetsUnderManagement() becomes zero while totalShares remains non-zero. All future deposits via fundStrategyManager() revert due to a division-by-zero in _convertToShares(), so the strategy manager becomes permanently DOSed.

This could realistically occur if the amount of assets in the strategy is small.

Recommendation

Strategy managers whose underlying strategy realizes a complete loss must be shut down and removed from all pools permanently. This is enforced in code of the Aave and Sky strategies. The allocation strategy does not enforce this, therefore, it must be handled operationally.

Maple: Acknowledged and will be clearly documented as the recommendation is the intended procedure.

Cantina: Acknowledged.

Description

MapleSkyStrategy._gemForUsds() estimates the amount of fundsAsset that will be received from buyGem() for a given usdsAmount_, by applying the conversion factor and fee in one calculation:

function _gemForUsds(address psm_, uint256 usdsAmount_) internal view returns (uint256 gemAmount_) {    uint256 tout_                 = _getTout(psm_);    uint256 to18ConversionFactor_ = IPSMLike(psm_).to18ConversionFactor();
    gemAmount_ = (usdsAmount_ * WAD) / (to18ConversionFactor_ * (WAD + tout_));}

However, UsdsPsmWrapper.buyGem() first rounds the fee down and then adds it to the base USDS amount:

uint256 gemAmt18 = gemAmt * to18ConversionFactor;usdsInWad = gemAmt18 + gemAmt18 * psm.tout() / WAD;

When the fee calculation has a remainder, the PSM can therefore sell one more gem unit than _gemForUsds() reports for the same USDS amount. For example, consider the followng example, which has:

• Gem as USDC, which means to18ConversionFactor = 1e12
• A fee of approximately 0.1% (tout = 0.001e18 + 500_000)

For gemAmt = 100e6 + 1, the calculation in buyGem() would be:

gemAmt = 100e6 + 1gemAmt18 = (100e6 + 1) * 1e12 = (100e18 + 1e12)
usdsInWad = (100e18 + 1e12) + (100e18 + 1e12) * (0.001e18 + 500_000) / 1e18 = 100_100_001_001_050_000_000

For the same USDS amount, the calculation in _gemForUsds() is:

(100_100_001_001_050_000_000 * 1e18) / (1e12 * (1e18 + (0.001e18 + 500_000))) = 100_000_000  // 100 USDC

Thus, buyGem() can purchase 100.000001 USDC with the supplied USDS, while _gemForUsds() reports only 100 USDC, underestimating the position by one USDC unit.

Since _gemForUsds() is used to calculate the strategy's current total assets, assetsUnderManagement() and availableToWithdraw() can be understated by one fundsAsset unit. However, this does not seem to have more severe impacts since underestimating both values are safe.

Recommendation

After calculating the conservative estimate, check whether the available USDS can purchase one additional gem unit using the PSM's exact rounding order:

function _gemForUsds(address psm_, uint256 usdsAmount_) internal view returns (uint256 gemAmount_) {    uint256 tout_                 = _getTout(psm_);    uint256 to18ConversionFactor_ = IPSMLike(psm_).to18ConversionFactor();
    gemAmount_ = (usdsAmount_ * WAD) / (to18ConversionFactor_ * (WAD + tout_));
    uint256 nextGemAmt18_ = (gemAmount_ + 1) * to18ConversionFactor_;    uint256 nextUsdsAmount_ = nextGemAmt18_ + nextGemAmt18_ * tout_ / WAD;
    if (nextUsdsAmount_ <= usdsAmount_) gemAmount_++;}

Maple: Acknowledged, we'll keep the code as is. Our view is in the case of a +ve tout the strategy will not be used and unwound and as the rounding causes 1 wei of precision loss this is acceptable without over complicating the calculation.

Cantina: Acknowledged.

Description

While the PSM is halted, funding and withdrawals revert, but both fee setters still reset lastRecordedTotalAssets to a fallbackTout-based valuation when no fees are due (L307, L331). When _accrueFees() has a non zero fee to pay, they revert with an arithmetic panic in _usdsForGem() (L477-L483) instead of a clear error.

Recommendation

Block both fee setters while the PSM is halted, as fundUnderlyingStrategy() already does (L148).

Maple Finance: Fixed in commit 46378ce.

Cantina Managed: Verified the fixes.

Description

1. _usdsForGem() overflows during a PSM halt. It reads the raw tout() instead of fallbackTout (L477-L483), so a fee harvest during a halt reverts with an arithmetic panic rather than a clear error.
2. A Strategy Manager is stuck if its delegate is de-listed before activation. De-listing is only blocked once the Strategy Manager is active (L294). Before that, it succeeds, and the Strategy Manager can't be activated (L169) or handed over (L416) until the same address is re-listed.

Recommendation

1. Revert with a clear error in _usdsForGem() while the PSM is halted.
2. Let the OA hand over an inactive Strategy Manager.

Maple Finance:

1. We are happy with the arithmetic panic whilst the PSM is paused, our system won't be sending txns during this period and a PSM pause will be monitored.
2. This will be operationally managed.

Cantina Managed: Acknowledged.

Maple engaged with Cantina to conduct a security review of the Modular Release. We would like to thank the Maple team for their responsiveness and constructive engagement throughout the review process. No critical, high or medium-severity issues were identified and all of the findings are low-severity and informational. Provided the trust assumptions hold, we expect the release to operate as intended.

• Strategy Delegates are trusted, like Pool Delegates. A delegate sets its own fee rate and can fund and operate its strategy even while it is impaired. The Operational Admin is trusted to reassign a delegate only for an agreed handover.
• Liquidity bots and the Liquidity Router are trusted, Maple-operated infrastructure. Caps limit how much capital they move, not when. Strategy Manager redemptions have no queue and are assumed to be processed in the order they were requested.
• Managed wallets are trusted, Maple-operated addresses. Capital deployed to a wallet leaves on-chain control, and the yield a wallet reports through realizeYield() is taken as given, within yieldCap and the hourly cooldown.
• Impairments, loss recognition, yield cancellation and Sky's fallbackTout are discretionary operator inputs, used without proof or delay. They directly set the price at which pools exit a strategy.
• Aave, Sky's LitePSM and sUSDS are assumed to account correctly. Positions are valued from their live balances and conversion rates, with no independent oracle.
• Allocation yield is released into AUM linearly, so it goes to whoever holds Strategy Manager shares while it vests, not to whoever held them when it was earned. Bots are assumed to avoid funding or redeeming pools on a shared Strategy Manager while a large amount of yield is still vesting.
• Strategy Managers and Pool Managers are assumed to be created only through the Strategy Deployer and Pool Deployer, with a non-zero bootstrap set in Globals. The upgrade procedure is assumed to drain the legacy Aave and Sky strategies before each pool is migrated.

The Modular Release replaces the one-to-one link between a Maple Pool and its strategies with shared strategies. A MaplePoolManager can now fund Strategy Managers, which combine capital from several Pool Managers into one underlying position. It does this alongside the strategies it owns directly; after the upgrade, the only one left is the Open Term Loan Manager.

Each modular strategy is a pair of contracts, deployed and wired together in one transaction by MapleStrategyDeployer. MapleStrategyManager tracks each Pool Manager's position with internal, non-transferable shares, enforces caps and handles redemptions. It never holds assets, and reads assetsUnderManagement() and unrealizedLosses() directly from its underlying strategy. Funding mints shares against current AUM. Redemptions take two steps, a request and then processing, and pay out at AUM minus unrealized losses.

There are three underlying strategies:

• MapleAaveV3Strategy supplies to an Aave V3 (or SparkLend) reserve.
• MapleSkyStrategy converts the funds asset to USDS through Sky's LitePSM and deposits it into sUSDS. It values the position net of the PSM's tout.
• MapleAllocationStrategy sends capital to Maple-managed wallets that deploy it off-chain. Wallets report yield in cash through realizeYield(), which takes fees up front and releases the rest into AUM linearly.

The Aave and Sky strategies charge delegate and protocol fees on growth since the last checkpoint, and pay them out on every interaction.

The release also upgrades existing contracts:

• Pool Manager v500 adds Strategy Manager support, per-strategy caps and a rewritten requestFunds(), and drops Pool Delegate Cover and cyclical withdrawal managers.
• MaplePoolManagerMigratorV500 removes fixed-term loan managers and legacy Aave and Sky strategies during the upgrade.
• MapleGlobals adds a Strategy Delegate registry, which binds each delegate to one Strategy Manager, and an allowlist for managed wallets.
• The queue MapleWithdrawalManager now checks the Pool Permission Manager in removeSharesById().