Loop Updates

The setFundingRate function allows a trusted address to assign the funding rate for the vault, however in almost any circumstance where the fundingRate is updated it will invalidate the funding accounting of the vault.

For example:

• fundingRate is 10% per year
• Position A is opened at year 0 with X collateral
• Position B is opened at year 1 with X collateral
• The vault experiences decay for 1 year collateral: X * 1/e^0.1 = X * 1/1.105 and then gains X collateral
• Vault collateral is now X * (1 + 1/1.105) = 1.905X
• The funding rate is set to 5% per year
• Position A is closed at year 2, the position experiences decay for 2 years at a rate of 5% per year, collateral:

X * 1/e^0.1 = X * 1/1.105 = 0.905X

• The vault experiences decay for 1 year at 5% collateral: 1.905X * 1/e^0.05 = 1.905X * 1/1.051 = 1.813X
• Position A’s collateral is now removed from the vault, collateral left is 1.813X - 0.905X = 0.908
• Position B is closed at year 2, the position experiences decay for 1 year at a rate of 5%, collateral: X *

1/e^0.05 = X * 1/1.051 = 0.951X

• Position B’s collateral is attempted to be removed from the vault, but the vault only has 0.908X collateral

left so the position cannot be fully closed.

The core issue is that every position must be updated to agree with the decay experienced by the vault, if the rate changes then every position must be updated along with the vault to decay at that time with the previous rate.

Updating every position to update the rate is not feasible in an EVM environment, consider restructuring the decay to rely on a single fundingDecayAcc which accumulates for every position in the vault, similar to a rewardsPerShare model.

Every position can be stamped with a last FundingDecayAcc and the decay can be measured as the difference between the latestFundingDecayAcc() - position.lastFundingDecayAcc.

Then the setFundingRate function can simply update the last FundingDecayAcc using the previous rate before assigning the new rate.

Baseline Team: We remediated this by using shares and an ever increasing index to calculate interest.

The closePosition function swaps bAssets for reserves before adding reserves back to the floor position, therefore it is possible for the bAsset sell to break through the floor tick and invalidate BLV.

At the end of closePosition revert if _tradingInFloor is true, similar to in _deleverage.

Baseline Team: Resolved.

In the configureDependencies function the sweepTick, slideTick, and lastDropTimestamp are assigned to their initial values. However there is no access control that prevents the configureDependencies function from being called again.

Consider only assigning these values on the first call to configureDependencies, and if necessary include a separate trusted function to re-assign the values.

Baseline Team: Resolved.

Proof of concept: PoC

The Loops vault decays the debt of every loop position over time and this decay is reported by the totalDebt, however the totalDebt function does not reduce the total circulating supply corresponding to the decay of the total position collaterals.

As a result the decay will invalidate the solvency check and DoS all functionality until funding has been charged.

Charge funding before completing every action in the system that relies on the solvency check, or consider accounting for the circulating supply that would decrease from the decay in the solvency check.

Baseline Team: We’ve added charge funding to every action in MarketMaking and CreditFacility.

In the loop facility fees are often collected to the contract with the _pullReserves function, however there is no functionality to retrieve these fees.

Implement a function similar to the setFeeRecipient function in the CreditFacility to retrieve these fees.

Baseline Team: Resolved.

In the LOOPSv1 module there is no configuration for blast yields in the constructor.

Add blast yields configuration to the constructor.

Baseline Team: Resolved.

Additional debt can now serve as capacity for the Baseline system in the Loops vault. This is accounted for in the CreditFacility but not in the MarketMaking contract.

As a result the capacity checks between the CreditFacility and MarketMaking policies will not agree.

Include the LOOPS.totalDebt() when computing the capacity in the MarketMaking contract.

Baseline Team: Resolved.

Function getFundingSince is not perfectly precise, such that the decay of two time deltas X and Y is not the same as the funding decay of one time delta X + Y. This is important since chargeFunding only updates the last update timestamp for the vault position, not user positions.

Consider this scenario where there is only one open position: 1) 10 seconds pass. 2) Vault is charged funding for 10 second decay. 3) 200 more seconds pass. 4) Vault is charged funding for 200 second decay; User is charged funding for 210 second delay. 5) User sends request to close their position.

Ultimately, the latest position of the vault is not aligned with the latest position of the user due to the imprecision of getFundingSince. The position the user can reduce is greater than the latest vault position, causing an underflow when performing vault.position -= _positionToReduce.

This can be harmful in the case there are multiple open positions, and a single depositor is left hanging and unable to close their position.

Note that this issue is also applicable to the vault.debt -= debtToReduce_; calculation as the debt is also updated when funding is charged.

Change the reduction to:

uint256 amtPosToReduce = vault.position < _positionToReduce - vault.position :
_positionToReduce; vault.position -= amtPosToReduce;
uint256 amtDebtToReduce = vault.debt < debtToReduce_ - vault.debt : debtToReduce_; vault.debt
-= amtDebtToReduce;
bAsset.transfer(msg.sender, amtPosToReduce)

Baseline Team: Since we are no longer decaying users debt separately from the vaults debt this should not be an issue.

