VMP-12 - Create Market - ETH/USD(USDT) Perpetual

🗳️ Governance Proposals Market Proposals
1

VMP-12 - Create Market - ETH/USD Perpetual

This is a perpetual futures market for Ethereum (ETH) denominated in USD and settled in USDT.

Market Summary:
Name:
ETH/USD(USDT) PERPETUAL

Settlement asset:
USDT

Rationale:
ETH is the second-largest Crypto asset with one of the highest trading volumes.

Market Details:
Instrument:
ETH/USD(USDT)-PERP

Data source definition for the settlement data oracle:
Chainlink Oracle

Risk model:
Log-Normal

Liquidity monitoring parameters:

        "liquidityMonitoringParameters": {
          "targetStakeParameters": {
            "timeWindow": "3600",
            "scalingFactor": 1
          },
          "triggeringRatio": "0.7",
          "auctionExtension": "1"
        },

Price monitoring parameters:

        "priceMonitoringParameters": {
          "triggers": [
            {
              "horizon": "43200",
              "probability": "0.9999999",
              "auctionExtension": "300"
            }
          ]

Full Proposal JSON:

{
  "rationale": {
    "title": "ETH/USD Perpetual",
    "description": "An Ethereum (ETH) Perpetual Market denominated in USD and settled in USDT"
  },
  "terms": {
    "newMarket": {
      "changes": {
        "linearSlippageFactor": "0.001",
        "quadraticSlippageFactor": "0",
        "decimalPlaces": "2",
        "positionDecimalPlaces": "3",
        "instrument": {
          "name": "ETH/USD PERPETUAL",
          "code": "ETHEREUM.PERP",
          "perpetual": {
            "settlementAsset": "bf1e88d19db4b3ca0d1d5bdb73718a01686b18cf731ca26adedf3c8b83802bba",
            "quoteName": "USDT",
            "dataSourceSpecForSettlementData": {
              "external": {
                "ethOracle": {
                  "address": "0x5f4eC3Df9cbd43714FE2740f5E3616155c5b8419",
                  "abi": "[{\"inputs\":[],\"name\":\"latestAnswer\",\"outputs\":[{\"internalType\":\"int256\",\"name\":\"\",\"type\":\"int256\"}],\"stateMutability\":\"view\",\"type\":\"function\"}]",
                  "method": "latestAnswer",
                  "normalisers": [
                    {
                      "name": "eth.price",
                      "expression": "$[0]"
                    }
                  ],
                  "requiredConfirmations": 3,
                  "trigger": {
                    "timeTrigger": {
                      "every": 30
                    }
                  },
                  "filters": [
                    {
                      "key": {
                        "name": "eth.price",
                        "type": "TYPE_INTEGER",
                        "numberDecimalPlaces": 8
                      },
                      "conditions": [
                        {
                          "operator": "OPERATOR_GREATER_THAN_OR_EQUAL",
                          "value": "0"
                        }
                      ]
                    }
                  ]
                }
              }
            },
            "settlementScheduleProperty": {
              "internal": {
                "timeTrigger": {
                  "conditions": [
                    {
                      "operator": "OPERATOR_GREATER_THAN_OR_EQUAL",
                      "value": "0"
                    }
                  ],
                  "triggers": [
                    {
                      "every": 1800
                    }
                  ]
                }
              }
            },
            "dataSourceSpecBinding": {
              "settlementDataProperty": "eth.price",
              "settlementScheduleProperty": "vegaprotocol.builtin.timetrigger"
            }
          }
        },
        "metadata": [
          "base: ETH",
          "quote: USDT",
          "class: crypto",
          "perpetual",
          "sector: defi",
          "enactment: 2023-11-15T01:00:00Z" 
        ],
        "priceMonitoringParameters": {
          "triggers": [
            {
              "horizon": "43200",
              "probability": "0.9999999",
              "auctionExtension": "300"
            }
          ]
        },
        "liquidityMonitoringParameters": {
          "targetStakeParameters": {
            "timeWindow": "3600",
            "scalingFactor": 1
          },
          "triggeringRatio": "0.7",
          "auctionExtension": "1"
        },
        "logNormal": {
          "tau": 0.000009506426342,
          "riskAversionParameter": 0.000001,
          "params": {
            "mu": 0,
            "r": 0.016,
            "sigma": 1.5
          }
        },
        "liquiditySlaParameters": {
          "priceRange": "0.03",
          "commitmentMinTimeFraction": "0.85",
          "performanceHysteresisEpochs": "1",
          "slaCompetitionFactor": "0.5"
        }
      }
    },
    "closingTimestamp": 1699966800,
    "enactmentTimestamp": 1700010000
  }
}

Request for feedback:

  • Risk params
  • SLA Params
  • I’ve left metadata blank, will its current form cause an issue?

Q:

  • How does vega read the price of USDT? as the ETH Oracle from chainlink is ETH/USD and not USDT. So what happens in the event of a USDT depeg?
2

The data source spec binding needs to be changed like so to work.

3

@Jubi How does vega read the price of USDT? as the ETH Oracle from chainlink is ETH/USD and not USDT. So what happens in the event of a USDT depeg?

–

Vega doesn’t know the price of USDT in dollars. It’s a good point that you’ve highlithed, that this contract is essentially a quanto.

Ultimately if USDT depegs, ETH will trade higher vs USDT, but the Chainlink oracle would still be coming through with the USD spot price. If the market on Vega was mistakenly mispriced, then there would be huge funding payments to account for the discrepency and bring it back inline.

This question makes me think it would be useful to have a USD-USDT perp on Vega if we can get an oracle for it.

4

Given the above, it may be clearer to rename USDT to USD in the relevant sections.

I believe the metadata fields are used by Console for some things, so if you want the market to work nicely on Console they’re probably worth adding in.

1 Like
5

Just wanted to share some thoughts on the SLA settings for our ETHUSDT market and see if we could give our market makers a better playground. Check out the tweaks I’m thinking about:

"liquiditySlaParameters": {
    "priceRange": "0.07",
    "commitmentMinTimeFraction": "0.80",
    "performanceHysteresisEpochs": "1",
    "slaCompetitionFactor": "0.7"
}

Keeping commitmentMinTimeFraction at 0.80 : I reckon 80% is a good middle ground. It’s enough to make sure our market’s liquid while not tying down MMs when there is a bug with datanodes / endpoints etc etc.

I’m really keen to hear what you all think. Will these changes make our market more dynamic and encourage some healthy competition? Maybe even up the game for quality liquidity? If you’ve got a take or a suggestion, let’s hear it.

My goal is to see MMs rewarded for both their size in the market and the quality of their liquidity. So that little efficient player can contribute and compete to big size MM.

1 Like
6

Hi Jubi,

It’s great to see the first Perp proposal hit the forums!

I have a few thoughts on the SLA parameters. A “commitmentMinTimeFraction” of 0.1 strikes me as being very low. This would only enforce LPs to quote at least 10% of the time. If the competition factor was higher then there would still be incentive for LPs to out-quote each other with respect to time on the book, but with a value of 0.2 the penalties are quite mild. I think if the minTimeFraction is going to be low then the competition factor should be 1 to encourage LPs to quote for longer.

That said, I don’t think we want penalties to be too high at least initially because we want to attract liquidity providers to the platform. If penalties are too high then MMs will not bother making liquidity commitments.

I think the idea of missing out on fees for not meeting the SLA will be an acceptable penalty for most MMs but having their bond slashed will act as a deterrent from providing liquidity. So as a result setting the competitionFactor to a high value (1.0) and the minTimeFraction to a moderate value (0.75-0.8) might be better for overall liquidity of the market while still giving LPs enough slack such that they are confident they won’t have their bond slashed.

Not sure about the hysteresisEpochs, larger values would seem to make fee penalties more “sticky”, encouraging LPs to be very consistent.

Can’t comment on the risk params since I’m no Quant. Would be good to have a forum and blog post from the team explaining the risk models and their params for those interested.

As far as I understand it, the market above would essentially just be an ETHUSD Perp that settles with USDT at 1:1 with USD. So if there was a USDT depeg then the market on Vega would be unaware of this and would continue to treat the market as an ETHUSD market. The participants however would likely rapidly exit the market because they would know that the value of any USDT they receive through settlement will not actually reflect the value of their PnL on the market. So in the case that the peg was quickly recovered then everything would be “fine” but in the case where the peg is not recovered then the market would still function but the value of the settlements wouldn’t reflect reality so no one would continue to use the market. It would be interesting if Vega could multiply values from an ETH/USD oracle with those from a USD/USDT oracle to produce an ETH/USDT reference rate, because then you could have an actual ETHUSDT perp.

1 Like
7

I think these values are reasonable, it makes sense to me to start with more forgiving SLA parameters initially. I believe we can adjust them later through governance?

8

I agree, especially on the bond penalties. Capital is already at risk through exposures and trading, I don’t think we should add another layer of risk to MMs, but indeed try to attract more MMs to increase competition

1 Like
9

Looks like you are considering suggesting Chainlink Price oracle, but as far as I can see on the feed it is using 8 Decimals?

1 Like
10

Thanks everyone for the feedback, I’ll edit the minor errors (@daunjuan @jeremy).

Regarding USDT depegging, I wonder if it would make sense to have a smart contract that combines both the ETH/USD and USDT/USD chainlink price feeds to accurately reflect the market as @ed-commodum has alluded to. I think it’s important to ensure that Vega remains robust to potential black swan events, especially when the insurance pool is still immature and the event of bad debt is somewhat avoidable.

Regarding the LP params, here are my updated thoughts:

"liquiditySlaParameters": { 
"priceRange": "0.02",
"commitmentMinTimeFraction": "0.85", 
"performanceHysteresisEpochs": "1", 
"slaCompetitionFactor": "0.5" }

priceRange = 0.02. 2% from mid-market price is fine for BTC and ETH pairs tbh, many other exchanges require this to be a lot less e.g., dYdX is 20bps. I think this is an underlooked parameter at ensuring we have strong liquidity on Vega and stopping LPs from being lazy. dYdX had a massive issue where LPs were just quoting large and wide to farm rewards, I don’t want to see Vega have the same issue.

@davidella agree that 80% seems reasonable for commitmentMinTimeFraction (i’m not sure what I was thinking initially I made the proposal after a long day of work), I think even bumping it to 85% should be fine as other exchanges require a 90%+ uptime. 85% gives some room to account for node errors.

performanceHysteresisEpochs = 1 & slaCompetitionFactor = 0.5:
I think a full epoch is sufficient to penalise MMs when coupled with a moderate level of reward penalisation (slaCompetitionFactore = 0.5). I think 0.7 is a bit too harsh and might end up causing apathy. The above params allow MMs to bounce back quickly with a sufficient level of incentive-slashing as a “slap on the wrist”.

In general the above SLA params will be an interesting section to dive into deeper and see if longer pHE with lower sCF is better for liquidity vs quick but harsher penalties. As an MM would you end up quoting more on another exchange if you know that for the next x days you’re going to earn less on Vega? So i’d assume given epochs are 24 hrs the latter will be better for liquidity.

Pls let me know your thoughts and if we are all rather aligned I will edit the proposal!

1 Like
11

I think these newly proposed parameters are well balanced.

With the one exception being the price range. I still maintain that I think a slightly larger price range is a better option since the probability based liquidity measure in Core will already greatly reduce the allocation of Liquidity fees to LPs that quote farther out than their competitors, so they will struggle to farm fees at the tail end of the price range anyway.

Based on the specs, if an LP quotes outside of the price range then their liquidity does not count towards their commitment, opening them up to performance penalties. I think it makes more sense to allow an LP to meet their commitment and earn marginal fees that epoch rather than apply non-performance penalties to their fees and slashing to their bond for them quoting slightly outside of a tight price range.

So starting off with a slightly more lenient price range and then tightening it later if needed makes sense to me. Keeping all other values in your updated proposal the same, I would propose the following value as a compromise:

 "priceRange": "0.03"
12

Just a question, if the settlementasset is USDT and that one goes to 0, if that is what you are referring to, how would that help?
If the value of USDT goes to 0 it would not matter anyway since that is the asset you would receive when closing positions?

13

Good point @duanjuan. I think it can still open up vega to adverse scenarios though right?

Some examples I’ve thought about are:

  1. excessive leverage - if USDT is trading at $0.80 yet vega values it at $1, wouldn’t this allow someone to begin leveraging a position (by depositing more USDT) that might not be able to be liquidated given the state of the order book?

  2. Farming rewards - if USDT becomes worthless and vega rewards exist for makers and takers, someone can just run junk volume through the exchange to farm vega rewards.

14

Obviously my replies are hypothetical and are to be viewed as such, as well as the views of me and not Vega.

    • If this was the case, then USDT quantum could be updated, by the community, to be 0.
15

With respect to point 1. If the target stake gets too high because of a large increase in open interest then the market will just go into liquidity auction, the USD-USDT reference rate is pretty much irrelevant in this case. The most relevant aspect I can think of would be that LPs and traders might all withdraw their liquidity and close their positions so that they can withdraw the USDT from Vega and dump it if they think the peg won’t be regained.

If the market used a ETH/USDT oracle then the price volatility of the market in the case of a depeg would be much greater. Think about it, if the market uses ETH/USDT reference rate and the value of USDT halves then the value of ETH/USDT would double. If the market uses ETH/USD reference rate then the halving of the value of USDT won’t affect the price of ETH in the same way because at settlement the price will be the current market price of ETH against USD. The only price movements and volatility you would get on the latter market would be those which are induced by positions rapidly unwinding so that people can dump their USDT.

16

There are some values missing under the perpetual part in order for the proposal to be accepted, you can always test on Fairground before mainnet. What you want the values to be I leave up to you but they are required.

"perpetual": {
              "clampLowerBound": "0",
              "clampUpperBound": "0",
              "interestRate": "0",
              "marginFundingFactor": "0.95",
17

Thanks.

It would be nice to have some MMs or the research team chime in on parameters they feel are suitable.

Looks like at least for Binance and Bitmex the clamp is: (0.05%, -0.05%), but unsure on suitable values for interestRate and marginFundingFactor

18

One more small mistake that needs to be corrected

Should be

"dataSourceSpecForSettlementSchedule": {
                "internal": {
19

If you’re asking about the perp clam settings then I think the ones suggested by @daunjuan are appropriate; these simply allow the funding payment happen without any clamp.

image
image1552Ă—504 49 KB

They correspond to Figure 3 in the diagram posted. Btw. figure is from here.

20

I’d strongly suggest changing the code. “ETHEREUM.PERP” is too generic and and not even correct — the asset is “Ether” not “Ethereum” and the code suggested does not indicate what it is priced in.

Additionally, given that there is an established convention by the community for the dates futures which are named/coded like “BTC/USDT-231231” and “BTC/USDT expiry 2023 Dec 31st” it would be good to retain a similar convention.

Something like “ETH/USD-PERP” and “ETH/USD perpetual” would make sense and address both issues.

It’s worth considering whether the quanto nature of the market described above should be in the name and code too. Perhaps they should… but I am less certain here.

Something like “ETH/USD(USDT)-PERP” and “ETH/USD perpetual (USDT)” would work in that case.