Market Maker Looping

In the _getUtilizationRate function the priceAdj is computed as:

FixedPointMathLib.divWad(TickMath.getSqrtRatioAtTick(activeTickAdj), FixedPoint96.Q96);

Which has units of the square root of the price. However the priceAdj is compared against the result of getBLV to compute the premiumRatio.

The result of getBLV is a price, instead of a square root price. Therefore the premiumRatio is incorrect.

Square the priceAdj to compute the correct price.

Baseline Team: Resolved.

The _updateTicks logic intentionally assigns the anchorTick such that new bAssets are not minted within the anchor range when the bAssets minted would be in addition to the liquidity in the discovery range.

This is to avoid the following arbitrage attack:

• Anchor liquidity < Discovery liquidity
• An attacker makes a large sell through the discovery range and into the anchor range
• Due to the instantaneous large sell, and the leveraging of the anchor liquidity, the anchor liquidity

becomes greater than the Discovery liquidity

• Now the attacker can buy back the same amount of bAssets but at a lower average price because

of the increased Anchor liquidity relative to the liquidity they sold through.

There is however another similar arbitrage attack which is not protected against:

• Anchor liquidity < Discovery liquidity
• Instead of selling through the discovery range, the attacker sells from the top of the Anchor range
• After the sell, the rebalance causes the higher liquidity discovery range to come down closer to the

new price

• Now the attacker can buy back the same amount of bAssets but at a lower average price because

of the increased Discovery liquidity relative to the liquidity they sold through.

• As long as the leveraging of the Anchor position is not greater than the liquidity difference between

the Anchor and Discovery then this arbitrage is profitable.

Consider rate limiting the amount of ticks that can be dropped at a time to limit the scale of this arbitrage vector.

Baseline Team: Partially Resolved.

The removeAllFrom function in the BPOOL contract reports the entirety of third party liquidity as fees when the liquidityToRemove > currentLiquidity, however the excess liquidity is burned from the msg.sender in the _removeLiquidity function.

This means that the calling contract will think it has more bAssets than it does because the reported bAssetFees_ includes an amount that was burnt from the sender.

During rebalances this results in an underflow DoS when ultimately attempting to send more bAssets then the contract holds to the fee receiver for bAssetFees_.

Do not burn the bAssets from the msg.sender in the _removeLiquidity function when removing third party liquidity.

Baseline Team: Resolved.

The criteria for a bump is described as:

That the total reserves in the system (inclusive of debt), when placed across the anchor position (with no reserves the floor), is enough to buy back the entire circulating supply.

However, in the _canBump function the capacity is calculated with the activeX96 as the upper to the Anchor range.

This is however flawed because the activeX96 may not reside within the new Anchor range. Instead the anchorTick may be selected such that the activeX96 is actually within the Discovery range.

This would not be an issue if the Discovery and Anchor ranges were guaranteed to have the same concentration of reserves.

However it is possible that the Discovery range liquidity is actually lower than the Anchor range liquidity, in which case assuming that the reserves were evenly spread out across this range would underestimate the capacity of the protocol and errantly indicate that a bump would not be possible when in fact it can be.

Consider executing the bump logic after the new anchorTick and liquidities of the Anchor and Discovery ranges have been defined. Then do not allow the bump logic to change the liquidity of the Anchor or discovery.

Baseline Team: Acknowledged.

The _getAnchorReserves function uses the min function between anchorReserves_ and totalReserves - _getVirtualReserves() inside the case where it is already determined that totalReserves - _getVirtualReserves() < anchorReserves_.

Therefore the min computation is unnecessary and the anchorReserves_ can always just be assigned to the totalReserves - _getVirtualReserves() value.

Remove the min computation and always assign the anchorReserves_ to totalReserves - _getVirtualReserves().

Baseline Team: Resolved.

In the _getACU function the activeX96 is declared but never used.

Remove the activeX96 variable from the _getACU function.

