Deposit

We only allow deposits from the liquidityProvider address. Any logic for handling user deposits needs to be implemented by the liquidityProvider itself. On each deposit, liquidityProvider should approve to HOT contract the amounts of token0 and/or token1 which should be deposited into the Sovereign Pool.

    /**
        @notice Sovereign ALM function to deposit reserves into `pool`.
        @param _amount0 Amount of token0 to deposit.
        @param _amount1 Amount of token1 to deposit.
        @param _expectedSqrtSpotPriceLowerX96 Minimum expected sqrt spot price, to mitigate against its manipulation.
        @param _expectedSqrtSpotPriceUpperX96 Maximum expected sqrt spot price, to mitigate against its manipulation.
        @return amount0Deposited Amount of token0 deposited (it can differ from `_amount0` in case of rebase tokens).
        @return amount1Deposited Amount of token1 deposited (it can differ from `_amount1` in case of rebase tokens).
        @dev Only callable by `liquidityProvider`.
        @dev It assumes that `liquidityProvider` implements sufficient internal protection against
             sandwich attacks or other types of spot price manipulation attacks. 
     */
    function depositLiquidity(
        uint256 _amount0,
        uint256 _amount1,
        uint160 _expectedSqrtSpotPriceLowerX96,
        uint160 _expectedSqrtSpotPriceUpperX96
    ) external onlyLiquidityProvider onlyUnpaused returns (uint256 amount0Deposited, uint256 amount1Deposited)

• A common error while depositing is HOT__depositLiquidity_spotPriceAndOracleDeviation It means that the oracle price is too far away from the current AMM spot price (above maxOracleDeviationBips, in relative distance). To deposit more liquidity a user needs to wait for the oracle price to update, or correct the spot price by making an AMM swap. In the absence of Oracle failure, we can expect the spot and Oracle prices to stay within the set bounds by relying on HOT spot price updates or AMM swap arbitrageurs. (IMP)