code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0024-OSTA-040.feature (about) 1 Feature: 0037-OPEG-020, 0037-OPEG-021 2 3 Background: 4 Given the following network parameters are set: 5 | name | value | 6 | market.liquidity.bondPenaltyParameter | 1 | 7 | network.markPriceUpdateMaximumFrequency | 0s | 8 | limits.markets.maxPeggedOrders | 6 | 9 | validators.epoch.length | 5s | 10 | market.liquidity.earlyExitPenalty | 0.25 | 11 | market.liquidity.stakeToCcyVolume | 1.0 | 12 | market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.19 | 13 | market.liquidity.sla.nonPerformanceBondPenaltyMax | 1 | 14 15 And the liquidity monitoring parameters: 16 | name | triggering ratio | time window | scaling factor | 17 | lqm-params | 0.1 | 24h | 1 | 18 19 And the average block duration is "1" 20 Given the following assets are registered: 21 | id | decimal places | 22 | ETH | 2 | 23 | BTC | 2 | 24 Given the fees configuration named "fees-config-1": 25 | maker fee | infrastructure fee | 26 | 0.01 | 0.03 | 27 Given the log normal risk model named "lognormal-risk-model-1": 28 | risk aversion | tau | mu | r | sigma | 29 | 0.001 | 0.01 | 0 | 0.0 | 1.2 | 30 And the price monitoring named "price-monitoring-1": 31 | horizon | probability | auction extension | 32 | 3600 | 0.999 | 1 | 33 And the liquidity sla params named "SLA": 34 | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | 35 | 0.01 | 0.5 | 1 | 1.0 | 36 37 Scenario: check invalid order types in spot market 38 #while a sell order pegged to the mid price should have it's price rounded down to the nearest market tick size 39 And the spot markets: 40 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | liquidity monitoring | decimal places | position decimal places | sla params | 41 | BTC/ETH | BTC/ETH | BTC | ETH | lognormal-risk-model-1 | 1 | fees-config-1 | price-monitoring-1 | lqm-params | 2 | 2 | default-basic | 42 And the parties deposit on asset's general account the following amount: 43 | party | asset | amount | 44 | party1 | ETH | 100000000 | 45 | party3 | ETH | 2000 | 46 | party4 | ETH | 100000000 | 47 | party4 | BTC | 10000 | 48 And the average block duration is "1" 49 And the parties submit the following liquidity provision: 50 | id | party | market id | commitment amount | fee | lp type | 51 | lp1 | party1 | BTC/ETH | 10000 | 0.001 | submission | 52 And the parties place the following orders: 53 | party | market id | side | volume | price | resulting trades | type | tif | reference | 54 | party3 | BTC/ETH | buy | 100 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | p3b1 | 55 | party3 | BTC/ETH | buy | 10 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | p3b2 | 56 | party4 | BTC/ETH | sell | 10 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | p4s2 | 57 | party4 | BTC/ETH | sell | 1000 | 1900 | 0 | TYPE_LIMIT | TIF_GTC | p4s1 | 58 59 Then the network moves ahead "2" blocks 60 And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 61 Then the market data for the market "BTC/ETH" should be: 62 | mark price | trading mode | horizon | min bound | max bound | target stake | supplied stake | open interest | 63 | 1100 | TRADING_MODE_CONTINUOUS | 3600 | 1055 | 1147 | 10000 | 10000 | 0 | 64 65 Then the following trades should be executed: 66 | buyer | price | size | seller | 67 | party3 | 1100 | 10 | party4 | 68 69 #0024-OSTA-047: Order reason of `ORDER_ERROR_INSUFFICIENT_ASSET_BALANCE` user does not have enough of the asset or does not have an account at all 70 When the parties place the following orders: 71 | party | market id | side | volume | price | resulting trades | type | tif | error | 72 | party3 | BTC/ETH | buy | 100 | 1160 | 0 | TYPE_LIMIT | TIF_IOC | party does not have sufficient balance to cover the trade and fees | 73 74 #0024-OSTA-048:self trade should be stopped 75 When the parties place the following orders: 76 | party | market id | side | volume | price | resulting trades | type | tif | error | reference | 77 | party3 | BTC/ETH | buy | 1 | 1120 | 0 | TYPE_LIMIT | TIF_GFN | | p3-b | 78 | party3 | BTC/ETH | sell | 1 | 1120 | 0 | TYPE_LIMIT | TIF_GFN | | p3-s | 79 80 And the orders should have the following status: 81 | party | reference | status | 82 | party3 | p3-b | STATUS_ACTIVE | 83 | party3 | p3-s | STATUS_STOPPED | 84 85 #trigger auction 86 When the parties place the following orders: 87 | party | market id | side | volume | price | resulting trades | type | tif | 88 | party3 | BTC/ETH | buy | 1 | 1160 | 0 | TYPE_LIMIT | TIF_GTC | 89 | party4 | BTC/ETH | sell | 1 | 1160 | 0 | TYPE_LIMIT | TIF_GTC | 90 91 Then the market data for the market "BTC/ETH" should be: 92 | mark price | trading mode | 93 | 1100 | TRADING_MODE_MONITORING_AUCTION | 94 95 #0024-OSTA-040:IOC; 0024-OSTA-041:FOK; 0024-OSTA-042:GFN; 0024-OSTA-046:order with invalid market ID, 96 When the parties place the following orders: 97 | party | market id | side | volume | price | resulting trades | type | tif | error | 98 | party3 | BTC/ETH | buy | 1 | 1160 | 0 | TYPE_LIMIT | TIF_IOC | ioc order received during auction trading | 99 | party3 | BTC/ETH | buy | 1 | 1160 | 0 | TYPE_LIMIT | TIF_FOK | fok order received during auction trading | 100 | party3 | BTC/ETH | buy | 1 | 1160 | 0 | TYPE_LIMIT | TIF_GFN | gfn order received during auction trading | 101 | party3 | ETH/DEC20 | buy | 1 | 1160 | 0 | TYPE_LIMIT | TIF_GFN | OrderError: Invalid Market ID |