Satoshi Plays started with a simple idea: build something useful, give it a clear purpose, and create something people have a reason to use.
Satoshi Plays is designed as a product and ecosystem with clear utility and room to evolve over time.
The project is built around a few simple but important principles: fairness, usability, real utility, responsibility, and continuous development. Everything we build should remain consistent with these principles.
$SPLAY is designed to launch on a fair and equal basis , without privileged purchases, hidden allocations, or special conditions for individuals. Anyone who chooses to support the project should participate on equal terms and clearly understand what they are supporting, how the project works, and where it is heading.
Any serious project depends on trust. Trust is not something a project should expect from investors. It is something a project must earn.
The community is more than a wallet count, a user count, or a number on a chart. Every person who gives this project their time, attention, or money deserves to know that I take that support seriously.
That means communicating openly, listening to criticism, and taking useful suggestions seriously. Not every idea will be adopted, but good ideas should always be heard and given proper consideration.
The game is the foundation of the system, while blockchain technology and $SPLAY serve practical roles within it. $SPLAY's utility is directly connected to the features and benefits the platform offers its users.
Satoshi Plays combines gaming, competition, rewards, and blockchain technology into an ecosystem that grows alongside its community. As the games and platform improve, the role of $SPLAY within the ecosystem can expand with them.
Launching the token is not the finish line for Satoshi Plays. It is one step in a longer development process that includes new games and features, stronger security, rewards, and continued expansion of $SPLAY's utility.
Building the project properly takes work, testing, learning, and a willingness to change anything that does not work well enough. Mistakes are part of development. What matters is identifying them, fixing them, and using what we learn to make the next version better.
I do not want to make promises about things that have not been built yet. I would rather have the project judged by what is actually built, how well it works, and how consistently it improves.
Satoshi Plays is an independent project currently developed and maintained by one person, responsible for the technical foundation, system architecture, game development, and smart-contract implementation.
Trusted administrators and moderators manage the project's community and social media presence across Telegram, X, and YouTube. They share the project's vision, have invested in it, and work alongside the founder to help build the ecosystem.
Moderator and administrator roles are not reserved for specific members. Anyone who shows initiative, acts responsibly, respects others, and contributes to the project may be considered for one of these roles. New team members are selected by the existing administrators and moderators together with the founder, based on trust, conduct, and contribution to the community.
Roles and Responsibilities:
Communication: Administrators and moderators communicate with the founder on a daily basis. Questions, proposals, criticism, and suggestions can be raised in the Telegram group and passed directly to the founder, who will consider each suggestion and implement what is useful and feasible.
Transparency: Administrators and moderators stay informed about the project's development so the community can remain updated on progress, important changes, and events.
Clearly Defined Roles: Administrators and moderators manage the community, communication, and social media, while the founder is responsible for development and the technical side of the project. This division of responsibilities makes organization simpler and day-to-day operations more efficient.
Satoshi Plays puts the product, its utility, and the community ahead of short-term promises. The project's rules and key information are structured to be clear, accessible, and verifiable.
The goal is to build a functional gaming ecosystem with clear rules and room for long-term development.
To keep communication organized and protect official channels from scammers, bots, and spam, the project uses clearly defined roles:
52,000,000 $SPLAY from the Community & Airdrops allocation is reserved for people who contribute through their work to the project and community.
The planned distribution is 500,000 $SPLAY per week for 104 weeks, without pauses or hidden conditions.
Rewards are intended for contributions in three main areas:
This allocation is not intended for passive token holders. It is intended for people who actively contribute to the project, with rewards distributed according to their work and contributions to the community.
The Satoshi Plays economy is built around $SPLAY on BNB Smart Chain. $SPLAY is a functional part of the ecosystem and is connected to verified competition, the Token Gate system, the Token Score Bonus, the reward pool, and the future development of the platform.
Users have two gameplay modes available: Guest Mode and Verified Mode. In Guest Mode, users can play without connecting a crypto wallet and without holding $SPLAY. Verified Mode is intended for players who connect a wallet and meet the Token Gate requirements, allowing them to participate in verified competition, the leaderboard system, and weekly rewards.
| Category | Amount | Share |
|---|---|---|
| Game 1 Rewards | 210,080,000 | 21.008% |
| Game 2 Rewards | 193,920,000 | 19.392% |
| Game 3 Rewards | 177,760,000 | 17.776% |
| DEX Liquidity | 150,000,000 | 15.00% |
| CEX Listings | 70,000,000 | 7.00% |
| Community & Airdrops | 52,000,000 | 5.20% |
| Treasury Reserve | 50,240,000 | 5.024% |
| Dev Wallet | 48,000,000 | 4.80% |
| Marketing & Growth | 48,000,000 | 4.80% |
| TOTAL | 1,000,000,000 | 100% |
The purpose and planned release of each category are explained below in the same order in which they appear in the table.
210,080,000 $SPLAY, or 21.008% of the initial supply, is allocated to rewards for the first game.
Game 1 launches together with the project. The planned reward period is 104 weeks, with a maximum weekly reward pool of 2,020,000 $SPLAY:
Tokens from this allocation are intended exclusively for rewards for the first game and are released gradually according to the planned schedule.
193,920,000 $SPLAY, or 19.392% of the initial supply, is allocated to the second game.
Game 2 is planned to launch two months after the project launch. Because of its later start, it has 96 planned reward weeks, with the same maximum weekly reward pool as Game 1:
177,760,000 $SPLAY, or 17.776% of the initial supply, is allocated to the third game.
Game 3 is planned to launch four months after the project launch. Because of its later start, it has 88 planned reward weeks, with the same maximum weekly reward pool:
All three games have the same maximum weekly reward pool of 2,020,000 $SPLAY.
150,000,000 $SPLAY, or 15% of the initial supply, is allocated to DEX liquidity.
These tokens are intended to provide initial liquidity for decentralized trading of $SPLAY, allowing users to buy and sell the token through a decentralized exchange.
The initial liquidity is planned to be locked for two years through PinkSale.
70,000,000 $SPLAY, or 7% of the initial supply, is allocated for potential future listings on centralized exchanges.
This allocation does not represent a promise that $SPLAY will be listed on a centralized exchange. Its purpose is to reserve the funds that may be required for a listing in advance if a suitable opportunity becomes available in the future.
The CEX allocation is therefore not intended to be time-locked. If a specific exchange opportunity appears, tokens may be required on short notice for the listing, additional liquidity, or other requirements set by the exchange. For that reason, these funds must remain available for the purpose for which they were allocated.
If a suitable opportunity does not arise, the tokens remain reserved for CEX-related needs.
52,000,000 $SPLAY, or 5.20% of the initial supply, is allocated to Community & Airdrops.
The planned distribution is 500,000 $SPLAY per week for 104 weeks.
This allocation is intended for people who actively contribute to the project through promotion, moderation, community support, testing, reporting problems, and other useful activities.
A more detailed explanation of how this allocation is used and how community contributions are rewarded is provided in Section 3.
The Treasury Reserve contains 50,240,000 $SPLAY, or 5.024% of the initial supply.
The Treasury serves as a reserve for project needs and as a supplement to the other predefined allocations when there is a justified need. Its role is to give the project additional flexibility if the funds planned for any of the purposes shown in the table are not sufficient during development.
For this reason, the Treasury Reserve is not intended to be time-locked. Its core purpose requires the funds to remain available when the project needs them. Locking the entire Treasury could create a situation in which the project holds reserve tokens but cannot use them when an existing allocation needs to be supplemented or another justified project need must be covered.
Treasury Reserve funds may, when necessary, be used to supplement allocations intended for development, infrastructure, liquidity, marketing, listings, rewards, or other categories defined in the token allocation.
The Treasury Reserve does not have an automatic weekly distribution schedule. Tokens remain in reserve until there is a specific need for their use.
If the project needs to purchase $SPLAY directly from the market in the future, those purchases may be made through the Treasury wallet.
48,000,000 $SPLAY, or 4.80% of the initial supply, is allocated to the Dev Wallet.
This allocation represents compensation to the founder for the time and work invested in creating, developing, and maintaining the Satoshi Plays project. It covers work on the platform, games, technical infrastructure, and other parts of the system required for its operation.
The Dev Wallet is planned to be covered by two-year PinkSale vesting, so the full amount will not be available immediately after the project launches. The tokens will be released gradually over a period of two years, according to a predefined schedule.
This ensures that compensation for the work invested is clearly defined from the beginning, while tokens from this allocation are released gradually over time.
48,000,000 $SPLAY, or 4.80% of the initial supply, is allocated to marketing and project growth.
This allocation is planned to remain untouched during the first two months after the project launch. From the third month, up to 500,000 $SPLAY per week is planned to be released until the allocation is exhausted.
These funds are intended for promotion, marketing, and other activities that can support the growth of Satoshi Plays, attract new users, and expand the ecosystem.
This section explains how the fee for buying and selling $SPLAY works, how it is distributed, and how the burn mechanism affects the total supply.
A total fee of 1% is planned for buying and selling $SPLAY through a decentralized exchange.
This 0.5% fee is intended to support the technical operation and continued development of Satoshi Plays.
These funds may be used for servers, databases, Web3 infrastructure, security, anti-cheat development, game development, maintenance, and technical support.
This 0.5% fee is used to permanently remove $SPLAY tokens from the total supply. Tokens removed through the burn mechanism cannot return to circulation.
The burn mechanism does not guarantee an increase in the price of $SPLAY. Its purpose is to gradually reduce the total supply through buy and sell activity to which the fee applies.
Direct transfers of $SPLAY from one user wallet to another are planned to carry a 0% fee.
The 1% fee applies to the defined buying and selling of the token, not to ordinary transfers between wallets.
The initial supply of 1,000,000,000 $SPLAY tokens is created only once, when the smart contract is first deployed on the blockchain.
The smart contract does not contain a function for creating additional tokens (mint), so the initial amount cannot be increased later.
As tokens are removed through the burn mechanism, the Total Supply shown on BscScan will decrease from the initial 1,000,000,000 $SPLAY. This allows users to verify the current total amount of $SPLAY directly on the blockchain without relying on information published by the project.
The $SPLAY smart contract is a separate part of the Satoshi Plays system and is not directly connected to the web platform, servers, or the game itself. This structure is intentional: the blockchain component remains separate from the parts of the platform that will continue to change and evolve over time.
After the smart contract is deployed on the blockchain and I have verified that all of its functions work as intended, I will renounce ownership through the renounceOwnership function. This will remove the ability to manage the contract through owner-only functions, so neither I as the founder nor anyone else will be able to use those functions for later changes or manipulation of the contract.
The web platform, servers, and games will continue to be developed, changed, and improved independently of the smart contract. This allows the product to keep evolving without requiring ownership control over the token contract itself.
If ownership of the contract remained active to allow later changes, token-review services such as CertiK, DEXTools, TokenSniffer, and others could identify those capabilities as a potential risk. Renouncing ownership removes the ability to use owner-only functions once that process has been completed.
Risk isolation: if a technical problem, outage, or attack affects the web platform or servers, that event by itself does not provide access to $SPLAY tokens or the ability to control the smart contract. The blockchain part of the system operates independently from the web platform.
Satoshi Plays does not require users to lock their $SPLAY tokens in a traditional staking contract in order to use features connected to the token and the game.
Traditional staking can be attractive as a way to earn passive returns, but locking tokens means that the user may not have full freedom to use them for a certain period. Technical limitations or other unforeseen issues can also make access to funds more difficult.
There is a long-standing principle in crypto: “Not your keys, not your coins.”
Satoshi Plays takes a different approach — $SPLAY remains in the user's own wallet and under their control.
Satoshi Plays provides benefits connected to holding $SPLAY without requiring users to send or lock their tokens in a separate staking contract.
When needed, the platform checks the amount of $SPLAY held in the connected wallet. This allows token ownership to have a practical role in verified competition while the user continues to keep the tokens in their own wallet.
The user keeps control of their tokens, while the server only verifies the information required to apply the platform's rules.
The game and servers use their own off-chain/backend infrastructure, while the $SPLAY smart contract operates independently on the blockchain.
A session interruption, loading issue, server outage, or problem with the game system has no direct effect on the smart contract or on the $SPLAY tokens held in the user's wallet.
This separation ensures that problems affecting the web platform or servers do not provide direct access to users' on-chain assets.
Guest Mode is not part of the competitive and reward system. A guest's result is not recorded in Weekly Best Score or Weekly Total Score, even if the guest achieves the best result of the day or week.
Guests also do not have access to all information on the Dashboard, such as the number of currently active players, the number of games played daily and weekly, statistics of other players, official rank, and results in the Weekly Best Score and Weekly Total Score tables.
Guests therefore do not take part in reward distribution. This distinction exists so that the competitive system and rewards are intended for verified users who meet the requirements for participation.
Simply put:
A guest can visit, play, and experience Satoshi Plays.
A verified user can play, track statistics, compete on the leaderboard, and participate in the reward system.
Verified Player Mode is the official competitive mode of the Satoshi Plays platform.
In this mode, valid results are recorded for official competition, shown on the weekly leaderboard tables and in player statistics, and used to determine eligibility for weekly rewards.
For verified gameplay, the user first connects their wallet through the Reown AppKit / WalletConnect system.
After connecting, Satoshi Plays receives the public wallet address and begins the authentication process.
The system then generates a
one-time nonce
, which is linked
to the specific wallet and has a limited validity period. The nonce is included
in the authentication message that the user confirms through their wallet
using the
personal_sign
function.
This proves that the user controls the wallet they are connecting to the platform.
This signature is
not a blockchain
transaction
. The user does not send tokens, perform a transfer, and
the
personal_sign
signature itself
does not require a gas fee or any blockchain transaction
.
The signature is used exclusively for user authentication.
After successful authentication, the nonce can no longer be reused, and the server creates an authentication session. As a result, the user does not need to sign a new message before every individual game.
After the wallet has been connected and authenticated, Satoshi Plays checks whether the user meets the basic requirement for verified gameplay .
The system checks the actual amount of $SPLAY tokens currently held in the user's wallet and calculates its value in US dollars.
A minimum threshold is required to activate verified game mode:
$10 worth of $SPLAY tokens in the wallet.
Before starting a verified game, the server checks the user's wallet balance in real time and retrieves the data required to determine the current USD value of their $SPLAY holdings.
If the user holds at least $10 worth of $SPLAY tokens , they meet the requirement for verified gameplay. If the value of their $SPLAY holdings is below $10 , the user cannot start a verified game.
In that case, the user can continue using the platform through Guest Mode .
The flow is straightforward:
Wallet connection → authentication → $SPLAY holding check → USD value check → verified game mode approved or rejected.
This approach keeps the game accessible to anyone who wants to try it, while the official competitive and reward system is focused on users who actively participate in the $SPLAY economy.
This model represents a Token Gate — a minimum level of token participation required to access verified gameplay.
The first time a wallet successfully meets the $10 Token Gate during a competition week, the system records the minimum amount of $SPLAY required for that wallet's weekly reward qualification.
This requirement is stored as a $SPLAY token amount based on the Token Gate calculation at the time of the wallet's first successful qualification. It is not recalculated as a new USD requirement at the end of the week. During the final reward eligibility check, the wallet must still hold at least that recorded amount of $SPLAY.
The Token Gate is only the first level of participation.
After the user meets the requirement for verified gameplay, Satoshi Plays additionally checks how many $SPLAY tokens the user holds relative to the total token supply .
The system checks:
Based on the ratio:
Amount of $SPLAY tokens in the wallet ÷ Total Supply
the system calculates the percentage of tokens held by the user relative to the total supply.
This percentage is then converted into a Token Score Bonus , which is applied to the score of a valid game.
This means the system does not only check whether the user meets the minimum $10 requirement, but also takes into account their relative share of the total token supply .
If a user holds 1% of the total supply , their valid score receives a 1% bonus .
For example:
If a user holds 2% of the total supply:
Put simply:
The larger the user's share of the total supply, the greater their potential score bonus.
This bonus is applied to the user's valid games.
This mechanism matters most on the Weekly leaderboard , because the user's weekly result is built from their valid games.
Because the weekly total includes all valid games, the Token Score Bonus can add up across a player's full week of activity.
The user therefore has two ways to improve their results:
Satoshi Plays therefore connects gaming activity with economic participation in the ecosystem.
The system does not grant an arbitrary advantage based on a user's identity.
Instead, the system follows a clear principle:
A larger relative share of $SPLAY in the total supply → a greater potential Token Score Bonus.
Users do not need to report their holdings manually or provide separate proof.
The system directly checks the wallet balance and token data.
For the Token Gate , the USD value of the user's $SPLAY holdings is checked, while the Token Score Bonus is calculated based on the ratio between the user's balance and the total supply.
This means the decision is based on the current on-chain wallet balance , rather than information manually entered by the user.
In the current implementation, token verification and bonus calculation are performed when the verified game is started, and the calculated bonus is associated with that specific game.
Satoshi Runner is the first game in the Satoshi Plays ecosystem. It is a fast browser-based endless runner where the player tries to avoid crypto-themed obstacles for as long as possible and achieve the best possible verified score.
The gameplay is simple: the avatar runs automatically, while the player focuses on timing jumps, recognizing obstacles, and staying in the game for as long as possible. Behind this simple gameplay is a server-authoritative system that controls the official game state and determines the result used in the competition.
Jumping is the player's main action. The player can use supported keyboard or touchscreen controls, while the server determines whether a jump is valid based on the current official player state.
This keeps the controls fast and simple, while preventing the browser from independently assigning an arbitrary position to the avatar.
Satoshi Runner becomes more difficult as the game continues. The server controls the game speed and obstacle spawning. The game begins at a lower speed, which gradually increases until it reaches a defined maximum.
In the current implementation, speed is calculated according to the server-side model 7 + elapsed time × 0.15, with a maximum value of 50.
This creates a gradual increase in difficulty rather than a sudden jump in speed.
One official game can last a maximum of approximately 180 seconds (3 minutes).
This limit is controlled by the server and is part of both the game design and the system's protection against abuse.
The server uses core obstacle types such as FUD, Meteor / REKT, Liquidation, Rug Pull, and Double Rug.
On the client side, these core obstacle types can appear under a wider range of names, graphics, effects, and crypto themes without changing the underlying server-side movement and collision-detection logic.
The expanded visual obstacle set includes:
The key point is simple: the visual part of the game can use different names, graphics, effects, and themes, while the server determines the actual obstacle type, its position, movement, and collision state.
Satoshi Plays keeps the visual layer separate from the authoritative game engine. This allows the project to improve presentation, animation, atmosphere, performance, and user experience without transferring control of the official game result to the browser.
Satoshi Runner uses Phaser for browser rendering. The client receives server state and translates that state into the visible player, obstacles, animations, background layers, score information, game-over presentation, and interface elements.
The game presentation includes layered backgrounds and atmospheric elements designed to make the world feel active without changing the competitive rules. Visual elements can include parallax city layers, sky elements, clouds, environmental motion, decorative objects, and other cinematic effects.
The interface supports fullscreen presentation so that the game can use the available display area while preserving the intended game proportions. Fullscreen presentation affects the visual experience only and does not alter the authoritative server coordinates or scoring rules.
The game includes an original melodic game soundtrack with an on-screen control that allows the player to enable or disable sound. Audio is a presentation feature and remains independent of server-side game validation.
The client can display live platform information such as online-player and active-game status. These interface elements provide additional context to the user while remaining separate from the authoritative scoring system.
Because the game runs in a web browser, rendering efficiency is an important part of the user experience. The client can adapt visual workload according to device capability, reduce unnecessary redraw frequency, limit expensive visual effects, and use a controlled rendering resolution to reduce unnecessary GPU and memory usage.
These optimizations are designed to improve smoothness and accessibility without weakening server-side game authority.
The Satoshi Plays dashboard brings together live platform activity, player statistics, $SPLAY information, and weekly competition data in one place. It allows players to follow what is happening on the platform, review their own activity, check their current $SPLAY status, and see their position in the weekly competition.
Dashboard information is presented as an interface and monitoring layer. Official game results, leaderboard positions, eligibility, and rewards continue to be determined by the server and the platform rules described in the relevant sections of this whitepaper.
The Live Activity panel provides a current view of platform activity.
These values give users a quick view of current platform activity without affecting official scoring or competition results.
The Game Statistics panel combines the player's own activity with broader game activity.
The $SPLAY Power panel shows information connected to the user's wallet and the role of $SPLAY in verified gameplay.
These values are shown for transparency and convenience while the underlying wallet and token checks follow the verification rules described elsewhere in this whitepaper.
The Weekly Arena panel gives the player a direct view of their current position in both weekly competition categories.
Weekly Best and Weekly Total remain separate competition categories. A player can therefore hold different positions in the two rankings at the same time.
Satoshi Plays uses a server-authoritative architecture. Key gameplay decisions are made by the server rather than the player's browser.
The client (
game.js
) primarily displays the game, animations,
player, obstacles, and results received from the server. The server
(
server.js
) acts as the central authority that determines
what actually happened during the game.
The basic communication flow is:
User → game.js → Socket.IO → server.js → verification → result → PostgreSQL → leaderboard
This means the client cannot simply tell the server:
"My score is 50,000."
The server maintains the game state and calculates the result using its own authoritative game logic.
The server controls the key elements of gameplay:
Put simply:
The client displays the game. The server determines what actually happened in the game.
That distinction matters because these results are used in an official competitive system.
In a conventional browser game, a large part of the logic may run on the user's computer.
The browser is controlled by the user, so it cannot be trusted as the sole source of truth.
If the client were the only authority, it could theoretically be possible to attempt to modify:
For this reason, Satoshi Plays does not treat data sent by the browser as the final source of truth.
The server maintains the state of the verified game itself.
Even if a user attempts to manipulate the client-side JavaScript, that alone should not allow them to impose an arbitrary result on the server.
Socket.IO is used for communication between the game and the server.
When the user starts the game, the client establishes a socket connection with the server.
During gameplay, the server sends the game state to the client in real time.
This state includes data such as:
game.js
then uses this data to display the corresponding game state.
The server does more than send a final score at the end of a run. It communicates with the client throughout gameplay.
One of the most important parts of the system is the server-side game loop.
In the current implementation, the server uses a tick of approximately:
30 ms
which corresponds to approximately:
33 ticks per second.
On each tick, the server updates the game state.
Among other things, the server processes:
physics → player → obstacles → score → collision → new game state
As a result, official gameplay is not determined solely by the player's local computer.
The server has its own parameters for the core game physics.
The current implementation uses values such as:
1.7
-18
350
120
When the user sends a jump request, the server checks whether that action is allowed in the current game state.
The server then applies the physics rules itself.
This means the client cannot arbitrarily determine:
"I just jumped 300 pixels."
The server determines how the player moves based on its game-state logic.
The server also controls the progressive increase in difficulty.
The speed increases as the game progresses until it reaches the defined maximum.
The current logic uses progressive speed increases with an approximate maximum value of:
50
The verified game is therefore not merely a local animation that the client can arbitrarily accelerate or slow down.
The server determines the pace of the verified game.
Obstacles are also generated on the server.
The current logic uses multiple obstacle types, including:
The server determines when and which obstacles are generated, as well as how they move within the game state.
Examples of the current probabilities:
The game's behavior therefore does not rely exclusively on JavaScript running on the user's device.
Score is one of the most important pieces of data because it directly affects the competition.
For this reason, the server maintains the score itself.
In the current implementation, the internal score value increases during server ticks, while the public score displayed to the player is generated from the server-side game state.
The client can display the score, but the final result is determined by the server.
This is an important security distinction:
game.js displays the score.
server.js determines the score.
The server also monitors the state of the player and obstacles.
When the server determines that a collision has occurred, it can end the game.
The server then determines:
The client then receives the information that the game has ended and displays the Game Over screen.
The server does not allow a verified game to continue indefinitely.
The current maximum duration is:
180,000 ms = 3 minutes.
Once the maximum duration is reached, the server can end the game and process its result.
This is important for system control because it prevents situations in which a single session could occupy server resources indefinitely or produce unnaturally large results.
The server-authoritative architecture provides the foundation of the anti-cheat system, but protection does not end there.
The server additionally monitors socket connection and request behavior.
The system can monitor factors such as:
The system therefore checks not only what the user sends , but also how the user behaves during the session .
The goal is to prevent conventional cheating while also making automation through bots, macros, and scripts more difficult.
For verified competition, the platform can also use server-recorded gameplay telemetry to analyse repeated behavior across sampled games. This analysis can examine factors such as jump timing, jump distance relative to obstacles, repeated reaction patterns, and repeated gameplay signatures.
A single unusual signal is not treated as automatic proof of bot activity. The system is designed to evaluate multiple independent signals and the amount of available gameplay data before a weekly anti-bot result is finalized.
Before weekly reward snapshots are created, the completed competition period must have a finalized anti-bot result. Wallets excluded by that finalized check are not eligible for the weekly reward snapshot, while wallets that pass or do not have enough sampled data continue to the remaining reward eligibility checks.
The weekly anti-bot finalization is a separate step from the reward payout process. It records the finalized anti-bot decision for the completed competition period, but does not create the reward snapshot and does not send $SPLAY. The reward system uses that finalized result afterward when determining weekly eligibility.
To prevent abuse, including attempts to launch a large number of sessions using a single wallet address from one or multiple browsers, as well as excessive server flooding and spamming, the system applies rules that limit concurrent play and excessive game-launch attempts.
One Active Session per Wallet Address
The system allows only one active session per wallet address. Once a session is already active, any subsequent attempt to start a new session using the same wallet address is automatically rejected, regardless of whether the request comes from another tab, a separate browser window, or a different browser. The server actively tracks sessions for each wallet and allows a new session to be started only after the previous active session no longer exists.
Game Launch Limits
To protect the competitive system and server infrastructure, limits are applied to the frequency at which games can be launched:
These rules help maintain fair competition, reduce opportunities for abuse, and protect the platform from excessive repeated requests.
Before the user receives access to verified gameplay, the server verifies their authentication.
After
personal_sign
verification, the server creates a session.
The session is linked to the wallet address, and the server stores a hash of the session token rather than the token itself as plain text.
Existing sessions for the same wallet can be revoked, and each session has a limited lifetime.
This allows the server to establish the relationship:
Wallet → user → game session → valid game → result.
This is important for leaderboard integrity.
The server uses PostgreSQL to store key system data.
The database is used for data such as:
Game results are not stored only in the browser.
The server maintains a persistent record of what happened.
When a game ends, the server processes the result.
The logic is approximately:
Gameplay
↓
Server verifies game state
↓
Collision / Game Over
↓
Final server score
↓
Token Score Bonus
↓
Game validation
↓
Result stored in PostgreSQL
↓
Weekly Best Score / Weekly Total Score
The leaderboard therefore does not depend on data manually entered by the user in the browser.
The leaderboard is built from data that has been processed and verified by the server.
The server also provides the foundation for the competitive system.
For Weekly Best Score , the system records the best valid individual result achieved by each user during the period from Monday at 00:00:00 through Sunday at 23:59:59 (UTC+2).
Weekly Total Score sums all valid results achieved during the current calendar week (from Monday at 00:00:00 through Sunday at 23:59:59 UTC+2), rewarding effort, persistence, and the overall number of games played.
To ensure consistent conditions for everyone, the system uses server-side UTC+2 time and records results throughout each calendar week within the exact period from Monday at 00:00:00 through Sunday at 23:59:59, eliminating differences caused by the browser's local time.
This is important because all players must compete under the same rules.
When all components are combined, Satoshi Plays operates as one connected system:
Wallet
→ authentication
→ Token Gate
→ Token Score Bonus
→ verified game launch
→ Socket.IO
→ Server-authoritative game engine
→ physics
→ obstacles
→ collision
→ score
→ anti-cheat controls
→ validation
→ PostgreSQL
→ Weekly Best Score / Weekly Total Score
→ user result.
The core principle of the architecture is simple:
The browser displays the game, but the server determines what actually happened.
This provides the foundation for a competitive Satoshi Plays gaming system in which results are not based solely on trust in the user's device, but on server-controlled game state, authentication, validation, and persistent result storage.
One competition period lasts 7 days and follows the official UTC+2 time basis used by the reward system.
The competition closes at the end of Sunday. The completed week is then separated from the new competition period so that the final results can be frozen and processed.
Only verified games are eligible for the official weekly rankings and reward distribution. Guest results are excluded.
A position on the Weekly Best Score or Weekly Total Score leaderboard does not by itself guarantee a reward. Final reward eligibility is confirmed after the competition closes through the platform's weekly eligibility and security checks.
Weekly Best Score rewards the highest valid score achieved by each verified wallet during the completed competition period.
A wallet can play multiple valid games, but only its highest valid score is used for Weekly Best Score ranking.
For example, if one wallet records:
500 → 720 → 640 → 810
its Weekly Best Score is 810 .
If the same person controls more than one independently verified wallet, each wallet is treated as a separate participant by the leaderboard system, provided each wallet satisfies the platform's verification and game rules.
At the end of the week, the system groups valid results by wallet, takes the maximum score for each wallet, sorts the results from highest to lowest, and selects up to the first 100 positions.
Weekly Total Score rewards consistent activity across the entire competition period. Rather than using only the best game, the system adds together all valid weekly scores achieved by the same verified wallet .
For example:
500 + 700 + 450 + 800 = 2,450 Weekly Total Score points.
The system groups valid results by wallet, calculates the total score for each wallet, sorts the totals from highest to lowest, and selects up to the first 100 positions.
Weekly Best Score and Weekly Total Score use the same fixed Top 100 payout schedule:
If all 100 positions are occupied:
Empty positions are not redistributed. If fewer than 100 wallets qualify, rewards are paid only for the positions that are actually occupied.
After the competition period closes and before the final reward snapshot is created, the system performs a final eligibility check for the wallets being considered for rewards.
A wallet must have a valid weekly Token Gate qualification and must still hold at least the minimum amount of $SPLAY that was recorded when it first qualified during that week. If the wallet no longer meets that requirement, it is skipped for reward eligibility and the next eligible wallet can move into the rewarded positions.
To keep this check consistent, the $SPLAY balances used for the final weekly eligibility process are read from a shared BNB Smart Chain block and stored as a weekly balance snapshot. The same stored balances can then be reused by both Weekly Best Score and Weekly Total Score.
The reward list therefore reflects both competitive ranking and the eligibility rules required for weekly reward distribution.
After the weekly competition ends, the reward system creates a frozen snapshot of the qualifying Top 100 wallets for each category.
The snapshot stores the information required for reward distribution, including:
Once the snapshot for a specific period and category already exists, the payout process does not create another independent snapshot of the same finalized ranking.
This separates the completed competition from the payment process and prevents later leaderboard changes from silently altering the finalized reward list.
When the weekly competition closes, a 24-hour payout window begins. The reward period records the start and end of this payment phase.
During this period, the finalized reward snapshot can be reviewed and the on-chain distribution can be processed. The Reward Center can display the payment state for each qualifying wallet.
Before a real bulk payout begins, the payout system performs technical checks designed to prevent an incorrectly configured distribution.
If these conditions are not satisfied, the bulk payout does not continue with new transfers.
Before a real distribution, the payout process can be executed in Dry Run mode.
Dry Run shows the payout information that would be processed — including rank, wallet, score, and reward amount — while intentionally preventing real token transfers.
This provides an additional operational verification step before the real on-chain distribution begins.
During the real payout process, the payout wallet sends the assigned $SPLAY reward directly to each qualifying wallet through an ERC-20 transfer on BNB Smart Chain.
Rewards are processed as individual blockchain transactions. For example:
The payout wallet's private key is loaded from the protected server environment rather than being hard-coded into the payout source code.
Each reward keeps its payment status and blockchain transaction information. If a bulk payout is interrupted, the process can resume from the recorded state instead of blindly restarting from the first wallet.
Before creating a replacement payment, the system checks the existing transaction when transaction data is already recorded. A confirmed transaction is treated as paid, a transaction that is still pending is retained, and an available signed transaction can be rebroadcast instead of creating a different payment. A new controlled attempt is made only when the previous transaction is definitively known to have failed.
The payout system records transaction information for each individual reward so that an interrupted payout can be resumed without blindly restarting payments from the first wallet.
If a payout entry already contains a transaction hash, the system checks the existing blockchain transaction before deciding what to do next.
This mechanism reduces the risk of duplicate reward transfers if the payout process stops or loses connectivity partway through distribution.
Reward records can move through payment states such as PENDING, PROCESSING, PAID, and FAILED .
When a transfer is successfully confirmed, the payout record is marked as PAID , the payment time is stored, and the transaction hash provides an on-chain reference for the reward transfer.
This creates a clear connection between the finalized leaderboard position, the reward assigned to the wallet, and the blockchain transaction used to distribute that reward.
If a player believes there is an error regarding a result, leaderboard position, game validity, reward calculation, or payment status, a verification request can be submitted through:
The player should provide the wallet address and any relevant information that can help identify the game or reward entry.
After one weekly competition closes, the next competition period can begin while the completed period remains represented by its frozen reward snapshot and payment records.
The recurring reward flow is:
7-day competition → final ranking → frozen Top 100 snapshots → fixed reward calculation → payout verification → on-chain distribution → transaction confirmation → new weekly cycle
This structure keeps competitive scoring, reward calculation, and blockchain payment execution separated while maintaining a clear record of how each weekly reward was determined and distributed.
Satoshi Plays is designed as a multi-game ecosystem rather than a platform built around a single game. Satoshi Runner is the first playable product and the first implementation of the wider platform.
The tokenomics plan includes separate reward allocations for Game 2 and Game 3. These games are planned to be introduced after Game 1. Their later planned start dates are the reason they have fewer reward weeks and smaller total reward allocations.
Future games are intended to use the same broader Satoshi Plays foundation, including wallet-based user sessions, server-side result validation, persistent database records, competitive leaderboards, and the $SPLAY ecosystem.
Future games do not need to copy Satoshi Runner. Each game can use its own mechanics, visual identity, difficulty model, and presentation while still belonging to the same wider platform.
The project is being developed in stages. New games, interface improvements, infrastructure upgrades, community features, and other platform functions can be introduced as the ecosystem develops and real user feedback becomes available.
The long-term goal is to give $SPLAY a practical role across multiple browser games rather than making the ecosystem dependent on a single title. The gaming platform can continue to evolve while the blockchain token contract remains technically separate from the website and game servers.