LUPYN Whitepaper

Final public whitepaper · Robinhood Chain • PONS.FAMILY • 14 September 2026 · Race and leaderboard rules revised 19 September 2026

LUPYN brings its character art and Crew identity into a six-horse racing ecosystem. TSLA Racing provides the game, the Crew Scoreboard provides weekly competition, and Crew Lock is introduced in Phase 2 so holders can build a Crew Streak and receive a proportional share of defined ecosystem reward pools. The visual identity, game loop, token utility, scoreboard, Crew Lock, and fee routing are designed as one connected product.

The economic foundation is a maximum issuance of 1 billion LUPYN, segregated player funds, variable rewards limited to assets actually received, and permanent burns funded by defined economic allocations. No new reward token, inflationary Crew Lock emission schedule, guaranteed return, or obligation to support LUPYN’s market price is introduced.

This whitepaper defines the production mechanics. The production ecosystem is LUPYN-native from the start, and paid racing is an early core utility. Testnet, demo, or non-value environments may still be used for quality assurance, but they do not replace the token-native production design. Financial features remain subject to applicable law, security controls, and the contract rules disclosed in this document.

Core system

1 TSLA Racing

Game identity and player experience

TSLA Racing is LUPYN’s primary game. Each race has six horses presented through the project’s existing character and Crew identity. The TSLA Racing name does not itself imply a Tesla partnership, equity backing, a TSLA trading pair, or rights to any company’s intellectual property.

Production TSLA Racing is LUPYN-native from the start. Players choose a horse, compare published race probabilities, follow the race, and may enter paid races using LUPYN under the published race rules. Separate free or non-value modes may be used for onboarding, demos, or testing, but paid racing remains an early core utility rather than a feature deferred to a later roadmap stage. Track themes, Crew rivalries, cosmetic customization, replay sharing, and seasonal achievements provide progression outside financial outcomes.

Initial race outcomes are chance-based. Horse selection and assessment of a changing pool provide decisions, but neither the animation nor winning a small sample demonstrates skill. Tactical controls that affect outcomes require a separately specified and tested engine before introduction. Free or non-value test modes may be used to measure whether the six-horse format remains enjoyable without earnings incentives, but those modes are not the production economic model.

Published race configuration

Every race publishes its unique ID, rules version, six horse IDs, probability weights, entry opening and closing timestamps, randomness timeout, and distribution percentages before accepting funds. The race has no minimum or maximum total pool. These terms become immutable for that race. The baseline rules version may assign weight 1 to each horse and use a uniform six-way draw. A nonuniform configuration uses six positive integer weights summing to 10,000 and a separate rules version.

A paid entry selects one horse and transfers LUPYN into escrow. One wallet may stake up to 10,000 LUPYN on each horse in a race. Repeated entries by the same wallet on the same horse add together toward that horse's 10,000 LUPYN limit; stakes on different horses have separate limits. A wallet may back multiple horses, including all four needed to qualify a race. This is a wallet limit, not proof of a person-level limit.

Betting is open for seven minutes and thirty seconds. The window is fixed in the race contract and cannot be lengthened, shortened or extended for a race once it has opened. A race runs only if at least four different horses have active bets when betting closes; one wallet may back all four. There is no extension: if fewer than four horses are backed at the close, the race is cancelled and each entry is fully refundable to the wallet that placed it. Refunds are claimed by that wallet; they are not pushed in the closing transaction.

Every race follows the same ten-minute schedule from the moment betting opens: seven and a half minutes of betting, then two and a half minutes in which the draw is made and verified, and the horses leave the gate on the ten-minute mark. The race itself runs for a little over a minute, and the next race opens about a minute after it ends. If a draw lands later than expected, the start moves to shortly after it arrives rather than beginning without a result.

Entries are accepted only before the on-chain closing timestamp. They cannot be edited or withdrawn after acceptance except through the refund rules in Section 1. Each entry also carries a small network fee in ETH (Section 1, Network fee), paid in the same transaction and never part of the prize pool; the player's own transaction gas is separate. The interface shows the network fee, the fee deduction, current pool, probability configuration, provisional payout multiple, and potential loss before confirmation.

Race allocation

For each successfully settled paid race, 80% of the original Race Pool is the winning allocation, 10% is allocated to Crew Lock (staking) Rewards through the TSLA Racing Vault, 5% to Development, and 5% to Burn. When the winning horse has no bets, its 80% allocation goes to the Crew Lock reserve instead of players, so that reserve receives the 80% allocation as well as its usual 10%. Because paid race entries are already denominated in LUPYN, the 5% Burn allocation is burned directly; no market buyback is required for that allocation. The percentages are applied to the original settled Race Pool.

Network fee (operations gas)

Running a race costs ETH gas that no player sees: opening the race, closing betting, delivering the verified drand draw, settling, and paying out. From the 19 September 2026 contract onward these costs are paid by the players who enter, not by the prize pool. Every entry sends a small ETH network fee alongside its LUPYN stake, calculated on-chain in the same block:

Network fee = current network base fee × gas units per entry, plus one quarter. The gas part goes directly to the keeper wallet that runs the race loop; the extra quarter goes directly to the deployment wallet that pays for future contract releases. Both transfers happen inside the entry transaction, the race contract keeps no ETH, and any ETH sent above the quoted fee is returned in the same transaction.

