diff --git a/CHANGELOG.md b/CHANGELOG.md index 6bdd9320fee..6385141cc07 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -18,6 +18,7 @@ - [9955](https://github.com/vegaprotocol/vega/issues/9955) - Add data node subscription for transaction results. - [10004](https://github.com/vegaprotocol/vega/issues/10004) Track average entry price in position engine - [9825](https://github.com/vegaprotocol/vega/issues/9825) - Remove quadratic slippage. +- [9943](https://github.com/vegaprotocol/vega/issues/9943) - Support amending the order size by defining the target size. ### 🐛 Fixes diff --git a/commands/errors.go b/commands/errors.go index ae9a32091b6..95ec1d3041d 100644 --- a/commands/errors.go +++ b/commands/errors.go @@ -78,6 +78,7 @@ var ( ErrMustBeGreaterThanEnactmentTimestamp = errors.New("must be greater than proposal_submission.terms.enactment_timestamp") ErrMustBeLessThen366 = errors.New("must be less then 366") ErrMustBeAtMost500 = errors.New("must be at most 500") + ErrMustBeSetTo0IfSizeSet = errors.New("must be set to 0 if the property \"order_amendment.size\" is set") ErrMustBeWithinRangeGT0LT20 = errors.New("price range must be strictly greater than 0 and less than or equal to 20") ) diff --git a/commands/order_amendment.go b/commands/order_amendment.go index f1be273ac65..faea3cb8880 100644 --- a/commands/order_amendment.go +++ b/commands/order_amendment.go @@ -68,7 +68,14 @@ func checkOrderAmendment(cmd *commandspb.OrderAmendment) Errors { } } + if cmd.Size != nil { + isAmending = true + } + if cmd.SizeDelta != 0 { + if cmd.Size != nil { + errs.AddForProperty("order_amendment.size_delta", ErrMustBeSetTo0IfSizeSet) + } isAmending = true } diff --git a/commands/order_amendment_test.go b/commands/order_amendment_test.go index 6e0f2c36df7..4a405dcf85b 100644 --- a/commands/order_amendment_test.go +++ b/commands/order_amendment_test.go @@ -26,13 +26,16 @@ import ( commandspb "code.vegaprotocol.io/vega/protos/vega/commands/v1" "github.com/stretchr/testify/assert" + "github.com/stretchr/testify/require" ) func TestCheckOrderAmendment(t *testing.T) { t.Run("Submitting a nil command fails", testNilOrderAmendmentFails) t.Run("amend order price - success", testAmendOrderJustPriceSuccess) - t.Run("amend order reduce - success", testAmendOrderJustReduceSuccess) - t.Run("amend order increase - success", testAmendOrderJustIncreaseSuccess) + t.Run("amend order reduce size delta - success", testAmendOrderJustReduceSizeDeltaSuccess) + t.Run("amend order increase size delta - success", testAmendOrderJustIncreaseSizeDeltaSuccess) + t.Run("amend order setting size delta and size - fails", testAmendOrderSettingSizeDeltaAndSizeFails) + t.Run("amend order update size - success", testAmendOrderJustUpdateSizeSuccess) t.Run("amend order expiry - success", testAmendOrderJustExpirySuccess) t.Run("amend order tif - success", testAmendOrderJustTIFSuccess) t.Run("amend order expiry before creation time - success", testAmendOrderPastExpiry) @@ -61,7 +64,7 @@ func testAmendOrderJustPriceSuccess(t *testing.T) { assert.NoError(t, err.ErrorOrNil()) } -func testAmendOrderJustReduceSuccess(t *testing.T) { +func testAmendOrderJustReduceSizeDeltaSuccess(t *testing.T) { arg := &commandspb.OrderAmendment{ OrderId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", MarketId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", @@ -71,7 +74,7 @@ func testAmendOrderJustReduceSuccess(t *testing.T) { assert.NoError(t, err.ErrorOrNil()) } -func testAmendOrderJustIncreaseSuccess(t *testing.T) { +func testAmendOrderJustIncreaseSizeDeltaSuccess(t *testing.T) { arg := &commandspb.OrderAmendment{ OrderId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", MarketId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", @@ -81,6 +84,29 @@ func testAmendOrderJustIncreaseSuccess(t *testing.T) { assert.NoError(t, err.ErrorOrNil()) } +func testAmendOrderSettingSizeDeltaAndSizeFails(t *testing.T) { + arg := &commandspb.OrderAmendment{ + OrderId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", + MarketId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", + SizeDelta: 10, + Size: ptr.From(uint64(10)), + } + err := checkOrderAmendment(arg) + foundErrors := err.Get("order_amendment.size_delta") + require.Len(t, foundErrors, 1, "expected 1 error on size_delta") + assert.ErrorIs(t, foundErrors[0], commands.ErrMustBeSetTo0IfSizeSet) +} + +func testAmendOrderJustUpdateSizeSuccess(t *testing.T) { + arg := &commandspb.OrderAmendment{ + OrderId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", + MarketId: "08dce6ebf50e34fedee32860b6f459824e4b834762ea66a96504fdc57a9c4741", + Size: ptr.From(uint64(10)), + } + err := checkOrderAmendment(arg) + assert.NoError(t, err.ErrorOrNil()) +} + func testAmendOrderJustExpirySuccess(t *testing.T) { now := time.Now() expires := now.Add(-2 * time.Hour) diff --git a/core/collateral/engine.go b/core/collateral/engine.go index 7e4baad1a1b..bf2c341657a 100644 --- a/core/collateral/engine.go +++ b/core/collateral/engine.go @@ -419,7 +419,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) // see https://github.com/vegaprotocol/vega/pull/2745 for more information e.addAccountToHashableSlice(externalAcc) e.broker.Send(events.NewAccountEvent(ctx, *externalAcc)) - e.log.Info("event emitted for new account", logging.String("accID", externalID)) } // when an asset is enabled a staking reward account is created for it @@ -438,7 +437,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) e.accs[rewardID] = rewardAcc e.addAccountToHashableSlice(rewardAcc) e.broker.Send(events.NewAccountEvent(ctx, *rewardAcc)) - e.log.Info("event emitted for new account", logging.String("accID", rewardID)) } } @@ -456,7 +454,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) e.accs[netTreasury] = ntAcc e.addAccountToHashableSlice(ntAcc) e.broker.Send(events.NewAccountEvent(ctx, *ntAcc)) - e.log.Info("event emitted for new account", logging.String("accID", netTreasury)) } // global insurance for the asset @@ -473,7 +470,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) e.accs[globalInsurance] = giAcc e.addAccountToHashableSlice(giAcc) e.broker.Send(events.NewAccountEvent(ctx, *giAcc)) - e.log.Info("event emitted for new account", logging.String("accID", globalInsurance)) } // pending transfers account @@ -491,7 +487,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) e.accs[pendingTransfersID] = pendingTransfersAcc e.addAccountToHashableSlice(pendingTransfersAcc) e.broker.Send(events.NewAccountEvent(ctx, *pendingTransfersAcc)) - e.log.Info("event emitted for new account", logging.String("accID", pendingTransfersID)) } pendingFeeReferrerRewardID := e.accountID(noMarket, systemOwner, asset.ID, types.AccountTypePendingFeeReferralReward) @@ -508,7 +503,6 @@ func (e *Engine) ensureAllAssetAccounts(ctx context.Context, asset types.Asset) e.accs[pendingFeeReferrerRewardID] = pendingFeeReferrerRewardAcc e.addAccountToHashableSlice(pendingFeeReferrerRewardAcc) e.broker.Send(events.NewAccountEvent(ctx, *pendingFeeReferrerRewardAcc)) - e.log.Info("event emitted for new account", logging.String("accID", pendingFeeReferrerRewardID)) } } diff --git a/core/integration/features/accounts/2943-distressed-trader-has-general-balance.feature b/core/integration/features/accounts/2943-distressed-trader-has-general-balance.feature index 1e1479aff2e..313e15b4efc 100644 --- a/core/integration/features/accounts/2943-distressed-trader-has-general-balance.feature +++ b/core/integration/features/accounts/2943-distressed-trader-has-general-balance.feature @@ -6,10 +6,10 @@ Feature: Distressed parties should not have general balance left | id | quote name | asset | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params | | ETH/DEC20 | ETH | ETH | default-simple-risk-model-3 | default-margin-calculator | 1 | default-none | default-none | default-eth-for-future | 1e6 | 1e6 | default-futures | And the following network parameters are set: - | name | value | - | market.auction.minimumDuration | 1 | - | network.markPriceUpdateMaximumFrequency | 0s | - | limits.markets.maxPeggedOrders | 4 | + | name | value | + | market.auction.minimumDuration | 1 | + | network.markPriceUpdateMaximumFrequency | 0s | + | limits.markets.maxPeggedOrders | 4 | | market.liquidity.providersFeeCalculationTimeStep | 1s | Scenario: Upper bound breached @@ -71,11 +71,11 @@ Feature: Distressed parties should not have general balance left Then the parties submit the following liquidity provision: | id | party | market id | commitment amount | fee | lp type | | lp2 | party3 | ETH/DEC20 | 20000 | 0.1 | submission | - And the parties place the following pegged iceberg orders: + And the parties place the following pegged iceberg orders: | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | reference | | party3 | ETH/DEC20 | 189 | 1 | buy | BID | 189 | 10 | lp2-ice-buy | | party3 | ETH/DEC20 | 117 | 1 | sell | ASK | 117 | 10 | lp2-ice-sell | - + Then the liquidity provisions should have the following states: | id | party | market | commitment amount | status | | lp2 | party3 | ETH/DEC20 | 20000 | STATUS_PENDING | @@ -84,11 +84,11 @@ Feature: Distressed parties should not have general balance left Then the liquidity provisions should have the following states: | id | party | market | commitment amount | status | | lp2 | party3 | ETH/DEC20 | 20000 | STATUS_ACTIVE | - + Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party3 | ETH/DEC20 | buy | 189 | 100 | STATUS_ACTIVE | - | party3 | ETH/DEC20 | sell | 117 | 130 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party3 | ETH/DEC20 | buy | 189 | 189 | 100 | STATUS_ACTIVE | + | party3 | ETH/DEC20 | sell | 117 | 117 | 130 | STATUS_ACTIVE | ## The sum of the margin + general account == 24000 - 10000 (commitment amount) Then the parties should have the following account balances: | party | asset | market id | margin | general | @@ -101,28 +101,28 @@ Feature: Distressed parties should not have general balance left | party1 | ETH/DEC20 | sell | 20 | 1850 | 0 | TYPE_LIMIT | TIF_GTC | ref-3 | Then the mark price should be "120" for the market "ETH/DEC20" Then the liquidity provider fee shares for the market "ETH/DEC20" should be: - | party | equity like share | average entry valuation | - | lpprov | 0.6428571428571429 | 10000 | - | party3 | 0.3571428571428571 | 60000.0000000000000556 | + | party | equity like share | average entry valuation | + | lpprov | 0.6428571428571429 | 10000 | + | party3 | 0.3571428571428571 | 60000.0000000000000556 | And the following trades should be executed: | buyer | price | size | seller | - | party5 | 120 | 20 | party1 | - | party5 | 120 | 20 | party3 | - Then the parties should have the following account balances: + | party5 | 120 | 20 | party1 | + | party5 | 120 | 20 | party3 | + Then the parties should have the following account balances: | party | asset | market id | margin | general | | party3 | ETH | ETH/DEC20 | 3152 | 1040 | Then the parties cancel the following orders: - | party | reference | - | party3 | lp2-ice-sell | - | party3 | lp2-ice-buy | + | party | reference | + | party3 | lp2-ice-sell | + | party3 | lp2-ice-buy | And the parties place the following pegged iceberg orders: | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | | party3 | ETH/DEC20 | 189 | 1 | buy | BID | 189 | 10 | | party3 | ETH/DEC20 | 136 | 1 | sell | ASK | 136 | 10 | - - Then the network moves ahead "10" blocks + + Then the network moves ahead "10" blocks And the parties should have the following account balances: | party | asset | market id | margin | general | diff --git a/core/integration/features/orders/amend-order.feature b/core/integration/features/orders/amend-order.feature index 856b5202e7b..464e3ef56ee 100644 --- a/core/integration/features/orders/amend-order.feature +++ b/core/integration/features/orders/amend-order.feature @@ -40,7 +40,7 @@ Feature: Amend orders | party | reference | price | size delta | tif | error | | myboi | myboi-ref-1 | 2 | 3 | TIF_GTC | OrderError: Invalid Order ID | - Scenario: Reduce size success and not loosing position in order book + Scenario: Reduce size with delta success and not loosing position in order book (0004-AMND-003, 0004-AMND-057) # setup accounts Given the parties deposit on asset's general account the following amount: | party | asset | amount | @@ -61,34 +61,51 @@ Feature: Amend orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | reference | - | myboi | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | - | myboi2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-2 | + | party | market id | side | volume | price | resulting trades | type | tif | reference | + | myboi | ETH/DEC19 | sell | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | + | myboi2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi2-ref-1 | - # reducing size + # reducing size with delta Then the parties amend the following orders: | party | reference | price | size delta | tif | | myboi | myboi-ref-1 | 0 | -2 | TIF_GTC | + And the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 8 | 2 | STATUS_ACTIVE | + # matching the order now # this should match with the size 3 order of myboi - Then the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | reference | - | myboi3 | ETH/DEC19 | buy | 3 | 2 | 1 | TYPE_LIMIT | TIF_GTC | myboi-ref-3 | + When the parties place the following orders: + | party | market id | side | volume | price | resulting trades | type | tif | reference | + | myboi3 | ETH/DEC19 | buy | 3 | 2 | 1 | TYPE_LIMIT | TIF_GTC | myboi3-ref-1 | Then the following trades should be executed: | buyer | seller | price | size | | myboi3 | myboi | 2 | 3 | - Scenario: Increase size success and loosing position in order book + And the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 5 | 2 | STATUS_ACTIVE | + + # reducing size with target + When the parties amend the following orders: + | party | reference | price | size | tif | + | myboi | myboi-ref-1 | 0 | 6 | TIF_GTC | + + Then the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 6 | 3 | 2 | STATUS_ACTIVE | + + Scenario: Increase size success and loosing position in order book (0004-AMND-005, 0004-AMND-056) # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | myboi | BTC | 10000 | - | myboi2 | BTC | 10000 | - | myboi3 | BTC | 10000 | - | aux | BTC | 100000 | - | aux2 | BTC | 100000 | + | party | asset | amount | + | myboi | BTC | 10000 | + | myboi2 | BTC | 10000 | + | myboi3 | BTC | 100000000 | + | aux | BTC | 100000 | + | aux2 | BTC | 100000 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -100,34 +117,61 @@ Feature: Amend orders Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" - Then the parties place the following orders: + When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | | myboi | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | | myboi2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-2 | - # reducing size And the parties amend the following orders: | party | reference | price | size delta | tif | | myboi | myboi-ref-1 | 0 | 3 | TIF_GTC | - # matching the order now - # this should match with the size 3 order of myboi + Then the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 8 | 2 | STATUS_ACTIVE | + When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | | myboi3 | ETH/DEC19 | buy | 3 | 2 | 1 | TYPE_LIMIT | TIF_GTC | myboi-ref-3 | + Then the following trades should be executed: | buyer | seller | price | size | | myboi3 | myboi2 | 2 | 3 | - Scenario: Reduce size success and order cancelled as < to remaining + And the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 8 | 2 | STATUS_ACTIVE | + | myboi2 | ETH/DEC19 | myboi-ref-2 | sell | 5 | 2 | 2 | STATUS_ACTIVE | + + When the parties amend the following orders: + | party | reference | price | size | tif | + | myboi2 | myboi-ref-2 | 0 | 10 | TIF_GTC | + + Then the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 8 | 2 | STATUS_ACTIVE | + | myboi2 | ETH/DEC19 | myboi-ref-2 | sell | 10 | 7 | 2 | STATUS_ACTIVE | + + When the parties place the following orders: + | party | market id | side | volume | price | resulting trades | type | tif | reference | + | myboi3 | ETH/DEC19 | buy | 3 | 2 | 1 | TYPE_LIMIT | TIF_GTC | myboi-ref-3 | + + Then the following trades should be executed: + | buyer | seller | price | size | + | myboi3 | myboi | 2 | 3 | + And the orders should have the following states: + | party | market id | reference | side | volume | remaining | price | status | + | myboi | ETH/DEC19 | myboi-ref-1 | sell | 8 | 5 | 2 | STATUS_ACTIVE | + | myboi2 | ETH/DEC19 | myboi-ref-2 | sell | 10 | 7 | 2 | STATUS_ACTIVE | + + + Scenario: Reduce size success and order cancelled as remaining is less than or equal to 0 (0004-AMND-058) # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | myboi | BTC | 10000 | - | myboi2 | BTC | 10000 | - | myboi3 | BTC | 10000 | - | aux | BTC | 100000 | - | aux2 | BTC | 100000 | + | party | asset | amount | + | myboi | BTC | 10000 | + | aux | BTC | 100000 | + | aux2 | BTC | 100000 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -139,24 +183,27 @@ Feature: Amend orders Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" - Then the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | reference | - | myboi | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | - | myboi2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-2 | - - # matching the order now - # this will reduce the remaining to 2 so it get cancelled later on When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | reference | - | myboi3 | ETH/DEC19 | buy | 3 | 2 | 1 | TYPE_LIMIT | TIF_GTC | myboi-ref-3 | + | party | market id | side | volume | price | resulting trades | type | tif | reference | + | myboi | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | - # reducing size, remaining goes from 2 to -1, this will cancel - Then the parties amend the following orders: + And the parties amend the following orders: | party | reference | price | size delta | tif | - | myboi | myboi-ref-1 | 0 | -3 | TIF_GTC | + | myboi | myboi-ref-1 | 0 | -5 | TIF_GTC | + + Then the orders should have the following status: + | party | reference | status | + | myboi | myboi-ref-1 | STATUS_CANCELLED | + + When the parties place the following orders: + | party | market id | side | volume | price | resulting trades | type | tif | reference | + | myboi | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | myboi-ref-1 | + + And the parties amend the following orders: + | party | reference | price | size | tif | + | myboi | myboi-ref-1 | 0 | 0 | TIF_GTC | - # check the order status, it should be cancelled - And the orders should have the following status: + Then the orders should have the following status: | party | reference | status | | myboi | myboi-ref-1 | STATUS_CANCELLED | diff --git a/core/integration/features/orders/iceberg-orders.feature b/core/integration/features/orders/iceberg-orders.feature index b136d792b35..3ed8edfeab7 100644 --- a/core/integration/features/orders/iceberg-orders.feature +++ b/core/integration/features/orders/iceberg-orders.feature @@ -26,9 +26,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -41,7 +41,7 @@ Feature: Iceberg orders When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | - | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | + | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | Then the iceberg orders should have the following states: | party | market id | side | visible volume | price | status | reserved volume | @@ -49,7 +49,7 @@ Feature: Iceberg orders When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | expires in | peak size | minimum visible size | only | - | party2 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTT | 3600 | 8 | 4 | post | + | party2 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTT | 3600 | 8 | 4 | post | Then the iceberg orders should have the following states: | party | market id | side | visible volume | price | status | reserved volume | @@ -72,9 +72,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -91,10 +91,10 @@ Feature: Iceberg orders | party2 | ETH/DEC19 | sell | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | best-ask | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | - | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 3 | 1 | ordinary-iceberg | + | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 3 | 1 | ordinary-iceberg | And the parties place the following pegged iceberg orders: | party | market id | side | volume | resulting trades | type | tif | peak size | minimum visible size | pegged reference | offset | reference | - | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | pegged-iceberg | + | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | pegged-iceberg | Then the order book should have the following volumes for market "ETH/DEC19": | side | price | volume | | buy | 5 | 3 | @@ -128,9 +128,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -143,7 +143,7 @@ Feature: Iceberg orders When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | only | reference | - | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | iceberg-order-1 | + | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | post | iceberg-order-1 | Then the iceberg orders should have the following states: | party | market id | side | visible volume | price | status | reserved volume | @@ -199,9 +199,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -214,7 +214,7 @@ Feature: Iceberg orders When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | + | party1 | ETH/DEC19 | buy | 100 | 10 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 5 | Then the iceberg orders should have the following states: | party | market id | side | visible volume | price | status | reserved volume | @@ -244,13 +244,13 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place an iceberg order that will trade when coming out of auction When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 10 | + | party1 | ETH/DEC19 | buy | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | 10 | 10 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -267,7 +267,7 @@ Feature: Iceberg orders | party1 | ETH/DEC19 | buy | 10 | 2 | STATUS_ACTIVE | 89 | -@iceberg + @iceberg Scenario: Iceberg order trading during auction uncrossing (0014-ORDT-013) # setup accounts Given the parties deposit on asset's general account the following amount: @@ -283,9 +283,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction And the parties place the following orders: @@ -295,13 +295,13 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | + | party1 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | + | party | market id | side | volume | price | resulting trades | type | tif | | party2 | ETH/DEC19 | buy | 8 | 2 | 0 | TYPE_LIMIT | TIF_GTC | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | - | party3 | ETH/DEC19 | sell | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | + | party3 | ETH/DEC19 | sell | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | And the opening auction period ends for market "ETH/DEC19" Then the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" # Check only the display volume of party1 is filled and is refreshed at the back of the que @@ -332,9 +332,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -347,8 +347,8 @@ Feature: Iceberg orders And the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | - | party1 | ETH/DEC19 | sell | 50 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | - | party2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | + | party1 | ETH/DEC19 | sell | 50 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | + | party2 | ETH/DEC19 | sell | 5 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | And the parties should have the following account balances: | party | asset | market id | margin | general | @@ -395,9 +395,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -410,8 +410,8 @@ Feature: Iceberg orders And the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | - | party1 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | - | party2 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | + | party1 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 2 | 1 | + | party2 | ETH/DEC19 | sell | 100 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | And the parties should have the following account balances: | party | asset | market id | margin | general | @@ -457,9 +457,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -472,8 +472,8 @@ Feature: Iceberg orders And the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | peak size | minimum visible size | - | party1 | ETH/DEC19 | sell | 16 | 5 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 5 | 1 | - | party2 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | + | party1 | ETH/DEC19 | sell | 16 | 5 | 0 | TYPE_LIMIT | TIF_GTC | this-order-1 | 5 | 1 | + | party2 | ETH/DEC19 | buy | 10 | 2 | 0 | TYPE_LIMIT | TIF_GTC | this-order-2 | 2 | 1 | # amend the buy order so that it will cross with the other iceberg Then the parties amend the following orders: @@ -503,9 +503,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -518,7 +518,7 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | - | party1 | ETH/DEC19 | buy | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party1 | ETH/DEC19 | buy | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | And the parties should have the following account balances: | party | asset | market id | margin | general | | party1 | BTC | ETH/DEC19 | 26 | 9974 | @@ -558,9 +558,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -576,7 +576,7 @@ Feature: Iceberg orders | party2 | ETH/DEC19 | sell | 15 | 5 | 0 | TYPE_LIMIT | TIF_GTC | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 10 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 10 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | Then the following trades should be executed: | buyer | seller | price | size | | party1 | party2 | 5 | 10 | @@ -601,9 +601,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -619,7 +619,7 @@ Feature: Iceberg orders | party2 | ETH/DEC19 | sell | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 15 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 15 | 5 | 1 | TYPE_LIMIT | TIF_GTC | 2 | 1 | Then the following trades should be executed: | buyer | seller | price | size | | party1 | party2 | 5 | 10 | @@ -644,9 +644,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -659,7 +659,7 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | | party2 | ETH/DEC19 | sell | 15 | 5 | 1 | TYPE_LIMIT | TIF_GTC | @@ -689,9 +689,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -704,7 +704,7 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | And the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | | party2 | ETH/DEC19 | buy | 7 | 5 | 0 | TYPE_LIMIT | TIF_GTC | @@ -740,9 +740,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -760,7 +760,7 @@ Feature: Iceberg orders | party4 | ETH/DEC19 | sell | 50 | 5 | 0 | TYPE_LIMIT | TIF_GTC | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 100 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 100 | 5 | 3 | TYPE_LIMIT | TIF_GTC | 2 | 1 | Then the following trades should be executed: | buyer | seller | price | size | | party1 | party2 | 5 | 30 | @@ -789,9 +789,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -808,7 +808,7 @@ Feature: Iceberg orders | party3 | ETH/DEC19 | sell | 40 | 5 | 0 | TYPE_LIMIT | TIF_GTC | When the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | buy | 100 | 5 | 2 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | buy | 100 | 5 | 2 | TYPE_LIMIT | TIF_GTC | 2 | 1 | Then the following trades should be executed: | buyer | seller | price | size | | party1 | party2 | 5 | 30 | @@ -836,9 +836,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -851,7 +851,7 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | - | party1 | ETH/DEC19 | sell | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | + | party1 | ETH/DEC19 | sell | 10 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | And the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | | party2 | ETH/DEC19 | buy | 7 | 4 | 0 | TYPE_LIMIT | TIF_GTC | order-to-amend | @@ -886,9 +886,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -905,7 +905,7 @@ Feature: Iceberg orders | party3 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | And the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | - | party1 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party1 | ETH/DEC19 | sell | 5 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | | party1 | ETH/DEC19 | buy | 20 | 5 | 2 | TYPE_LIMIT | TIF_GTC | normal | @@ -914,8 +914,8 @@ Feature: Iceberg orders | party1 | party2 | 5 | 5 | | party1 | party3 | 5 | 5 | And the orders should have the following states: - | party | market id | reference | side | volume | price | status | - | party1 | ETH/DEC19 | normal | buy | 20 | 5 | STATUS_PARTIALLY_FILLED | + | party | market id | reference | side | volume | remaining | price | status | + | party1 | ETH/DEC19 | normal | buy | 20 | 10 | 5 | STATUS_PARTIALLY_FILLED | And the iceberg orders should have the following states: | party | market id | reference | side | visible volume | price | status | reserved volume | | party1 | ETH/DEC19 | iceberg | sell | 2 | 5 | STATUS_ACTIVE | 3 | @@ -938,9 +938,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -953,9 +953,9 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | - | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | - | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | - | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | | party4 | ETH/DEC19 | buy | 300 | 5 | 3 | TYPE_LIMIT | TIF_GTC | @@ -989,9 +989,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -1004,9 +1004,9 @@ Feature: Iceberg orders Given the parties place the following iceberg orders: | party | market id | side | volume | price | resulting trades | type | tif | peak size | minimum visible size | reference | - | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | - | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | - | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party1 | ETH/DEC19 | sell | 200 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party2 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | + | party3 | ETH/DEC19 | sell | 100 | 5 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | iceberg | When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | | party4 | ETH/DEC19 | buy | 600 | 5 | 3 | TYPE_LIMIT | TIF_GTC | @@ -1034,9 +1034,9 @@ Feature: Iceberg orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -1055,7 +1055,7 @@ Feature: Iceberg orders | party2 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | And the parties place the following pegged iceberg orders: | party | market id | side | volume | resulting trades | type | tif | peak size | minimum visible size | pegged reference | offset | - | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | + | party1 | ETH/DEC19 | buy | 10 | 0 | TYPE_LIMIT | TIF_GTC | 2 | 1 | BID | 1 | And the parties place the following pegged orders: | party | market id | side | volume | pegged reference | offset | | party1 | ETH/DEC19 | buy | 1 | BID | 2 | diff --git a/core/integration/features/orders/market-depth-1.feature b/core/integration/features/orders/market-depth-1.feature index 355e028e9b8..5923e9c5c62 100644 --- a/core/integration/features/orders/market-depth-1.feature +++ b/core/integration/features/orders/market-depth-1.feature @@ -40,9 +40,9 @@ Feature: Test market depth events for pegged orders | aux | ETH/DEC19 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-s-1 | | aux2 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-b-1 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 1000 | 120 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 1000 | 80 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 1000 | 1000 | 120 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 1000 | 1000 | 80 | STATUS_ACTIVE | # Checked out, remove the order events we've checked, now let's have a look at the pegged order events Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" diff --git a/core/integration/features/orders/market-depth-2.feature b/core/integration/features/orders/market-depth-2.feature index 53968d3378d..9dd27a76d86 100644 --- a/core/integration/features/orders/market-depth-2.feature +++ b/core/integration/features/orders/market-depth-2.feature @@ -41,9 +41,9 @@ Feature: Test market depth events for pegged orders | aux | ETH/DEC19 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-s-1 | | aux2 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-b-1 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 1000 | 120 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 1000 | 80 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 1000 | 1000 | 120 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 1000 | 1000 | 80 | STATUS_ACTIVE | # Checked out, remove the order events we've checked, now let's have a look at the pegged order events Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" diff --git a/core/integration/features/orders/market-depth-3.feature b/core/integration/features/orders/market-depth-3.feature index 525db5b8804..dca46411304 100644 --- a/core/integration/features/orders/market-depth-3.feature +++ b/core/integration/features/orders/market-depth-3.feature @@ -43,9 +43,9 @@ Feature: Test market depth events for pegged orders (with BID and ASK price) | aux | ETH/DEC19 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-s-1 | | aux2 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-b-1 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 1000 | 120 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 1000 | 80 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 1000 | 1000 | 120 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 1000 | 1000 | 80 | STATUS_ACTIVE | Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" # Now check what happened to our pegged orders diff --git a/core/integration/features/orders/market-depth-4.feature b/core/integration/features/orders/market-depth-4.feature index 9554aadf499..c8207aeaa30 100644 --- a/core/integration/features/orders/market-depth-4.feature +++ b/core/integration/features/orders/market-depth-4.feature @@ -44,9 +44,9 @@ Feature: Test market depth events for pegged orders (cancelling pegged orders) | aux | ETH/DEC19 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-s-1 | | aux2 | ETH/DEC19 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | aux-b-1 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 1000 | 120 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 1000 | 80 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 1000 | 1000 | 120 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 1000 | 1000 | 80 | STATUS_ACTIVE | Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" # Now check what happened to our pegged orders diff --git a/core/integration/features/orders/offsets_with_decimals.feature b/core/integration/features/orders/offsets_with_decimals.feature index d6bccfc35ae..52d3fe49efc 100644 --- a/core/integration/features/orders/offsets_with_decimals.feature +++ b/core/integration/features/orders/offsets_with_decimals.feature @@ -1,95 +1,95 @@ Feature: Test how offsets are applied with decimals - Scenario: + Scenario: - Given the following network parameters are set: - | name | value | - | market.value.windowLength | 1h | - | network.markPriceUpdateMaximumFrequency | 0s | - | limits.markets.maxPeggedOrders | 8 | - And the liquidity monitoring parameters: - | name | triggering ratio | time window | scaling factor | - | lqm-params | 0.00 | 24h | 1 | - And the following assets are registered: - | id | decimal places | - | ETH | 5 | - | USD | 2 | - And the average block duration is "2" + Given the following network parameters are set: + | name | value | + | market.value.windowLength | 1h | + | network.markPriceUpdateMaximumFrequency | 0s | + | limits.markets.maxPeggedOrders | 8 | + And the liquidity monitoring parameters: + | name | triggering ratio | time window | scaling factor | + | lqm-params | 0.00 | 24h | 1 | + And the following assets are registered: + | id | decimal places | + | ETH | 5 | + | USD | 2 | + And the average block duration is "2" - And the log normal risk model named "log-normal-risk-model-1": - | risk aversion | tau | mu | r | sigma | - | 0.000001 | 0.1 | 0 | 0 | 1.0 | - And the fees configuration named "fees-config-1": - | maker fee | infrastructure fee | - | 0.0004 | 0.001 | - And the price monitoring named "price-monitoring-1": - | horizon | probability | auction extension | - | 100000 | 0.99 | 3 | + And the log normal risk model named "log-normal-risk-model-1": + | risk aversion | tau | mu | r | sigma | + | 0.000001 | 0.1 | 0 | 0 | 1.0 | + And the fees configuration named "fees-config-1": + | maker fee | infrastructure fee | + | 0.0004 | 0.001 | + And the price monitoring named "price-monitoring-1": + | horizon | probability | auction extension | + | 100000 | 0.99 | 3 | - And the liquidity sla params named "SLA": - | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | - | 1.0 | 0.5 | 1 | 1.0 | - And the following network parameters are set: - | name | value | - | market.liquidity.providersFeeCalculationTimeStep | 660s | + And the liquidity sla params named "SLA": + | price range | commitment min time fraction | performance hysteresis epochs | sla competition factor | + | 1.0 | 0.5 | 1 | 1.0 | + And the following network parameters are set: + | name | value | + | market.liquidity.providersFeeCalculationTimeStep | 660s | - And the markets: - | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | decimal places | position decimal places | linear slippage factor | quadratic slippage factor | sla params | - | USD/DEC19 | USD | ETH | lqm-params | log-normal-risk-model-1 | default-margin-calculator | 1 | default-none | price-monitoring-1 | default-usd-for-future | 3 | 3 | 1e6 | 1e6 | SLA | + And the markets: + | id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | decimal places | position decimal places | linear slippage factor | quadratic slippage factor | sla params | + | USD/DEC19 | USD | ETH | lqm-params | log-normal-risk-model-1 | default-margin-calculator | 1 | default-none | price-monitoring-1 | default-usd-for-future | 3 | 3 | 1e6 | 1e6 | SLA | - Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | lp1 | ETH | 100000000000000 | - | party1 | ETH | 10000000000000 | - | party2 | ETH | 10000000000000 | - | party3 | ETH | 10000000000000 | + Given the parties deposit on asset's general account the following amount: + | party | asset | amount | + | lp1 | ETH | 100000000000000 | + | party1 | ETH | 10000000000000 | + | party2 | ETH | 10000000000000 | + | party3 | ETH | 10000000000000 | - And the parties submit the following liquidity provision: - | id | party | market id | commitment amount | fee | lp type | - | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | - | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | - | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | - | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | - And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lp1 | USD/DEC19 | 2 | 1 | buy | BID | 66667 | 0 | - | lp1 | USD/DEC19 | 2 | 1 | buy | MID | 33334 | 1 | - | lp1 | USD/DEC19 | 2 | 1 | sell | MID | 33334 | 1 | - | lp1 | USD/DEC19 | 2 | 1 | sell | ASK | 66667 | 0 | - - Then the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1 | USD/DEC19 | buy | 10000 | 999999 | 0 | TYPE_LIMIT | TIF_GTC | - | party1 | USD/DEC19 | buy | 10000 | 1000000 | 0 | TYPE_LIMIT | TIF_GTC | - | party2 | USD/DEC19 | sell | 10000 | 1000000 | 0 | TYPE_LIMIT | TIF_GTC | - | party2 | USD/DEC19 | sell | 10000 | 1000001 | 0 | TYPE_LIMIT | TIF_GTC | + And the parties submit the following liquidity provision: + | id | party | market id | commitment amount | fee | lp type | + | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | + | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | + | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | + | lp1 | lp1 | USD/DEC19 | 10000000000 | 0.001 | submission | + And the parties place the following pegged iceberg orders: + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lp1 | USD/DEC19 | 2 | 1 | buy | BID | 66667 | 0 | + | lp1 | USD/DEC19 | 2 | 1 | buy | MID | 33334 | 1 | + | lp1 | USD/DEC19 | 2 | 1 | sell | MID | 33334 | 1 | + | lp1 | USD/DEC19 | 2 | 1 | sell | ASK | 66667 | 0 | - Then the opening auction period ends for market "USD/DEC19" - And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USD/DEC19" - And the market data for the market "USD/DEC19" should be: - | mark price | trading mode | best static bid price | static mid price | best static offer price | - | 1000000 | TRADING_MODE_CONTINUOUS | 999999 | 1000000 | 1000001 | - Then the orders should have the following states: - | party | market id | side | volume | price | status | - | lp1 | USD/DEC19 | buy | 66667 | 999999 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | buy | 33334 | 999999 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | sell | 33334 | 1000001 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | sell | 66667 | 1000001 | STATUS_ACTIVE | + Then the parties place the following orders: + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | USD/DEC19 | buy | 10000 | 999999 | 0 | TYPE_LIMIT | TIF_GTC | + | party1 | USD/DEC19 | buy | 10000 | 1000000 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | USD/DEC19 | sell | 10000 | 1000000 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | USD/DEC19 | sell | 10000 | 1000001 | 0 | TYPE_LIMIT | TIF_GTC | - Then the parties place the following pegged orders: - | party | market id | side | volume | pegged reference | offset | - | party3 | USD/DEC19 | buy | 5 | BID | 0 | - | party3 | USD/DEC19 | buy | 4 | MID | 1 | - | party3 | USD/DEC19 | sell | 3 | ASK | 0 | - | party3 | USD/DEC19 | sell | 2 | MID | 1 | + Then the opening auction period ends for market "USD/DEC19" + And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "USD/DEC19" + And the market data for the market "USD/DEC19" should be: + | mark price | trading mode | best static bid price | static mid price | best static offer price | + | 1000000 | TRADING_MODE_CONTINUOUS | 999999 | 1000000 | 1000001 | + Then the orders should have the following states: + | party | market id | side | volume | remaining | price | status | + | lp1 | USD/DEC19 | buy | 66667 | 2 | 999999 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | buy | 33334 | 2 | 999999 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | sell | 33334 | 2 | 1000001 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | sell | 66667 | 2 | 1000001 | STATUS_ACTIVE | - Then the orders should have the following states: - | party | market id | side | volume | price | status | - | lp1 | USD/DEC19 | buy | 66667 | 999999 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | buy | 33334 | 999999 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | sell | 33334 | 1000001 | STATUS_ACTIVE | - | lp1 | USD/DEC19 | sell | 66667 | 1000001 | STATUS_ACTIVE | - | party3 | USD/DEC19 | buy | 5 | 999999 | STATUS_ACTIVE | - | party3 | USD/DEC19 | buy | 4 | 999999 | STATUS_ACTIVE | - | party3 | USD/DEC19 | sell | 3 | 1000001 | STATUS_ACTIVE | - | party3 | USD/DEC19 | sell | 2 | 1000001 | STATUS_ACTIVE | \ No newline at end of file + Then the parties place the following pegged orders: + | party | market id | side | volume | pegged reference | offset | + | party3 | USD/DEC19 | buy | 5 | BID | 0 | + | party3 | USD/DEC19 | buy | 4 | MID | 1 | + | party3 | USD/DEC19 | sell | 3 | ASK | 0 | + | party3 | USD/DEC19 | sell | 2 | MID | 1 | + + Then the orders should have the following states: + | party | market id | side | volume | remaining | price | status | + | lp1 | USD/DEC19 | buy | 66667 | 2 | 999999 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | buy | 33334 | 2 | 999999 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | sell | 33334 | 2 | 1000001 | STATUS_ACTIVE | + | lp1 | USD/DEC19 | sell | 66667 | 2 | 1000001 | STATUS_ACTIVE | + | party3 | USD/DEC19 | buy | 5 | 5 | 999999 | STATUS_ACTIVE | + | party3 | USD/DEC19 | buy | 4 | 4 | 999999 | STATUS_ACTIVE | + | party3 | USD/DEC19 | sell | 3 | 3 | 1000001 | STATUS_ACTIVE | + | party3 | USD/DEC19 | sell | 2 | 2 | 1000001 | STATUS_ACTIVE | diff --git a/core/integration/features/orders/stoporders.feature b/core/integration/features/orders/stoporders.feature index 45a3ec8bdbe..97d21b1507b 100644 --- a/core/integration/features/orders/stoporders.feature +++ b/core/integration/features/orders/stoporders.feature @@ -27,9 +27,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -43,8 +43,8 @@ Feature: stop orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | - | party1| ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET| TIF_GTC | post| 47 | stop order must be reduce only | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | + | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_GTC | post | 47 | stop order must be reduce only | Scenario: A stop order placed by a key with a zero position and no open orders will be rejected. (0014-ORDT-042) # setup accounts @@ -61,9 +61,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -77,8 +77,8 @@ Feature: stop orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | - | party1| ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | stop order submission not allowed without existing position | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | + | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | stop order submission not allowed without existing position | Scenario: A stop order placed by a key with a zero position but open orders will be accepted. (0014-ORDT-043) @@ -96,9 +96,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -112,9 +112,9 @@ Feature: stop orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | - | party1| ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | + | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | Scenario: Attempting to create more stop orders than is allowed by the relevant network parameter will result in the transaction failing to execute. (0014-ORDT-044) @@ -132,9 +132,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -148,15 +148,15 @@ Feature: stop orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | - | party1| ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | + | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | # this next one goes over the top - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | max stop orders per party reached | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | max stop orders per party reached | Scenario: A stop order wrapping a limit order will, once triggered, place the limit order as if it just arrived as an order without the stop order wrapping. (0014-ORDT-045) @@ -175,9 +175,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -191,31 +191,31 @@ Feature: stop orders # setup party1 position, open a 10 short position Given the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # place an order to match with the limit order then check the stop is filled And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 80 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 80 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | - | party1| ETH/DEC19 | buy | 5 | 80 | 0 | TYPE_LIMIT | TIF_IOC | reduce | 75 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | + | party1 | ETH/DEC19 | buy | 5 | 80 | 0 | TYPE_LIMIT | TIF_IOC | reduce | 75 | | stop1 | # now we trade at 75, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order was triggered Then the stop orders should have the following states | party | market id | status | reference | | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1 | And the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | buy | 5 | 80 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | buy | 5 | 0 | 80 | STATUS_FILLED | stop1 | Scenario: With a last traded price at 50, a stop order placed with Rises Above setting at 75 will be triggered by any trade at price 75 or higher. (0014-ORDT-047) (0014-ORDT-046) @@ -234,9 +234,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -250,31 +250,31 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 75 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 20 | 80 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 20 | 80 | 0 | TYPE_LIMIT | TIF_GTC | # now we trade at 75, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 75 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 75 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | buy | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | Scenario: With a last traded price at 50, a stop order placed with Rises Above setting at 25 will be triggered immediately (before another trade is even necessary). (0014-ORDT-048) @@ -293,9 +293,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -309,26 +309,26 @@ Feature: stop orders # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 0 | 1 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | Scenario: With a last traded price at 50, a stop order placed with Falls Below setting at 25 will be triggered by any trade at price 25 or lower. (0014-ORDT-049) @@ -347,9 +347,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -363,31 +363,31 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # now we trade at 75, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | Scenario: With a last traded price at 50, a stop order placed with Falls Below setting at 75 will be triggered immediately (before another trade is even necessary). (0014-ORDT-050) @@ -406,9 +406,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -423,26 +423,26 @@ Feature: stop orders # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | buy | 10 | 0 | 1 | TYPE_MARKET| TIF_IOC | reduce| 75 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | buy | 10 | 0 | 1 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | buy | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | Scenario: With a last traded price at 50, a stop order placed with any trigger price which does not trigger immediately will trigger as soon as a trade occurs at a trigger price, and will not wait until the next mark price update to trigger. (0014-ORDT-051) @@ -467,9 +467,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -484,28 +484,28 @@ Feature: stop orders # setup party1 position, open a 10 long position Given the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # place volume to trade with stop order Given the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # place stop order And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce | 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # trigger stop order When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party2| ETH/DEC19 | buy | 10 | 24 | 0 | TYPE_LIMIT | TIF_GTC | - | party3| ETH/DEC19 | sell | 10 | 24 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party2 | ETH/DEC19 | buy | 10 | 24 | 0 | TYPE_LIMIT | TIF_GTC | + | party3 | ETH/DEC19 | sell | 10 | 24 | 1 | TYPE_LIMIT | TIF_GTC | # check that the stop order was triggered despite the mark price not updating Then the mark price should be "50" for the market "ETH/DEC19" Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1 | # check the mark price is later updated correctly Given the network moves ahead "2" blocks @@ -529,9 +529,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -546,20 +546,20 @@ Feature: stop orders # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | When time is updated to "2019-11-30T00:00:10Z" # create party1 stop order, no trade resulting, expires in 10 secs When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 75 | | stop1 | 10 | EXPIRY_STRATEGY_CANCELS | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_CANCELS | # add 20 secs, should expire When time is updated to "2019-11-30T00:00:30Z" @@ -587,9 +587,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -597,28 +597,28 @@ Feature: stop orders | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | When time is updated to "2019-11-30T00:00:10Z" # create party1 stop order, no trade resulting, expires in 10 secs When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 75 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | # add 20 secs, should expire When time is updated to "2019-11-30T00:00:30Z" @@ -629,8 +629,8 @@ Feature: stop orders # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | buy | 10 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | STATUS_FILLED | stop1 | Scenario: If the order is triggered before reaching time T, the order will have been removed and will not trigger at time T. (0014-ORDT-054) (0014-ORDT-041) @@ -651,9 +651,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -669,23 +669,23 @@ Feature: stop orders Given time is updated to "2019-11-30T00:00:10Z" # setup party1 position, open a 10 long position And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, no trade resulting, expires in 10 secs And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | so expires in | so expiry strategy | - | party1| ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | so expires in | so expiry strategy | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | # trigger the stop order When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party2| ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | - | party3| ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party2 | ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | + | party3 | ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | # check the stop order is filled Then the stop orders should have the following states | party | market id | status | reference | @@ -716,9 +716,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -733,9 +733,9 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | Then the network moves ahead "1" blocks @@ -748,24 +748,24 @@ Feature: stop orders # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # now we trade at 25, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the network moves ahead "1" blocks And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" @@ -793,9 +793,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | @@ -809,31 +809,31 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | 75 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 75 | | stop1 | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 10 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # now we trade at 75, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 25 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 25 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 10 | 0 | STATUS_FILLED | stop1-1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | STATUS_FILLED | stop1-1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -858,9 +858,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -875,9 +875,9 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | Then the network moves ahead "1" blocks @@ -890,15 +890,15 @@ Feature: stop orders # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger |error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | 100 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 100 | | stop1 | # close party1 position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 2 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party1| ETH/DEC19 | sell | 2 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 2 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party1 | ETH/DEC19 | sell | 2 | 50 | 1 | TYPE_LIMIT | TIF_GTC | Then the network moves ahead "1" blocks And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" @@ -910,15 +910,15 @@ Feature: stop orders # now we trade at 25, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 1 | 25 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 1 | 25 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 1 | 25 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 1 | 25 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted and stopped as would not reduce the position Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_STOPPED | stop1-1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 1 | 0 | STATUS_STOPPED | stop1-1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -929,22 +929,22 @@ Feature: stop orders # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 10000000000| - | party2 | BTC | 10000000000| - | party3 | BTC | 10000000000| - | aux | BTC | 10000000000| - | aux2 | BTC | 10000000000| - | lpprov | BTC | 9000000000 | + | party | asset | amount | + | party1 | BTC | 10000000000 | + | party2 | BTC | 10000000000 | + | party3 | BTC | 10000000000 | + | aux | BTC | 10000000000 | + | aux2 | BTC | 10000000000 | + | lpprov | BTC | 9000000000 | When the parties submit the following liquidity provision: | id | party | market id | commitment amount | fee | lp type | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -959,20 +959,20 @@ Feature: stop orders # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 0.05 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | # create volume to close party 1 # high price sell so it doesn't trade When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | - | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # move prive to 60, nothing happen @@ -1001,7 +1001,7 @@ Feature: stop orders # check the volum as not reduced Then the parties should have the following profit and loss: | party | volume | unrealised pnl | realised pnl | - | party1 | 1 | 8 | 0 | + | party1 | 1 | 8 | 0 | # move first to 57, nothing happen When the parties place the following orders: @@ -1011,8 +1011,8 @@ Feature: stop orders # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -1022,22 +1022,22 @@ Feature: stop orders # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 10000000000| - | party2 | BTC | 10000000000| - | party3 | BTC | 10000000000| - | aux | BTC | 10000000000| - | aux2 | BTC | 10000000000| - | lpprov | BTC | 9000000000 | + | party | asset | amount | + | party1 | BTC | 10000000000 | + | party2 | BTC | 10000000000 | + | party3 | BTC | 10000000000 | + | aux | BTC | 10000000000 | + | aux2 | BTC | 10000000000 | + | lpprov | BTC | 9000000000 | When the parties submit the following liquidity provision: | id | party | market id | commitment amount | fee | lp type | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1052,20 +1052,20 @@ Feature: stop orders # setup party1 position, open a 10 short position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra trailing | error | reference | - | party1| ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 0.05 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra trailing | error | reference | + | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.05 | | stop1 | # create volume to close party 1 # high price sell so it doesn't trade When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | - | aux | ETH/DEC19 | sell | 1 | 70 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | sell | 1 | 70 | 0 | TYPE_LIMIT | TIF_GTC | # move prive to 60, nothing happen @@ -1104,8 +1104,8 @@ Feature: stop orders # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | buy | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | buy | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -1115,22 +1115,22 @@ Feature: stop orders # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 10000000000| - | party2 | BTC | 10000000000| - | party3 | BTC | 10000000000| - | aux | BTC | 10000000000| - | aux2 | BTC | 10000000000| - | lpprov | BTC | 9000000000 | + | party | asset | amount | + | party1 | BTC | 10000000000 | + | party2 | BTC | 10000000000 | + | party3 | BTC | 10000000000 | + | aux | BTC | 10000000000 | + | aux2 | BTC | 10000000000 | + | lpprov | BTC | 9000000000 | When the parties submit the following liquidity provision: | id | party | market id | commitment amount | fee | lp type | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1145,20 +1145,20 @@ Feature: stop orders # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, results in a trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 0.25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb trailing | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 0.25 | | stop1 | # create volume to close party 1 # high price sell so it doesn't trade When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | - | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # move prive to 60, nothing happen @@ -1215,7 +1215,7 @@ Feature: stop orders # check the volum as not reduced Then the parties should have the following profit and loss: | party | volume | unrealised pnl | realised pnl | - | party1 | 1 | -4 | 0 | + | party1 | 1 | -4 | 0 | # move first to 46, nothing happen @@ -1227,8 +1227,8 @@ Feature: stop orders # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -1238,12 +1238,12 @@ Feature: stop orders # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 100000000 | - | party2 | BTC | 100000000 | - | party3 | BTC | 100000000 | - | aux | BTC | 100000000 | - | aux2 | BTC | 100000000 | + | party | asset | amount | + | party1 | BTC | 100000000 | + | party2 | BTC | 100000000 | + | party3 | BTC | 100000000 | + | aux | BTC | 100000000 | + | aux2 | BTC | 100000000 | | lpprov | BTC | 900000000 | When the parties submit the following liquidity provision: @@ -1251,26 +1251,26 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | - | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | - | aux2 | ETH/DEC19 | buy | 5 | 51 | 0 | TYPE_LIMIT | TIF_GTC | - | aux | ETH/DEC19 | sell | 5 | 51 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | + | aux2 | ETH/DEC19 | buy | 5 | 51 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | sell | 5 | 51 | 0 | TYPE_LIMIT | TIF_GTC | # setup our order for later - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order # still in auction When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | Then the opening auction period ends for market "ETH/DEC19" @@ -1278,24 +1278,24 @@ Feature: stop orders # trade with party 1 When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 1 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # now we trade at 25, this will breach the trigger When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 1 | 25 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 1 | 25 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 1 | 25 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 1 | 25 | 1 | TYPE_LIMIT | TIF_GTC | # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -1305,12 +1305,12 @@ Feature: stop orders # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 100000000 | - | party2 | BTC | 100000000 | - | party3 | BTC | 100000000 | - | aux | BTC | 100000000 | - | aux2 | BTC | 100000000 | + | party | asset | amount | + | party1 | BTC | 100000000 | + | party2 | BTC | 100000000 | + | party3 | BTC | 100000000 | + | aux | BTC | 100000000 | + | aux2 | BTC | 100000000 | | lpprov | BTC | 900000000 | When the parties submit the following liquidity provision: @@ -1318,37 +1318,34 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | - | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | - | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | aux | ETH/DEC19 | sell | 2 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | + | aux2 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | aux | ETH/DEC19 | sell | 2 | 50 | 0 | TYPE_LIMIT | TIF_GTC | # setup our order for later - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order # still in auction When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 50 | | stop1 | - + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 50 | | stop1 | Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" - - # check that the order got submitted Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | ETH/DEC19 | sell | 1 | 0 | STATUS_FILLED | stop1 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | STATUS_FILLED | stop1 | Then the stop orders should have the following states | party | market id | status | reference | @@ -1371,9 +1368,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1388,40 +1385,40 @@ Feature: stop orders # open position Given the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # create party1 limit orders And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 1 | 51 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 1 | 51 | 0 | TYPE_LIMIT | TIF_GTC | # close position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | And the network moves ahead "1" blocks # check stop orders have not been cancelled and are still pending Then the stop orders should have the following states - | party | market id | status | reference | - | party1 | ETH/DEC19 | STATUS_PENDING | stop1 | + | party | market id | status | reference | + | party1 | ETH/DEC19 | STATUS_PENDING | stop1 | Scenario: If a trader has open stop orders and their position moves to zero with no open limit orders their stop orders are cancelled. (0014-ORDT-068) # setup accounts Given the parties deposit on asset's general account the following amount: - | party | asset | amount | - | party1 | BTC | 100000000 | - | party2 | BTC | 100000000 | - | party3 | BTC | 100000000 | - | aux | BTC | 100000000 | - | aux2 | BTC | 100000000 | + | party | asset | amount | + | party1 | BTC | 100000000 | + | party2 | BTC | 100000000 | + | party3 | BTC | 100000000 | + | aux | BTC | 100000000 | + | aux2 | BTC | 100000000 | | lpprov | BTC | 900000000 | When the parties submit the following liquidity provision: @@ -1429,9 +1426,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1446,21 +1443,21 @@ Feature: stop orders # open position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # create party1 stop order When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 25 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 1 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | | stop1 | # close position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 1 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 1 | 50 | 1 | TYPE_LIMIT | TIF_GTC | Then the network moves ahead "1" blocks And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" @@ -1486,9 +1483,9 @@ Feature: stop orders | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1502,9 +1499,9 @@ Feature: stop orders And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | stop1 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | Then the parties cancel the following stop orders: | party | reference | @@ -1514,8 +1511,8 @@ Feature: stop orders | party | market id | status | reference | | party1 | ETH/DEC19 | STATUS_CANCELLED | stop1 | -@SLABug -Scenario: All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072) + @SLABug + Scenario: All stop orders for a specific party can be cancelled by a single stop order cancellation. (0014-ORDT-072) # setup accounts Given the parties deposit on asset's general account the following amount: @@ -1533,11 +1530,11 @@ Scenario: All stop orders for a specific party can be cancelled by a single stop | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1556,13 +1553,13 @@ Scenario: All stop orders for a specific party can be cancelled by a single stop And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC20" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | - | party1| ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | stop1 | - | party1| ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 48 | | stop2 | - | party1| ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | - | party1| ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 49 | | stop3 | - | party1| ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 49 | | stop4 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | + | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | + | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | + | party1 | ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | + | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | + | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | Then the party "party1" cancels all their stop orders @@ -1573,8 +1570,8 @@ Scenario: All stop orders for a specific party can be cancelled by a single stop | party1 | ETH/DEC20 | STATUS_CANCELLED | stop3 | | party1 | ETH/DEC20 | STATUS_CANCELLED | stop4 | -@SLABug -Scenario: All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073) + @SLABug + Scenario: All stop orders for a specific party for a specific market can be cancelled by a single stop order cancellation. (0014-ORDT-073) # setup accounts Given the parties deposit on asset's general account the following amount: @@ -1592,11 +1589,11 @@ Scenario: All stop orders for a specific party for a specific market can be canc | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1615,13 +1612,13 @@ Scenario: All stop orders for a specific party for a specific market can be canc And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC20" When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | - | party1| ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | - | party1| ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 47 | | stop1 | - | party1| ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 48 | | stop2 | - | party1| ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | - | party1| ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 49 | | stop3 | - | party1| ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET| TIF_GTC | reduce| 49 | | stop4 | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | error | reference | + | party1 | ETH/DEC19 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | + | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 47 | | stop1 | + | party1 | ETH/DEC19 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 48 | | stop2 | + | party1 | ETH/DEC20 | sell | 10 | 60 | 0 | TYPE_LIMIT | TIF_GTC | | | | | + | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop3 | + | party1 | ETH/DEC20 | buy | 2 | 0 | 0 | TYPE_MARKET | TIF_GTC | reduce | 49 | | stop4 | Then the party "party1" cancels all their stop orders for the market "ETH/DEC19" @@ -1632,7 +1629,7 @@ Scenario: All stop orders for a specific party for a specific market can be canc | party1 | ETH/DEC20 | STATUS_PENDING | stop3 | | party1 | ETH/DEC20 | STATUS_PENDING | stop4 | -Scenario: A stop order cannot be triggered by orders crossing during an auction. (WIP TEST CASE 2) + Scenario: A stop order cannot be triggered by orders crossing during an auction. (WIP TEST CASE 2) # setup accounts Given the parties deposit on asset's general account the following amount: @@ -1649,9 +1646,9 @@ Scenario: A stop order cannot be triggered by orders crossing during an auction. | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | | lp2 | lpprov | ETH/DEC20 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1699,7 +1696,7 @@ Scenario: A stop order cannot be triggered by orders crossing during an auction. | party | market id | status | reference | | party1 | ETH/DEC20 | STATUS_PENDING | stop | -Scenario: A stop order cannot be triggered by a stop order expiring during an auction. (WIP TEST CASE 2) + Scenario: A stop order cannot be triggered by a stop order expiring during an auction. (WIP TEST CASE 2) # setup accounts Given time is updated to "2019-11-30T00:00:00Z" @@ -1716,9 +1713,9 @@ Scenario: A stop order cannot be triggered by a stop order expiring during an au | lp1 | lpprov | ETH/DEC20 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC20 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC20 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC20 | 2 | 1 | sell | ASK | 50 | 100 | And the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | | aux | ETH/DEC20 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | @@ -1796,9 +1793,9 @@ Scenario: A stop order cannot be triggered by a stop order expiring during an au | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 900000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1814,28 +1811,28 @@ Scenario: A stop order cannot be triggered by a stop order expiring during an au Given time is updated to "2019-11-30T00:00:10Z" # setup party1 position, open a 10 long position And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | buy | 20 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | sell | 20 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | buy | 20 | 20 | 0 | TYPE_LIMIT | TIF_GTC | # create party1 stop order, no trade resulting, expires in 10 secs And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger| error | reference | so expires in | so expiry strategy | - | party1| ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 100 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | + | party | market id | side | volume | price | resulting trades | type | tif | only | fb price trigger | ra price trigger | error | reference | so expires in | so expiry strategy | + | party1 | ETH/DEC19 | sell | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 25 | 100 | | stop1 | 10 | EXPIRY_STRATEGY_SUBMIT | # trigger the stop order When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party2| ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | - | party3| ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party2 | ETH/DEC19 | buy | 1 | 24 | 0 | TYPE_LIMIT | TIF_GTC | + | party3 | ETH/DEC19 | sell | 1 | 24 | 1 | TYPE_LIMIT | TIF_GTC | # check the stop order is filled Then the stop orders should have the following states - | party | market id | status | reference | - | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1-1 | - | party1 | ETH/DEC19 | STATUS_STOPPED | stop1-2 | + | party | market id | status | reference | + | party1 | ETH/DEC19 | STATUS_TRIGGERED | stop1-1 | + | party1 | ETH/DEC19 | STATUS_STOPPED | stop1-2 | # add 20 secs, should expire Given time is updated to "2019-11-30T00:00:30Z" @@ -1864,9 +1861,9 @@ Scenario: A stop order cannot be triggered by a stop order expiring during an au | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | | lp1 | lpprov | ETH/DEC19 | 90000000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | - | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | lpprov | ETH/DEC19 | 2 | 1 | buy | BID | 50 | 100 | + | lpprov | ETH/DEC19 | 2 | 1 | sell | ASK | 50 | 100 | # place auxiliary orders so we always have best bid and best offer as to not trigger the liquidity auction When the parties place the following orders: @@ -1874,28 +1871,28 @@ Scenario: A stop order cannot be triggered by a stop order expiring during an au | aux | ETH/DEC19 | buy | 1 | 1 | 0 | TYPE_LIMIT | TIF_GTC | | aux | ETH/DEC19 | sell | 1 | 10001 | 0 | TYPE_LIMIT | TIF_GTC | | aux2 | ETH/DEC19 | buy | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | aux3 | ETH/DEC19 | sell | 5 | 50 | 0 | TYPE_LIMIT | TIF_GTC | Then the opening auction period ends for market "ETH/DEC19" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" # setup party1 position, open a 10 long position When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party1| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | - | party2| ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party1 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party2 | ETH/DEC19 | buy | 10 | 50 | 1 | TYPE_LIMIT | TIF_GTC | # volume for the stop trade When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | - | party3| ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | + | party | market id | side | volume | price | resulting trades | type | tif | + | party3 | ETH/DEC19 | sell | 10 | 50 | 0 | TYPE_LIMIT | TIF_GTC | When time is updated to "2019-11-30T00:00:10Z" # create party1 stop order, no trade resulting, expires in 10 secs When the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | - | party1| ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET| TIF_IOC | reduce| 75 | stop order expiry in the past | stop1 | -10 | EXPIRY_STRATEGY_SUBMIT | + | party | market id | side | volume | price | resulting trades | type | tif | only | ra price trigger | error | reference | so expires in | so expiry strategy | + | party1 | ETH/DEC19 | buy | 10 | 0 | 0 | TYPE_MARKET | TIF_IOC | reduce | 75 | stop order expiry in the past | stop1 | -10 | EXPIRY_STRATEGY_SUBMIT | Then the stop orders should have the following states | party | market id | status | reference | diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0001-SimpleSpot.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0001-SimpleSpot.feature index f76840a7af8..c8fd13c1e68 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0001-SimpleSpot.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0001-SimpleSpot.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order between two parties match successfully + Scenario: Simple Spot Order matches with counter party + Background: Given the fees configuration named "fees-config-1": | maker fee | infrastructure fee | @@ -27,9 +29,9 @@ Feature: Simple Spot Order between two parties match successfully Then "party1" should have holding account balance of "100" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 100 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" @@ -39,4 +41,4 @@ Feature: Simple Spot Order between two parties match successfully | buyer | price | size | seller | | party1 | 100 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0002-SimpleSpot-No-Fill.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0002-SimpleSpot-No-Fill.feature index 7dfd4576bc7..f4ad9ba314a 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0002-SimpleSpot-No-Fill.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0002-SimpleSpot-No-Fill.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order between two parties do not match successfully + Scenario: Simple Spot Order does not match with counter party + Background: Given the fees configuration named "fees-config-1": | maker fee | infrastructure fee | @@ -20,16 +22,16 @@ Feature: Simple Spot Order between two parties do not match successfully | party2 | BTC | 100 | # place orders and generate trades And the parties place the following orders: - | party | market id | side | volume | price | resulting trades | type | tif | reference | - | party1 | BTC/ETH | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GFA | t1-b-1 | - | party2 | BTC/ETH | sell | 1 | 200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | + | party | market id | side | volume | volume | price | resulting trades | type | tif | reference | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | 0 | TYPE_LIMIT | TIF_GFA | t1-b-1 | + | party2 | BTC/ETH | sell | 1 | 1 | 200 | 0 | TYPE_LIMIT | TIF_GTC | t2-s-1 | Then "party2" should have holding account balance of "1" for asset "BTC" Then "party1" should have holding account balance of "100" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 200 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 200 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_OPENING_AUCTION" for the market "BTC/ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0003-Spot-OrderAmend-Price-Down.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0003-Spot-OrderAmend-Price-Down.feature index afaa4dfc923..afa94bb4a6c 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0003-Spot-OrderAmend-Price-Down.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0003-Spot-OrderAmend-Price-Down.feature @@ -1,4 +1,5 @@ Feature: Amend the price down to match and fill the order with counter party + Scenario: Amend the price down to match and fill the order with counter party Background: @@ -28,9 +29,9 @@ Feature: Amend the price down to match and fill the order with counter party Then "party1" should have holding account balance of "300" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 300 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 400 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 300 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 400 | STATUS_ACTIVE | And the parties amend the following orders: | party | reference | price | size delta | tif | @@ -45,4 +46,4 @@ Feature: Amend the price down to match and fill the order with counter party | buyer | price | size | seller | | party1 | 100 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0004-Spot-OrderAmend-QuantityDown.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0004-Spot-OrderAmend-QuantityDown.feature index 3a7cfe59330..1c40d7655e4 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0004-Spot-OrderAmend-QuantityDown.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0004-Spot-OrderAmend-QuantityDown.feature @@ -1,4 +1,5 @@ Feature: Amend the quantity down for a spot order + Scenario: Amend the quantity down for a spot order Background: @@ -28,9 +29,9 @@ Feature: Amend the quantity down for a spot order Then "party1" should have holding account balance of "200" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 2 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 2 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 2 | 2 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 2 | 2 | 100 | STATUS_ACTIVE | And the parties amend the following orders: | party | reference | price | size delta | tif | @@ -38,9 +39,9 @@ Feature: Amend the quantity down for a spot order | party2 | t2-s-1 | 100 | -1 | TIF_GTC | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 100 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" @@ -50,4 +51,4 @@ Feature: Amend the quantity down for a spot order | buyer | price | size | seller | | party1 | 100 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0005-Spot-OrderAmend-Price-And-Quantity.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0005-Spot-OrderAmend-Price-And-Quantity.feature index 38cb6be34bb..9e70ae7df03 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0005-Spot-OrderAmend-Price-And-Quantity.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0005-Spot-OrderAmend-Price-And-Quantity.feature @@ -1,4 +1,5 @@ Feature: Amend the price and quantity amend to match and fill the order with counter party + Scenario: Amend the price and quantity match and fill the order with counter party Background: @@ -28,9 +29,9 @@ Feature: Amend the price and quantity amend to match and fill the order with cou Then "party1" should have holding account balance of "600" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 2 | 300 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 2 | 400 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 2 | 2 | 300 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 2 | 2 | 400 | STATUS_ACTIVE | And the parties amend the following orders: | party | reference | price | size delta | tif | @@ -38,9 +39,9 @@ Feature: Amend the price and quantity amend to match and fill the order with cou | party1 | t1-b-1 | 350 | -1 | TIF_GTC | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 350 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 350 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 350 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 350 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" @@ -51,4 +52,4 @@ Feature: Amend the price and quantity amend to match and fill the order with cou | party1 | 350 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0006-Spot-OrderAmend-Price-Up.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0006-Spot-OrderAmend-Price-Up.feature index f8aba02da03..0fb85d54ddd 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0006-Spot-OrderAmend-Price-Up.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0006-Spot-OrderAmend-Price-Up.feature @@ -1,4 +1,5 @@ Feature: Amend the price up to match and fill the order with counter party + Scenario: Amend the price up to match and fill the order with counter party Background: @@ -28,9 +29,9 @@ Feature: Amend the price up to match and fill the order with counter party Then "party1" should have holding account balance of "300" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 300 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 400 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 300 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 400 | STATUS_ACTIVE | And the parties amend the following orders: | party | reference | price | size delta | tif | @@ -46,4 +47,4 @@ Feature: Amend the price up to match and fill the order with counter party | party1 | 450 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0007-Spot-OrderAmend-QuantityUp.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0007-Spot-OrderAmend-QuantityUp.feature index cd4e954d388..abae3689935 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0007-Spot-OrderAmend-QuantityUp.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0007-Spot-OrderAmend-QuantityUp.feature @@ -1,4 +1,5 @@ Feature: Amend the quantity increase for a spot order + Scenario: Amend the quantity increase for a spot order Background: @@ -29,9 +30,9 @@ Feature: Amend the quantity increase for a spot order Then "party1" should have holding account balance of "2000" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 20 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 20 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 20 | 20 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 20 | 20 | 100 | STATUS_ACTIVE | And the parties amend the following orders: | party | reference | price | size delta | tif | @@ -39,9 +40,9 @@ Feature: Amend the quantity increase for a spot order # | party2 | t2-s-1 | 100 | 1 | TIF_GTC | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 21 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 20 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 21 | 21 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 20 | 20 | 100 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" @@ -52,4 +53,4 @@ Feature: Amend the quantity increase for a spot order | party1 | 100 | 20 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "100" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "100" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0009-Spot-SamePartyTradesDontMatch.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0009-Spot-SamePartyTradesDontMatch.feature index 3c4af04d0e1..3007a099eee 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0009-Spot-SamePartyTradesDontMatch.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0009-Spot-SamePartyTradesDontMatch.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order between two parties do not match successfully + Scenario: Simple Spot Order does not match with counter party + Background: Given the fees configuration named "fees-config-1": | maker fee | infrastructure fee | @@ -27,9 +29,9 @@ Feature: Simple Spot Order between two parties do not match successfully Then "party1" should have holding account balance of "100" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | - | party1 | BTC/ETH | sell | 1 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | party1 | BTC/ETH | sell | 1 | 1 | 100 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" @@ -40,9 +42,9 @@ Feature: Simple Spot Order between two parties do not match successfully # see https://github.com/vegaprotocol/specs/blob/95afe22b7807b47e6231b3cdab21f6196b7dab91/protocol/0024-OSTA-order_status.md#wash-trading Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_FILLED | - | party1 | BTC/ETH | sell | 1 | 100 | STATUS_FILLED | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 0 | 100 | STATUS_FILLED | + | party1 | BTC/ETH | sell | 1 | 0 | 100 | STATUS_FILLED | # now that we're in continuous trading, lets try to do a wash trade by part @@ -55,7 +57,7 @@ Feature: Simple Spot Order between two parties do not match successfully Then "party1" should have holding account balance of "0" for asset "BTC" Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | t1-b-111 | - | party1 | BTC/ETH | sell | 1 | 100 | STATUS_STOPPED | t2-s-112 | + | party | market id | side | volume | remaining | price | status | reference | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | t1-b-111 | + | party1 | BTC/ETH | sell | 1 | 1 | 100 | STATUS_STOPPED | t2-s-112 | diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0010-Spot-Bid-Decimals.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0010-Spot-Bid-Decimals.feature index 0e6623a39af..d39a760631a 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0010-Spot-Bid-Decimals.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0010-Spot-Bid-Decimals.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order between two parties match successfully + Scenario: Simple Spot Order matches with counter party + Background: Given the following assets are registered: | id | decimal places | @@ -31,9 +33,9 @@ Feature: Simple Spot Order between two parties match successfully Then "party1" should have holding account balance of "1000000" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 100000 | 10000 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 100000 | 10000 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 100000 | 100000 | 10000 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 100000 | 100000 | 10000 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0011-Spot-Ask-Decimals.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0011-Spot-Ask-Decimals.feature index f76840a7af8..c8fd13c1e68 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0011-Spot-Ask-Decimals.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0011-Spot-Ask-Decimals.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order between two parties match successfully + Scenario: Simple Spot Order matches with counter party + Background: Given the fees configuration named "fees-config-1": | maker fee | infrastructure fee | @@ -27,9 +29,9 @@ Feature: Simple Spot Order between two parties match successfully Then "party1" should have holding account balance of "100" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 100 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" @@ -39,4 +41,4 @@ Feature: Simple Spot Order between two parties match successfully | buyer | price | size | seller | | party1 | 100 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Infra-FeeCalculation.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Infra-FeeCalculation.feature index 901588b61cc..220e1a5ea32 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Infra-FeeCalculation.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Infra-FeeCalculation.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order Market fee and infrastructure fee calculation + Scenario: Simple Spot Order Market fee and infrastructure fee calculation + Background: Given the following network parameters are set: | name | value | @@ -37,9 +39,9 @@ Feature: Simple Spot Order Market fee and infrastructure fee calculation Then "party1" should have holding account balance of "1000" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100000 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 100000 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100000 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 100000 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Maker-FeeCalculation.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Maker-FeeCalculation.feature index 472fd0df5ec..a68cae47fc0 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Maker-FeeCalculation.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0012-Spot-Maker-FeeCalculation.feature @@ -1,5 +1,7 @@ Feature: Simple Spot Order Market fee and infrastructure fee calculation + Scenario: Simple Spot Order Market fee and infrastructure fee calculation + Background: Given the following network parameters are set: | name | value | @@ -42,9 +44,9 @@ Feature: Simple Spot Order Market fee and infrastructure fee calculation Then "party1" should have holding account balance of "1000" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 100000 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 100000 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 100000 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 100000 | STATUS_ACTIVE | Then the opening auction period ends for market "BTC/ETH" And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "BTC/ETH" diff --git a/core/integration/features/spots/SpotFunctionalTests/TC-0013-Spot-OrderAmend-account-balance.feature b/core/integration/features/spots/SpotFunctionalTests/TC-0013-Spot-OrderAmend-account-balance.feature index 13705aa25e5..7710e2ec080 100644 --- a/core/integration/features/spots/SpotFunctionalTests/TC-0013-Spot-OrderAmend-account-balance.feature +++ b/core/integration/features/spots/SpotFunctionalTests/TC-0013-Spot-OrderAmend-account-balance.feature @@ -1,4 +1,5 @@ Feature: Amend the price up above the account balance + Scenario: Amend the price up above the account balance Background: @@ -28,9 +29,9 @@ Feature: Amend the price up above the account balance Then "party1" should have holding account balance of "300" for asset "ETH" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | BTC/ETH | buy | 1 | 300 | STATUS_ACTIVE | - | party2 | BTC/ETH | sell | 1 | 1100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | BTC/ETH | buy | 1 | 1 | 300 | STATUS_ACTIVE | + | party2 | BTC/ETH | sell | 1 | 1 | 1100 | STATUS_ACTIVE | Given the parties amend the following orders: | party | reference | price | size delta | tif | error | @@ -51,4 +52,4 @@ Feature: Amend the price up above the account balance | party1 | 1000 | 1 | party2 | Then "party2" should have holding account balance of "0" for asset "BTC" - Then "party1" should have holding account balance of "0" for asset "ETH" \ No newline at end of file + Then "party1" should have holding account balance of "0" for asset "ETH" diff --git a/core/integration/features/verified/0035-LIQM-liquidity_monitoring.feature b/core/integration/features/verified/0035-LIQM-liquidity_monitoring.feature index 8af2ac3873e..7fceb9cc572 100644 --- a/core/integration/features/verified/0035-LIQM-liquidity_monitoring.feature +++ b/core/integration/features/verified/0035-LIQM-liquidity_monitoring.feature @@ -2,14 +2,14 @@ Feature: Test liquidity monitoring Background: Given the following network parameters are set: - | name | value | - | network.floatingPointUpdates.delay | 10s | - | market.auction.minimumDuration | 1 | - | network.markPriceUpdateMaximumFrequency | 0s | - | limits.markets.maxPeggedOrders | 4 | + | name | value | + | network.floatingPointUpdates.delay | 10s | + | market.auction.minimumDuration | 1 | + | network.markPriceUpdateMaximumFrequency | 0s | + | limits.markets.maxPeggedOrders | 4 | Given the liquidity monitoring parameters: - | name | triggering ratio | time window | scaling factor | - | lqm-params | 1.0 | 1s | 1.0 | + | name | triggering ratio | time window | scaling factor | + | lqm-params | 1.0 | 1s | 1.0 | And the average block duration is "1" And the margin calculator named "margin-calculator-1": | search factor | initial factor | release factor | @@ -108,7 +108,7 @@ Feature: Test liquidity monitoring | AuctionEvent | Scenario: 002: A market which enters a state requiring liquidity auction through reduced current stake (e.g. through LP bankruptcy) during a block but then leaves state again prior to block completion never enters liquidity auction. (0035-LIQM-006) - + And the average block duration is "1" And the parties submit the following liquidity provision: @@ -171,8 +171,8 @@ Feature: Test liquidity monitoring Scenario: 004: When the Max Open Interest field decreases for a created block to a level such that a liquidity auction which is active at the start of a block can now be exited the block stays in auction within the block but leaves at the end. (0035-LIQM-008) Given the following network parameters are set: - | name | value | - | market.liquidity.bondPenaltyParameter | 1 | + | name | value | + | market.liquidity.bondPenaltyParameter | 1 | Given the liquidity monitoring parameters: | name | triggering ratio | time window | scaling factor | | updated-lqm-params | 1.0 | 5s | 1 | @@ -212,11 +212,11 @@ Feature: Test liquidity monitoring When the network moves ahead "1" blocks Then the orders should have the following states: - | party | market id | side | volume | price | status | reference | - | lprov1 | ETH/DEC21 | buy | 1 | 968 | STATUS_ACTIVE | lp1_buy | - | lprov1 | ETH/DEC21 | sell | 1 | 1032 | STATUS_ACTIVE | lp1_sell | - | lp2Bdistressed | ETH/DEC21 | buy | 1 | 960 | STATUS_ACTIVE | lp2_buy | - | lp2Bdistressed | ETH/DEC21 | sell | 1 | 1040 | STATUS_ACTIVE | lp2_sell | + | party | market id | side | volume | remaining | price | status | reference | + | lprov1 | ETH/DEC21 | buy | 1 | 1 | 968 | STATUS_ACTIVE | lp1_buy | + | lprov1 | ETH/DEC21 | sell | 1 | 1 | 1032 | STATUS_ACTIVE | lp1_sell | + | lp2Bdistressed | ETH/DEC21 | buy | 1 | 1 | 960 | STATUS_ACTIVE | lp2_buy | + | lp2Bdistressed | ETH/DEC21 | sell | 1 | 1 | 1040 | STATUS_ACTIVE | lp2_sell | And the parties should have the following margin levels: | party | market id | maintenance | initial | | lp2Bdistressed | ETH/DEC21 | 100 | 100 | diff --git a/core/integration/features/verified/0038-OLIQ-liquidity_provision_creation.feature b/core/integration/features/verified/0038-OLIQ-liquidity_provision_creation.feature index 21f734c7e25..5349f6606e9 100644 --- a/core/integration/features/verified/0038-OLIQ-liquidity_provision_creation.feature +++ b/core/integration/features/verified/0038-OLIQ-liquidity_provision_creation.feature @@ -23,9 +23,9 @@ Feature: Test LP orders | lp1 | party1 | ETH/DEC19 | 50000 | 0.1 | submission | | lp1 | party1 | ETH/DEC19 | 50000 | 0.1 | submission | And the parties place the following pegged iceberg orders: - | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | - | party1 | ETH/DEC19 | 2 | 1 | buy | BID | 500 | 10 | - | party1 | ETH/DEC19 | 2 | 1 | sell | ASK | 500 | 10 | + | party | market id | peak size | minimum visible size | side | pegged reference | volume | offset | + | party1 | ETH/DEC19 | 2 | 1 | buy | BID | 500 | 10 | + | party1 | ETH/DEC19 | 2 | 1 | sell | ASK | 500 | 10 | And the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | | auxiliary | ETH/DEC19 | buy | 1 | 80 | 0 | TYPE_LIMIT | TIF_GTC | oa-b-1 | @@ -50,11 +50,11 @@ Feature: Test LP orders And the mark price should be "100" for the market "ETH/DEC19" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | auxiliary | ETH/DEC19 | buy | 1 | 80 | STATUS_ACTIVE | - | auxiliary | ETH/DEC19 | sell | 1 | 120 | STATUS_ACTIVE | - | aux2 | ETH/DEC19 | buy | 1 | 100 | STATUS_ACTIVE | - | auxiliary | ETH/DEC19 | sell | 1 | 100 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | auxiliary | ETH/DEC19 | buy | 1 | 1 | 80 | STATUS_ACTIVE | + | auxiliary | ETH/DEC19 | sell | 1 | 1 | 120 | STATUS_ACTIVE | + | aux2 | ETH/DEC19 | buy | 1 | 1 | 100 | STATUS_ACTIVE | + | auxiliary | ETH/DEC19 | sell | 1 | 1 | 100 | STATUS_ACTIVE | When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | @@ -63,17 +63,17 @@ Feature: Test LP orders | party1 | ETH/DEC19 | buy | 1 | 110 | 0 | TYPE_LIMIT | TIF_GTC | lp-ref-1 | | party1 | ETH/DEC19 | sell | 1 | 120 | 0 | TYPE_LIMIT | TIF_GTC | lp-ref-2 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 1000 | 120 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 1000 | 80 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 1000 | 1000 | 120 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 1000 | 1000 | 80 | STATUS_ACTIVE | Then the liquidity provisions should have the following states: | id | party | market | commitment amount | status | | lp1 | party1 | ETH/DEC19 | 50000 | STATUS_ACTIVE | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | ETH/DEC19 | buy | 500 | 100 | STATUS_ACTIVE | - | party1 | ETH/DEC19 | sell | 500 | 130 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | ETH/DEC19 | buy | 500 | 2 | 100 | STATUS_ACTIVE | + | party1 | ETH/DEC19 | sell | 500 | 2 | 130 | STATUS_ACTIVE | Scenario: 002, create liquidity provisions (0038-OLIQ-additional-tests); test decimal; asset 3; market 1; position:2 AC: 0070-MKTD-004;0070-MKTD-005; 0070-MKTD-006; 0070-MKTD-007;0070-MKTD-008 Given the following assets are registered: @@ -123,10 +123,10 @@ Feature: Test LP orders | aux2 | 1000 | 100 | auxiliary | And the mark price should be "1000" for the market "ETH/DEC19" Then the orders should have the following states: - | party | market id | side | volume | price | status | - | auxiliary | ETH/DEC19 | buy | 100 | 800 | STATUS_ACTIVE | - | auxiliary | ETH/DEC19 | sell | 100 | 1200 | STATUS_ACTIVE | - | aux2 | ETH/DEC19 | buy | 100 | 1000 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | auxiliary | ETH/DEC19 | buy | 100 | 100 | 800 | STATUS_ACTIVE | + | auxiliary | ETH/DEC19 | sell | 100 | 100 | 1200 | STATUS_ACTIVE | + | aux2 | ETH/DEC19 | buy | 100 | 100 | 1000 | STATUS_ACTIVE | And the trading mode should be "TRADING_MODE_CONTINUOUS" for the market "ETH/DEC19" When the parties place the following orders: | party | market id | side | volume | price | resulting trades | type | tif | reference | @@ -135,14 +135,15 @@ Feature: Test LP orders | party1 | ETH/DEC19 | buy | 5000 | 1100 | 0 | TYPE_LIMIT | TIF_GTC | lp-ref-1 | | party1 | ETH/DEC19 | sell | 5000 | 1200 | 0 | TYPE_LIMIT | TIF_GTC | lp-ref-2 | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | sellSideProvider | ETH/DEC19 | sell | 100000 | 1200 | STATUS_ACTIVE | - | buySideProvider | ETH/DEC19 | buy | 100000 | 800 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | sellSideProvider | ETH/DEC19 | sell | 100000 | 100000 | 1200 | STATUS_ACTIVE | + | buySideProvider | ETH/DEC19 | buy | 100000 | 100000 | 800 | STATUS_ACTIVE | Then the liquidity provisions should have the following states: | id | party | market | commitment amount | status | | lp1 | party1 | ETH/DEC19 | 50000000 | STATUS_ACTIVE | Then the orders should have the following states: - | party | market id | side | volume | price | status | - | party1 | ETH/DEC19 | buy | 500 | 1000 | STATUS_ACTIVE | - | party1 | ETH/DEC19 | sell | 500 | 1300 | STATUS_ACTIVE | + | party | market id | side | volume | remaining | price | status | + | party1 | ETH/DEC19 | buy | 500 | 2 | 1000 | STATUS_ACTIVE | + | party1 | ETH/DEC19 | sell | 500 | 2 | 1300 | STATUS_ACTIVE | + diff --git a/core/integration/steps/errors.go b/core/integration/steps/errors.go index 319b7df0e31..31c51fcb75b 100644 --- a/core/integration/steps/errors.go +++ b/core/integration/steps/errors.go @@ -24,6 +24,8 @@ import ( "code.vegaprotocol.io/vega/logging" types "code.vegaprotocol.io/vega/protos/vega" commandspb "code.vegaprotocol.io/vega/protos/vega/commands/v1" + + "golang.org/x/exp/maps" ) type ErroneousRow interface { @@ -51,7 +53,7 @@ func DebugLPSTxErrors(broker *stubs.BrokerStub, log *logging.Logger) { } // checkExpectedError checks if expected error has been returned, -// if no expecteation has been set a regular error check is carried out, +// if no expectation has been set a regular error check is carried out, // unexpectedErrDetail is an optional parameter that can be used to return a more detailed error when an unexpected error is encoutered. func checkExpectedError(row ErroneousRow, returnedErr, unexpectedErrDetail error) error { if row.ExpectError() && returnedErr == nil { @@ -83,19 +85,32 @@ func checkExpectedError(row ErroneousRow, returnedErr, unexpectedErrDetail error func formatDiff(msg string, expected, got map[string]string) error { var expectedStr strings.Builder var gotStr strings.Builder - formatStr := "\n\t%s\t(%s)" + padding := findLongestKeyLen(expected) + 1 + formatStr := "\n\t\t%-*s(%s)" for name, value := range expected { - _, _ = fmt.Fprintf(&expectedStr, formatStr, name, value) - _, _ = fmt.Fprintf(&gotStr, formatStr, name, got[name]) + _, _ = fmt.Fprintf(&expectedStr, formatStr, padding, name, value) + _, _ = fmt.Fprintf(&gotStr, formatStr, padding, name, got[name]) } - return fmt.Errorf("\n%s\nexpected:%s\ngot:%s", + return fmt.Errorf("%s\n\texpected:%s\n\tgot:%s", msg, expectedStr.String(), gotStr.String(), ) } +func findLongestKeyLen(expected map[string]string) int { + keys := maps.Keys(expected) + maxLen := 0 + for i := range keys { + iLen := len(keys[i]) + if iLen > maxLen { + maxLen = iLen + } + } + return maxLen +} + func u64ToS(n uint64) string { return strconv.FormatUint(n, 10) } diff --git a/core/integration/steps/parties_amend_the_following_orders.go b/core/integration/steps/parties_amend_the_following_orders.go index fb9d4c7af6d..d22a55eab54 100644 --- a/core/integration/steps/parties_amend_the_following_orders.go +++ b/core/integration/steps/parties_amend_the_following_orders.go @@ -52,18 +52,13 @@ func PartiesAmendTheFollowingOrders( amend := types.OrderAmendment{ OrderID: o.Id, MarketID: o.MarketId, + Price: row.Price(), SizeDelta: row.SizeDelta(), + Size: row.Size(), + ExpiresAt: row.ExpirationDate(), TimeInForce: row.TimeInForce(), } - if p := row.Price(); p != nil { - amend.Price = p - } - - if t := row.ExpirationDate(); t != nil { - amend.ExpiresAt = t - } - _, err = exec.AmendOrder(context.Background(), &amend, o.PartyId) if err := checkExpectedError(row, err, nil); err != nil { return err @@ -81,10 +76,11 @@ func parseAmendOrderTable(table *godog.Table) []RowWrapper { return StrictParseTable(table, []string{ "party", "reference", - "price", - "size delta", "tif", }, []string{ + "price", + "size delta", + "size", "error", "expiration date", }) @@ -103,9 +99,16 @@ func (r amendOrderRow) Price() *num.Uint { } func (r amendOrderRow) SizeDelta() int64 { + if !r.row.HasColumn("size delta") { + return 0 + } return r.row.MustI64("size delta") } +func (r amendOrderRow) Size() *uint64 { + return r.row.MaybeU64("size") +} + func (r amendOrderRow) TimeInForce() types.OrderTimeInForce { return r.row.MustTIF("tif") } diff --git a/core/integration/steps/parties_amend_the_following_pegged_iceberg_orders.go b/core/integration/steps/parties_amend_the_following_pegged_iceberg_orders.go index 8cf5ddf38f8..89a80532b50 100644 --- a/core/integration/steps/parties_amend_the_following_pegged_iceberg_orders.go +++ b/core/integration/steps/parties_amend_the_following_pegged_iceberg_orders.go @@ -45,10 +45,7 @@ func PartiesAmendTheFollowingPeggedIcebergOrders( if row.HasTimeInForce() { tif = row.TimeInForce() } - var offset *num.Uint - if row.HasOffset() { - offset = row.Offset() - } + var pegRef types.PeggedReference if row.HasPeggedReference() { pegRef = row.PeggedReference() @@ -58,9 +55,10 @@ func PartiesAmendTheFollowingPeggedIcebergOrders( OrderID: o.Id, MarketID: o.MarketId, SizeDelta: row.SizeDelta(), - TimeInForce: tif, + Size: row.Size(), ExpiresAt: row.ExpirationDate(now), - PeggedOffset: offset, + TimeInForce: tif, + PeggedOffset: row.Offset(), PeggedReference: pegRef, } @@ -76,10 +74,11 @@ func parseAmendPeggedIcebergOrderTable(table *godog.Table) []RowWrapper { return StrictParseTable(table, []string{ "party", "reference", - "size delta", }, []string{ "pegged reference", "offset", + "size delta", + "size", "tif", "error", "expires in", @@ -95,9 +94,16 @@ func (r amendPeggedIcebergOrderRow) Party() string { } func (r amendPeggedIcebergOrderRow) SizeDelta() int64 { + if !r.row.HasColumn("size delta") { + return 0 + } return r.row.MustI64("size delta") } +func (r amendPeggedIcebergOrderRow) Size() *uint64 { + return r.row.MaybeU64("size") +} + func (r amendPeggedIcebergOrderRow) HasTimeInForce() bool { return r.row.HasColumn("tif") } @@ -140,5 +146,5 @@ func (r amendPeggedIcebergOrderRow) HasOffset() bool { } func (r amendPeggedIcebergOrderRow) Offset() *num.Uint { - return r.row.Uint("offset") + return r.row.MaybeUint("offset") } diff --git a/core/integration/steps/table_wrapper.go b/core/integration/steps/table_wrapper.go index 61f89c3344e..6e44a084b99 100644 --- a/core/integration/steps/table_wrapper.go +++ b/core/integration/steps/table_wrapper.go @@ -25,6 +25,7 @@ import ( "code.vegaprotocol.io/vega/core/events" "code.vegaprotocol.io/vega/core/types" "code.vegaprotocol.io/vega/libs/num" + "code.vegaprotocol.io/vega/libs/ptr" proto "code.vegaprotocol.io/vega/protos/vega" datav1 "code.vegaprotocol.io/vega/protos/vega/data/v1" @@ -240,6 +241,13 @@ func (r RowWrapper) MaybeUint(name string) *num.Uint { return u } +func (r RowWrapper) MaybeU64(name string) *uint64 { + if !r.HasColumn(name) { + return nil + } + return ptr.From(r.MustU64(name)) +} + func (r RowWrapper) Uint(name string) *num.Uint { value, err := Uint(r.values[name]) panicW(name, err) diff --git a/core/integration/steps/the_orders_should_have_the_following_states.go b/core/integration/steps/the_orders_should_have_the_following_states.go index 42bff001103..3e44b55ea92 100644 --- a/core/integration/steps/the_orders_should_have_the_following_states.go +++ b/core/integration/steps/the_orders_should_have_the_following_states.go @@ -24,7 +24,7 @@ import ( ) func TheOrdersShouldHaveTheFollowingStates(broker *stubs.BrokerStub, table *godog.Table) error { - data := broker.GetOrderEvents() + orderEvents := broker.GetOrderEvents() for _, row := range parseOrdersStatesTable(table) { party := row.MustStr("party") @@ -32,23 +32,36 @@ func TheOrdersShouldHaveTheFollowingStates(broker *stubs.BrokerStub, table *godo side := row.MustSide("side") size := row.MustU64("volume") price := row.MustU64("price") + remaining := row.MustU64("remaining") status := row.MustOrderStatus("status") ref, hasRef := row.StrB("reference") match := false - for _, e := range data { + for i := len(orderEvents) - 1; i >= 0; i-- { + e := orderEvents[i] o := e.Order() if hasRef { if ref != o.Reference { continue } if o.PartyId == party && o.Status == status && o.MarketId == marketID && o.Side == side { - if o.Size != size || stringToU64(o.Price) != price { - return fmt.Errorf("side: %s, expected price: %v actual: %v, expected volume: %v, actual %v", side.String(), price, o.Price, size, o.Size) + if o.Size != size || stringToU64(o.Price) != price || o.Remaining != remaining { + return formatDiff(fmt.Sprintf("the order didn't match the expectation for reference %q", ref), + map[string]string{ + "size": u64ToS(size), + "price": u64ToS(price), + "remaining": u64ToS(remaining), + }, + map[string]string{ + "size": u64ToS(o.Size), + "price": o.Price, + "remaining": u64ToS(o.Remaining), + }, + ) } } } - if o.PartyId != party || o.Status != status || o.MarketId != marketID || o.Side != side || o.Size != size || stringToU64(o.Price) != price { + if o.PartyId != party || o.Status != status || o.MarketId != marketID || o.Side != side || o.Size != size || stringToU64(o.Price) != price || o.Remaining != remaining { continue } match = true @@ -68,6 +81,9 @@ func parseOrdersStatesTable(table *godog.Table) []RowWrapper { "side", "volume", "price", + "remaining", "status", - }, []string{"reference"}) + }, []string{ + "reference", + }) } diff --git a/core/types/matching.go b/core/types/matching.go index 62a47c12461..3be86fbbc78 100644 --- a/core/types/matching.go +++ b/core/types/matching.go @@ -378,8 +378,13 @@ func (o *Order) applyOrderAmendmentSizeIceberg(delta int64) { o.IcebergOrder.ReservedRemaining = 0 } -// applyOrderAmendmentSizeDelta update the orders size/remaining fields based on the size an direction of the given delta. -func (o *Order) applyOrderAmendmentSizeDelta(delta int64) { +func (o *Order) amendSize(size uint64) { + o.amendSizeWithDelta(int64(size) - int64(o.Size)) +} + +// amendSizeWithDelta update the orders size/remaining fields based on the size +// an direction of the given delta. +func (o *Order) amendSizeWithDelta(delta int64) { if o.IcebergOrder != nil { o.applyOrderAmendmentSizeIceberg(delta) return @@ -426,9 +431,12 @@ func (o *Order) ApplyOrderAmendment(amendment *OrderAmendment, updatedAtNano int order.OriginalPrice = amendment.Price.Clone() } - // apply size changes + if amendment.Size != nil { + order.amendSize(*amendment.Size) + } + if delta := amendment.SizeDelta; delta != 0 { - order.applyOrderAmendmentSizeDelta(delta) + order.amendSizeWithDelta(delta) } // apply tif diff --git a/core/types/orders.go b/core/types/orders.go index aebae01d762..69048238663 100644 --- a/core/types/orders.go +++ b/core/types/orders.go @@ -56,6 +56,7 @@ type OrderAmendment struct { MarketID string Price *num.Uint SizeDelta int64 + Size *uint64 ExpiresAt *int64 // timestamp TimeInForce OrderTimeInForce PeggedOffset *num.Uint @@ -90,6 +91,7 @@ func NewOrderAmendmentFromProto(p *commandspb.OrderAmendment) (*OrderAmendment, MarketID: p.MarketId, Price: price, SizeDelta: p.SizeDelta, + Size: p.Size, ExpiresAt: exp, TimeInForce: p.TimeInForce, PeggedOffset: peggedOffset, @@ -102,6 +104,7 @@ func (o OrderAmendment) IntoProto() *commandspb.OrderAmendment { OrderId: o.OrderID, MarketId: o.MarketID, SizeDelta: o.SizeDelta, + Size: o.Size, TimeInForce: o.TimeInForce, PeggedReference: o.PeggedReference, } @@ -140,10 +143,11 @@ func (o OrderAmendment) Validate() error { func (o OrderAmendment) String() string { return fmt.Sprintf( - "orderID(%s) marketID(%s) sizeDelta(%v) timeInForce(%s) peggedReference(%s) price(%s) expiresAt(%v) peggedOffset(%s)", + "orderID(%s) marketID(%s) sizeDelta(%v) size(%v) timeInForce(%s) peggedReference(%s) price(%s) expiresAt(%v) peggedOffset(%s)", o.OrderID, o.MarketID, o.SizeDelta, + stringer.PtrToString(o.Size), o.TimeInForce.String(), o.PeggedReference.String(), stringer.PtrToString(o.Price), diff --git a/protos/sources/vega/commands/v1/commands.proto b/protos/sources/vega/commands/v1/commands.proto index e4aabc989ad..b1abb18e9fe 100644 --- a/protos/sources/vega/commands/v1/commands.proto +++ b/protos/sources/vega/commands/v1/commands.proto @@ -147,6 +147,7 @@ message OrderAmendment { // - To increase the size from the current value, set a positive integer value // - To leave the size unchanged set a value of zero // This field needs to be scaled using the market's position decimal places. + // If specified, size must not be set. int64 size_delta = 4; // Timestamp, in Unix nanoseconds, for the new expiry time for the order. optional int64 expires_at = 5; @@ -157,6 +158,14 @@ message OrderAmendment { string pegged_offset = 7; // New pegged reference for the order. vega.PeggedReference pegged_reference = 8; + // New size for the order. + // Amending the size causes the size and remaining part of the order to be changed by the difference between the original and amended size. + // - Specifying a size smaller than the current size leaves the order at its current order book position. + // - Specifying a size larger than the current size removes and reinserts the order at the back of the price level. + // - Specifying a size that results in the remaining part of the order being reduced to zero cancels the order. + // This field is an unsigned integer scaled to the market's decimal places. + // If specified, size_delta must be set to 0. + optional uint64 size = 9; } // A command that indicates to the network the party's intention to supply liquidity to the given market and become a liquidity provider. diff --git a/protos/vega/commands/v1/commands.pb.go b/protos/vega/commands/v1/commands.pb.go index f6ca7d71d5b..599d6cd32aa 100644 --- a/protos/vega/commands/v1/commands.pb.go +++ b/protos/vega/commands/v1/commands.pb.go @@ -802,6 +802,7 @@ type OrderAmendment struct { // - To increase the size from the current value, set a positive integer value // - To leave the size unchanged set a value of zero // This field needs to be scaled using the market's position decimal places. + // If specified, size must not be set. SizeDelta int64 `protobuf:"varint,4,opt,name=size_delta,json=sizeDelta,proto3" json:"size_delta,omitempty"` // Timestamp, in Unix nanoseconds, for the new expiry time for the order. ExpiresAt *int64 `protobuf:"varint,5,opt,name=expires_at,json=expiresAt,proto3,oneof" json:"expires_at,omitempty"` @@ -812,6 +813,14 @@ type OrderAmendment struct { PeggedOffset string `protobuf:"bytes,7,opt,name=pegged_offset,json=peggedOffset,proto3" json:"pegged_offset,omitempty"` // New pegged reference for the order. PeggedReference vega.PeggedReference `protobuf:"varint,8,opt,name=pegged_reference,json=peggedReference,proto3,enum=vega.PeggedReference" json:"pegged_reference,omitempty"` + // New size for the order. + // Amending the size causes the size and remaining part of the order to be changed by the difference between the original and amended size. + // - Specifying a size smaller than the current size leaves the order at its current order book position. + // - Specifying a size larger than the current size removes and reinserts the order at the back of the price level. + // - Specifying a size that results in the remaining part of the order being reduced to zero cancels the order. + // This field is an unsigned integer scaled to the market's decimal places. + // If specified, size_delta must be set to 0. + Size *uint64 `protobuf:"varint,9,opt,name=size,proto3,oneof" json:"size,omitempty"` } func (x *OrderAmendment) Reset() { @@ -902,6 +911,13 @@ func (x *OrderAmendment) GetPeggedReference() vega.PeggedReference { return vega.PeggedReference(0) } +func (x *OrderAmendment) GetSize() uint64 { + if x != nil && x.Size != nil { + return *x.Size + } + return 0 +} + // A command that indicates to the network the party's intention to supply liquidity to the given market and become a liquidity provider. // An active liquidity provider for a market will earn fees based on the trades that occur in the market. type LiquidityProvisionSubmission struct { @@ -2280,7 +2296,7 @@ var file_vega_commands_v1_commands_proto_rawDesc = []byte{ 0x6f, 0x6e, 0x12, 0x19, 0x0a, 0x08, 0x6f, 0x72, 0x64, 0x65, 0x72, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x6f, 0x72, 0x64, 0x65, 0x72, 0x49, 0x64, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x5f, 0x69, 0x64, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, - 0x52, 0x08, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, 0x22, 0xe3, 0x02, 0x0a, 0x0e, 0x4f, + 0x52, 0x08, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, 0x22, 0x85, 0x03, 0x0a, 0x0e, 0x4f, 0x72, 0x64, 0x65, 0x72, 0x41, 0x6d, 0x65, 0x6e, 0x64, 0x6d, 0x65, 0x6e, 0x74, 0x12, 0x19, 0x0a, 0x08, 0x6f, 0x72, 0x64, 0x65, 0x72, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x07, 0x6f, 0x72, 0x64, 0x65, 0x72, 0x49, 0x64, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, @@ -2301,167 +2317,170 @@ var file_vega_commands_v1_commands_proto_rawDesc = []byte{ 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x08, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x15, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x50, 0x65, 0x67, 0x67, 0x65, 0x64, 0x52, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x52, 0x0f, 0x70, 0x65, 0x67, 0x67, 0x65, 0x64, 0x52, 0x65, - 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x42, 0x08, 0x0a, 0x06, 0x5f, 0x70, 0x72, 0x69, 0x63, - 0x65, 0x42, 0x0d, 0x0a, 0x0b, 0x5f, 0x65, 0x78, 0x70, 0x69, 0x72, 0x65, 0x73, 0x5f, 0x61, 0x74, - 0x22, 0xa4, 0x01, 0x0a, 0x1c, 0x4c, 0x69, 0x71, 0x75, 0x69, 0x64, 0x69, 0x74, 0x79, 0x50, 0x72, - 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, - 0x6e, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x5f, 0x69, 0x64, 0x18, 0x01, - 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, 0x12, 0x2b, - 0x0a, 0x11, 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x5f, 0x61, 0x6d, 0x6f, - 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x10, 0x63, 0x6f, 0x6d, 0x6d, 0x69, - 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x41, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x10, 0x0a, 0x03, 0x66, - 0x65, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x66, 0x65, 0x65, 0x12, 0x1c, 0x0a, - 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x06, 0x20, 0x01, 0x28, 0x09, - 0x52, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x4a, 0x04, 0x08, 0x04, 0x10, - 0x05, 0x4a, 0x04, 0x08, 0x05, 0x10, 0x06, 0x22, 0x3d, 0x0a, 0x1e, 0x4c, 0x69, 0x71, 0x75, 0x69, - 0x64, 0x69, 0x74, 0x79, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x43, 0x61, 0x6e, - 0x63, 0x65, 0x6c, 0x6c, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, - 0x6b, 0x65, 0x74, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x6d, 0x61, - 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, 0x22, 0xa3, 0x01, 0x0a, 0x1b, 0x4c, 0x69, 0x71, 0x75, 0x69, - 0x64, 0x69, 0x74, 0x79, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x41, 0x6d, 0x65, - 0x6e, 0x64, 0x6d, 0x65, 0x6e, 0x74, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, - 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x6d, 0x61, 0x72, 0x6b, 0x65, - 0x74, 0x49, 0x64, 0x12, 0x2b, 0x0a, 0x11, 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, - 0x74, 0x5f, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x10, - 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x41, 0x6d, 0x6f, 0x75, 0x6e, 0x74, - 0x12, 0x10, 0x0a, 0x03, 0x66, 0x65, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x66, - 0x65, 0x65, 0x12, 0x1c, 0x0a, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, - 0x06, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, - 0x4a, 0x04, 0x08, 0x04, 0x10, 0x05, 0x4a, 0x04, 0x08, 0x05, 0x10, 0x06, 0x22, 0x67, 0x0a, 0x12, - 0x57, 0x69, 0x74, 0x68, 0x64, 0x72, 0x61, 0x77, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, - 0x6f, 0x6e, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x01, 0x20, 0x01, - 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x14, 0x0a, 0x05, 0x61, 0x73, - 0x73, 0x65, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x61, 0x73, 0x73, 0x65, 0x74, - 0x12, 0x23, 0x0a, 0x03, 0x65, 0x78, 0x74, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x11, 0x2e, - 0x76, 0x65, 0x67, 0x61, 0x2e, 0x57, 0x69, 0x74, 0x68, 0x64, 0x72, 0x61, 0x77, 0x45, 0x78, 0x74, - 0x52, 0x03, 0x65, 0x78, 0x74, 0x22, 0x94, 0x01, 0x0a, 0x12, 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, - 0x61, 0x6c, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x1c, 0x0a, 0x09, - 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, - 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x12, 0x29, 0x0a, 0x05, 0x74, 0x65, - 0x72, 0x6d, 0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x13, 0x2e, 0x76, 0x65, 0x67, 0x61, - 0x2e, 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x54, 0x65, 0x72, 0x6d, 0x73, 0x52, 0x05, - 0x74, 0x65, 0x72, 0x6d, 0x73, 0x12, 0x35, 0x0a, 0x09, 0x72, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x61, - 0x6c, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, - 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x52, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, - 0x65, 0x52, 0x09, 0x72, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x65, 0x22, 0x59, 0x0a, 0x0e, - 0x56, 0x6f, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x1f, - 0x0a, 0x0b, 0x70, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, - 0x01, 0x28, 0x09, 0x52, 0x0a, 0x70, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x49, 0x64, 0x12, - 0x26, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x10, - 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x56, 0x6f, 0x74, 0x65, 0x2e, 0x56, 0x61, 0x6c, 0x75, 0x65, - 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x22, 0x45, 0x0a, 0x12, 0x44, 0x65, 0x6c, 0x65, 0x67, - 0x61, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x17, 0x0a, - 0x07, 0x6e, 0x6f, 0x64, 0x65, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, - 0x6e, 0x6f, 0x64, 0x65, 0x49, 0x64, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, - 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x22, 0xe2, - 0x01, 0x0a, 0x14, 0x55, 0x6e, 0x64, 0x65, 0x6c, 0x65, 0x67, 0x61, 0x74, 0x65, 0x53, 0x75, 0x62, - 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x17, 0x0a, 0x07, 0x6e, 0x6f, 0x64, 0x65, 0x5f, - 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x6e, 0x6f, 0x64, 0x65, 0x49, 0x64, - 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, - 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x45, 0x0a, 0x06, 0x6d, 0x65, 0x74, 0x68, - 0x6f, 0x64, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x2d, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, - 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x55, 0x6e, 0x64, 0x65, - 0x6c, 0x65, 0x67, 0x61, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, - 0x2e, 0x4d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x52, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x22, - 0x52, 0x0a, 0x06, 0x4d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x12, 0x16, 0x0a, 0x12, 0x4d, 0x45, 0x54, - 0x48, 0x4f, 0x44, 0x5f, 0x55, 0x4e, 0x53, 0x50, 0x45, 0x43, 0x49, 0x46, 0x49, 0x45, 0x44, 0x10, - 0x00, 0x12, 0x0e, 0x0a, 0x0a, 0x4d, 0x45, 0x54, 0x48, 0x4f, 0x44, 0x5f, 0x4e, 0x4f, 0x57, 0x10, - 0x01, 0x12, 0x1a, 0x0a, 0x16, 0x4d, 0x45, 0x54, 0x48, 0x4f, 0x44, 0x5f, 0x41, 0x54, 0x5f, 0x45, - 0x4e, 0x44, 0x5f, 0x4f, 0x46, 0x5f, 0x45, 0x50, 0x4f, 0x43, 0x48, 0x10, 0x02, 0x22, 0x04, 0x08, - 0x03, 0x10, 0x03, 0x22, 0xea, 0x02, 0x0a, 0x08, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, - 0x12, 0x3d, 0x0a, 0x11, 0x66, 0x72, 0x6f, 0x6d, 0x5f, 0x61, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, - 0x5f, 0x74, 0x79, 0x70, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x11, 0x2e, 0x76, 0x65, - 0x67, 0x61, 0x2e, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x52, 0x0f, - 0x66, 0x72, 0x6f, 0x6d, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x12, - 0x0e, 0x0a, 0x02, 0x74, 0x6f, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, 0x74, 0x6f, 0x12, - 0x39, 0x0a, 0x0f, 0x74, 0x6f, 0x5f, 0x61, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x5f, 0x74, 0x79, - 0x70, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x11, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, - 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x52, 0x0d, 0x74, 0x6f, 0x41, - 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x12, 0x14, 0x0a, 0x05, 0x61, 0x73, - 0x73, 0x65, 0x74, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x61, 0x73, 0x73, 0x65, 0x74, - 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x05, 0x20, 0x01, 0x28, 0x09, - 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x1c, 0x0a, 0x09, 0x72, 0x65, 0x66, 0x65, - 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x06, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x72, 0x65, 0x66, - 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x12, 0x3b, 0x0a, 0x07, 0x6f, 0x6e, 0x65, 0x5f, 0x6f, 0x66, - 0x66, 0x18, 0x65, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x20, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x63, - 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x4f, 0x6e, 0x65, 0x4f, 0x66, - 0x66, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x48, 0x00, 0x52, 0x06, 0x6f, 0x6e, 0x65, - 0x4f, 0x66, 0x66, 0x12, 0x43, 0x0a, 0x09, 0x72, 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, 0x6e, 0x67, - 0x18, 0x66, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x23, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x63, 0x6f, - 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x52, 0x65, 0x63, 0x75, 0x72, 0x72, - 0x69, 0x6e, 0x67, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x48, 0x00, 0x52, 0x09, 0x72, - 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, 0x6e, 0x67, 0x42, 0x06, 0x0a, 0x04, 0x6b, 0x69, 0x6e, 0x64, - 0x22, 0x2f, 0x0a, 0x0e, 0x4f, 0x6e, 0x65, 0x4f, 0x66, 0x66, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, - 0x65, 0x72, 0x12, 0x1d, 0x0a, 0x0a, 0x64, 0x65, 0x6c, 0x69, 0x76, 0x65, 0x72, 0x5f, 0x6f, 0x6e, - 0x18, 0x01, 0x20, 0x01, 0x28, 0x03, 0x52, 0x09, 0x64, 0x65, 0x6c, 0x69, 0x76, 0x65, 0x72, 0x4f, - 0x6e, 0x22, 0xc1, 0x01, 0x0a, 0x11, 0x52, 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, 0x6e, 0x67, 0x54, - 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x12, 0x1f, 0x0a, 0x0b, 0x73, 0x74, 0x61, 0x72, 0x74, - 0x5f, 0x65, 0x70, 0x6f, 0x63, 0x68, 0x18, 0x01, 0x20, 0x01, 0x28, 0x04, 0x52, 0x0a, 0x73, 0x74, - 0x61, 0x72, 0x74, 0x45, 0x70, 0x6f, 0x63, 0x68, 0x12, 0x20, 0x0a, 0x09, 0x65, 0x6e, 0x64, 0x5f, - 0x65, 0x70, 0x6f, 0x63, 0x68, 0x18, 0x02, 0x20, 0x01, 0x28, 0x04, 0x48, 0x00, 0x52, 0x08, 0x65, - 0x6e, 0x64, 0x45, 0x70, 0x6f, 0x63, 0x68, 0x88, 0x01, 0x01, 0x12, 0x16, 0x0a, 0x06, 0x66, 0x61, - 0x63, 0x74, 0x6f, 0x72, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x66, 0x61, 0x63, 0x74, - 0x6f, 0x72, 0x12, 0x43, 0x0a, 0x11, 0x64, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, 0x68, 0x5f, 0x73, - 0x74, 0x72, 0x61, 0x74, 0x65, 0x67, 0x79, 0x18, 0x04, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x16, 0x2e, - 0x76, 0x65, 0x67, 0x61, 0x2e, 0x44, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, 0x68, 0x53, 0x74, 0x72, - 0x61, 0x74, 0x65, 0x67, 0x79, 0x52, 0x10, 0x64, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, 0x68, 0x53, - 0x74, 0x72, 0x61, 0x74, 0x65, 0x67, 0x79, 0x42, 0x0c, 0x0a, 0x0a, 0x5f, 0x65, 0x6e, 0x64, 0x5f, - 0x65, 0x70, 0x6f, 0x63, 0x68, 0x22, 0x31, 0x0a, 0x0e, 0x43, 0x61, 0x6e, 0x63, 0x65, 0x6c, 0x54, - 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x12, 0x1f, 0x0a, 0x0b, 0x74, 0x72, 0x61, 0x6e, 0x73, - 0x66, 0x65, 0x72, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0a, 0x74, 0x72, - 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x49, 0x64, 0x22, 0x94, 0x01, 0x0a, 0x0f, 0x49, 0x73, 0x73, - 0x75, 0x65, 0x53, 0x69, 0x67, 0x6e, 0x61, 0x74, 0x75, 0x72, 0x65, 0x73, 0x12, 0x1c, 0x0a, 0x09, - 0x73, 0x75, 0x62, 0x6d, 0x69, 0x74, 0x74, 0x65, 0x72, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, - 0x09, 0x73, 0x75, 0x62, 0x6d, 0x69, 0x74, 0x74, 0x65, 0x72, 0x12, 0x37, 0x0a, 0x04, 0x6b, 0x69, - 0x6e, 0x64, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x23, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, - 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x4e, 0x6f, 0x64, 0x65, - 0x53, 0x69, 0x67, 0x6e, 0x61, 0x74, 0x75, 0x72, 0x65, 0x4b, 0x69, 0x6e, 0x64, 0x52, 0x04, 0x6b, - 0x69, 0x6e, 0x64, 0x12, 0x2a, 0x0a, 0x11, 0x76, 0x61, 0x6c, 0x69, 0x64, 0x61, 0x74, 0x6f, 0x72, - 0x5f, 0x6e, 0x6f, 0x64, 0x65, 0x5f, 0x69, 0x64, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0f, - 0x76, 0x61, 0x6c, 0x69, 0x64, 0x61, 0x74, 0x6f, 0x72, 0x4e, 0x6f, 0x64, 0x65, 0x49, 0x64, 0x22, - 0x8d, 0x02, 0x0a, 0x11, 0x43, 0x72, 0x65, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, - 0x61, 0x6c, 0x53, 0x65, 0x74, 0x12, 0x17, 0x0a, 0x07, 0x69, 0x73, 0x5f, 0x74, 0x65, 0x61, 0x6d, - 0x18, 0x01, 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x69, 0x73, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x41, - 0x0a, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x28, 0x2e, 0x76, - 0x65, 0x67, 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, - 0x43, 0x72, 0x65, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, 0x53, 0x65, - 0x74, 0x2e, 0x54, 0x65, 0x61, 0x6d, 0x48, 0x00, 0x52, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x88, 0x01, - 0x01, 0x1a, 0x92, 0x01, 0x0a, 0x04, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x12, 0x0a, 0x04, 0x6e, 0x61, - 0x6d, 0x65, 0x18, 0x0a, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, 0x12, 0x1e, - 0x0a, 0x08, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x18, 0x0b, 0x20, 0x01, 0x28, 0x09, - 0x48, 0x00, 0x52, 0x07, 0x74, 0x65, 0x61, 0x6d, 0x55, 0x72, 0x6c, 0x88, 0x01, 0x01, 0x12, 0x22, - 0x0a, 0x0a, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x18, 0x0c, 0x20, 0x01, - 0x28, 0x09, 0x48, 0x01, 0x52, 0x09, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x55, 0x72, 0x6c, 0x88, - 0x01, 0x01, 0x12, 0x16, 0x0a, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, 0x64, 0x18, 0x0d, 0x20, 0x01, - 0x28, 0x08, 0x52, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, 0x64, 0x42, 0x0b, 0x0a, 0x09, 0x5f, 0x74, - 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x0d, 0x0a, 0x0b, 0x5f, 0x61, 0x76, 0x61, 0x74, - 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x22, - 0xbb, 0x02, 0x0a, 0x11, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, - 0x61, 0x6c, 0x53, 0x65, 0x74, 0x12, 0x0e, 0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, - 0x09, 0x52, 0x02, 0x69, 0x64, 0x12, 0x17, 0x0a, 0x07, 0x69, 0x73, 0x5f, 0x74, 0x65, 0x61, 0x6d, - 0x18, 0x02, 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x69, 0x73, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x41, - 0x0a, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x28, 0x2e, 0x76, - 0x65, 0x67, 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, - 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, 0x53, 0x65, - 0x74, 0x2e, 0x54, 0x65, 0x61, 0x6d, 0x48, 0x00, 0x52, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x88, 0x01, - 0x01, 0x1a, 0xb0, 0x01, 0x0a, 0x04, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x17, 0x0a, 0x04, 0x6e, 0x61, - 0x6d, 0x65, 0x18, 0x0a, 0x20, 0x01, 0x28, 0x09, 0x48, 0x00, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, - 0x88, 0x01, 0x01, 0x12, 0x1e, 0x0a, 0x08, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x18, - 0x0b, 0x20, 0x01, 0x28, 0x09, 0x48, 0x01, 0x52, 0x07, 0x74, 0x65, 0x61, 0x6d, 0x55, 0x72, 0x6c, - 0x88, 0x01, 0x01, 0x12, 0x22, 0x0a, 0x0a, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, - 0x6c, 0x18, 0x0c, 0x20, 0x01, 0x28, 0x09, 0x48, 0x02, 0x52, 0x09, 0x61, 0x76, 0x61, 0x74, 0x61, - 0x72, 0x55, 0x72, 0x6c, 0x88, 0x01, 0x01, 0x12, 0x1b, 0x0a, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, - 0x64, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x08, 0x48, 0x03, 0x52, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, - 0x64, 0x88, 0x01, 0x01, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x6e, 0x61, 0x6d, 0x65, 0x42, 0x0b, 0x0a, - 0x09, 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x0d, 0x0a, 0x0b, 0x5f, 0x61, - 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x09, 0x0a, 0x07, 0x5f, 0x63, 0x6c, - 0x6f, 0x73, 0x65, 0x64, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x22, 0x23, 0x0a, - 0x11, 0x41, 0x70, 0x70, 0x6c, 0x79, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, 0x43, 0x6f, - 0x64, 0x65, 0x12, 0x0e, 0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, - 0x69, 0x64, 0x42, 0x33, 0x5a, 0x31, 0x63, 0x6f, 0x64, 0x65, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x70, - 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x6f, 0x6c, 0x2e, 0x69, 0x6f, 0x2f, 0x76, 0x65, 0x67, 0x61, 0x2f, - 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x73, 0x2f, 0x76, 0x65, 0x67, 0x61, 0x2f, 0x63, 0x6f, 0x6d, 0x6d, - 0x61, 0x6e, 0x64, 0x73, 0x2f, 0x76, 0x31, 0x62, 0x06, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x33, + 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x12, 0x17, 0x0a, 0x04, 0x73, 0x69, 0x7a, 0x65, 0x18, + 0x09, 0x20, 0x01, 0x28, 0x04, 0x48, 0x02, 0x52, 0x04, 0x73, 0x69, 0x7a, 0x65, 0x88, 0x01, 0x01, + 0x42, 0x08, 0x0a, 0x06, 0x5f, 0x70, 0x72, 0x69, 0x63, 0x65, 0x42, 0x0d, 0x0a, 0x0b, 0x5f, 0x65, + 0x78, 0x70, 0x69, 0x72, 0x65, 0x73, 0x5f, 0x61, 0x74, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x73, 0x69, + 0x7a, 0x65, 0x22, 0xa4, 0x01, 0x0a, 0x1c, 0x4c, 0x69, 0x71, 0x75, 0x69, 0x64, 0x69, 0x74, 0x79, + 0x50, 0x72, 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, + 0x69, 0x6f, 0x6e, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x5f, 0x69, 0x64, + 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, + 0x12, 0x2b, 0x0a, 0x11, 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x5f, 0x61, + 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x10, 0x63, 0x6f, 0x6d, + 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x41, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x10, 0x0a, + 0x03, 0x66, 0x65, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x03, 0x66, 0x65, 0x65, 0x12, + 0x1c, 0x0a, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x06, 0x20, 0x01, + 0x28, 0x09, 0x52, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x4a, 0x04, 0x08, + 0x04, 0x10, 0x05, 0x4a, 0x04, 0x08, 0x05, 0x10, 0x06, 0x22, 0x3d, 0x0a, 0x1e, 0x4c, 0x69, 0x71, + 0x75, 0x69, 0x64, 0x69, 0x74, 0x79, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x43, + 0x61, 0x6e, 0x63, 0x65, 0x6c, 0x6c, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x12, 0x1b, 0x0a, 0x09, 0x6d, + 0x61, 0x72, 0x6b, 0x65, 0x74, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, + 0x6d, 0x61, 0x72, 0x6b, 0x65, 0x74, 0x49, 0x64, 0x22, 0xa3, 0x01, 0x0a, 0x1b, 0x4c, 0x69, 0x71, + 0x75, 0x69, 0x64, 0x69, 0x74, 0x79, 0x50, 0x72, 0x6f, 0x76, 0x69, 0x73, 0x69, 0x6f, 0x6e, 0x41, + 0x6d, 0x65, 0x6e, 0x64, 0x6d, 0x65, 0x6e, 0x74, 0x12, 0x1b, 0x0a, 0x09, 0x6d, 0x61, 0x72, 0x6b, + 0x65, 0x74, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x08, 0x6d, 0x61, 0x72, + 0x6b, 0x65, 0x74, 0x49, 0x64, 0x12, 0x2b, 0x0a, 0x11, 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, + 0x65, 0x6e, 0x74, 0x5f, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, + 0x52, 0x10, 0x63, 0x6f, 0x6d, 0x6d, 0x69, 0x74, 0x6d, 0x65, 0x6e, 0x74, 0x41, 0x6d, 0x6f, 0x75, + 0x6e, 0x74, 0x12, 0x10, 0x0a, 0x03, 0x66, 0x65, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, + 0x03, 0x66, 0x65, 0x65, 0x12, 0x1c, 0x0a, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, + 0x65, 0x18, 0x06, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, + 0x63, 0x65, 0x4a, 0x04, 0x08, 0x04, 0x10, 0x05, 0x4a, 0x04, 0x08, 0x05, 0x10, 0x06, 0x22, 0x67, + 0x0a, 0x12, 0x57, 0x69, 0x74, 0x68, 0x64, 0x72, 0x61, 0x77, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, + 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x01, + 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x14, 0x0a, 0x05, + 0x61, 0x73, 0x73, 0x65, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x61, 0x73, 0x73, + 0x65, 0x74, 0x12, 0x23, 0x0a, 0x03, 0x65, 0x78, 0x74, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, + 0x11, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x57, 0x69, 0x74, 0x68, 0x64, 0x72, 0x61, 0x77, 0x45, + 0x78, 0x74, 0x52, 0x03, 0x65, 0x78, 0x74, 0x22, 0x94, 0x01, 0x0a, 0x12, 0x50, 0x72, 0x6f, 0x70, + 0x6f, 0x73, 0x61, 0x6c, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x1c, + 0x0a, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, + 0x09, 0x52, 0x09, 0x72, 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x12, 0x29, 0x0a, 0x05, + 0x74, 0x65, 0x72, 0x6d, 0x73, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x13, 0x2e, 0x76, 0x65, + 0x67, 0x61, 0x2e, 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x54, 0x65, 0x72, 0x6d, 0x73, + 0x52, 0x05, 0x74, 0x65, 0x72, 0x6d, 0x73, 0x12, 0x35, 0x0a, 0x09, 0x72, 0x61, 0x74, 0x69, 0x6f, + 0x6e, 0x61, 0x6c, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x17, 0x2e, 0x76, 0x65, 0x67, + 0x61, 0x2e, 0x50, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x52, 0x61, 0x74, 0x69, 0x6f, 0x6e, + 0x61, 0x6c, 0x65, 0x52, 0x09, 0x72, 0x61, 0x74, 0x69, 0x6f, 0x6e, 0x61, 0x6c, 0x65, 0x22, 0x59, + 0x0a, 0x0e, 0x56, 0x6f, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, + 0x12, 0x1f, 0x0a, 0x0b, 0x70, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x5f, 0x69, 0x64, 0x18, + 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0a, 0x70, 0x72, 0x6f, 0x70, 0x6f, 0x73, 0x61, 0x6c, 0x49, + 0x64, 0x12, 0x26, 0x0a, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0e, + 0x32, 0x10, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x56, 0x6f, 0x74, 0x65, 0x2e, 0x56, 0x61, 0x6c, + 0x75, 0x65, 0x52, 0x05, 0x76, 0x61, 0x6c, 0x75, 0x65, 0x22, 0x45, 0x0a, 0x12, 0x44, 0x65, 0x6c, + 0x65, 0x67, 0x61, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, + 0x17, 0x0a, 0x07, 0x6e, 0x6f, 0x64, 0x65, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, + 0x52, 0x06, 0x6e, 0x6f, 0x64, 0x65, 0x49, 0x64, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, + 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, + 0x22, 0xe2, 0x01, 0x0a, 0x14, 0x55, 0x6e, 0x64, 0x65, 0x6c, 0x65, 0x67, 0x61, 0x74, 0x65, 0x53, + 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, 0x6f, 0x6e, 0x12, 0x17, 0x0a, 0x07, 0x6e, 0x6f, 0x64, + 0x65, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x6e, 0x6f, 0x64, 0x65, + 0x49, 0x64, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x02, 0x20, 0x01, + 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x45, 0x0a, 0x06, 0x6d, 0x65, + 0x74, 0x68, 0x6f, 0x64, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x2d, 0x2e, 0x76, 0x65, 0x67, + 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x55, 0x6e, + 0x64, 0x65, 0x6c, 0x65, 0x67, 0x61, 0x74, 0x65, 0x53, 0x75, 0x62, 0x6d, 0x69, 0x73, 0x73, 0x69, + 0x6f, 0x6e, 0x2e, 0x4d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x52, 0x06, 0x6d, 0x65, 0x74, 0x68, 0x6f, + 0x64, 0x22, 0x52, 0x0a, 0x06, 0x4d, 0x65, 0x74, 0x68, 0x6f, 0x64, 0x12, 0x16, 0x0a, 0x12, 0x4d, + 0x45, 0x54, 0x48, 0x4f, 0x44, 0x5f, 0x55, 0x4e, 0x53, 0x50, 0x45, 0x43, 0x49, 0x46, 0x49, 0x45, + 0x44, 0x10, 0x00, 0x12, 0x0e, 0x0a, 0x0a, 0x4d, 0x45, 0x54, 0x48, 0x4f, 0x44, 0x5f, 0x4e, 0x4f, + 0x57, 0x10, 0x01, 0x12, 0x1a, 0x0a, 0x16, 0x4d, 0x45, 0x54, 0x48, 0x4f, 0x44, 0x5f, 0x41, 0x54, + 0x5f, 0x45, 0x4e, 0x44, 0x5f, 0x4f, 0x46, 0x5f, 0x45, 0x50, 0x4f, 0x43, 0x48, 0x10, 0x02, 0x22, + 0x04, 0x08, 0x03, 0x10, 0x03, 0x22, 0xea, 0x02, 0x0a, 0x08, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, + 0x65, 0x72, 0x12, 0x3d, 0x0a, 0x11, 0x66, 0x72, 0x6f, 0x6d, 0x5f, 0x61, 0x63, 0x63, 0x6f, 0x75, + 0x6e, 0x74, 0x5f, 0x74, 0x79, 0x70, 0x65, 0x18, 0x01, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x11, 0x2e, + 0x76, 0x65, 0x67, 0x61, 0x2e, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, + 0x52, 0x0f, 0x66, 0x72, 0x6f, 0x6d, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, + 0x65, 0x12, 0x0e, 0x0a, 0x02, 0x74, 0x6f, 0x18, 0x02, 0x20, 0x01, 0x28, 0x09, 0x52, 0x02, 0x74, + 0x6f, 0x12, 0x39, 0x0a, 0x0f, 0x74, 0x6f, 0x5f, 0x61, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x5f, + 0x74, 0x79, 0x70, 0x65, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x11, 0x2e, 0x76, 0x65, 0x67, + 0x61, 0x2e, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x52, 0x0d, 0x74, + 0x6f, 0x41, 0x63, 0x63, 0x6f, 0x75, 0x6e, 0x74, 0x54, 0x79, 0x70, 0x65, 0x12, 0x14, 0x0a, 0x05, + 0x61, 0x73, 0x73, 0x65, 0x74, 0x18, 0x04, 0x20, 0x01, 0x28, 0x09, 0x52, 0x05, 0x61, 0x73, 0x73, + 0x65, 0x74, 0x12, 0x16, 0x0a, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x18, 0x05, 0x20, 0x01, + 0x28, 0x09, 0x52, 0x06, 0x61, 0x6d, 0x6f, 0x75, 0x6e, 0x74, 0x12, 0x1c, 0x0a, 0x09, 0x72, 0x65, + 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x18, 0x06, 0x20, 0x01, 0x28, 0x09, 0x52, 0x09, 0x72, + 0x65, 0x66, 0x65, 0x72, 0x65, 0x6e, 0x63, 0x65, 0x12, 0x3b, 0x0a, 0x07, 0x6f, 0x6e, 0x65, 0x5f, + 0x6f, 0x66, 0x66, 0x18, 0x65, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x20, 0x2e, 0x76, 0x65, 0x67, 0x61, + 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x4f, 0x6e, 0x65, + 0x4f, 0x66, 0x66, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x48, 0x00, 0x52, 0x06, 0x6f, + 0x6e, 0x65, 0x4f, 0x66, 0x66, 0x12, 0x43, 0x0a, 0x09, 0x72, 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, + 0x6e, 0x67, 0x18, 0x66, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x23, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, + 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x52, 0x65, 0x63, 0x75, + 0x72, 0x72, 0x69, 0x6e, 0x67, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x48, 0x00, 0x52, + 0x09, 0x72, 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, 0x6e, 0x67, 0x42, 0x06, 0x0a, 0x04, 0x6b, 0x69, + 0x6e, 0x64, 0x22, 0x2f, 0x0a, 0x0e, 0x4f, 0x6e, 0x65, 0x4f, 0x66, 0x66, 0x54, 0x72, 0x61, 0x6e, + 0x73, 0x66, 0x65, 0x72, 0x12, 0x1d, 0x0a, 0x0a, 0x64, 0x65, 0x6c, 0x69, 0x76, 0x65, 0x72, 0x5f, + 0x6f, 0x6e, 0x18, 0x01, 0x20, 0x01, 0x28, 0x03, 0x52, 0x09, 0x64, 0x65, 0x6c, 0x69, 0x76, 0x65, + 0x72, 0x4f, 0x6e, 0x22, 0xc1, 0x01, 0x0a, 0x11, 0x52, 0x65, 0x63, 0x75, 0x72, 0x72, 0x69, 0x6e, + 0x67, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x12, 0x1f, 0x0a, 0x0b, 0x73, 0x74, 0x61, + 0x72, 0x74, 0x5f, 0x65, 0x70, 0x6f, 0x63, 0x68, 0x18, 0x01, 0x20, 0x01, 0x28, 0x04, 0x52, 0x0a, + 0x73, 0x74, 0x61, 0x72, 0x74, 0x45, 0x70, 0x6f, 0x63, 0x68, 0x12, 0x20, 0x0a, 0x09, 0x65, 0x6e, + 0x64, 0x5f, 0x65, 0x70, 0x6f, 0x63, 0x68, 0x18, 0x02, 0x20, 0x01, 0x28, 0x04, 0x48, 0x00, 0x52, + 0x08, 0x65, 0x6e, 0x64, 0x45, 0x70, 0x6f, 0x63, 0x68, 0x88, 0x01, 0x01, 0x12, 0x16, 0x0a, 0x06, + 0x66, 0x61, 0x63, 0x74, 0x6f, 0x72, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, 0x52, 0x06, 0x66, 0x61, + 0x63, 0x74, 0x6f, 0x72, 0x12, 0x43, 0x0a, 0x11, 0x64, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, 0x68, + 0x5f, 0x73, 0x74, 0x72, 0x61, 0x74, 0x65, 0x67, 0x79, 0x18, 0x04, 0x20, 0x01, 0x28, 0x0b, 0x32, + 0x16, 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x44, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, 0x68, 0x53, + 0x74, 0x72, 0x61, 0x74, 0x65, 0x67, 0x79, 0x52, 0x10, 0x64, 0x69, 0x73, 0x70, 0x61, 0x74, 0x63, + 0x68, 0x53, 0x74, 0x72, 0x61, 0x74, 0x65, 0x67, 0x79, 0x42, 0x0c, 0x0a, 0x0a, 0x5f, 0x65, 0x6e, + 0x64, 0x5f, 0x65, 0x70, 0x6f, 0x63, 0x68, 0x22, 0x31, 0x0a, 0x0e, 0x43, 0x61, 0x6e, 0x63, 0x65, + 0x6c, 0x54, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x12, 0x1f, 0x0a, 0x0b, 0x74, 0x72, 0x61, + 0x6e, 0x73, 0x66, 0x65, 0x72, 0x5f, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, 0x52, 0x0a, + 0x74, 0x72, 0x61, 0x6e, 0x73, 0x66, 0x65, 0x72, 0x49, 0x64, 0x22, 0x94, 0x01, 0x0a, 0x0f, 0x49, + 0x73, 0x73, 0x75, 0x65, 0x53, 0x69, 0x67, 0x6e, 0x61, 0x74, 0x75, 0x72, 0x65, 0x73, 0x12, 0x1c, + 0x0a, 0x09, 0x73, 0x75, 0x62, 0x6d, 0x69, 0x74, 0x74, 0x65, 0x72, 0x18, 0x01, 0x20, 0x01, 0x28, + 0x09, 0x52, 0x09, 0x73, 0x75, 0x62, 0x6d, 0x69, 0x74, 0x74, 0x65, 0x72, 0x12, 0x37, 0x0a, 0x04, + 0x6b, 0x69, 0x6e, 0x64, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0e, 0x32, 0x23, 0x2e, 0x76, 0x65, 0x67, + 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, 0x31, 0x2e, 0x4e, 0x6f, + 0x64, 0x65, 0x53, 0x69, 0x67, 0x6e, 0x61, 0x74, 0x75, 0x72, 0x65, 0x4b, 0x69, 0x6e, 0x64, 0x52, + 0x04, 0x6b, 0x69, 0x6e, 0x64, 0x12, 0x2a, 0x0a, 0x11, 0x76, 0x61, 0x6c, 0x69, 0x64, 0x61, 0x74, + 0x6f, 0x72, 0x5f, 0x6e, 0x6f, 0x64, 0x65, 0x5f, 0x69, 0x64, 0x18, 0x03, 0x20, 0x01, 0x28, 0x09, + 0x52, 0x0f, 0x76, 0x61, 0x6c, 0x69, 0x64, 0x61, 0x74, 0x6f, 0x72, 0x4e, 0x6f, 0x64, 0x65, 0x49, + 0x64, 0x22, 0x8d, 0x02, 0x0a, 0x11, 0x43, 0x72, 0x65, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, + 0x72, 0x72, 0x61, 0x6c, 0x53, 0x65, 0x74, 0x12, 0x17, 0x0a, 0x07, 0x69, 0x73, 0x5f, 0x74, 0x65, + 0x61, 0x6d, 0x18, 0x01, 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x69, 0x73, 0x54, 0x65, 0x61, 0x6d, + 0x12, 0x41, 0x0a, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x18, 0x02, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x28, + 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, + 0x31, 0x2e, 0x43, 0x72, 0x65, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, + 0x53, 0x65, 0x74, 0x2e, 0x54, 0x65, 0x61, 0x6d, 0x48, 0x00, 0x52, 0x04, 0x74, 0x65, 0x61, 0x6d, + 0x88, 0x01, 0x01, 0x1a, 0x92, 0x01, 0x0a, 0x04, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x12, 0x0a, 0x04, + 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x0a, 0x20, 0x01, 0x28, 0x09, 0x52, 0x04, 0x6e, 0x61, 0x6d, 0x65, + 0x12, 0x1e, 0x0a, 0x08, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x18, 0x0b, 0x20, 0x01, + 0x28, 0x09, 0x48, 0x00, 0x52, 0x07, 0x74, 0x65, 0x61, 0x6d, 0x55, 0x72, 0x6c, 0x88, 0x01, 0x01, + 0x12, 0x22, 0x0a, 0x0a, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x18, 0x0c, + 0x20, 0x01, 0x28, 0x09, 0x48, 0x01, 0x52, 0x09, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x55, 0x72, + 0x6c, 0x88, 0x01, 0x01, 0x12, 0x16, 0x0a, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, 0x64, 0x18, 0x0d, + 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x63, 0x6c, 0x6f, 0x73, 0x65, 0x64, 0x42, 0x0b, 0x0a, 0x09, + 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x0d, 0x0a, 0x0b, 0x5f, 0x61, 0x76, + 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x74, 0x65, 0x61, + 0x6d, 0x22, 0xbb, 0x02, 0x0a, 0x11, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, + 0x72, 0x72, 0x61, 0x6c, 0x53, 0x65, 0x74, 0x12, 0x0e, 0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, + 0x01, 0x28, 0x09, 0x52, 0x02, 0x69, 0x64, 0x12, 0x17, 0x0a, 0x07, 0x69, 0x73, 0x5f, 0x74, 0x65, + 0x61, 0x6d, 0x18, 0x02, 0x20, 0x01, 0x28, 0x08, 0x52, 0x06, 0x69, 0x73, 0x54, 0x65, 0x61, 0x6d, + 0x12, 0x41, 0x0a, 0x04, 0x74, 0x65, 0x61, 0x6d, 0x18, 0x03, 0x20, 0x01, 0x28, 0x0b, 0x32, 0x28, + 0x2e, 0x76, 0x65, 0x67, 0x61, 0x2e, 0x63, 0x6f, 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2e, 0x76, + 0x31, 0x2e, 0x55, 0x70, 0x64, 0x61, 0x74, 0x65, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, + 0x53, 0x65, 0x74, 0x2e, 0x54, 0x65, 0x61, 0x6d, 0x48, 0x00, 0x52, 0x04, 0x74, 0x65, 0x61, 0x6d, + 0x88, 0x01, 0x01, 0x1a, 0xb0, 0x01, 0x0a, 0x04, 0x54, 0x65, 0x61, 0x6d, 0x12, 0x17, 0x0a, 0x04, + 0x6e, 0x61, 0x6d, 0x65, 0x18, 0x0a, 0x20, 0x01, 0x28, 0x09, 0x48, 0x00, 0x52, 0x04, 0x6e, 0x61, + 0x6d, 0x65, 0x88, 0x01, 0x01, 0x12, 0x1e, 0x0a, 0x08, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, + 0x6c, 0x18, 0x0b, 0x20, 0x01, 0x28, 0x09, 0x48, 0x01, 0x52, 0x07, 0x74, 0x65, 0x61, 0x6d, 0x55, + 0x72, 0x6c, 0x88, 0x01, 0x01, 0x12, 0x22, 0x0a, 0x0a, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, + 0x75, 0x72, 0x6c, 0x18, 0x0c, 0x20, 0x01, 0x28, 0x09, 0x48, 0x02, 0x52, 0x09, 0x61, 0x76, 0x61, + 0x74, 0x61, 0x72, 0x55, 0x72, 0x6c, 0x88, 0x01, 0x01, 0x12, 0x1b, 0x0a, 0x06, 0x63, 0x6c, 0x6f, + 0x73, 0x65, 0x64, 0x18, 0x0d, 0x20, 0x01, 0x28, 0x08, 0x48, 0x03, 0x52, 0x06, 0x63, 0x6c, 0x6f, + 0x73, 0x65, 0x64, 0x88, 0x01, 0x01, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x6e, 0x61, 0x6d, 0x65, 0x42, + 0x0b, 0x0a, 0x09, 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x0d, 0x0a, 0x0b, + 0x5f, 0x61, 0x76, 0x61, 0x74, 0x61, 0x72, 0x5f, 0x75, 0x72, 0x6c, 0x42, 0x09, 0x0a, 0x07, 0x5f, + 0x63, 0x6c, 0x6f, 0x73, 0x65, 0x64, 0x42, 0x07, 0x0a, 0x05, 0x5f, 0x74, 0x65, 0x61, 0x6d, 0x22, + 0x23, 0x0a, 0x11, 0x41, 0x70, 0x70, 0x6c, 0x79, 0x52, 0x65, 0x66, 0x65, 0x72, 0x72, 0x61, 0x6c, + 0x43, 0x6f, 0x64, 0x65, 0x12, 0x0e, 0x0a, 0x02, 0x69, 0x64, 0x18, 0x01, 0x20, 0x01, 0x28, 0x09, + 0x52, 0x02, 0x69, 0x64, 0x42, 0x33, 0x5a, 0x31, 0x63, 0x6f, 0x64, 0x65, 0x2e, 0x76, 0x65, 0x67, + 0x61, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x63, 0x6f, 0x6c, 0x2e, 0x69, 0x6f, 0x2f, 0x76, 0x65, 0x67, + 0x61, 0x2f, 0x70, 0x72, 0x6f, 0x74, 0x6f, 0x73, 0x2f, 0x76, 0x65, 0x67, 0x61, 0x2f, 0x63, 0x6f, + 0x6d, 0x6d, 0x61, 0x6e, 0x64, 0x73, 0x2f, 0x76, 0x31, 0x62, 0x06, 0x70, 0x72, 0x6f, 0x74, 0x6f, + 0x33, } var (