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

[Bug]: maker volume not considered in the next epoch when calculating maker volume fraction #11592

Closed
cdummett opened this issue Aug 16, 2024 · 0 comments · Fixed by #11596
Closed
Assignees
Labels

Comments

@cdummett
Copy link
Contributor

Problem encountered

Tests added in #11591 check volume for trades correctly contribute towards a party's cumulative maker volume and therefore are used to consider their maker volume fraction and rebate factor.

Currently... with a volume rebate program enacted, regardless of window length

  • if volume is generated in an epoch
  • in the next epoch - volume is not considered (party receives no rebate)
  • in the next epoch - volume is now considered (party does receive a rebate)

Following tests demonstrate this behaviour:

go test -v ./core/integration/... --godog.format=pretty $(pwd)/core/integration/features/volume-rebate/0095-HVMR.feature:59
go test -v ./core/integration/... --godog.format=pretty $(pwd)/core/integration/features/volume-rebate/0095-HVMR.feature:156

Observed behaviour

Volume rebate program is created and enacted by moving forwards an epoch.

    Given the volume rebate program tiers named "vrt":
      | fraction | rebate |
      | 0.0001   | 0.001  |
    And the volume rebate program:
      | id | tiers | closing timestamp | window length |
      | id | vrt   | 0                 | 1             |
    And the network moves ahead "1" epochs

party1 is the maker, party2 is the taker

And the parties place the following orders:
      | party  | market id   | side | volume | price | resulting trades | type       | tif     | error |
      | party1 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | party2 | BTC/USD-0-1 | sell | 1      | 50000 | 1                | TYPE_LIMIT | TIF_GTC |       |
    When the network moves ahead "1" blocks
    Then the following trades should be executed:
      | buyer  | seller | size | price | aggressor side | buyer maker fee | seller maker fee |
      | party1 | party2 | 1    | 50000 | sell           | 0               | 500              |

We move forwards an epoch and now both party1 and party2 are makers

Given the network moves ahead "1" epochs
    And the parties place the following orders:
      | party  | market id   | side | volume | price | resulting trades | type       | tif     | error |
      | party1 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | party2 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | aux1   | BTC/USD-0-1 | sell | 2      | 50000 | 2                | TYPE_LIMIT | TIF_GTC |       |
    When the network moves ahead "1" blocks

party1 however receives no rebate.... 🔴

    Then the following trades should be executed:
      | buyer  | seller | size | price | aggressor side | buyer high volume maker fee | seller high volume maker fee |
      | party1 | aux1   | 1    | 50000 | sell           | 0                           | 0                            |
      | party2 | aux1   | 1    | 50000 | sell           | 0                           | 0                            |

Note, if we instead moved forwards "2" epochs before generating the final trades, the rebate is applied successfully.

Expected behaviour

Volume rebate program is created and enacted by moving forwards an epoch.

    Given the volume rebate program tiers named "vrt":
      | fraction | rebate |
      | 0.0001   | 0.001  |
    And the volume rebate program:
      | id | tiers | closing timestamp | window length |
      | id | vrt   | 0                 | 1             |
    And the network moves ahead "1" epochs

party1 is the maker, party2 is the taker

And the parties place the following orders:
      | party  | market id   | side | volume | price | resulting trades | type       | tif     | error |
      | party1 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | party2 | BTC/USD-0-1 | sell | 1      | 50000 | 1                | TYPE_LIMIT | TIF_GTC |       |
    When the network moves ahead "1" blocks
    Then the following trades should be executed:
      | buyer  | seller | size | price | aggressor side | buyer maker fee | seller maker fee |
      | party1 | party2 | 1    | 50000 | sell           | 0               | 500              |

We move forwards an epoch and now both party1 and party2 are makers

Given the network moves ahead "1" epochs
    And the parties place the following orders:
      | party  | market id   | side | volume | price | resulting trades | type       | tif     | error |
      | party1 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | party2 | BTC/USD-0-1 | buy  | 1      | 50000 | 0                | TYPE_LIMIT | TIF_GTC |       |
      | aux1   | BTC/USD-0-1 | sell | 2      | 50000 | 2                | TYPE_LIMIT | TIF_GTC |       |
    When the network moves ahead "1" blocks

party1 should receives a rebate.... 🟢

    Then the following trades should be executed:
      | buyer  | seller | size | price | aggressor side | buyer high volume maker fee | seller high volume maker fee |
      | party1 | aux1   | 1    | 50000 | sell           | 0                           | 50                           |
      | party2 | aux1   | 1    | 50000 | sell           | 0                           | 0                            |
    Then the following transfers should happen:
      | from | to     | from account            | to account           | market id   | amount | asset   | type                                        |
      |      | party1 | ACCOUNT_TYPE_FEES_MAKER | ACCOUNT_TYPE_GENERAL | BTC/USD-0-1 | 50     | USD-0-1 | TRANSFER_TYPE_HIGH_MAKER_FEE_REBATE_RECEIVE |

Steps to reproduce

git checkout feat/hvmr-acs
go test -v ./core/integration/... --godog.format=pretty $(pwd)/core/integration/features/volume-rebate/0095-HVMR.feature:59

Software version

d596da3

Failing test

core/integration/features/volume-rebate/0095-HVMR.feature

Jenkins run

No response

Configuration used

defaults

Relevant log output

none
@cdummett cdummett added the bug label Aug 16, 2024
@cdummett cdummett added this to the 🏯 Suzuka Castle milestone Aug 16, 2024
@ze97286 ze97286 self-assigned this Aug 17, 2024
@vega-issues vega-issues moved this to Waiting Review in Core Kanban Aug 17, 2024
@vega-issues vega-issues moved this from Waiting Review to Approved in Core Kanban Aug 17, 2024
@github-project-automation github-project-automation bot moved this from Approved to Merged in Core Kanban Aug 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

2 participants