The fee follows the network base fee automatically, so it rises and falls with chain congestion. At launch the setting is 260,000 gas units per entry, about 0.00002 ETH per entry at a 0.063 gwei base fee. The owner may adjust the gas units to match measured costs, but never above the 1,000,000 hard limit written into the contract, and the 25% markup is fixed. The network fee is separate from the 80 / 10 / 5 / 5 LUPYN allocation, which is unchanged. It is not refunded if a race is cancelled or voided: stakes are refunded in full, the network fee is not, because the keeper has already paid gas for that race. The fee and its split are recorded on-chain in a BetFeePaid event for every entry.

TSLA Racing settlement rules

Winner determination and verifiable randomness

The winner comes from the public drand randomness beacon (the League of Entropy “evmnet” network, one signed round every 3 seconds), verified on-chain on Robinhood Chain. When betting closes, the contract fixes the drand round that will decide the race: the first round published at least 60 seconds after the effective close. That round does not exist yet while bets are open, so nobody, including the team, can know the result in advance. Betting is also closed by a drand proof a few rounds before the target, so a lagging chain clock cannot keep entries open after the result becomes public. Once the round is published, anyone may submit its signature; the contract checks the BLS signature against drand’s published public key and accepts only that exact round, so a different round or a forged or substituted signature is rejected and cannot change the outcome. The race seed is derived from the signature together with the race ID, contract address and chain ID, and the winner is drawn from the published horse weights. There is no request step, subscription or operator-held seed. Block timestamps or a single operator’s unpublished seed are not used. Limits: the result relies on the drand network’s threshold of independent operators not colluding, and on the chain’s sequencer including the closing and draw transactions on time.

For equal chances, map a verified uniform random word to one of six horses using rejection sampling to avoid modulo bias. For weighted races, map an unbiased integer from 0 to 9,999 into the six published cumulative weight intervals. Domain-separated random words identify the race and draw index. The audited algorithm defines deterministic rejection and expansion of the provider output.

The animation illustrates the recorded outcome and cannot determine or override it. Anyone can reproduce the result from the proof, rules version, and weights. The replacement contract targets the first eligible drand publication about 60–62 seconds after the effective betting close. The deadline for a valid draw is five minutes after that close. A qualified race without a valid draw by then is voided for full refunds; late draws are rejected and no outcome is rerolled.

Pool accounting and payouts

Let P be the LUPYN actually received in valid entries and W the sum of entries on the winning horse. At successful settlement, the ordinary Crew Lock allocation is floor(P × 10%), Development receives floor(P × 5%), and the direct LUPYN Burn allocation is floor(P × 5%). The remaining settled balance is the winning allocation, targeting 80% while absorbing only unavoidable smallest-unit allocation dust. When W is positive, each winning claim is floor(winning allocation × entry ÷ W). When W is zero, there are no player claims and the entire winning allocation moves to the Crew Lock reserve. Individual payout rounding on backed winners remains encumbered in race escrow; it never becomes Development revenue.

For a 1,000 LUPYN settled Race Pool with 250 on the winner, the allocations are 800 to the winning players, 100 to Crew Lock Rewards, 50 to Development, and 50 burned directly. An entry of 50 on the winning horse receives 160 LUPYN, a net gain of 110 before gas. An entry on a losing horse receives zero. If the drawn winner has no bets, the same 1,000 LUPYN pool instead sends 900 to Crew Lock, 50 to Development, and burns 50; every bettor loses the entry. Returns are pari-mutuel and depend on the total winning-side pool.

Cancellations and claims

If P is zero, the race closes with no transfers. A race with fewer than four backed horses at the final betting deadline is cancelled with full claimable refunds. If W is zero after a qualified race is drawn, there is no player winner and no refund: the 80% winning allocation goes to the Crew Lock reserve, alongside its normal 10% allocation; 5% goes to Development and 5% is burned. If no valid drand result is delivered within five minutes of the close, the race is voided and every entry is refundable; late results are rejected. An emergency cancellation is possible only while betting is open and returns all entries. After betting closes, administrators cannot cancel, so no one can cancel a losing or expensive outcome once the drawing round is fixed.

Payouts and refunds use separate pull claims, with replay protection and no expiry. Settlement never loops over all participants. Residual payout rounding remains encumbered in that race escrow and is reported; it cannot become Development revenue. Network gas and the per-entry network fee are nonrefundable. During outages claims wait for network recovery; new races pause, and unresolved races follow the same deadline rules.

2 TSLA Racing Vault

Purpose and ownership of funds

The TSLA Racing Vault holds the Crew Lock allocation from successfully settled races. Ordinarily, each settled Race Pool routes 10% of the original pool to the reserve. If an unbacked horse wins, the unclaimed 80% winning allocation also goes to the reserve, for about 90% of that race's pool in total, subject to smallest-unit rounding. Open entries, refundable entries, player winnings, Crew Lock principal, Development funds, and burn allocations are held or routed separately. No developer wallet can withdraw the reserve directly; routing to a future Crew Lock receiver follows the published contract controls.

A race allocation becomes distributable only after final settlement. A cancelled or refundable race contributes zero to Crew Lock Rewards, Development, or Burn. The Vault transfers each settled-race Crew Lock allocation, including any unbacked-winner winning allocation, to the weekly Crew Reward ledger through an idempotent, permissionless function that records each source race once. A failed transfer can be retried without duplicating funding.

