Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improved coverage for vAMMs #11527

Merged
merged 7 commits into from
Aug 7, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 0 additions & 18 deletions .vscode/launch.json

This file was deleted.

8 changes: 7 additions & 1 deletion core/execution/future/market.go
Original file line number Diff line number Diff line change
Expand Up @@ -5523,6 +5523,7 @@ func (m *Market) SubmitAMM(ctx context.Context, submit *types.SubmitAMM, determi
if order == nil {
m.amm.Confirm(ctx, pool)
m.matching.UpdateAMM(pool.AMMParty)
m.checkForReferenceMoves(ctx, nil, false)
return nil
}

Expand All @@ -5548,6 +5549,7 @@ func (m *Market) SubmitAMM(ctx context.Context, submit *types.SubmitAMM, determi
m.amm.Confirm(ctx, pool)
// now tell the matching engine something new has appeared incase it needs to update its auction IPV cache
m.matching.UpdateAMM(pool.AMMParty)
m.checkForReferenceMoves(ctx, nil, false)
return nil
}

Expand All @@ -5570,7 +5572,6 @@ func (m *Market) AmendAMM(ctx context.Context, amend *types.AmendAMM, determinis
if err != nil {
return err
}

// if we failed to rebase the amended pool be sure to reinstante the old one
defer func() {
if err != nil {
Expand Down Expand Up @@ -5598,6 +5599,7 @@ func (m *Market) AmendAMM(ctx context.Context, amend *types.AmendAMM, determinis
if order == nil {
m.amm.Confirm(ctx, pool)
m.matching.UpdateAMM(pool.AMMParty)
m.checkForReferenceMoves(ctx, nil, false)
return nil
}

Expand All @@ -5615,6 +5617,7 @@ func (m *Market) AmendAMM(ctx context.Context, amend *types.AmendAMM, determinis

m.amm.Confirm(ctx, pool)
m.matching.UpdateAMM(pool.AMMParty)
m.checkForReferenceMoves(ctx, nil, false)
return nil
}

Expand All @@ -5636,6 +5639,9 @@ func (m *Market) CancelAMM(ctx context.Context, cancel *types.CancelAMM, determi
// tell matching incase it needs to remove the AMM's contribution to the IPV cache
m.matching.UpdateAMM(ammParty)

// rejig any pegged orders that might need re-pricing now an AMM is not longer there, or is no longer quoting one side
m.checkForReferenceMoves(ctx, nil, false)

if closeout == nil {
return nil
}
Expand Down
212 changes: 212 additions & 0 deletions core/integration/features/amm/0090-VAMM-037.feature
Original file line number Diff line number Diff line change
@@ -0,0 +1,212 @@
Feature: 0090-VAMM-037: Pegged orders are deployed using vAMM orders as pegs if possible
Background:
Given the average block duration is "1"
And the margin calculator named "margin-calculator-1":
| search factor | initial factor | release factor |
| 1.2 | 1.5 | 1.7 |
And the log normal risk model named "log-normal-risk-model":
| risk aversion | tau | mu | r | sigma |
| 0.001 | 0.0011407711613050422 | 0 | 0.9 | 3.0 |
And the liquidity monitoring parameters:
| name | triggering ratio | time window | scaling factor |
| lqm-params | 1.00 | 20s | 1 |

And the following network parameters are set:
| name | value |
| market.value.windowLength | 60s |
| network.markPriceUpdateMaximumFrequency | 2s |
| limits.markets.maxPeggedOrders | 6 |
| market.auction.minimumDuration | 1 |
| market.fee.factors.infrastructureFee | 0.001 |
| market.fee.factors.makerFee | 0.004 |
| spam.protection.max.stopOrdersPerMarket | 5 |
| market.liquidity.equityLikeShareFeeFraction | 1 |
| market.amm.minCommitmentQuantum | 1 |
| market.liquidity.bondPenaltyParameter | 0.2 |
| market.liquidity.stakeToCcyVolume | 1 |
| market.liquidity.successorLaunchWindowLength | 1h |
| market.liquidity.sla.nonPerformanceBondPenaltySlope | 0.1 |
| market.liquidity.sla.nonPerformanceBondPenaltyMax | 0.6 |
| validators.epoch.length | 10s |
| market.liquidity.earlyExitPenalty | 0.25 |
| market.liquidity.maximumLiquidityFeeFactorLevel | 0.25 |
#risk factor short:3.5569037
#risk factor long:0.801225765
And the following assets are registered:
| id | decimal places |
| USD | 0 |
And the fees configuration named "fees-config-1":
| maker fee | infrastructure fee |
| 0.0004 | 0.001 |

And the liquidity sla params named "SLA-22":
| price range | commitment min time fraction | performance hysteresis epochs | sla competition factor |
| 0.5 | 0.6 | 1 | 1.0 |

And the markets:
| id | quote name | asset | liquidity monitoring | risk model | margin calculator | auction duration | fees | price monitoring | data source config | linear slippage factor | quadratic slippage factor | sla params |
| ETH/MAR22 | USD | USD | lqm-params | log-normal-risk-model | margin-calculator-1 | 2 | fees-config-1 | default-none | default-eth-for-future | 1e0 | 0 | SLA-22 |

# Setting up the accounts and vAMM submission now is part of the background, because we'll be running scenarios 0090-VAMM-006 through 0090-VAMM-014 on this setup
Given the parties deposit on asset's general account the following amount:
| party | asset | amount |
| lp1 | USD | 1000000 |
| lp2 | USD | 1000000 |
| lp3 | USD | 1000000 |
| party1 | USD | 1000000 |
| party2 | USD | 1000000 |
| party3 | USD | 1000000 |
| party4 | USD | 1000000 |
| party5 | USD | 1000000 |
| vamm1 | USD | 1000000 |

When the parties submit the following liquidity provision:
| id | party | market id | commitment amount | fee | lp type |
| lp_1 | lp1 | ETH/MAR22 | 600 | 0.02 | submission |
| lp_2 | lp2 | ETH/MAR22 | 400 | 0.015 | submission |
Then the network moves ahead "4" blocks
And the current epoch is "0"

And the parties place the following orders:
| party | market id | side | volume | price | resulting trades | type | tif | reference |
| lp1 | ETH/MAR22 | buy | 20 | 40 | 0 | TYPE_LIMIT | TIF_GTC | LP1BO |
| party1 | ETH/MAR22 | buy | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | |
| party2 | ETH/MAR22 | sell | 1 | 100 | 0 | TYPE_LIMIT | TIF_GTC | |
| lp1 | ETH/MAR22 | sell | 10 | 160 | 0 | TYPE_LIMIT | TIF_GTC | LP1SO |
When the opening auction period ends for market "ETH/MAR22"
Then the following trades should be executed:
| buyer | price | size | seller |
| party1 | 100 | 1 | party2 |

And the market data for the market "ETH/MAR22" should be:
| mark price | trading mode | target stake | supplied stake | open interest | ref price | mid price | static mid price |
| 100 | TRADING_MODE_CONTINUOUS | 39 | 1000 | 1 | 100 | 100 | 100 |
When the parties submit the following AMM:
| party | market id | amount | slippage | base | upper bound | upper leverage | proposed fee |
| vamm1 | ETH/MAR22 | 100000 | 0.1 | 100 | 150 | 4 | 0.01 |
Then the AMM pool status should be:
| party | market id | amount | status | base | upper bound | upper leverage |
| vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 150 | 4 |

And set the following AMM sub account aliases:
| party | market id | alias |
| vamm1 | ETH/MAR22 | vamm1-id |
And the following transfers should happen:
| from | from account | to | to account | market id | amount | asset | is amm | type |
| vamm1 | ACCOUNT_TYPE_GENERAL | vamm1-id | ACCOUNT_TYPE_GENERAL | | 100000 | USD | true | TRANSFER_TYPE_AMM_LOW |

@VAMM
Scenario: 0090-VAMM-037: With an existing book consisting solely of vAMM orders on one side, pegged orders referencing best bid/best ask remain deployed on the side with the vAMM orders. Pegged orders referencing the empty side of the book are parked.
# LPs submit pegged iceberg orders
When the parties place the following pegged iceberg orders:
| party | market id | side | volume | peak size | minimum visible size | pegged reference | offset |
| lp1 | ETH/MAR22 | buy | 100 | 10 | 2 | BID | 5 |
| lp1 | ETH/MAR22 | sell | 100 | 10 | 2 | ASK | 5 |
Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 20 |
| buy | 35 | 10 |
| sell | 106 | 10 |
| sell | 160 | 10 |

# Make sure the book stays the same when moving ahead blocks
When the network moves ahead "1" blocks
Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 20 |
| buy | 35 | 10 |
| sell | 106 | 10 |
| sell | 160 | 10 |

When the parties cancel the following orders:
| party | reference |
| lp1 | LP1BO |
| lp1 | LP1SO |
Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 0 |
| buy | 35 | 0 |
| sell | 106 | 10 |
| sell | 160 | 0 |

# Move ahead 1 block to ensure the end block CheckBook call doesn't panic.
When the network moves ahead "1" blocks
Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 0 |
| buy | 35 | 0 |
| sell | 106 | 10 |
| sell | 160 | 0 |

# Switch sides, still on an empty book, the pegged orders on sell side are now parked
# but the buy order is deployed again.
When the parties amend the following AMM:
| party | market id | slippage | base | lower bound |
| vamm1 | ETH/MAR22 | 0.05 | 100 | 85 |
Then the AMM pool status should be:
| party | market id | amount | status | base | lower bound |
| vamm1 | ETH/MAR22 | 100000 | STATUS_ACTIVE | 100 | 85 |

When the network moves ahead "1" blocks
Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 0 |
| buy | 94 | 10 |
| sell | 106 | 0 |
| sell | 160 | 0 |

@VAMM
Scenario: 0090-VAMM-037: Cancelling an AMM with pegged orders hanging off its quotes causes them to be re-pegged

And the market data for the market "ETH/MAR22" should be:
| mark price | trading mode | ref price | mid price | static mid price | best bid price | best offer price |
| 100 | TRADING_MODE_CONTINUOUS | 100 | 70 | 70 | 40 | 101 |


When the parties place the following pegged orders:
| party | market id | side | volume | pegged reference | offset |
| lp1 | ETH/MAR22 | buy | 100 | BID | 5 |
| lp1 | ETH/MAR22 | sell | 100 | ASK | 5 |


Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 20 |
| buy | 35 | 100 |
| sell | 106 | 100 |
| sell | 160 | 10 |

# cancel the AMM and the pegged order should get repriced
When the network moves ahead "1" blocks
When the parties cancel the following AMM:
| party | market id | method |
| vamm1 | ETH/MAR22 | METHOD_IMMEDIATE |

Then the market data for the market "ETH/MAR22" should be:
| mark price | trading mode | ref price | mid price | static mid price | best bid price | best offer price |
| 100 | TRADING_MODE_CONTINUOUS | 100 | 100 | 100 | 40 | 160 |

Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 20 |
| buy | 35 | 100 |
| sell | 160 | 10 |
| sell | 165 | 100 |

# submit a new AMM that will cause a reprice again
When the network moves ahead "1" blocks
When the parties submit the following AMM:
| party | market id | amount | slippage | lower bound | base | upper bound | upper leverage | proposed fee |
| vamm1 | ETH/MAR22 | 100000 | 0.1 | 90 | 100 | 150 | 4 | 0.01 |

Then the market data for the market "ETH/MAR22" should be:
| mark price | trading mode | ref price | mid price | static mid price | best bid price | best offer price |
| 100 | TRADING_MODE_CONTINUOUS | 100 | 100 | 100 | 99 | 101 |


Then the order book should have the following volumes for market "ETH/MAR22":
| side | price | volume |
| buy | 40 | 20 |
| buy | 94 | 100 |
| sell | 106 | 100 |
| sell | 160 | 10 |
Loading
Loading