❓Trading Rewards - FAQs

Frequently asked questions for VRTX trading rewards.

How to query the amount of rewards I have earned?

Via the Rewards query.

Do we need to be >0.25% of maker volume in epoch 1 to qualify for epoch 2?

No, each epoch is independent. You will qualify as long as your maker volume of the current epoch is >0.25%.

Quoting requirements are 5K per side for BTC/USDC and ETH/USDC spot, what’s the requirements for BTC and ETH perps?

Spot and perpetual markets have the same requirements, so both of them should be 5K.

How is the uptime field in the rewards response calculated?

Uptime represents the total minutes in the epoch (out of 28 days) your Q_MIN(N) is positive, so it's a value in the range of [0, 40320].

What does maker_fee in rewards response represent? Isn’t maker fee rate 0?

maker_fee doesn’t represent fees that maker paid, it represents the accumulative taker_fee that the opposite side of your maker order paid, which means for a trade --

(taker, maker, taker_fee), we keep track of fees as follows --

taker_fees(taker) += taker_fee, maker_fees(maker) += taker_fee.

Are all calculations based on subaccount or wallet address?

Calculations are based on wallet addresses. To sum them up, we extract the wallet from all subaccounts, and all trades / orders across multiple subaccounts are unified.

Do we have to provide liquidity on both the bid and ask sides of the orderboook to get rewards?

Yes, we take the smaller side of bid and ask as your size.

What does reward_coefficient refer to in global_rewards of rewards response?

The reward_coefficient / num_product represents the portion of tokens (both maker and taker) allocated to the product. Assume epoch total maker tokens are 1000, we have 4 products. If a product has reward_coefficient = 1.2, maker / taker tokens allocated to this product will be 1000 * 1.2 / 4.

We want to allocate more tokens to more active markets, so the more fees a market collected, the higher reward_coefficient it will have.

For Q_MIN(N), does the order need to be in the books for the whole minute to qualify?

Not the whole minute, we take a snapshot every minute using random sampling. You’ll qualify as long as you meet the requirements when the snapshot is taken.

How is the base price determined when calculating spread?

We use the mid-market price --(bid_1 + ask_1) / 2.

Can you provide an example illustrating the Q_MIN(N) calculations?

Q_MIN(N) = min(Q_BID(N), Q_ASK(N)), where:

• Q_BID(N) = BidDepth_1 / BidSpread_1 + BidDepth_2 / BidSpread_2 + ...

• Q_ASK(N) = AskDepth_1 / AskSpread_1 + AskDepth_2 / AskSpread_2 + ...

We’ll use an example to introduce how these values (Depth and Spread) are calculated.

Assume you have the following orders:

• Price: $80, size: 999 (bid)

• Price: $98, size: 10 (bid)

• Price: $99, size: 6 (bid)

• Price: $101, size: 8 (ask)

• Price: $102, size: 15 (ask)

• Price: $140: size: 999 (ask)

Assuming the mid market price is $100, min depth is $1.5k, and max spread is 0.05, we have:

• BidDepth_3 = 80*999 = 79920, BidSpread_3 = (100-80)/100 = 0.2

• BidDepth_2 = 98*10 = 980, BidSpread_2 = (100-98)/100 = 0.02

• BidDepth_1 = 99*6 = 594, BidSpread_1 = (100-99)/100 = 0.01

• AskDepth_1 = 101*8 = 808, AskSpread_1 = (101-100)/100 = 0.01

• AskDepth_2 = 102*15 = 1530, AskSpread_2 = (102-100)/100 = 0.02

• AskDepth_3 = 140*999 = 139860, AskSpread_3 = (140-100)/100 = 0.4

Since BidSpread_3 > 0.05 and AskSpread_3 > 0.05, these two orders will be ignored. Now the depths of valid orders are:

• BidDepth = BidDepth_2 + BidDepth_1 = 1574

• AskDepth = AskDepth_2 + AskDepth_1 = 2338

Since both depths are more than the requirement ($1.5k), we have:

• Q_BID(N) = 594 / 0.01 + 980 / 0.02 = 108400

• Q_ASK(N) = 808 / 0.01 + 1530 / 0.02 = 157300

So, Q_MIN(N) = min(108400, 157300) = 108400.

However, if the $99 order’s size is 5 (instead of 6), the Q_MIN(N) will be 0 since the min depth requirement can’t be fulfilled on the bid side.

How can I get more maker tokens?

We have q_score = sum_q_min^0.3 * maker_fee^0.7 * uptime^5, where sum_q_min represents the sum Q_MIN(N) across all minutes, maker_fee and uptime have been introduced above. q_score directly determines how many tokens you will get which is -- q_score / sum(q_score, across all addresses) * total_maker_tokens, so you can try to increase any of these three values to get better q_score subsequently getting more tokens.