Introduction to the Psychological Game Theory Game
This is a game that uses huge prizes to incentivize players’ willingness to participate. Any player, when placing bets, participating in crowdfunding (time competition), or engaging in other ordinary player behaviors, as well as manipulation behavior attempting to manipulate the winning numbers, will directly affect the amount changes of the corresponding modules. All values that affect the winning numbers are publicly disclosed in real time on the front end. When other players see the value changes, they will change their own behavior according to their own interests. The behaviors of all players influence one another. Players calculate their own gains and losses before taking each step. The game encourages actors to profit; players willing to take the next action always have an advantage over players who do not react, and have a greater probability of profiting. This kind of game, in which the operation of the program is driven by players’ dynamic strategic behavior, is called a “psychological game theory game.”
The psychological game theory game is fundamentally different from traditional lotteries.
It does not pursue what traditional lotteries pursue:
- Every number has the same probability, the winning number cannot be manipulated, the result is unrelated to investment, and each bet has a guaranteed minimum prize.
Instead, it pursues the following for strategic behavior:
- Consistent rules: Everyone faces the same set of game rules, and players’ wins and losses stem from differences in their own decisions.
- Information symmetry: Information that has been made public and affects decisions is visible to everyone.
- Freedom of action: Players can choose, according to their own strategy, whether to follow up or stop influencing the winning result.
- Procedural fairness: There is no hidden party in the game that can secretly change the results of players’ strategic interactions.
In this game, the winning number is not an external random source, but the result of the mutual aggregation, mutual influence, and mutual strategic interaction of all participants’ behavior. A player’s behavior interferes with other players and is also interfered with by other players. The winning number is the result of all users’ strategic behavior. Participants influence and counter each other; the game itself is the gameplay.
In the game, players self-identify different roles based on their behavior—player, manipulator, colluder.
A player’s role changes or strengthens with the player’s behavior. At the start of a game, all bettors are ordinary players; when a player attempts to obtain super profits by manipulating the winning number, the player’s role then changes into a manipulator; when multiple manipulators attempt to manipulate the winning number through division of labor, these players become colluders.
Manipulators need to face interference from other people’s manipulation behavior, and the setting that prize pool money is split equally according to the number of winning bets means colluders need to face a game of profit distribution among themselves. Of course, all manipulation behavior is not free; it still requires spending real Lucky. The game does not prohibit manipulation; instead, it makes manipulation itself a strategic behavior with opponents, risks, countermeasures, and costs.
To offset as much as possible the advantage of potential script/bot players, a 3-second interval is set between two operations by a player in the game.
Each round lasts about 10 minutes, of which the first 5 minutes are betting time and the first 8 minutes are crowdfunding time. After crowdfunding closes, winning number generation begins immediately and the prize distribution procedure is prepared. After prize distribution is completed, the next round starts immediately. The program runs in the following order:
Previous round’s prize distribution completed → betting and crowdfunding modules run in parallel → betting module closes → crowdfunding module closes 3 minutes later → determine the 1st–3rd winning digits → determine the 4th and 5th winning digits → determine the 6th and 7th winning digits → transfer the crowdfunding pool to the treasury → execute excess transfer from the total prize pool → begin prize distribution.
Note: The treasury and token exchange handling fees do not affect the game’s draw data and can operate as independent modules around the clock.
Betting
Users can choose a 7-digit array to bet on. Any of the 7 digits can be any digit from 0 to 9. For example, users can bet on 1234567, 7654321, or 0000000, 8888888.
The bet cost is 1 Lucky per bet. All bet costs enter the total prize pool. The front end updates the total prize pool amount. The top 10 number combinations with the most bets are displayed.
To ensure the attractiveness of the prizes, when the total prize pool is depleted, the DAO may use treasury funds to replenish the total prize pool. The platform plans (tentatively) to maintain the total prize pool amount for each round at not less than 1,000,000 Lucky. If the game is below this value for two consecutive rounds, the DAO authorizes the use of treasury funds to replenish it. When replenishing funds, the treasury withdrawal rules are followed. The DAO will not replenish the prize pool while the game is running, so as not to interfere with the game’s operation.
Crowdfunding (Time Competition)
Players use Lucky to participate in crowdfunding. The crowdfunding results directly determine the generation of the 1st–3rd digits of the winning number.
The crowdfunding amount for each digit must be a positive integer multiple of 1; decimal inputs are not supported. The maximum single crowdfunding amount is 100,000 Lucky.
Players independently crowdfund digits 0–9 for the 1st, 2nd, and 3rd positions respectively. Whether or not the digit supported by the user wins, crowdfunding fees are non-refundable.
Each round’s crowdfunding amount becomes treasury income. Within the scope where excess transfer is not triggered, the more funds accumulated in the total prize pool, the greater the potential profit from manipulating the winning number; the more users attempting to manipulate the 1st–3rd winning digits, the greater the platform’s income. Optimistically, the game’s daily income can reach 21,000,000 Lucky (assuming each round is 10 minutes and at least one digit in the 1st–3rd positions’ crowdfunding reaches the threshold).
The front end updates in real time the total crowdfunding amount for each digit and the leading digit in crowdfunding.
The digits for the 1st, 2nd, and 3rd positions are generated independently. The generation rule for each position is the same and follows the following priority:
- During crowdfunding, if a digit’s cumulative amount first reaches the target threshold of 100,000 Lucky, that digit is selected as the winning number for the corresponding position.
Each digit has a target threshold of 100,000 Lucky, but continuing support for a digit beyond this amount is allowed. The excess amount is included in the total crowdfunding amount but no longer affects the results of the 1st–3rd winning digits. When determining which digit wins, only whether and when it reaches this target value is considered. At any time after each round starts, the digit that first reaches the threshold is directly locked as the winning number for the corresponding position and is publicly displayed in real time on the front end.
Note: Setting a target threshold is mainly to allow small-capital users to obtain the right to win through surprise attacks, avoiding the 1st–3rd winning digits being monopolized by large-capital users. At the same time, each time a target threshold locks in a winning digit in advance, the amount required to chase the first prize through multiple betting (full coverage) drops exponentially, thereby stimulating users’ betting enthusiasm. This process is also a group game.
- If multiple digits reach the target amount at the same moment, the judgment is based on on-chain timestamps; the digit with the smallest timestamp is selected as the winning number. If the timestamps are exactly the same, the smaller digit is selected as the winning number.
Note: ICP block confirmations are fast, and messages within a single Canister are executed sequentially. It is almost impossible for two transactions to share the same timestamp. “Reaching the threshold at the same moment” will almost never happen in practice. Therefore, “if timestamps are the same, choose the smaller digit” is an edge rule, not a dominant strategy.
- If, after crowdfunding time closes, no digit has reached the target amount, the digit with the highest crowdfunding amount is selected as the winning number. If the amounts are the same, the larger digit is selected as the winning number.
Note: Crowdfunding itself generates no returns. Crowdfunding fees are non-refundable, and crowdfunding amounts go to the treasury. The only function of crowdfunding is to change the winning number. If a person only crowdfunds and does not bet, even if he adjusts the winning number to a certain digit, he cannot receive any prize, because prizes are only paid to winning bets. Therefore, under rational conditions, crowdfunders are almost always also bettors: they first bet on the target number, then use crowdfunding to make the winning number match their bet.
Winning Number Generation Rules
A 7-digit winning number is jointly generated by four parts of rules:
-
The 1st, 2nd, and 3rd digits (from crowdfunding): see the rules above.
-
The 4th and 5th digits come from the current total prize pool amount; at this time, no excess transfer is performed on the total prize pool:
Take the second-to-last digit (tens place) of the total prize pool amount as the 4th winning digit, and the last digit (ones place) as the 5th winning digit.
If the total prize pool amount is less than two digits, pad with a leading zero (the 4th winning digit is 0; this situation is almost impossible).
- The 6th and 7th digits come from the current total crowdfunding amount:
Take the second-to-last digit (tens place) of the total crowdfunding amount as the 6th winning digit, and the last digit (ones place) as the 7th winning digit.
Example: Suppose the crowdfunding results are 3 for the 1st digit, 5 for the 2nd digit, and 7 for the 3rd digit; the total bet amount is 100,000,012, the total crowdfunding amount is 1,000,000, and the total prize pool amount is 100,000,012. Take the last two digits “12,” i.e., the 4th digit is 1 and the 5th digit is 2; the second-to-last digit of the total crowdfunding amount 1,000,000 is 0, i.e., the 6th digit is 0; the last digit is 0, i.e., the 7th digit is 0. Final number: 3 5 7 1 2 0 0.
Prize Distribution Module
Prize priority: First Prize > Second Prize > Third Prize > Fourth Prize > Fifth Prize > Sixth Prize. Each bet number matches only the highest tier.
Prize calculation: Single-bet prize = that prize tier’s allocation pool ÷ number of winning bets. Round down; the decimal part rolls over to the next round’s total prize pool. For example, if the single-bet prize is 1.2 Lucky, then 0.2 Lucky rolls over per bet, and the actual single-bet prize is 1 Lucky; if the single-bet prize is 0.9 Lucky, then 0.9 Lucky rolls over per bet, and the actual single-bet prize is 0 Lucky.
Note: The prize is rounded down, and the decimal part rolls over to the next round’s total prize pool; this also uses game theory principles:
Users must not only ensure that they obtain absolute profit through the number of bets, but also consider avoiding the situation where other users’ bets cause the single-bet prize to be less than 1. If a user wins but the single-bet prize is 0, it means that prize tier’s allocation pool is diluted by an extremely large number of winning bets. This is part of the game. Users need to judge the number of bets to avoid excessive concentration causing prize dilution.
Total Prize Pool Processing
After the 4th and 5th digits of the winning number are determined, the excess portion of the prize pool is transferred.
When the total prize pool > 99,999,900 Lucky, the excess portion is transferred to the treasury, and the remaining 99,999,900 is used for prize allocation.
After the excess prize pool transfer, the total prize pool used for prize distribution in each round is at most 99,999,900 Lucky (≤99,999,900), and the payout ratio of each prize tier is also based on this number.
The total prize distribution amount in each round does not exceed 40% of the total prize pool amount (≤40%). The remaining 60% remains in the prize pool as prize money for the next round. The allocation pools of prize tiers with no winners roll over to the next round’s total prize pool after the draw is completed. The excess transfer rules remain unchanged.
Prize Tiers and Matching Rules
First Prize: all 7 digits match completely; equally share the amount of total prize pool × 10%.
Second Prize: exactly 6 digit positions match; equally share the amount of total prize pool × 8%.
Third Prize: exactly 5 digit positions match; equally share the amount of total prize pool × 7%.
Fourth Prize: exactly 4 digit positions match; equally share the amount of total prize pool × 6%.
Fifth Prize: exactly 3 digit positions match; equally share the amount of total prize pool × 5%.
Sixth Prize: exactly 2 digit positions match; equally share the amount of total prize pool × 4%.
Token Exchange
- Token Economy Module
The game’s DAO controls a two-way exchange pool between ICP and Lucky. There is no upper limit on the total supply of Lucky. Newly minted Lucky is prohibited from being directly released and can only be used to supplement the liquidity of Lucky in the exchange pool. The DAO will not misappropriate the ICP in the exchange pool.
The initial Lucky tokens in the exchange pool come from transfers by the token contract controlled by the DAO. ICP tokens are deposited when users exchange for Lucky.
Users can exchange Lucky or ICP at the fixed exchange rate of 1 ICP = 1000 Lucky. The amount of tokens a user exchanges cannot exceed the remaining amount of the corresponding token in the exchange pool. The front end displays in real time the remaining Lucky balance and ICP balance in the pool. When a user exchanges for a certain token, the system checks whether the target token balance in the exchange pool is sufficient; if insufficient, it prohibits the operation and gives a prompt.
Note: The total prize pool and treasury will always retain a portion of Lucky. Token exchange uses a fixed exchange rate. Theoretically, when the amount of Lucky circulating in the market is also 0, the ICP in the exchange pool will not be exhausted.
- Lucky Token Exchange Rules
ICP to Lucky:
- No handling fee. Minimum single exchange is 0.1 ICP and must be a positive integer multiple of 0.1 (e.g., 0.2, 0.3, 1.1; exchange requests such as 0.11 are not supported). Maximum single exchange is 10,000 ICP.
Lucky to ICP:
- The input amount must be a positive integer multiple of 1000. Maximum single exchange is 10,000,000 Lucky.
- A 3% handling fee is paid in Lucky; handling fee revenue is injected into the game treasury.
The front end displays real-time updates of the treasury balance. All funds entering the treasury belong entirely to the DAO. When the DAO withdraws or spends treasury funds, the DAO guarantees that the treasury funds used are integer multiples of 100 and does not interfere with the data of ongoing games.
-
Example Exchange Implementation Logic
-
A user uses 1000 Lucky to exchange for ICP; the front end displays an actual receipt of 0.97 ICP.
After confirmation: the exchange pool initiates a transfer of 0.97 ICP to the user’s wallet; at the same time, 970 of the user’s 1000 Lucky is transferred into the exchange pool, and 30 is transferred to the treasury. Update the exchange pool balance.
- A user uses 1 ICP to exchange for Lucky; the front end displays an actual receipt of 1000 Lucky.
After confirmation: the exchange pool initiates a transfer of 1000 Lucky to the user’s wallet; at the same time, the user’s 1 ICP is transferred into the exchange pool. Update the exchange pool balance.