Comment on page
🇪🇺
How are hashrate and PAN rewards calculated in Trade Mining V2.0?
Reward calculations in Trade Mining V2.0.
Trade Mining V2.0 is set to bring about many significant changes in the way Pandora's users are rewarded for trading on pandora.digital.
Trade mining rewards are funded by 37% of the total number of PAN minted in each block. More specifically, for each new block minted, 9.28125 PAN tokens will go towards funding trade mining. In the reinvented version of Trade Mining, there are two major reward pools: Instant Pool & Savings Pool. The purposes of these two also vary, let’s figure out:
Instant Pool: the more you trade, the higher your hashrate, and the more PAN rewards you receive.
Savings Pool: you earn compound interest as long as you do not harvest your PAN rewards.
Currently, 50% of the total trade mining rewards are set aside for the Instant Pool, whereas 50% is allocated directly to the Savings Pool. That means for every new block minted, 4.640625 PAN will go to the Instant Pool, and an equal number of PAN will go to the Savings Pool.
The reward ratio between the Instant and Saving Pools is subject to change.
In version 2, trade mining rewards will be paid out every epoch, initially equaling 1 hour. This interval may be subject to change.
In Trade Mining V2.0, every time someone conducts a successful trade via Pandora Swap, he or she will earn a certain amount of hashrate proportional to the volume of that particular trade. This amount of hashrate is used upon calculating the trade mining rewards from the Instant Pool the user is entitled to in each epoch.
Note: Hashrate earned during a specific epoch is valid during that epoch only and shall not be carried over to the next one. That means your hashrate will be reset to 0 when a new epoch starts.
Individual Rewards = Individual Hashrate [i] / Total Hashrate [i] * Epoch [i] Rewards
Individual Hashrate: Hashrate a user earned in epoch [i]
Total Hashrate: The sum of the hashrate acquired by all users in epoch [i]
Epoch [i] ewards: The total rewards allocated to Instant Pool in epoch [i]
User A’s Hashrate Earned | User B’s Hashrate Earned | Rewards Earned from Instant Pool | |
Epoch 1 | 10 | 0 | User A will earn 100% rewards of Instant Pool for this epoch. |
Epoch 2 | 0 | 5 | User B will earn 100% rewards of Instant Pool for this epoch. |
Epoch 3 | 10 | 40 | User A will earn 10/50 = 20% rewards of Instant Pool for this epoch. Meanwhile, user B will receive 40/50 = 80% rewards. ***50 is the total hashrate earned by all users during this epoch. |
Individual Rewards = Individual Pending Rewards [i] / Total Pending Rewards [i] * Epoch [i] Rewards
Individual Rewards: PAN rewards earned from the Savings Pool by a user during epoch [i].
Individual Pending Rewards [i]: The total unclaimed rewards of a user snapshotted when epoch [i] ends.
Total Pending Rewards [i]: The total unclaimed rewards of all users snapshotted when epoch [i] ends.
Epoch [i] Rewards: The total rewards allocated to Savings Pool in epoch [i].
There are 2 token lists to determine whether a trade is qualified for receiving hashrate.
Incentive List: a list of all tokens qualified for hashrate and predetermined by Pandora. A trade is entitled to hashrate when either or both input or output token of that specific trade fall into this list. Each token in this list is associated with a preset multiplier.
Verified List: a list of all tokens that have been internally audited and verified by Pandora. In case only the input or output token of a swap is listed in the Incentive List, the other one must fall into the Verified List, otherwise, no hashrate will be credited for your trade.
For instance: you’d like to swap 100 X tokens for 50 Y tokens. Your trade will be eligible for hashrate in case:
Both X and Y tokens belong in the Incentive List
or
Either X or Y belongs in the Incentive List
&
If X falls into the Incentive List, then Y must belong in the Verified List and vice versa.
Supposing there’re currently 3 tokens in the Incentive List, including PSR, PAN, and BNB. Along with that, there’re 2 tokens in the Verified List, which are BUSD & USDT.
Let’s review in which of the cases below a person will receive hashrate upon trading on pandora.digital:
Input => Output | Earn Hashrate? | Elaboration |
PSR => BUSD | Yes | The user swapped PSR for BUSD. While PSR belongs in the Incentive List, BUSD, on other hand, belongs in the Verified List, thus this swap is eligible for hashrate. |
USDT => PAN | Yes | PAN falls into the Incentive List, whereas USDT belongs in the Verified List. In this case, the user will receive hashrate. |
PAN => BNB | Yes | Both PAN and BNB belong in the Incentive List. Therefore, the user will earn hashrate. |
BNB => MEME | No | BNB falls into the Incentive List but MEME does not belong in any list. Therefore, the swap is not eligible for hashrate. |
BUSD => USDT | No | Both BUSD and USDT belong in the Verified List, with none of them falls into the Incentive List, thus this swap is not eligible for hashrate. |
A swap might be routed across different liquidity pools for best price execution. Therefore, a swap might involve more than 2 tokens.
For instance, a user would like to swap PSR for USDT, and Pandora’s Swap V2.0 algorithmically suggests route PSR > BUSD > USDC > USDT because this would bring the highest token output. If the user opts for this route, only the input token PSR and the output token USDT will be taken into consideration upon determining whether this trade is eligible for hashrate.

