code.vegaprotocol.io/vega@v0.79.0/core/integration/features/amm/0090-VAMM-market-ticks.feature (about) 1 Feature: vAMM rebasing when created or amended 2 3 Background: 4 Given the average block duration is "1" 5 And the margin calculator named "margin-calculator-1": 6 | search factor | initial factor | release factor | 7 | 1.2 | 1.5 | 1.7 | 8 And the log normal risk model named "log-normal-risk-model": 9 | risk aversion | tau | mu | r | sigma | 10 | 0.001 | 0.0011407711613050422 | 0 | 0.9 | 3.0 | 11 And the liquidity monitoring parameters: 12 | name | triggering ratio | time window | scaling factor | 13 | lqm-params | 1.00 | 20s | 1 | 14 15 And the following network parameters are set: 16 | name | value | 17 | market.value.windowLength | 60s | 18 | network.markPriceUpdateMaximumFrequency | 0s | 19 | limits.markets.maxPeggedOrders | 6 | 20 | market.auction.minimumDuration | 1 | 21 | market.fee.factors.infrastructureFee | 0.001 | 22 | market.fee.factors.makerFee | 0.004 | 23 | spam.protection.max.stopOrdersPerMarket | 5 | 24 | market.liquidity.equityLikeShareFeeFraction | 1 | 25 | market.amm.minCommitmentQuantum | 1 | 26 | market.liquidity.bondPenaltyParameter | 0.2 | 27 | market.liquidity.stakeToCcyVolume | 1 | 28 | market.liquidity.successorLaunchWindowLength | 1h | 29 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0 | 30 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 | 31 | validators.epoch.length | 10s | 32 | market.liquidity.earlyExitPenalty | 0.25 | 33 | market.liquidity.maximumLiquidityFeeFactorLevel | 0.25 | 34 #risk factor short:3.5569036 35 #risk factor long:0.801225765 36 And the following assets are registered: 37 | id | decimal places | 38 | USD | 0 | 39 And the fees configuration named "fees-config-1": 40 | maker fee | infrastructure fee | 41 | 0.0004 | 0.001 | 42 43 And the liquidity sla params named "SLA-22": 44 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 45 | 0.5 | 0.6 | 1 | 1.0 | 46 47 And the oracle spec for settlement data filtering data from "0xCAFECAFE19" named "termination-oracle": 48 | property | type | binding | decimals | 49 | prices.ETH.value | TYPE_INTEGER | settlement data | 0 | 50 51 And the oracle spec for trading termination filtering data from "0xCAFECAFE19" named "termination-oracle": 52 | property | type | binding | 53 | trading.terminated | TYPE_BOOLEAN | trading termination | 54 55 56 # tick size is 57 And the markets: 58 | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | tick size | 59 | ETH/MAR22 | USD | USD | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | default-none | termination-oracle | 1e0 | 0 | SLA-22 | 7 | 60 61 # Setting up the accounts and vAMM submission now is part of the background, because we'll be running scenarios 0090-VAMM-006 through 0090-VAMM-014 on this setup 62 Given the parties deposit on asset's general account the following amount: 63 | party | asset | amount | 64 | lp1 | USD | 10000000 | 65 | lp2 | USD | 10000000 | 66 | lp3 | USD | 10000000 | 67 | party1 | USD | 10000000 | 68 | party2 | USD | 10000000 | 69 | party3 | USD | 10000000 | 70 | party4 | USD | 10000000 | 71 | party5 | USD | 10000000 | 72 | vamm1 | USD | 1000000000 | 73 | vamm2 | USD | 1000000000 | 74 75 76 And the parties place the following orders: 77 | party | market id | side | volume | price | resulting trades | type | tif | reference | 78 | lp1 | ETH/MAR22 | buy | 20 | 42 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 79 | party5 | ETH/MAR22 | buy | 20 | 70 | 0 | TYPE_LIMIT | TIF_GTC | lp1-b | 80 | party1 | ETH/MAR22 | buy | 1 | 77 | 0 | TYPE_LIMIT | TIF_GTC | | 81 | party2 | ETH/MAR22 | sell | 1 | 77 | 0 | TYPE_LIMIT | TIF_GTC | | 82 | party3 | ETH/MAR22 | sell | 10 | 140 | 0 | TYPE_LIMIT | TIF_GTC | | 83 | lp1 | ETH/MAR22 | sell | 10 | 140 | 0 | TYPE_LIMIT | TIF_GTC | lp1-s | 84 When the opening auction period ends for market "ETH/MAR22" 85 Then the following trades should be executed: 86 | buyer | price | size | seller | 87 | party1 | 77 | 1 | party2 | 88 89 90 Then the parties submit the following AMM: 91 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 92 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 100 | 90 | 110 | 0.03 | 93 Then the AMM pool status should be: 94 | party | market id | amount | status | base | lower bound | upper bound | 95 | vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 90 | 110 | 96 97 And set the following AMM sub account aliases: 98 | party | market id | alias | 99 | vamm1 | ETH/MAR22 | vamm1-id | 100 101 And the market data for the market "ETH/MAR22" should be: 102 | mark price | trading mode | best bid price | best offer price | best bid volume | best offer volume | 103 | 77 | TRADING_MODE_CONTINUOUS | 99 | 101 | 51 | 45 | 104 105 @VAMM 106 Scenario: AMM exists and trades outside of market tick sizes 107 108 # AMM's has a BUY at 99 so a SELL at that price should match 109 When the parties place the following orders: 110 | party | market id | side | volume | price | resulting trades | type | tif | reference | 111 | party1 | ETH/MAR22 | sell | 1 | 77 | 1 | TYPE_LIMIT | TIF_GTC | | 112 113 # trade was made outside of tick sizes, great 114 Then the following trades should be executed: 115 | buyer | price | size | seller | is amm | 116 | vamm1-id | 99 | 1 | party1 | true | 117 118 119 @VAMM 120 Scenario: pegged orders pegged to non-tick size AMM's 121 122 Then the parties place the following pegged orders: 123 | party | market id | side | volume | pegged reference | offset | reference | 124 | lp3 | ETH/MAR22 | sell | 10 | ASK | 7 | peg-ask | 125 | lp3 | ETH/MAR22 | buy | 10 | BID | 7 | peg-bid | 126 | lp3 | ETH/MAR22 | buy | 5 | MID | 14 | peg-mid-bid | 127 | lp3 | ETH/MAR22 | sell | 5 | MID | 14 | peg-mid-ask | 128 129 # check that the pegged orders are priced on market ticks, moving *towards* the 130 Then the order book should have the following volumes for market "ETH/MAR22": 131 | side | price | volume | 132 | buy | 91 | 5 | 133 | buy | 98 | 10 | 134 | sell | 105 | 10 | 135 | sell | 112 | 5 | 136 137 @VAMM 138 Scenario: Reference price is AMM not at market-tick and pegged offset is 0 139 140 When the parties cancel the following AMM: 141 | party | market id | method | 142 | vamm1 | ETH/MAR22 | METHOD_IMMEDIATE | 143 144 145 # have pegged offset at 0 and at a size of the market tick, they should both get pegged to the same price 146 When the parties place the following pegged iceberg orders: 147 | party | market id | side | volume | peak size | minimum visible size | pegged reference | offset | 148 | lp1 | ETH/MAR22 | buy | 100 | 10 | 2 | BID | 0 | 149 | lp1 | ETH/MAR22 | buy | 100 | 10 | 2 | BID | 7 | 150 | lp1 | ETH/MAR22 | sell | 100 | 10 | 2 | ASK | 0 | 151 | lp1 | ETH/MAR22 | sell | 100 | 10 | 2 | ASK | 7 | 152 # create an AMM outside of tick prices and force a recalculate 153 Then the parties submit the following AMM: 154 | party | market id | amount | slippage | base | lower bound | upper bound | proposed fee | 155 | vamm1 | ETH/MAR22 | 100000 | 0.05 | 100 | 90 | 110 | 0.03 | 156 157 And the network moves ahead "1" blocks 158 Then the order book should have the following volumes for market "ETH/MAR22": 159 | side | price | volume | 160 | buy | 98 | 20 | 161 | sell | 105 | 20 | 162 163