Mispriced HOT Quote

In this section we describe several scenarios where HOT Signer provides mispriced HOT quotes, either the AMM spot price update or price quoted to Solvers, or both.

Below we describe several threat scenarios and respective mitigation measures. HOT Liquidity Provider and HOT Signer implementations must be aware of these. In case HOT Liquidity Provider contract manages liquidity reserves on behalf of other users, special consideration needs to be taken into account to ensure that said users are sufficiently protected against worst-case scenarios, while granting the HOT Signer and HOT Liquidity Provider roles with sufficient flexibility to improve the profitability and price risk protection of their LP strategies.

Below we describe several threats and recommend various mitigation procedures:

• Restrict the amount of volume that can be swapped via HOT quotes, for both tokens in the pool.

• Restrict the number of HOT quotes which can land on each block.

• The HOT contract automatically enforces that the AMM spot price update from each HOT is close in relative distance to the one derived from Chainlink price feeds, up to a maximum deviation tolerance. It is recommended that such maximum deviation tolerance is not set too high.

• The HOT contract automatically enforces that the AMM spot price update from each HOT is close in relative distance to the HOT price quoted to the Solver, up to a maximum deviation tolerance in relative distance. It is recommended that such maximum deviation tolerance is set as low as possible (the smallest possible range of price discounts to Solvers, so that they are still incentivized to swap against the Valantis pool).

• AMM swap fees can also be updated via HOT quotes, which can mitigate the effect of mispriced AMM spot price updates. It is recommended that the minimum AMM fee parameter in the smart contract is set high enough so that the HOT Signer cannot set the AMM swap fee too low, which could otherwise expose the pool to unwanted ex-post arbitrage opportunities.

• The HOT contract automatically reverts if the current AMM spot price is far from the price derived from Chainlink price feeds. This is an extra protection condition from either Chainlink oracle failure or AMM spot price manipulation, up to a maximum deviation tolerance. It is recommended that such maximum deviation tolerance is not set too high, at the expense of reduced liveness of the HOT swaps under volatile market conditions.

• If some of the above parameters are not set up appropriately, a malicious or faulty HOT Signer can construct HOT quotes to extract the maximum allowed amount of value on each block (by executing as many round-trip swaps against the pool as the smart contract allows). To mitigate this, HOT Signer should be set up as securely as possible (its signing key is securely stored by custodians or self-hosted, MPC, require multiple signers for each HOT, etc). It is also possible to set up a Verifier Module in the Sovereign Pool to restrict the addresses of Solvers which are allowed to swap using HOT quotes, under the assumption that these Solvers do not collude with the malicious or faulty HOT signer.

• In case some of the above roles are compromised, the HOT Manager can still pause swaps and deposits. HOT Manager must not collude with other roles in the system. It is possible to have fast circuit breakers if the HOT Manager is implemented using an off-chain monitoring service.

The HOT smart contract is meant to be low-level and flexible enough to allow sophisticated HOT Liquidity Providers to reduce exposure to latency arbitrage, while maximizing exposure to non-toxic order flow (coming from Solvers or other sources), using flexible quoting, AMM repricing and rebalancing mechanisms. It is important to set up the whole system in a way that HOT Signer and HOT Liquidity Provider have enough flexibility to achieve their core objectives and mitigate inventory risk, but in a way where they do not become critical points of failure exposed to significant amounts of value leakage. This is especially important if the HOT Liquidity Provider is responsible for managing liquidity on behalf of others. All relevant users of the system must be aware of the risks described above, and we recommend that many of the proposed guidelines are followed, and set up with sensible bounds and constraints.