Baseline Team: Resolved.

When deploying the threshold liquidity to the Discovery position in the _deployLiquidity function there is no cap on the amount of reserve assets that can be used.

It may be possible in some rare cases that the active price is within the Discovery range during a rebalance and the corresponding reserves requested by the _getThresholdLiquidity result are greater than the amount sitting in the MarketMaking contract due to most of the reserves being virtual reserves.

In this scenario the current logic will revert instead of gracefully handling the conditions, thus preventing a rebalance.

Consider how this edge case should be handled. If a revert is acceptable then consider explicitly reverting in this case.

Otherwise gracefully handle the case where the _getThresholdLiquidity result requests more reserves than are available in the MarketMaking contract, similarly to how this is handled in the _getAnchorReserves function.

Baseline Team: Acknowledged.

In the _getUtilizationRate function the active tick is reduced by the BUMPABLE_PREMIUM which is currently set at 1500 ticks.

In scenarios where the active tick is near the min tick, this will lead to a subsequent revert when attempting to do computations with a resulting tick that is under the min tick.

Ensure that system configurations never allow for any active price to be near the min tick.

Baseline Team: Acknowledged.

In _updateTicks the rebalanceTicks assignment does not take into account where the active price is, but rather purely where the anchorTick was assigned to.

This can result in scenarios where the active price has to travel a minimum distance of 100 ticks to trigger a rebalance, or a maximum distance of 300 ticks to trigger a rebalance.

This makes rebalances less or more responsive during different types of price action which may be unexpected and lead to unintended results.

Consider taking the activeTick into account when assigning the rebalanceTicks so that liquidity rebalances are triggered in a more uniform manner.

Baseline Team: Acknowledged.

In the _removeLiquidity function there is no logic to set aside the reserve assets which may be sitting in the MarketMaking contract before the liquidity positions are removed.

Any reserves which were artificially sent to the MarketMaking contract are able to affect the market making operations because balanceOf is used liberally throughout the logic.

This can potentially be used to manipulate a number of things, notably the anchorTick can be influenced to be the upper or lower tick based upon the buffer reserves which are based upon the balanceOf

Introduce a bufferedReserves approach similar to the previous iteration of the MarketMaking policy:

https://github.com/0xBaseline/baseline-v2/blob/6434202087be8278f09016f28be7dc9933d1085c/

src/policies/MarketMaking.sol#L434

Baseline Team: Acknowledged.

In the BPOOL contract the getBaselineValue function still returns the original baseline value of the lower floor tick instead of the upper floor tick.

Update this function to reflect the real baseline value of the upper floor tick.

Baseline Team: Acknowledged.

The getCirculatingSupply function does not subtract the BPOOL contract balance from it’s result and therefore reports any bAssets sitting in the BPOOL as circulating supply when in fact they should not be.

This does not cause any immediate issues in the market making logic because the BPOOL assets are burned before this function is used. However for integrators and public display via this view function the BPOOL bAsset amount should be removed from the circulating supply result.

Deduct the BPOOL bAssets from the result of the getCirculatingSupply function.

Baseline Team: Acknowledged.

The MarketMaking contract does not impose any validation on the starting value of the blvTick, therefore it is possible that a deployment of the market making policy is based on a blvTick that does not agree with the upper tick of the floor position.

This is currently the case in the TestFoundation as the BaselineInit.launch invocation uses the INITIAL_FLOOR_TICK as the initial floor lower tick while the MarketMaking deployment uses the same INITIAL_FLOOR_TICK as the initial blvTick.

This deployment allows for a scenario where the liquidity structure cannot absorb all supply since funds can initially be borrowed in the credit and looping facilities at a higher baseline value which is based on the upper tick of the floor position rather than the blvTick.

Consider adding validation in the constructor of the MarketMaking policy to ensure that no errant deployments can happen which do not have agreement between the blvTick and the range assigned in the BPOOL module.

Baseline Team: Acknowledged.