code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-118.feature (about) 1 Feature: Spot market 2 3 Background: 4 Given time is updated to "2024-01-01T00:00:00Z" 5 6 Given the following network parameters are set: 7 | name | value | 8 | network.markPriceUpdateMaximumFrequency | 0s | 9 | market.value.windowLength | 1h | 10 11 Given the following assets are registered: 12 | id | decimal places | 13 | ETH | 2 | 14 | BTC | 2 | 15 16 Given the fees configuration named "fees-config-1": 17 | maker fee | infrastructure fee | 18 | 0.01 | 0.03 | 19 Given the log normal risk model named "lognormal-risk-model-1": 20 | risk aversion | tau | mu | r | sigma | 21 | 0.001 | 0.01 | 0 | 0.0 | 1.2 | 22 And the price monitoring named "price-monitoring-1": 23 | horizon | probability | auction extension | 24 | 360000 | 0.999 | 1 | 25 26 And the spot markets: 27 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | decimal places | position decimal places | sla params | 28 | BTC/ETH | BTC/ETH | BTC | ETH | lognormal-risk-model-1 | 1 | fees-config-1 | price-monitoring-1 | 2 | 2 | default-basic | 29 30 # setup accounts 31 Given the parties deposit on asset's general account the following amount: 32 | party | asset | amount | 33 | party1 | ETH | 10000 | 34 | party1 | BTC | 1000 | 35 | party2 | ETH | 10000 | 36 | party4 | BTC | 1000 | 37 | party5 | BTC | 1000 | 38 And the average block duration is "1" 39 40 # Place some orders to get out of auction 41 And the parties place the following orders: 42 | party | market id | side | volume | price | resulting trades | type | tif | 43 | party1 | BTC/ETH | buy | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GFA | 44 | party5 | BTC/ETH | sell | 1 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 45 46 And the opening auction period ends for market "BTC/ETH" 47 When the network moves ahead "1" blocks 48 Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" 49 And the mark price should be "1000" for the market "BTC/ETH" 50 51 Scenario: Wash trading is not permitted for iceberg orders. The same party has one iceberg order that 52 sits at the back of the queue, another normal order in opposite direction, when the iceberg 53 at the back comes in front the normal order should be stopped. (0014-ORDT-118) 54 55 Given the parties place the following orders: 56 | party | market id | side | volume | price | resulting trades | type | tif | 57 | party4 | BTC/ETH | sell | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 58 | party5 | BTC/ETH | sell | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 59 And the parties place the following iceberg orders: 60 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | 61 | party1 | BTC/ETH | sell | 5 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg1 | 62 When the parties place the following orders: 63 | party | market id | side | volume | price | resulting trades | type | tif | reference | 64 | party1 | BTC/ETH | buy | 20 | 1000 | 2 | TYPE_LIMIT | TIF_GTC | buy1 | 65 66 Then the following trades should be executed: 67 | buyer | seller | price | size | 68 | party1 | party4 | 1000 | 5 | 69 | party1 | party5 | 1000 | 5 | 70 And the orders should have the following states: 71 | party | market id | reference | side | volume | remaining | price | status | 72 | party1 | BTC/ETH | buy1 | buy | 20 | 10 | 1000 | STATUS_PARTIALLY_FILLED | 73 And the iceberg orders should have the following states: 74 | party | market id | reference | side | visible volume | price | status | reserved volume | 75 | party1 | BTC/ETH | iceberg1 | sell | 2 | 1000 | STATUS_ACTIVE | 3 |