The Vault is a routing and reward reserve, not a price-support fund, general treasury, insurance guarantee, lending strategy, or source of new tokens. Its balance may rise between distributions and fall as rewards become claimable. Activity can stop, so future funding can be zero.

Weekly Crew Epoch distribution and empty participation

Crew Lock uses global seven-day Crew Epochs. For operational consistency, a Crew Epoch follows the same Monday 00:00 UTC to Monday 00:00 UTC cadence as the Crew Scoreboard unless a published contract version defines another fixed seven-day boundary. Funds enter a Crew Reward Pool only when actually received and recognized by the Crew Lock ledger. Settled race allocations received after an epoch checkpoint are attributed to the next Crew Epoch and are never backdated.

If a Crew Epoch closes with no eligible Crew Weight, its reward balances remain earmarked for Crew Lock and carry forward in the same asset to the next Crew Epoch. The dashboard separately discloses carryover by asset. Carryover cannot be redirected to Development or Burn merely because no position was eligible in a particular epoch.

Paid racing is part of the Phase 1 LUPYN production economy. From the first value-bearing race, the race contract, TSLA Racing Vault, Development route, and direct-burn route account for the 80/10/5/5 split. Before Crew Lock activates in Phase 2, the 10% settled-race allocation remains segregated in the Crew Lock Reserve and is not claimable or available to Development or Burn. Crew Lock distribution begins only after Phase 2 activation under the published Crew Lock rules.

Solvency invariant

For every asset, the relevant contract must hold at least its recorded obligations: unspent earmarked budgets, claimable rewards, and rounding reserves. Crew Lock principal has an additional separate one-for-one LUPYN obligation. In race escrow, funds must cover open entries, refunds, and prize claims until each liability is resolved. Development and Burn/Buyback allocations are never counted as collateral for user liabilities.

A shortfall triggers a halt to new exposure and public incident reporting. A book entry, estimated token price, future fee forecast, or treasury promise cannot satisfy an asset-denominated obligation. No administrator may sweep an asset that backs a recorded user claim.

3 The Crew Scoreboard

Weekly Leaderboard Competition

The Crew Scoreboard runs in recurring seven-day cycles funded from 40% of recognized Creator Rewards. The number of rewarded positions follows the project’s seven-day average market-cap tier fixed before each cycle begins. That tier remains unchanged through the cycle. Current standings have been cleared while race functionality is completed; monetary Scoreboard awards remain inactive.

A wallet earns one Leaderboard Point per $1 equivalent of eligible betting volume in successfully completed races. Cancelled races, refunded entries and races that do not proceed earn zero. A settled house-win race is completed, so its exposed losing stakes remain eligible. Fractional points are retained in accounting; the display precision must be fixed before activation.

For each wallet and completed race, add its stakes separately on all six horses. Let m be the smallest of those six horse totals, with zero for an unbacked horse. Subtract 6 × m from the wallet's total stake before USD conversion. Six equal $10 stakes earn zero points because all $60 is fully hedged; $20 on one horse and $10 on each other horse leaves $10 of eligible exposure. The conversion price source, timestamp and treatment of token-price changes during a race must be published before points are activated. This wallet-level rule alone cannot detect coordinated bets split across wallets.

Within a season, wallets rank by descending eligible points. If totals tie, the wallet that reached the final tied score first ranks higher, using ordered chain events; a deterministic fallback for truly simultaneous events must be published before activation. At each new season's start, points reset to zero. Closed seasons retain their recorded results.

The season tier uses the project's seven-day average market capitalization measured at the season start, not its live market cap. Below $500,000 rewards Top 10; $500,000 up to but not including $3 million rewards Top 20; $3 million up to but not including $5 million rewards Top 30; and $5 million or more rewards Top 40. The tier remains locked through the season. For example, a $3.5 million seven-day average locks Top 30 even if market cap later falls. The source, circulating-supply definition and observation cadence across the seven-day window must be published and verified before the first tier is activated.

At cycle close, record the final points and rankings. Funded Leaderboard awards become claimable only after the published verification and seven-day public challenge process resolves; the next cycle may start with zero points while a prior result remains under review. Recalculate the seven-day average and lock the next tier before the new cycle opens. The exact rank weights for every active tier must be published before its cycle begins. No monetary awards are active while the tier weights and verification process remain unfinished.

A Scoreboard season lasts seven days. Before it opens, publish the UTC start and end, entry eligibility, USD conversion and market-cap data sources, the locked tier, ranking and tie method, prize weights, and reward-eligibility requirements. These rules cannot change during that season.

Crew Lock weight does not alter Scoreboard prize allocations. Scoreboard rewards remain funded only from the defined Creator Reward allocation, and the Scoreboard follows the rules published for each seven-day cycle.

Rankings and funded awards

Each cycle's Scoreboard budget is the asset-by-asset 40% Creator Reward allocation recognized during that cycle plus any scheduled same-asset reserve release. Prize allocations follow the rewarded positions and published rank weights for the active leaderboard tier; those weights cannot change during the cycle. A tied score favors the wallet that reached it first. If fewer players qualify than rewarded positions, unused rank shares remain in the Scoreboard reserve. Amounts round down and any dust remains in the same-asset reserve. If no players qualify, no payout is made and the funded allocation remains in reserve.

