New markets checklist

This section will provide information to determine the parameters for new markets, as well as providing instructions to follow when deploying the new markets.

Parameters for new markets

We divide the parameters into 3 types:

External market parameters

These values are based on the behavior of the block chain (gas costs and maximum gas per transaction).

Business Parameters

These are determined by business requirements.

Market Parameters

Each new market has a set of parameters that are set in market-config-updates.toml. The parameters are listed below with their default values:

• trading_fee_counter_collateral and trading_fee_notional_size: The trading fee is charged by a combination of a ratio of the counter collateral plus a separate ratio of notional size. In addition to providing protocol fees, higher fees provide protection against spot price manipulation attacks by increasing the cost of opening positions. If there were no fee you could update your position's counter-side collateral manipulating utilization ratio without any cost. Reference Reference with sheets

  1. Most assets have the trading_fee_counter_collateral and trading_see_notional_size set at 0.001, but a few assets have both set at 0.002 if their spot markets are more easily manipulated.

• funding_rate_sensitivity This value is always between 1 and 2. The smaller the market, the higher its sensitivity. The current used values are 1, 1.5, and 2. At some point in the future, we can try to identify good reasons to change this from the defaults. For now, follow existing markets for guidance.

• funding_rate_max_annualized: The max annualized unpopular funding rate that is allowed. (This means that funding rate can never be higher than 90% when using default value) Most assets have it set to 0.9. Only a few have it set to 0.45. These are either FX, BTC, Silver and Gold. The markets with lower max funding rates are set that way to support 100x leverage without setting high DNF fees. There markets have a lower funding max rate in order to support 100x. In any case, they are down to 50x leverage.

• borrow_fee_parameters We set the initial borrow rate based on the risk-free return available (usually staking rewards APR). The min and max borrow fees are somewhat arbitrary, intended to ensure LPs receive a reasonable return on their deposits. Follow existing markets.

Further Reading: When you open a position, your max possible gain is locked by the LP. You pay borrow fees to cover the cost of the locked collateral – LP’s cannot withdraw that. Borrow fee is a function of locked collateral (utilization ratio) We have a target utilization ratio – 50% on low market. If it is less than 50%, then borrow fee is decreased We have min and max borrow fees (And max funding rate) Conversation the describes the relationship between borrow fees and utilisation ratio

• target_utilization This is the LP utilisation ratio that we aim for. All assets have it set to 0.5%

• Reference

• On the relationship between target utilisation, and actual utilisation ratio

• Another long conversation from the early days

• exposure_margin_ratio:

This was added to addressed the "delayed trigger" attack:

Delayed trigger

• Attacker opens up a pair of delta neutral positions and allows one of the positions to approach liquidation price. Attacker congests the chain, blocking the ability to liquidate a position as it continues to go further into its liquidation margin. Eventually the position cannot pay out its entire negative price exposure, while its pair position continues to experience gains on its price exposure.
• Mitigated by including an exposure margin and more fully realizing trader losses from the rest of the liquidation margin.
• Mitigated by having bots use very aggressive gas prices for extreme price movements.

• liquidity_cooldown_seconds There is a potential vulnerability that could exploit liquidity providers (LPs) by taking advantage of unrealized profits not affecting LP holdings. The LP price is only updated when trades are closed, meaning liquidity is locked to cover maximum gains without influencing LP value until then. A malicious actor could monitor real-time trades, provide liquidity right before liquidations or stop-loss events, and withdraw rewards at will. They could also farm LP rewards and withdraw them when large positions approach "maximum gain" thresholds, or attempt front-running attacks before a trader closes a position. Since the trading price is settled by oracles, sandwich attacks are unlikely. To mitigate this, we introduced the liquidity cooldown value. Detailed thread can be found here, explaining the need for a liquidity withdrawal cooldown, to avoid any malicious attacks on the LP pools

• liquifunding_delay_seconds This prevents an attack vector from large deposits and withdraws by ensuring that LPs will be exposed to at least one realization of price exposure during their time holding LP tokens.

  • Further Reading
  • On potentially making this random

• liquifunding_delay_fuzz_seconds This is a mechanism to ensure we don't have large groupings of liquifundings at once. The goal is to avoid congestion of the protocol. The concern was an event that caused a bunch of positions to be opened at the same time. We want to smooth out the liquifunding times. Reference

Notes

• COIN_USDC and ETH_BTC are not actually used. They're just for testing