Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/novationscripts/multimillionaire

Multimillionaire Token Game: And earnings of 7% from each referral's million would be approximately ~$50,000+ if the referred player reaches the finish line.
https://github.com/novationscripts/multimillionaire

blockchain-game ethereum ethereum-contract millionaire millionaire-game multimillionaire solidity token token-game

Last synced: 30 days ago
JSON representation

Multimillionaire Token Game: And earnings of 7% from each referral's million would be approximately ~$50,000+ if the referred player reaches the finish line.

Awesome Lists containing this project

README 

        
**The Path of the Multimillionaire**



[Token+Game.sol](https://github.com/NovationScripts/Multimillionaire/blob/main/Token+Game.sol) In this case, the token is integrated into the game, making the token and the game a unified whole.



**In this game, there are 99 different and sequential deposits, 99 separate budgets, and 99 separate queues**.



By using the **reserve budget** and configuring the ratio between **those who have made a deposit and those awaiting payment**, we can balance between the exponential queue growth and the capabilities of our reserve budget. The **ratioMultiplier** and **payoutCycle** protects against the exponential growth of players in the payout queue and prevents cheating with the game’s economy. However, if there is an exponential increase in new players, the compensator may not be needed, or needed only rarely.



In this scenario, the reserve budget is filled to the maximum, and no one else has tokens. However, it can be configured so that a certain number of players can make their first deposit for free, using the reserve budget. The option to make the first deposit at the referrer's expense has also been added if the referrer activates this feature. We added a second referral line. From the first line, the player earns 0.4%, and from the second line, 0.3%, making a total of the same ~50000$+ from one refferal if we assume that on the P2P DEX, 1 ETH = 1 Token. With two referral lines, a player can potentially earn more, but it will take more time. This is because there could be at least twice as many referrals on the second line, especially considering that some may start creating multiple accounts for themselves. In such a case, having two lines could be more beneficial.



In this version, the economy is the most sustainable. If we assume that the equivalent of all the money on planet Earth is a septillion, then the reserve budget would be enough for 109,999,999,999,999,999,999,999 such planets. But tokens can be taken from the reserve budget only after every fifth successful payout if the ratio of players in the queue is greater than 10 waiting for payout to 1 making a deposit.  This is a fairly optimized and safe budget expenditure. Primarily, users will be transferring deposits between each other, but if the queue starts to stall, the reserve budget will kick in. Out of every 10 people who pass through, with the current settings, 9 × 1.09 equals 9.81, leaving 1.9% for referral and contract payouts. Even if a player has to make a donation of $100–$500 and pay $50,000 in gas fees while playing the game, it’s incomparable to how much they can earn, guaranteed, honestly, and with liquidity. Just one referral can cover all the expenses.



This version includes flag verification during registration and the addition of flags after completing the game. Theoretically, it is possible to create contracts with different conditions based on the configuration of flags. For example, to access a shared P2P liquidity pool or other complex contracts, and to set the sequence of access to contracts. The current flags can be pre-programmed variables and constants.



**The gameplay is as follows: During player registration, it is mandatory to specify a referrer; registration without a referrer is not allowed. Additionally, the system checks for flags from other contracts. The player can then make a free first deposit from the reserve budget if available, or from the referrer's account if that option is active, or the player can make the deposit independently. When the deposit budget has sufficient funds, the player will receive a payout and can make the next deposit. The referrer earns a commission from each player's deposit, both from the first and second referral lines, and can withdraw referral earnings without delays. Once the player has made all possible deposits, the game is considered completed, and the player receives the "hasFinished" flag. The simplest example of using flags: a player needs to make a donation in another contract, which will be immediately sent to its destination. After this, the player will receive a flag granting access to the game. In this case, everyone who wants to play will be required to donate to the specified destination in order to gain access to the game. The [donation](https://github.com/NovationScripts/Multimillionaire/blob/main/donationMade.sol) can serve as a barrier, which in turn increases liquidity and creates a small hurdle for overly enthusiastic participants.**



We could say that players confirm blocks with their deposits.



There may be significant token issuance, but an exponential influx of new players can curb inflation. Moreover, these tokens can be stored, used for transactions, and this might be an experimental project, making it uncertain how users will behave. What if we create a DEX with the following structure: 1 Token #1 = 1 ETH, 500 Token #1 = 1 Token #2, and 1 Token #2 = 500 ETH, it would create an interesting closed-loop exchange system. For better stability, the waiting time and limits per account can be adjusted. The Token #2 contract and the DEX are also ready and need testing and debugging.



What if we implement automatic waiting time increase over time, like in cryptocurrency mining?



If the errors are fixed, it might actually work. The contract compiles and deploys, but errors occur during testing. If optimization cannot be improved further, it's time to move on to the debugging stage.



If you have any thoughts, you can leave them in the discussions of this repository. https://github.com/NovationScripts/Multimillionaire/discussions



**We enjoy doing what we love, and we have a talent for it**.