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
  • Owner
  • Owner role in STEXRatioSwapFeeModule
  • Owner role in stHYPEWithdrawalModule
  • Owner role in STEXAMM
  • Lending Module in stHYPEWithdrawalModule (AaveLendingModule)
  • stHYPE Protocol (Overseer and stHYPE contracts)

Was this helpful?

  1. Stake Exchange (stHYPE AMM)

Risks and Trust Assumptions

There are two major roles we define the trust assumptions of

  • owner in STEXAMM, stHYPEWithdrawalModule, and STEXRatioSwapFeeModule

  • Lending Protocol pool in AAVELendingModule

  • stHYPE Protocol, particularly the upgradable Overseer.sol and its dependencies

Owner

Owner role in STEXRatioSwapFeeModule

Role:

  • Can change fee parameters without Timelock

    • Swap fees are bounded between 0-5_000 BIPs by the Sovereign Pool

  • Can set the STEX Sovereign Pool only once

Risks:

  • Owner can change parameters for token0-> token1 swaps freely, with the constraint that fees applied are between 0-5_000 BIPs

Owner role in stHYPEWithdrawalModule

Role:

  • Can update the lending module under 3-7 day timelock

  • Can send any amount of token1 to the lending module deposit() function

  • Can withdraw any amount of token1 from the lending module withdraw() function and send it to the pool.

  • Can send the pool's entire token0 balance to the stHYPE Overseer burnAndRedeemIfPossible function, queuing for withdrawal with the Withdrawal Module being the recipient.

Risks:

  • Owner can steal token1 reserves with a minimum 3-day timelock by upgrading the lending module to a malicious contract.

  • The current implementation complies with the fact that no slashing is implemented for HyperEVM nor stHYPE Protocol's Overseer. Once slashing is enabled, the current implementation of stHYPEWithdrawalModule would need to be replaced with one that allows LPs to claim partial amounts of native token withdrawals due to slashing.

Owner role in STEXAMM

Role:

  • Can propose a new Swap Fee Module under 3-7 day timelock

    • Swap fees are always bounded between 0-5_000 BIPs by the Sovereign Pool regardless of Swap Fee Module implementation

  • Can set Pool Manager Fees without timelock

  • Can propose a new Withdrawal Module under a 7-day timelock

  • Can pause swaps and deposits.

Risks:

  • Owner can add non-zero fees for token1 -> token0 swaps under a minimum 3-day timelock bounded between 0-5_000 BIPs

    • This can harm the native integrations of external LST protocols that expect a no-fee rate for token1 -> token0 swaps

  • Can change Pool Manager Fee recipient without timelock

    • Manager Fee Share is only applied to Swap Fees accrued after the change is made

    • Manager Fee share can go as high as 100% of accrued Swap Fees

    • Manager Fee recipients cannot be changed

  • Can steal token0and token1reserves with a minimum of a 7 days timelock by upgrading the Withdrawal Module to a malicious contract.

Lending Module in stHYPEWithdrawalModule (AaveLendingModule)

The integrated lending protocol in Lending Module custodies a portion of token1 reserves determined by `owner`.

Risks:

  • If the integrated lending protocol becomes insolvent or contains faulty withdrawal logic, funds will be lost.

  • If the integrated lending protocol is working correctly but does not have enough liquidity to honor instant withdrawals, then LP withdrawals via STEX AMM `withdraw` would become temporarily blocked. In this scenario, the user is expected to withdraw at a later stage.

  • It is assumed that the lending protocol's depositfunction does not allow for partially deposited amounts. If that is the case, the Lending Module would need to handle refunds of unused token amounts back into the pool.

stHYPE Protocol (Overseer and stHYPE contracts)

stHYPE AMM integrates with the stHYPE Overseer contract for token0 withdrawals, and allows the external custody of up to 100% of the AMMs token0 reserves as Pending Withdrawals. Overseer is upgradable, and stHYPE AMM trusts the management of the stHYPE protocol to manage its stHYPE assets for delayed redemption at its true rate.

This codebase is currently intended to deployed on Hyperliquid's HyperEVM, where slashing is not active. This is why the stHYPEWithdrawalModulecontract always assumes that Overseerwill honor stHYPE withdrawal requests amount at 1:1 rate against Native Token.

PreviousAaveLendingModule.solNextIntegration examples

Last updated 1 month ago

Was this helpful?