For instance: there’re currently 3 tokens in the Incentive List, including PSR, PAN, and BNB, and 2 tokens in the Verified List, which are BUSD & USDT. Although USDC does not fall into any of the aforementioned categories, this swap is still qualified for hashrate because its input token PSR is included in the Incentive List and its output token is indeed mentioned in the Verified List.
In some cases, Pandora will restrict a certain swap route that goes through a specific DEX from earning hashrate. Although you may see that your input or output token is listed in the Verified or Incentive List, your swap might not be eligible for hashrate because the swap route you undertake has been restricted from receiving hashrate.
Let’s take a closer look at this circumstance.
Pandora’s Incentive List currently includes BTCB and ETH, and its Verified List includes USDT.
A user wants to conduct the following swaps:
BTCB (NomiSwap) => BNB (Biswap) => USDT
USDT (PancakeSwap) => BNB (Biswap) => ETH
You might assume both the input (BTCB, USDT) and output token (USDT, ETH) of these swaps meet the requirements for receiving hashrate. However, if Pandora restricts the following routes: BTCB + NomiSwap; ETH + Biswap from receiving hashrate, meaning no hashrate will be given to you for conducting the swaps above.
Hashrate Received = Token’s Multiplier/Total Multiplier * Trading Volume
Hashrate Received: the amount of hashrate you earned for a successful trade
Token’s Multiplier: if both the input and output tokens belong in the Incentive List, each is assigned a specific multiplier. The higher multiplier will be taken into consideration upon calculating hashrate for that swap.
Total Multiplier: the sum of the multiplier of all the tokens available in the Incentive List
Trading Volume = Number of Input Tokens * Input Token’s Price
(updated on 14 December 2022)
Trading Volume: the USD value of the incentive token of the trade:
If the input token belongs in the Incentive List, then the trading volume is calculated as follows:
If the output token belongs in the Incentive List, then the trading volume is calculated as follows:
Trading Volume = Number of Output Tokens * Output Token’s Price
If both the input and output tokens belong in the Incentive List, then the one with the higher multiplier will be used upon calculating trading volume.
Token price is the 10-minute price average of a particular token and is sourced from Price Oracle.
Input => Output | Trading Volume | Hashrate Earned | Elaboration |
PSR => BUSD | $10 | 10*100/300 = 3.33 | PSR is an incentive token. BUSD is a verified token. This swap is qualified for receiving hashrate. |
USDT => PAN | $10 | 10*150/300 = 5 | PAN is an incentive token, USDT is a verified token. This swap is qualified for receiving hashrate. |
PAN => BNB | $10 | 10*150/300 = 5 | Both PAN and BNB are incentive tokens. However, PAN has a higher multiplier of 150. Therefore, PAN’s multiplier is used when calculating the amount of hashrate given for this swap. |
BNB => MEME | $10 | 0 | BNB is an incentive token but MEME is neither an incentive nor a verified token, thus this swap is not qualified for receiving hashrate. |