If monetary Scoreboard prizes are temporarily disabled, the 40% Creator Reward share remains in the Scoreboard reserve; it does not become Development, Crew Lock, or Burn/Buyback money. Each reserve addition is disclosed and may be released under the published Scoreboard reserve rules when prizes resume.

Rankings have a seven-day public challenge period with reproducible Scoreboard data and the published cycle rules; unresolved challenges block finalization. Once finalized, awards are claimable without expiry. Fraud reviews require stated evidence and an appeal path; an administrator cannot silently replace a result.

4 Creator Rewards distribution

Define the actual receipt before allocating it

Recognized Creator Rewards means the supported assets actually credited to the designated creator recipient by the launch platform after platform-level deductions. It excludes trading volume, fees retained by PONS or liquidity providers, unrealized accruals, user deposits, initial token-sale proceeds, and transfers already recognized as revenue. The same receipt cannot be counted twice.

For each supported asset actually received, the Creator Reward router allocates 40% to the Crew Scoreboard, 30% to Crew Lock Rewards, 20% to Development, and 10% to Burn/Buyback. Allocations are calculated from the recognized creator-side receipt, not from gross trading volume or an assumed fee amount. Each destination is rounded down in the smallest unit; any unallocated smallest-unit dust remains segregated in the same-asset router balance and carries forward rather than being silently assigned to Development.

Illustrative creator-fee example

For illustration only, if a launch configuration produced a 700-unit recognized creator receipt, the LUPYN router would allocate 280 to the Crew Scoreboard, 210 to Crew Lock Rewards, 140 to Development, and 70 to Burn/Buyback. The actual LUPYN launch configuration and assets received govern live allocations; gross trading volume is not itself Creator Rewards. [1]

Currency and configuration controls

Scoreboard and Crew Lock rewards are distributed in the supported assets actually received. LUPYN remains LUPYN; ETH may be wrapped one-for-one to WETH for contract accounting. The initial reward allowlist contains LUPYN and the verified canonical WETH only. Other reward assets remain quarantined and undistributed until a reviewed adapter and updated disclosure exist. Different reward assets are never combined into one reward balance merely by quoting a common dollar value.

The 10% Creator Reward Burn/Buyback allocation follows the source asset. If the allocated asset is already LUPYN, it is burned directly through the defined on-chain burn mechanism. If the allocated asset is not LUPYN, that allocation may be used for a disclosed Buyback + Burn execution that acquires LUPYN and then burns the acquired LUPYN. The source asset remains segregated until an published execution occurs; failed or unsafe execution does not shift the allocation to Development. Published controls should identify the route, slippage limits, execution records, and amount of LUPYN ultimately burned.

5 Crew Lock (staking)

Crew Streak reward structure

Crew Lock is LUPYN staking. You lock (stake) LUPYN in Crew Lock and, while it stays locked, earn a share of the race and creator-fee rewards set aside for stakers; the longer you stay, the higher your Crew Streak multiplier. Staking opens in Phase 2.

Crew Lock is a Phase 2 optional application-level LUPYN locking (staking) mechanic that distributes variable, fee-funded rewards according to Crew Weight. No Crew Lock positions are accepted during Phase 1. It does not validate blocks, secure Robinhood Chain consensus, confer ownership of the operating business, or guarantee investment returns. Users may claim race winnings to their wallet and decide separately whether to open a Crew Lock position once Phase 2 is active. Crew Lock is never a condition of receiving a race payout.

The Crew Streak multipliers affect only the proportional division of a finite funded reward pool. They are not APRs, APYs, or promises to multiply principal. Week 1 uses 1.00×, Week 2 uses 1.25×, and Week 3 onward uses the maximum 1.50× multiplier while that position remains continuously locked. If most mature positions eventually reach 1.50×, the common multiplier largely cancels in proportional allocation; the streak still functions as a retention advantage for continuous positions relative to newer positions.

Positions, tranches, and next-epoch eligibility

Every new deposit creates a separate nontransferable position or tranche with its own position ID, principal, deposit timestamp, first eligible Crew Epoch, completed eligible-epoch count, current Crew Streak multiplier, claim records, and withdrawal status. Adding LUPYN to an existing wallet always creates a new position; new principal never inherits the streak of an older position. A new position becomes reward-eligible only at the next Crew Epoch checkpoint after deposit.

Crew Weight = LUPYN Locked × Crew Streak Multiplier. A position earns its next multiplier only after it completes a full eligible Crew Epoch without exiting. Its first eligible epoch uses 1.00×; after completing that epoch, the next eligible epoch uses 1.25×; after completing the second eligible epoch, Week 3 and all later continuous epochs use 1.50×. Claiming finalized rewards does not reset the streak. A position that has not completed the entire eligible epoch receives no reward for that epoch.

Withdrawals, checkpoints, and Emergency Exit

A user may request a normal withdrawal at any time and must select the specific Crew Lock position being withdrawn. The position remains locked through the current Crew Epoch and, if it completes that full epoch, remains eligible for that epoch’s finalized rewards. The normal withdrawal completes at the next Crew Epoch checkpoint after settlement, and that position’s Crew Streak then ends. If the user locks again later, the new position begins at Week 1 and follows next-epoch eligibility.

Emergency Exit allows the owner to withdraw a selected position’s principal at any time without waiting for the next checkpoint. Emergency Exit immediately ends that position’s Crew Streak and forfeits its unsettled reward for the current Crew Epoch. Finalized rewards from earlier Crew Epochs remain claimable. A position that Emergency Exits before epoch completion is excluded from that epoch’s finalized eligible Crew Weight, so the current funded pool remains available to positions that completed the epoch. Principal is never swapped, lent, bridged, or rehypothecated by Crew Lock.

No Crew Lock reward emissions are minted and rewards do not automatically compound. Claimed LUPYN may be voluntarily deposited as a new Week 1 position; claimed non-LUPYN rewards remain in their original asset unless the user independently swaps them. If recognized funding and carryover are both zero, that Crew Epoch’s reward is zero. A permanent shutdown stops new positions and future reward epochs, preserves finalized claims, and keeps principal recoverable under the continuity rules in Section 11.

Crew Lock (staking) reward accounting

Weekly funded allocation

Once Phase 2 is active, for each seven-day Crew Epoch and each supported asset, the Crew Reward Pool equals recognized Creator Reward receipts allocated 30% to Crew Lock plus recognized settled-race Crew allocations received during that epoch, plus any same-asset balance released from the pre-Phase 2 Crew Lock Reserve under the published activation schedule, plus same-asset carryover. The ordinary race contribution is 10% of each original settled Race Pool, not 10% of the already-separated 10% Crew allocation; an unbacked winner adds the 80% winning allocation to the Crew Lock reserve. Because paid races are denominated in LUPYN, settled-race Crew allocations enter the LUPYN reward pool. Creator-side Crew allocations remain in whatever supported asset was actually received. Different assets are accounted for and distributed separately.

For each supported asset: User Reward = Weekly Crew Reward Pool × (User Eligible Crew Weight ÷ Total Eligible Crew Weight), rounded down in the asset’s smallest unit. Eligible Crew Weight includes only positions that remained locked for the entire eligible epoch. If no eligible weight exists, the pool carries forward in the same asset. Unclaimed finalized rewards remain liabilities. Distribution rounding and dust remain in the same-asset Crew Reward ledger and carry forward; they are not spendable by Development or Burn/Buyback.

Example: if a completed Crew Epoch has 50,000 LUPYN available and a position represents 1% of that epoch’s finalized eligible Crew Weight, the position earns 500 LUPYN. If the same epoch also has 2 WETH in a separate Crew Reward Pool, that same 1% position earns 0.02 WETH separately. The two assets are never merged into a single reward amount. This example describes one funded epoch and does not forecast future earnings.

At each checkpoint, the system finalizes the funded pools, removes positions that failed to complete the epoch, calculates the final eligible Crew Weight denominator, records rewards, applies earned multiplier increases for continuing positions, and completes normal withdrawals scheduled for that checkpoint. Settled race allocations or creator receipts recognized after the checkpoint enter the next Crew Epoch. Claims use bounded per-position and per-asset accounting so settlement never requires looping over all Crew members. A delayed checkpoint changes claim availability, not which completed epoch receives a receipt under the published recognition rule.

Historical APR rather than assumed APY

The interface displays actual rewards by asset for recent completed Crew Epochs, the position principal, current Crew Streak multiplier, Crew Weight, first eligible epoch, next checkpoint, pending normal withdrawal status, and any backlog receipts. It may display a Historical annualized APR based only on finalized rewards; it must not present the 1.25× or 1.50× Crew Streak multiplier as an APR or guaranteed return.

For a fixed-principal position, a LUPYN-only historical annualized APR over N eligible Crew Epochs is (52.142857 × total LUPYN rewards earned during those epochs ÷ (principal × N)) × 100. The interface must show the number of eligible epochs used. A zero denominator produces N/A. Zero LUPYN rewards with a positive denominator produces 0%. This is a simple annualization of observed weekly rewards and does not assume reinvestment.

A combined-asset historical APR may be shown only with a disclosed, manipulation-resistant valuation method: value each finalized asset reward using the stated historical price source and observation time, divide by eligible principal value for the same completed epochs, and annualize consistently. The window, price source, observation time, and valuation currency must be shown. If reliable prices are unavailable, suppress the combined APR and retain raw asset amounts. No APY is displayed without a separately documented reinvestment model.

6 Crew Lock (staking) utility and limits

Crew Lock gives holders a defined way to remain with the Crew, build a continuous Crew Streak, and participate proportionally in funded reward pools. Community recognition or cosmetics may acknowledge Crew Streak participation, but Crew Lock cannot improve paid-race odds, alter Scoreboard ranking rules, or create unfunded financial claims. Locking can delay sales; it does not create permanent demand or ensure a higher token price. Product retention, protocol solvency, and holder returns remain separate measures of success.

7 Complete token economy

Supply and launch ownership

Maximum issuance is fixed at 1,000,000,000 LUPYN. No minting authority may remain capable of increasing issuance above that amount. Defined direct burns and Buyback + Burn executions may permanently reduce outstanding supply over time. This edition introduces no additional Crew Lock emission allocation, separate project Treasury token allocation, or project LP token allocation. Any platform-created liquidity position must nevertheless be disclosed; the absence of a project LP allocation does not mean that trading has no liquidity pool.

