Valantis Documentation
Valantis Website
  • Welcome to Valantis
  • Sovereign Pool
    • The Modules
      • Pool Manager
      • Liquidity Module
      • Swap Fee Module
      • Verifier Module
      • Oracle Module
      • Sovereign Vault
        • Rebase token support
      • Gauge
    • Interacting with Pools
      • Swap Parameters
      • Swap Steps
      • Multi Token Support
      • Deposit Liquidity
      • Withdraw Liquidity
      • Flash Loans
  • Hybrid Order Type (HOT)
    • Understanding HOT: A Graphical Overview
    • HOT API
      • HTTP request parameters
      • HTTP request response
      • Reasoning for Request structure
      • Solver Integration
      • Market Maker integration
    • HOT Smart Contracts
      • Interfaces
      • State variables and roles
      • AMM
      • HOT Swap
      • AMM Swap
      • Hybrid Order Type (HOT) struct parameters
      • Alternating Nonce Bitmap
      • Deposits
      • Withdrawals
      • Deployment Assumptions
    • Liquidity Manager Docs
      • Reference Oracle
      • Deposit
      • Withdraw
      • Signature
    • Swap
      • Swap Context
      • AMM Swap
      • HOT Swap
      • HOT Quote Parameters
        • Bitmap Nonce Instructions
    • Solver Docs
      • Solver Request
      • Simple HOT Swap Example
      • Partial Fill HOT Swap Example
    • Risks and Trust Assumptions
      • Roles
        • Sovereign Pool Manager
        • HOT Manager
        • HOT Signer
        • Liquidity Provider
      • Threats
        • Deposit Sandwich
        • Malicious Price Bound
        • Malicious Signer
        • Mispriced HOT Quote
  • Validly
    • Understanding Validly
    • Swap
    • Deposits and Withdrawals
    • Deployments
  • Stake Exchange (stHYPE AMM)
    • Swap
      • Instant Withdrawals (LST -> Native Token)
      • New Stake (Native Token -> LST)
    • LP Positions
      • LP Withdrawals Instant
      • LP Withdrawal Queued
    • Ratio Fee
    • Lending of Reserves
    • Smart contracts
      • STEXAMM.sol
      • StHYPEWithdrawalModule.sol
      • StexRatioSwapFeeModule.sol
      • DepositWrapper.sol
      • AaveLendingModule.sol
    • Risks and Trust Assumptions
    • Integration examples
  • Deploy and Build
  • Resources
    • Audits
    • Links
    • Get HYPE on HyperEVM
Powered by GitBook
On this page

Was this helpful?

  1. Hybrid Order Type (HOT)
  2. HOT Smart Contracts

AMM Swap

One can think of the AMM as a standard UniV3 range order, where sqrtPriceLowX96 and sqrtPriceHighX96 represent the upper and lower bounds of the range. These ranges are determined and actively managed by the liquidityProvider, to provide the best risk-adjusted returns to its users.

The parameters for an incoming AMM swap can look like the following Solidity example:

SovereignPoolSwapContextData memory data;
SovereignPoolSwapParams memory params = SovereignPoolSwapParams({
    isSwapCallback: false,
    isZeroToOne: true,
    amountIn: 1e18,
    amountOutMin: 0,
    recipient: address(this),
    deadline: block.timestamp + 2,
    swapTokenOut: address(token1),
    swapContext: data
});

Note: It is important to leave the swapContext field empty because the HOT differentiates between an HOT swap and an AMM swap by checking if the length of the swapContext.externalContext and the swapContext.swapFeeModuleContext is 0 or not.

Effective Liquidity

AMM swaps can only trade against the liquidity stored in the _effectiveAMMLiquidity variable. The remaining part of the reserves are considered passive ( more about this later ). So there might be cases where the reserves available to the the AMM are low, even though the total reserves deposited in the pool are high. This is intentional since _effectiveAMMLiquidity requires careful security checks before it can be updated, as described below.

Effective AMM Liquidity

HOT assumes that at any point of time reserves can be in any arbitrary composition. This is because incoming HOT swaps can trade at any price and amounts (restricted by some configurable bounds), hence creating a misalignment of reserve amounts that would otherwise be implied by a standard UniV3 range order. Consequently, the fundamental invariants of CPMMs do not hold for the reserves.

To make sure that the AMM works correctly no matter what the reserve composition looks like, we decouple the reserves into 2 categories:

  1. Active Reserves - These are balanced reserves that adhere to the xy=k invariant, and can be utilized by both the AMM and HOT swaps.

  2. Passive Reserves - Any unbalanced reserves that are not part of the active reserves are considered passive. Only HOT swaps can access the passive reserves.

Design Goals:

  1. Minimize the amount of passive reserves in the system, by rebalancing into active reserves at any opportunity we get.

  2. Make sure that the liquidity remains constant (_effectiveAMMLiquidity) before and after any AMM swap.

  3. Utilize the maximum possible amount of active reserves.

We achieve these design goals by calling the _updateAMMLiquidity internal function after any interaction that could potentially change the reserve composition, and if said interaction contains the appropriate number of invariant checks to mitigate the damage from AMM spot price manipulation.

More about the risks, and protections around _updateAMMLiquidity in a separate document.

PreviousHOT SwapNextHybrid Order Type (HOT) struct parameters

Last updated 1 year ago

Was this helpful?