As explained on the Mechanics page, one of the key components of this game is the "autoplay" functionality. Players can enable an automatic upgrading option at any time which causes new giftboxes to be purchased for them anytime their current giftboxes contain enough value to do so:
- Players can choose to opt-in to automatically compound re-invest their giftboxes
- Whenever one or more giftboxes can be purchased, twice (2x) the total value inside their existing giftboxes are used to purchase more boxes, without destroying the ones they already hold
- Every time a player re-invests, they automatically re-enter the top 100, and re-qualify for the prize at the end of the round
- This automatic upgrade is free and can be switched on or off at any time
But how is autoplay achieved behind the scenes?
About Decentralized Reinvest Mining
Players can run a special software they build to get rewarded with bonuses as they execute automatic upgrade actions on behalf of other players:
- Players (aka "Miners") can run a software which powers the auto-reinvesting feature for other players
- Miners are then paid 1% of the value they helped to reinvest (from the contract, not the player) to process the auto-reinvests for other players
- Any player can choose to become a miner, and this is how automatic upgrades work behind the scenes! It's important to note that all fees paid to miners come from the contract and are not paid by the player triggering the auto-reinvest.
In this guide, we'll look at the technical details you'll need to build your own miner!
Can anyone build a miner? or do I need to be a developer?
To develop your own miner requires basic coding knowledge or the ability to learn:
- Basic programming knowledge
- TronWeb - For communicating with the contract
❗ Warning: Note that running code from someone you don't know in the crypto space is really dangerous. Don't try to use other people's code that you have not verified yourself or that has been verified by someone you trust.
At a later time, we may provide a safe open-source miner which would allow mining to be more widely accessible. For now, you will need to be able to develop your own miner as described below.
What does a mining software do?
- Within JUST.GAME, users with existing tokens can toggle a boolean setting in their profile called "auto-play" (
- This boolean is flagged in an event on chain, giving information to third parties that users are willing to have their reinvestments taken care off.
- Now whenever this hypothetical user's accumulated dividends reach a certain threshold, third party bots are enabled to reinvest on their behalf
- When this occurs, the third party bot takes this user's dividends, and reinvests it all on their behalf using the
- The third party miner is then awarded 1% of the value used in the reinvestment as compensation, without taking that amount from the original user
In summary, the mining software will scan for accounts on Just.game that have reached the reinvestment threshold, and then execute that reinvest on their behalf, in order to take that 1% premium for every successfully reinvested account.
Developing our First Reinvest Miner
Let's take a look at all the pieces you'll need to develop your own miner!
Interacting with the Smart Contract
In order to develop our miner, first let's note that we will primarily be interacting with the Just.game TRON smart contract on the mainnet (address:
To interact with the smart contract, you'll need a few helpful resources for reference:
- ABI Summary - This is the list of relevant methods and events you can call to interact with the smart contract.
- ABI JSON - This is the slimmed down ABI JSON in order to get more insight into the inputs/outputs/etc for each of these calls.
- Sample TronWeb Starter Code - The basics of how TronWeb works to interact with a smart contract.
How do we know if a user can be reinvested by the miner? Each active account holds a boolean
automaticallyUpgrade. Whenever this is set to true, you can reinvest on their behalf at any time, the only real condition here is that the reinvestment action would result in one "box" (currently that means they should hold about 0.20$ approximately in dividends). You can check if this the case by observing their outstanding dividend balance.
So how do we reinvest on a user's behalf? The actual reinvestment mechanism consists of a singular solidity function you need to invoke
upgradeTickets, taking one parameter: the address of the user you're reinvesting for. As long as this specified user has enough dividends to receive 1 whole box ("ticket") on reinvesting (about 0.20$) - you will be credited 1% of that reinvest.
Basic Strategy Definition
One challenge is that even though you can see how many dividends there are queued in balance for each user, there's no on-chain way to "automatically" see when the threshold of dividends of a user is reached. Your bot will need to manually track, one way or the other, when the best time to fire off the reinvestment function is per user.
The easiest way to do this is to cache a list of every user who has the autoplay feature enabled, and constantly do HTTP/RPC calls to the chain to check their outstanding dividends and checking if it's worthy to fire an auto-reinvest yet. This is, of course, very simple but also highly inefficient and if you don't run a private node yourself, you will most likely crash whichever public node you are connected to due to the high volume of HTTP/RPC calls you will be doing.
To recap our miner's basic directives in this strategy:
- Cache a list of all users with autoplay enabled, or otherwise determine which users are on autoplay
- Simulate/model outstanding dividends or check with the contract manually to see a user's dividends
- If they are holding at least 0.20$ in dividends, initiate a delegated reinvest on their behalf
- Listen for new autoplay enables/disables, and disable users from re-investing if they untoggle
Leveling Up Our Strategy
Constantly doing HTTP/RPC calls to the chain to check every user's outstanding dividends when a purchase happens is highly inefficient and if you don't run a private node yourself, you will most likely crash whichever public node you are connected to due to the high number of calls.
In order to make our miner more efficient, we might want want to cache a snapshot of the list of every that have autoplay boolean enabled, storing their current outstanding dividends AND their total tokens on-disk. Your bot then listens for new blocks, filtering all JUST.GAME transactions. Whenever there's a block with one or multiple buys/reinvests, your bot simulates the new dividend balances in-memory for each of these stored users and consider if it's worthy to fire the auto-reinvest.
This way you effectively mirror the blockchain without doing any expensive calls, or waiting for things to compute. More efficiency, but also more difficult to pull off without screwing up. Also don't forget to listen for new autoplay enables/disables.
There's many possible strategies layers here. For example, you can take it a step further by simulating the cascading effect your reinvest will have on other accounts and line up a reinvestment for them as well. And so forth.
To recap our advanced miner's upgraded functionality in this case:
- Cache a user's outstanding dividends AND their total tokens on-disk along with autoplay
- Listen for new blocks on chain, and filter all JUST.GAME transactions
- When a block has one or multiple buys/reinvests, your bot simulates the new dividend balances in-memory for each of these stored users and consider if it's worthy to fire the autoreinvest.
- This way you effectively mirror the blockchain without doing any expensive calls
- You can take it a step further by simulating the cascading effect your reinvest will have on other accounts and line up a reinvestment for them as well.
(Note that this may be very difficult in practice due to missing data, but feel free to explore and see what works, some form of caching is better than none)
Calculating a Player's Dividends
In pseudocode, here is how you would calculate a player's total royalties available for reinvesting:
roundRoyalties = dividendsOf(currentRound, activeAccount); totalRoyalties = Players[activeAccount].squadEarnings + Players[activeAccount].dividendEarnings + Players[activeAccount].winnerEarnings + roundRoyalties;
In other words, to calculate if a player can be reinvested, you need to take into account all of these different factors leveraging info in both
Due to the glitches, entry price for boxes get continuously cheaper as time goes on. They cascade down by 25% of the base price for every time "the bomb" triggers. Refer to the following methods:
Rounds[currentRoundNumber()].bombFuseCounter -> total times bomb has triggered function bombTriggerThreshold(uint256 _fuseCounter) -> static return, total amount of time that will elapse before a bomb triggers, this is connected with the main game timer in code itself but simply returns a flat value for reference. function toTickets(uint256 _incomingFunds) -> calculate how many tickets you get, factors in the bombFuseCounter.
Testing Your Miner
Feel free to test your new miner directly on mainnet, and see if you can start reinvesting transactions! Good luck and happy mining!
Bonus Miner Tips
Loading Player Cache
When starting out fresh and without a cache of current players, you would have to iterate through all of the players in the active round for your starting point. I'd recommend using your own node for this on the mainnet, as it will be a taxing.
Inputting String into Function on TronWeb
The correct way to input bytes32 for a function using tronweb is:
If you fail to reinvest an account, you pay the price of your fee limit no matter what. For example, suppose your fee limit is 2,000,000, you will lose 2 TRX if it fails for any reason.