Project-side holdings remain limited to the designated development wallets under the launch structure. At or before financial activation, the team should publish a supply reconciliation covering platform liquidity, development and related-party holdings, public holdings, Crew Lock principal, locked or vested amounts, and any other destination. Categories should be mutually exclusive and reconcile to original issuance, with cumulative burns shown separately so outstanding supply can be reproduced.

Publish each development wallet, beneficial controller or accountable entity, token quantity and percentage, acquisition method and price where applicable, vesting start, cliff, release schedule, transfer restrictions, and vesting contract. Unvested or unlocked holdings must be described accurately; there is no assumed vesting protection. The ownership and authority register should remain current and identify creator-fee rights and administrative privileges.

Distinguish flows from new demand

Race turnover is the sum of settled race entry pools and may include the same tokens played many times. It is not new capital, operating profit, or external customer demand. Creator fees are transfers from trading activity, which may also be speculative or manufactured. Both reward sources can decline together when interest in LUPYN falls.

For a settled Race Pool of 1,000 LUPYN, the baseline sends 800 to the Race/Prize Pool, 100 to Crew Lock Rewards, 50 to Development, and 50 to direct Burn. A closed group re-entering only its remaining winner payouts retains about 107.37 LUPYN after ten rounds: 1,000 multiplied by 0.8 ten times. This illustration excludes new deposits, Crew Lock receipts, Scoreboard prizes, gas, burn effects on market price, and individual outcome differences.

For any total race deduction d, a coordinated group controlling the whole settled pool and a fraction s of eligible Crew Weight may recover the winner share plus its proportional Crew Lock share of the 10% race allocation. Under the 20% total deduction, Crew Lock represents half of that deduction. The group’s net race cost before other prizes and transaction costs is therefore P × d × (1 − s/2). At d = 20% and s = 80%, that is 12% of P; at s = 100%, it is 10%. The 20% deduction therefore does not by itself prove farming is unprofitable.

Scoreboard awards, Creator Rewards, and racing activity should be monitored together for coordinated farming or manipulation. No trading-volume rewards or guaranteed fee rebates are introduced. Marketing must not call circular turnover organic growth or characterize fee redistribution as new wealth creation.

8 Development funding and reserves

Operating funding principles

At the baseline, Development receives 5% of settled racing turnover and 20% of recognized Creator Rewards. It may retain only those Development allocations as operating reserves. Player deposits, race prizes, Scoreboard reserves, Crew Lock principal, Crew Lock rewards, direct burns, and Buyback + Burn reserves are excluded from operating assets.

Development operating costs and one-time build, security, legal, infrastructure, and support commitments must be funded from Development resources or other unrestricted project funding. User principal, race prizes, Scoreboard reserves, Crew Lock rewards, and Burn/Buyback allocations are not operating funds.

Runway and reserve policy

Operating reserves should be sized to the project’s actual recurring costs and separately identified one-time commitments. Expected future fees, encumbered user assets, and illiquid positions are not counted as available operating reserves.

Development’s own token receipts may be converted in capped batches to fund expenses and reserves. Publish the published route, maximum slippage, batch limits, execution records, realized proceeds, and costs. Do not guarantee execution at an oracle price. Below acceptable liquidity, defer conversion, cut expenses, or use unrestricted reserves; do not sell player assets or raid reward budgets.

Development should review operating runway regularly and reduce or pause new exposure if unrestricted reserves become insufficient to support safe operation and orderly wind-down. Existing claims, refunds, Crew Lock principal, and earmarked reward balances remain protected from operating shortfalls.

9 Economic and participation flows

Asset routing

Each allocation is recorded once. Race allocations are made in LUPYN: 80% to backed winners, 10% to Crew Lock Rewards, 5% to Development, and 5% to direct Burn. If the winning horse is unbacked, the 80% winning allocation also goes to Crew Lock and no player receives a prize or refund. Creator allocations follow the actually received asset: 40% Crew Scoreboard, 30% Crew Lock Rewards, 20% Development, and 10% Burn/Buyback. Internal transfers are not new revenue. Buyback + Burn from a non-LUPYN source asset does not assume execution at a fixed token price and remains subject to disclosed execution controls.

Player control

A race winner claims LUPYN without a Crew Lock obligation. They may retain it, use it for another race, or transfer it. Once Phase 2 is active, they may also open a new Crew Lock position. A new position becomes eligible at the next Crew Epoch, begins at Week 1, and builds its own Crew Streak only by completing full eligible epochs. Claims, normal checkpoint withdrawals, and Emergency Exit are separate actions.

Crew Scoreboard participation follows the published rules for the applicable seven-day cycle. Crew Lock remains a separate mechanic and does not change the Scoreboard’s ranking method, Leaderboard Points, or reward allocation for the active leaderboard tier.

10 Sustainable participation

A useful product-health test is whether players return for the racing experience, Crew competition, lore, social features, and cosmetics rather than only for expected token profit. Measure day-1, day-7, and day-30 retention by cohort; completed races per returning player; voluntary session frequency; enjoyment surveys; and use of social and cosmetic features. Production remains LUPYN-native, while free or non-value modes may be used to measure entertainment demand without replacing the production token utility.

Evaluate fee cohorts using retained players, voluntary spending per player, net Development revenue after delivery costs, and loss concentration. Select a rate from observed results rather than maximizing the percentage taken from each race. New cosmetic or content revenue requires a published price and allocation policy before introduction and is excluded from current forecasts.

The game must be supportable as entertainment without promising earnings. If retention or paid entertainment demand is weak, improve the game, onboarding, content, fee settings, and community experience. Do not add another reward token, advertise guaranteed yield, or rely on new entrants merely to conceal deteriorating demand.

Economic validation and monitoring

Required integrated tests

Economic testing must model coordinated wallets as one actor where appropriate. Include a group covering all six horses, 0% to 100% Crew Weight ownership, Week 1 / Week 2 / Week 3+ streak levels, mass checkpoint withdrawals, Emergency Exits, creator-fee rebates, Scoreboard awards, burns, gas, and slippage. Report net asset profit and loss after every recoverable reward or rebate, not only the race deduction.

Test duplicate submissions from the same wallet, coordinated multi-wallet strategies, borrowed tokens, last-minute pool changes, self-trading, bots, collusive prize sharing, small pools, no-winning-entry races, cancelled events, zero eligible Crew Weight, late race settlement near a Crew Epoch checkpoint, repeated deposit tranches, and Emergency Exit behavior. Adversaries who can influence randomness, rankings, receipt timing, or administrative actions must be modeled separately from ordinary players.

Paid racing is an early production utility rather than a feature gated behind a late roadmap stage. The race has no minimum or maximum total pool; one wallet is limited to 10,000 LUPYN per horse in each race. Monitoring, a pause for new entries, and a published randomness budget remain operational controls. Changes to exposure or economics should be based on completed weekly data and follow the published change-control process, but the core paid-racing mechanic is not contingent on a tokenless production phase.

Stress scenarios and acceptance

No model can prove all future strategies unprofitable. Known positive expected-profit paths caused by manipulation or duplicated eligibility must be fixed, or the affected reward feature remains disabled. Honest competitive prizes can have positive expected value for some entrants; the security objective is to prevent manufactured activity from capturing unintended rewards.

Public reporting

Publish monthly Creator Reward receipts by asset, settled racing turnover, Scoreboard participation metrics, allocated and paid rewards, cumulative burns, Burn/Buyback execution records, all reserve balances, expenses, realized conversion costs, and operating runway. Show top-1, top-5, and top-10 Crew Weight concentration, the share of eligible weight at Week 1 / Week 2 / Week 3+, and principal scheduled for normal withdrawal at the next checkpoint. Exclude infrastructure and custody contracts from holder statistics where appropriate and explain classification.

Report net payer spending, retention without prizes, revenue concentration, and subsidy use alongside gross activity. Compare forecast and actual results. A successful product does not guarantee token-holder returns; fixed issuance prevents inflationary reward creation but cannot eliminate selling pressure or a decline in token value.

11 Smart contract architecture

Components and responsibilities

Ranking verification and bounded execution

A permissionless proposer may submit a weekly Scoreboard result root with the complete dataset required by the published cycle rules and deterministic ranking output. The challenge mechanism must verify omitted eligible records, incorrect totals, tie handling, and duplicate records where applicable. Finalization requires a bond and an audited dispute process whose parameters and bond adequacy are published before prizes activate. Alternatively, a fully on-chain bounded computation may be used if gas testing supports it. A trusted spreadsheet alone is insufficient for valuable prizes.

The Scoreboard proposer, verifier, and dispute contracts are disclosed dependencies. If the chosen proof and challenge mechanism cannot be implemented and tested on the target network, monetary awards remain disabled and a non-monetary leaderboard may continue without prizes. Do not label an administrator-approved result trustless.

Administrative authority

Administrative roles and privileged permissions must be disclosed before activation. Material changes to economic parameters, allowlists, recipients, or upgradeable components must be published before they apply. Active races, funded claims, finalized Crew Epochs, and existing Crew Lock position terms cannot be rewritten by a parameter update. Material changes require a new rules version and apply only to future participation.

Prefer immutable race escrow and Crew Lock principal custody, with replaceable front ends and new contract versions for new positions. Any unavoidable proxy or upgrade authority must be published with its exact powers and timelock. Existing positions retain their economic terms; migration is opt-in. The authority register identifies all administrators, permissions, creator-fee recipients, burn/buyback authorities, and vesting administrators.

An emergency role may pause new race entries and new Crew Lock deposits immediately, but cannot choose winners, move user principal, take reward reserves, redirect burn/buyback reserves to Development, or erase finalized claims. Safe claims, deterministic race refunds, normal checkpoint withdrawals where safe, and the Crew Lock Emergency Exit remain available. If an affected path is itself unsafe, any temporary pause requires an incident notice and reviewed recovery process; the whitepaper does not promise instant access during a vulnerability or chain outage.

Security and continuity

Implementation requirements

Verify actual token behavior, supported asset addresses, burn capability, and chain finality assumptions. Use balance-delta accounting, safe transfers, reentrancy protection, domain-separated signatures, replay protection, access controls, and checked arithmetic. Keep race escrow, Crew Lock principal, reward pools, Development funds, and Burn/Buyback balances as separate obligations even when the same LUPYN contract is the underlying asset.

Tests must cover conservation of funds, allocation rounding, reward dust, duplicate claims, late randomness, entry-close boundaries, empty pools, no winner bets, delayed routing, next-epoch Crew Lock activation, multiplier transitions, added-deposit tranche isolation, normal checkpoint withdrawals, Emergency Exit forfeiture, zero denominators, unsettled races across epoch boundaries, long inactivity, bounded catch-up, and adversarial admin calls. Fuzz and invariant tests must show that user liabilities cannot be spent as Development revenue or burn inventory.

From the 19 September 2026 contract, keeper gas and drand delivery are funded by the per-entry network fee (Section 1); Development covers any shortfall, such as races that open but receive no entries. Permissionless fallback functions support settlement and epoch closing, but cannot guarantee liveness when the chain is unavailable. Production infrastructure requires monitored RPC failover, event reconciliation, archival access, and alerts for balance shortfalls, missed epochs, stale price displays, and unauthorized changes.

Shutdown and residual balances

An orderly shutdown stops new race entries, Scoreboard prize cycles, and new Crew Lock deposits; settles or refunds open races using their existing rules; resolves completed competition awards; and closes the final complete funded Crew Epoch. Finalized rewards remain claimable. A one-way shutdown mode may allow all remaining Crew Lock principal to exit without waiting for another normal checkpoint while preserving the same restriction that user principal cannot be redirected.

Accrued race prizes, Scoreboard awards, and finalized Crew Lock rewards remain claims without expiry. Rounding, dust, unused earmarked reward balances, and pending Burn/Buyback balances remain segregated and publicly reported. They cannot be silently swept to Development. Any legally required residual disposition needs a published separate process that preserves established claims; it is not assumed as operating income.

12 Legal readiness

Jurisdiction and participant protection

Paid entries, chance-based outcomes, transferable prizes, Crew Lock reward sharing, and token-distribution mechanics require qualified legal assessment in every operating and targeted player jurisdiction. The review should address racing, Crew Scoreboard competitions, Crew Lock, Creator Rewards, burns and buybacks, token distribution, marketing, consumer protection, tax, sanctions, and relevant licensing obligations. A disclaimer does not decide legal classification.

For example, Britain’s Gambling Commission treats tradable virtual items as money or money’s worth and states that offering gambling with them requires licensing. This example is not a legal conclusion for every jurisdiction or an authorization for LUPYN. [3]

Before activation, implement the review's required age checks, permitted-jurisdiction access controls, spending limits, cooling-off and self-exclusion tools, complaints process, and responsible-play disclosures. Review TSLA naming and all third-party artwork and trademarks. Financial features remain unavailable wherever the required authorization or safeguards are absent.

Network disclosure and material risks

Production and network positioning

The production ecosystem is LUPYN-native from the start and paid racing is an early core utility. Testnet, demo, or non-value environments may be used for contract testing, UX validation, simulations, and onboarding, but they do not replace the production mechanics or convert LUPYN into an optional production token.

Robinhood Chain documentation lists mainnet chain ID 4663 and ETH as gas. Deployment information should be verified again at release. Building on the chain does not by itself establish a Robinhood endorsement, brokerage listing, or integration with brokerage accounts. The TSLA Racing name does not itself establish a Tesla or TSLA-token partnership. This whitepaper makes no unverified claim that LUPYN is the first game in a category. [2]

Material risks

LUPYN can lose substantial or all market value. Fixed supply does not ensure demand, liquidity, price appreciation, or access to an exit. Race entrants can lose their entire entry and pay gas. Even winning entries can receive less than the amount entered when the winning pool is crowded.

Crew Lock reduces immediate liquidity and may produce no rewards. Rewards depend on actual recognized receipts, settled race activity, asset prices, total eligible Crew Weight, and timing. Concentrated holdings, many mature Week 3+ positions, and large checkpoint withdrawals can change reward shares and selling pressure. Creator Rewards and racing demand may decline together. In-kind non-LUPYN rewards introduce price exposure different from LUPYN.

Smart contracts, randomness providers, score disputes, administrative keys, indexers, networks, bridges, and supported assets can fail or be compromised. A funded ledger prevents intentional unfunded promises but cannot guarantee recovery after theft or a contract exploit. Financial and operating reserves serve different purposes and are not insurance.

Regulatory changes, licensing restrictions, intellectual property disputes, and platform configuration changes can delay, restrict, or end features. The project must disclose material changes promptly and follow the established pause and exit rules. No section promises income, token appreciation, reimbursement of market losses, or perpetual operation.

Appendix A Reference calculations

Numerical consistency checks

These checks verify the specified arithmetic. They are not a simulation of player demand, a smart-contract audit, or evidence of commercial sustainability.

Appendix B References

[1] PONS documentation, reviewed 11 September 2026. https://docs.ponsfamily.com/ — platform fee and creator-receipt documentation. Actual LUPYN launch settings govern live routing.

[2] Robinhood Chain Connecting documentation, reviewed 11 September 2026. https://docs.robinhood.com/chain/connecting/ — network and gas configuration. Building on Robinhood Chain does not imply Robinhood endorsement or brokerage integration.

[3] UK Gambling Commission, Digital and virtual currencies guidance, reviewed 11 September 2026. https://www.gamblingcommission.gov.uk/licensees-and-businesses/guide/page/digital-and-virtual-currencies — regulatory example concerning tradable virtual items used in gambling. It is not a legal conclusion for every jurisdiction.