01 / Product and positioning
The Market Rush experience
Market Rush is a browser-based arcade game that turns familiar market themes into short competitive sessions.
Players collect assets inspired by BTC, ETH, NVDA, AAPL and TSLA while avoiding red candles and responding to
changing arena conditions. These are game elements, not claims on the underlying financial assets.
The project is designed around accessible gameplay, repeat participation and community identity. The base game
remains free to play. Holding $MARKETRUSH is not required to enter a standard match, and purchased cosmetics must
not improve a player's competitive advantage.
| Game element | Current implementation |
|---|
| Match format | Online 1v1 duels, public matchmaking, invitation rooms and solo practice. |
| Session rules | Five lanes, three lives and a maximum duration of 60 seconds. The survivor wins; otherwise the highest score wins when time expires. Equal scores draw. |
| Market events | Simulated market crash, good-news rally and jobs-report shock. These are scripted scenarios, not a live economic-news feed. |
| Identity and scoring | Optional wallet sign-in; game servers validate scoring and store profiles, rooms and XP. |
| Free progression | Win: 100 XP. Draw: 50 XP. Completed loss: 25 XP. Solo practice: one XP per 20 points. Forfeits earn no XP. |
XP and tokens serve different purposes
XP is a free progression record. It cannot be purchased, transferred or redeemed, and there is no automatic
XP-to-$MARKETRUSH conversion. Standard duels do not use deposits or player-funded stakes. No losing player's
token balance is transferred to the winner.
Implementation status
A multiplayer prototype and eight automated backend tests have been completed. Real-wallet testing, cross-device
performance, load testing and abuse resistance remain validation work. No independent audit, active-user total,
revenue, exchange agreement or token launch is claimed by this document.
The token policies below describe the intended next stage. The game remains server-operated; wallet connectivity
does not make its gameplay fully decentralized.
02 / $MARKETRUSH
Token design and allocation
$MARKETRUSH is the proposed ecosystem token of Market Rush. Its intended uses include optional cosmetics, community
experiences and non-binding input on future content. These utilities are planned; the current prototype does not
yet process token payments.
| Parameter | Specification or disclosure status |
|---|
| Project and ticker | Market Rush / $MARKETRUSH. This English edition replaces the earlier proposed ticker. |
| Project domain | marketrush.fun. Domain deployment and published contract records still require verification. |
| Target network | Robinhood Chain; intended token interface: ERC-20. Final contract and permissions must be published before launch. |
| Initial supply | S = 1,000,000,000 MARKETRUSH tokens. This is the confirmed initial supply specification; contract deployment still requires verification. |
| Developer allocation | 30,000,000 tokens (3% of S) across disclosed developer-controlled launch wallets in aggregate. Locked for the first seven days. |
| Other distribution | 970,000,000 tokens (97% of S). Public distribution, liquidity and other allocations must be itemized; this is not a claim of circulating supply. |
97% · other distribution
970,000,000 other distribution
30,000,000 developer (3%) → 15M marketing sale + 15M burn
Allocation arithmetic
Developer allocation = 30,000,000 tokens. After the seven-day lock, 15,000,000 tokens are designated for sale to
fund marketing and 15,000,000 for burn. Each portion equals 1.5% of the initial one-billion supply. The 50/50 split
refers to token quantity, not proceeds or market capitalization.
If the 1.5% burn is implemented through a genuine supply-reducing token burn, and no other issuance or burn occurs,
outstanding supply becomes 985,000,000 tokens. A transfer to an inaccessible address may remove spendable tokens
without reducing the contract's reported totalSupply; those methods must not be presented as equivalent [2].
Utility and holder rights
Ownership does not confer equity, dividends, a claim on marketing funds, guaranteed yield or a right to redemption.
A working cosmetic-purchase flow is a target for token activation. Final supply, launch mechanism, admin permissions
and allocation wallets must match the published contract.
03 / Lock, marketing and initial burn
The seven-day developer policy
The developer allocation is intended to be locked for seven consecutive 24-hour periods. For this specification, the
reference start is the publicly announced token-generation event (TGE). Exact UTC start and release timestamps must
be published before launch. The allocation should be funded into a verifiable lock contract no later than TGE.
TGE → day 7
30,000,000 tokens (3%)
Publish the funded lock contract, beneficiary, amount and release timestamp. Verify whether any administrator can withdraw early or change the schedule.
After release · marketing
15,000,000 tokens (1.5%)
Sell the marketing-designated half. Disclose execution records and direct net proceeds into the identified marketing wallet.
After release · burn
15,000,000 tokens (1.5%)
Burn the other half and publish transaction evidence and the resulting supply accounting. Burn execution does not depend on the sale being profitable.
Marketing proceeds and execution
The policy commits 100% of net proceeds from the marketing-designated sale to marketing. Net proceeds means realized
sale proceeds after disclosed, unavoidable transaction and execution fees. Report gross proceeds, fees, net proceeds,
spending and the unspent balance separately.
Unlocking makes tokens transferable; it does not ensure that the full amount can be sold immediately at the displayed
price. The sale should use a pre-disclosed execution window and position limits appropriate to liquidity. Any unsold
balance remains earmarked for marketing and must not be described as spent or burned.
The marketing wallet should publish a spending log covering approved campaigns, vendors, delivered work and outcomes.
Related-party payments must be identified. The 1.5% sale allocation is not an unlimited fundraising mandate, and
proceeds are not developer profit under this policy.
What this lock does not establish
A seven-day lock is short and creates a known post-unlock supply event. It is not a liquidity lock, long-term vesting
schedule or guarantee against selling pressure. Pool ownership, liquidity controls and any other insider holdings
require separate disclosure. No lock or burn should be advertised as completed before its evidence is available.
04 / Every additional USD 100,000 milestone
Milestone buyback and burn
The developer intends to fund gradual $MARKETRUSH buybacks and burns from realized net developer profits as new
market-cap milestones are reached in USD 100,000 increments. Purchased tokens, rather than cash profits themselves,
are burned. The policy is not a price floor or a promised return.
$100K$200K$300K$400K$500K+ every $100K
Proposed operating rules
The following rules make the milestone policy measurable. They are proposed implementation details and must be
ratified, funded and published before activation. No automated buyback contract or monitoring service is claimed to exist.
| Rule | Proposed definition |
|---|
| Milestone sequence | $100,000; $200,000; $300,000; and subsequent $100,000 multiples. Start with the first threshold strictly above the reference market cap at program activation. No retroactive obligations. |
| Valuation basis | Reference market cap = 30-minute time-weighted USD price × verified circulating supply. Publish the price venue, conversion source and supply method. Do not substitute fully diluted valuation without a disclosed policy change. |
| Qualification | A threshold qualifies after the reference value remains at or above it for 30 consecutive minutes. Invalid data or insufficient liquidity suspends qualification. |
| Once-only treatment | Record each threshold once. A fall and recovery does not retrigger it. If several thresholds qualify together, queue each new one; do not duplicate or silently skip entries. |
| Execution and evidence | Execute from the disclosed, funded budget under published limits. Burn the tokens actually acquired and link each purchase and burn to its milestone record. |
Profit-funded execution
The funding source is realized net developer profit. Publish the originating activity and profit after attributable
costs. Unrealized gains, token inventory and funds earmarked for marketing do not qualify. The profit percentage
committed, per-milestone cap, funded balance and execution limits remain to be set. Stage purchases within that
available budget; do not count the same profit twice.
A milestone is marked completed only after the purchase and burn are verified. If funding or execution conditions fail,
publish it as pending or suspended with the reason. Token scarcity does not guarantee higher prices, and a higher quoted
market cap does not create spendable project revenue.
05 / Progression by evidence
Roadmap and market access
Expansion follows a successful first launch stage, not a promised valuation. Only the seven-day developer lock has a
fixed duration in this policy. The remaining stages are conditional objectives, without guaranteed listing dates or
exchange commitments.
| Phase | Planned delivery | Progression condition |
|---|
| 01 / FoundationPrototype available | Refine duels, solo play and wallet sign-in; validate devices, connection recovery and abuse controls. | Game tests, named operator, support process and basic performance reporting. |
| 02 / Launch and week onePlanned | Finalize token and 97% distribution; publish pool details; fund and verify the 3% developer lock. | Contract, launch timestamp, lock evidence and operational support available. |
| 03 / Post-unlock executionAfter day 7 | Sell 1.5% of initial supply for marketing; burn 1.5%; publish records. Fund staged milestone buybacks from disclosed realized developer profits. | Auditable sale, burn and marketing records; no unresolved critical incident. |
| 04 / Market-data applicationsConditional | Apply to CoinGecko and/or CoinMarketCap after first-stage review and eligibility checks. | Complete website, explorer, supply disclosures and usable market data; provider approval required. |
| 05 / Initial exchange accessConditional | Evaluate suitable Tier 3 venues, then pursue stronger Tier 2 distribution where justified. | Network integration, security review, liquidity, operating budget and each venue's approval. |
| 06 / Major exchange ambitionLong-term objective | Seek Tier 1 consideration while expanding seasons, creator content and game reliability. | Sustained legitimate activity, operating maturity and successful exchange diligence. |
A practical definition of first-stage success
Proposed internal gates: complete the lock and initial burn disclosures; reconcile marketing proceeds; close critical
incidents; and demonstrate at least 100 completed human duels with a normal-completion rate of 95% or better. Publish
the measurement window and real results. These targets are not achievements or listing criteria.
CoinGecko and CoinMarketCap are market-data services, not exchanges. Listings and applications are separate events.
"Tier 3", "Tier 2" and "Tier 1" are project planning labels, not standardized ratings or evidence that any venue has
agreed to list the token [3][4].
06 / Operating commitments
Governance and material risks
Disclosure before promotion
Publish the contract address, supply methodology, developer-controlled wallets, funded lock, release timestamp, pool
controls and relevant admin permissions. Use verified contract links as the token identifier; a ticker can be copied.
Do not describe applications, negotiations or submitted documents as confirmed partnerships.
Separate responsibilities and funds
The token lock, marketing wallet and buyback wallet should have distinct purposes and public records. A
multisignature control model and independent review are recommended for managed funds, but neither is claimed as
deployed. Name the operator responsible for signing, reporting and incident response.
Report marketing transactions, initial and subsequent burns, milestone status, remaining buyback funds and policy
changes. A seven-day lock does not by itself constrain other wallets or guarantee execution of a later buyback. Any
further insider allocation, acquisition or related-party payment must be disclosed.
Developer unlockSelling 1.5% of initial supply after one week may produce significant selling pressure, particularly in a shallow pool. Marketing funding is not a promise of returns.
Buyback capacityMilestones may occur without realized developer profit. Buybacks require allocated cash profits and can remain pending or be suspended when that budget is unavailable.
Burn accountingBurn evidence must distinguish reduced totalSupply from merely inaccessible balances. Neither mechanism guarantees demand or price appreciation.
Market integrityShort-term prices, circulating-supply estimates and liquidity can be unreliable. Do not use fabricated activity, wash trades or misleading volume to qualify milestones or listings.
Product and securityServer validation is not complete bot resistance. Real-wallet tests, load tests, contract review and key-management controls are still needed.
External approvalsData platforms and exchanges control their own reviews. Rejection, delay, network incompatibility and continuing compliance requirements may prevent expansion.
No liquidity, exchange access or investment performance is guaranteed.
07 / Version control
Launch disclosures and references
This version confirms a one-billion initial supply and realized developer profits as the source of staged buybacks
and burns. The 3% developer allocation, seven-day lock and 50/50 disposition remain unchanged. Operational
disclosures are still required.
| Item | Required final disclosure |
|---|
| Supply and other allocation | Initial supply: 1,000,000,000 tokens. Disclose destinations for the remaining 970,000,000 tokens, issuance permissions and beneficial ownership. |
| Seven-day lock | TGE and UTC release time; contract, beneficiary and funding transaction; any early-release or admin powers. |
| Marketing sale and burn | Sale window and limits; marketing wallet; fee treatment; burn method; reporting schedule and transaction references. |
| Buyback activation | Realized developer-profit records; committed profit percentage; funded balance; milestone cap; price and supply sources; execution and suspension rules. |
| Market access | Launch-stage results; truthful application status; target venue fit; network support; budget and operator contact. |
References and evidence boundary
- Project source: Market Rush multiplayer prototype, backend test suite and README; commit c07163917b68734a83bada1418032e59d5164066. Implementation and local tests do not establish an independent audit, user adoption or completed token operations.
- OpenZeppelin Contracts, ERC20 API: supply-reducing burn behavior. Final token behavior depends on the contract actually deployed. docs.openzeppelin.com ↗
- CoinMarketCap, Listings Criteria: tracked-listing guidelines and discretionary review. Meeting guidelines does not guarantee acceptance. coinmarketcap.com ↗
- CoinGecko, cryptocurrency listing and curation explanation. Inclusion is a platform decision, not a project-controlled milestone. coingecko.com ↗
Version and publication policy
This English edition uses $MARKETRUSH and the intended project domain marketrush.fun. It does not claim affiliation
with any named network, wallet, company, data service or exchange. Publish material policy changes before execution
and retain prior versions for comparison.