In the slide function the reserves of the anchor position are added back to the anchor after potentially extending the Anchor further downwards with a call to _updateTicks.

This can result in the Anchor position having little liquidity or disappearing entirely after the slide operation. This is because the price may have been set less than or equal to the lower end of the Anchor position, in which case there would be no reserves in the liquidity position.

In this case the Anchor position would not be built up again until a sweep occurs, and in the meantime there can be erratic price fluctuations between the floor and discovery which may be far apart.

In these situations consider keeping the Anchor position to the tickSpacing above the current price so that the Anchor does not entirely disappear, but is not extended below the active price because that would require reserves to be pulled from the floor.

Otherwise be aware of this quirk in the system and document it for users and integrators.

Baseline Team: Acknowledged.

In the launch function the pessimisticCapacity includes the floor reserves when stretching the virtual reserves over the entire floor position to compute its worst case capacity.

This incorrectly accounts for stretching out the floor reserves which would actually increase if the price were to rise to the upper floor tick.

This was the original reason why the virtual reserves had to be stretched because they would not receive corresponding reserves in as price rose to the upper tick of the floor.

This accounting is attempted to be fixed by leaving the bAssets of the floor position in the circulating supply, as if they had been swapped out of the floor as price rose.

However this again does not account for the reserves of the floor increasing due to swap input amounts.

Remove the special accounting for the floor position and revert to the original solvency check that was previously present in the launch function, with the one addition of the LOOPS.totalDebt() value in the pessimisticCapacity accounting.

Baseline Team: Resolved.

Since the floor.bAssets will only be nonzero if the price is inside of the floor, the floor.bAssets can just be removed from the subtraction of BPOOL.totalSupply instead of using the special _tradingInFloor case.

Remove the special case handling and remove the floor.bAssets from the subtraction of BPOOL.totalSupply.

Baseline Team: Resolved.

In the getCurrentThreshold the full tick spacing below the sweepTick is computed, however the computation uses a direct subtraction of 200 rather than the T_S constant which is determined by the BPOOL.

Use the T_S rather than a hardcoded spacing of 200.

Baseline Team: Resolved.

The slide function will now no longer move the anchorUpper/discoveryLower tick down, and instead only extend the lower tick of the anchor range downwards.

This is because the _updateTicks function will not update the sweepTick but will set the lower anchor tick as the anchor width below the activeTS which has indeed changed.

This may be expected behavior, if so then consider documenting clearly that the Anchor can exceed the defined width.

Baseline Team: Acknowledged.

In the drop function when the tick range is assigned to the Anchor position in _decrementSweepTick it is possible for the targetSweepTick to be lower than the anchorTickL in rare cases where there is a large gap between the Anchor and Floor ranges which price has traversed.

This will result in an InvalidTickRange revert and disallow the drop from occurring. The workaround is to simply call slide before dropping so that the anchor can sufficiently extend downwards.

Consider adding this case to the return false case in _decrementSweepTick to explicitly revert with the CannotDropDiscovery error or consider adding a revert specific to cases where slide must be called first.

Baseline Team: Resolved.

If _totalCollateral is a very small value such as 20 wei, debt_ =_totalCollateral.mulWad (BPOOL.getBaselineValue()); will output 0 due to precision loss, and the position will increase without a corresponding increase in debt.

Consider validating that the debt is non-zero when opening a position.

Baseline Team: Resolved.

The documentation for function openPosition contains the typo posisble which should be updated to possible.

Update the typo.

Baseline Team: Resolved.

In the openPosition function a refund is issued to the user when the maximum reserves are not fully used, however even when the reservesIn_ == _maxReservesIn the transfer is still initiated.

For some reserve tokens this may cause a revert due to the zero amount transfer. Additionally another potential zero transfer occurs in the closePosition function on line 190.

Add an if case to both of these transfers so that they are only attempted if there is a nonzero transfer amount.

Baseline Team: Resolved.

When deploying the new MarketMaking policy the slideTick will be assigned to the current active tick spacing.

However this tick spacing may be in the current Discovery range, which can lead to a minor unexpected state.

Be sure to deploy the new MarketMaking system when the active price is within the Anchor position.

Baseline Team: Resolved.

When the activeTick is on an even tick spacing and the slideTick is the direct tick spacing above then a user can invoke a slide over and over again.

This is because the criteria for a slide is: activeTick <= slideTick - TS And _updateTicks performs:

slideTick = activeTS.

Consider requiring activeTick < slideTick - TS to trigger a slide.

Baseline Team: Resolved.

Inside _decrementSweepTick the following calculation is performed: uint256 discoveryPremiumTS = uint256(uint24((sweepTick - activeTS) / T_S));

The issue is that the uint24 may potentially cast a negative value, causing silent overflow.

For Example:

• sweepTick = -64400
• activeTS = -64200
• Difference = -200
• (sweepTick - activeTS) / T_S) = -1
• uint24(sweepTick - activeTS) / T_S) = uint24(-1) = 16777215

The discoveryPremiumTS becomes much larger than it should be, which leads to an overflow when performing (tickSpacingsToDecay * T_S).

Consequently, dropping liquidity is prevented from occurring due to panic overflow.

Consider using SafeCast.

Baseline Team: Resolved.