You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
Following tests demonstrate this behaviour:
Observed behaviour
Volume rebate program is created and enacted by moving forwards an epoch.
party1 is the maker, party2 is the taker
We move forwards an epoch and now both party1 and party2 are makers
party1 however receives no rebate.... 🔴
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.
party1 is the maker, party2 is the taker
We move forwards an epoch and now both party1 and party2 are makers
party1 should receives a rebate.... 🟢
Steps to reproduce
Software version
d596da3
Failing test
core/integration/features/volume-rebate/0095-HVMR.feature
Jenkins run
No response
Configuration used
Relevant log output
The text was updated successfully, but these errors were encountered: