code.vegaprotocol.io/vega@v0.79.0/core/integration/features/spot/orders/0014-ORDT-088.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 | limits.markets.maxPeggedOrders | 6 | 11 12 Given the following assets are registered: 13 | id | decimal places | 14 | ETH | 2 | 15 | BTC | 2 | 16 17 Given the fees configuration named "fees-config-1": 18 | maker fee | infrastructure fee | 19 | 0.01 | 0.03 | 20 Given the log normal risk model named "lognormal-risk-model-1": 21 | risk aversion | tau | mu | r | sigma | 22 | 0.001 | 0.01 | 0 | 0.0 | 1.2 | 23 And the price monitoring named "price-monitoring-1": 24 | horizon | probability | auction extension | 25 | 360000 | 0.999 | 1 | 26 27 And the spot markets: 28 | id | name | base asset | quote asset | risk model | auction duration | fees | price monitoring | decimal places | position decimal places | sla params | 29 | BTC/ETH | BTC/ETH | BTC | ETH | lognormal-risk-model-1 | 1 | fees-config-1 | price-monitoring-1 | 2 | 2 | default-basic | 30 31 # setup accounts 32 Given the parties deposit on asset's general account the following amount: 33 | party | asset | amount | 34 | party1 | ETH | 10000 | 35 | party3 | BTC | 100 | 36 | party4 | BTC | 100 | 37 | party5 | BTC | 100 | 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_GFA | 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 50 # Place some orders to give price levels in the book 51 And the parties place the following orders: 52 | party | market id | side | volume | price | resulting trades | type | tif | reference | 53 | party1 | BTC/ETH | buy | 1 | 999 | 0 | TYPE_LIMIT | TIF_GTC | buy1 | 54 | party5 | BTC/ETH | sell | 1 | 1001 | 0 | TYPE_LIMIT | TIF_GTC | sell1 | 55 56 57 Scenario: An iceberg order with an ordinary price can be submitted (0014-ORDT-088) 58 59 # Check we can submit a normal GTC iceberg order 60 When the parties place the following iceberg orders: 61 | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | 62 | party1 | BTC/ETH | buy | 10 | 1000 | 0 | TYPE_LIMIT | TIF_GTC | 5 | 2 | post | 63 64 Then the order book should have the following volumes for market "BTC/ETH": 65 | side | price | volume | 66 | buy | 999 | 1 | 67 | buy | 1000 | 5 | 68 | sell | 1001 | 1 | 69 70 71 72 Scenario: An iceberg order with a pegged limit price can be submitted (0014-ORDT-088) 73 74 # Check we can submit a normal pegged iceberg order 75 And the parties place the following pegged iceberg orders: 76 | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | 77 | party1 | BTC/ETH | 5 | 2 | buy | BID | 10 | 100 | 78 79 Then the order book should have the following volumes for market "BTC/ETH": 80 | side | price | volume | 81 | buy | 899 | 5 | 82 | buy | 999 | 1 | 83 | sell | 1001 | 1 |