LUPYN Whitepaper

REVISED PROJECT MECHANICS · Robinhood Chain • PONS · Revision v3 — 11 September 2026 · public edition

PROPOSED PRODUCT & ECONOMIC SPECIFICATION — NOT INVESTMENT / FINANCIAL-LAUNCH READY

This v3 incorporates the 11 September 2026 red-team review. Design issues are revised where possible. Missing ownership data, legal opinions, audits, operating funding, live deployments, user-demand evidence, and provider integrations are marked EVIDENCE REQUIRED or ACTIVATION BLOCKER rather than presented as completed facts.

Design objective

Build a game-first, non-inflationary token ecosystem whose rewards are funded by real ecosystem activity — while keeping launch scope, security risk, and economic dependencies understandable.

DESIGN PRINCIPLES

• No inflationary staking-emission schedule. Rewards must come from disclosed ecosystem activity or pre-funded reserves.
• Gameplay must be understandable without relying on token-price appreciation.
• External revenue (creator fees) must be separated from internal token redistribution (race pools).
• Economic functions should be on-chain where custody or payout integrity matters; high-frequency ranking and analytics should remain off-chain but verifiable.
• No mechanic should depend on a PONS feature, fee rate, or launch version that has not been confirmed at deployment time.

0. EVIDENCE STATUS & RELEASE PRINCIPLE

LUPYN will use an evidence-gated release model. Financial features remain disabled unless the evidence required for that feature is verified. “EVIDENCE REQUIRED” means the project has identified a diligence requirement; it does not mean that requirement has been satisfied.

1. CORE SYSTEM

1A. PRODUCT THESIS

$LUPYN is proposed as the participation and settlement asset for the LUPYN ecosystem, but the core game does not technically require a proprietary transferable token. Token necessity is therefore a hypothesis to be tested, not an assumption. The product must first demonstrate repeat entertainment value without relying on token-price appreciation, guaranteed rewards, or mandatory purchases.

Before mandatory token gating or settlement is adopted, the project should compare a free/tokenless prototype with a LUPYN-enabled version across onboarding friction, retention, conversion cost, volatility, legal complexity, willingness to pay, and player preference. If the evidence does not show a net user/product benefit, mandatory LUPYN use should be reconsidered for future participation.

2. TOKEN & LAUNCH CONFIGURATION

ECONOMIC DEFINITION. Do not hard-code a “PONS creator fee = X% of all fees” statement until the exact launch configuration is finalized. LUPYN’s internal 50/30/20 split is defined below against Net Creator Revenue, not against gross trading volume.

3. PRODUCT VALIDATION & LUPYN RACING — PHASE 0 / PHASE 1

LUPYN Racing is the proposed primary game utility. The recommended first release is a free/tokenless prototype using six racing characters/horses to validate whether users actually return for the entertainment and competitive experience before the project requires a token purchase, launches financial rewards, or exposes user principal.

Phase 1 Participation Flow

MVP Design Rules

• The MVP should not promise profit from gameplay.
• Score is not proportional to wallet size or amount spent.
• Daily/weekly participation scoring is capped to reduce spam and farming.
• Game animation may run off-chain, but the data used for rewards must be reproducible from the finalized scoring dataset and published rules.
• If a later LUPYN-gated test is run, the eligibility threshold must be justified by measured user benefit and must not make the product pay-to-win.

Product Validation Evidence

• Define the target user segment and acquisition channel before recruitment.
• Predeclare D1/D7/D30 retention and repeat-session thresholds before testing.
• Separate free-play usability evidence from willingness-to-pay evidence.
• Compare LUPYN-gated and simpler settlement/access alternatives before making the token mandatory.
• Report sample size, cohort quality, uncertainty and churn rather than relying on wallet count or raw transaction volume.

4. CONDITIONAL PAID RACING — LATER PHASE ONLY

Token-risk racing remains a possible later product, not an approved launch feature. It may activate only after a lawful paid perimeter, contract-level eligibility enforcement, verified randomness, independent security review, sufficient liquidity, realistic operating funding and real-money pilot evidence are established for the target market.

ACTIVATION BLOCKER

No paid race may rely only on frontend geofencing or disclaimers. Where eligibility, self-exclusion, person-level limits, or jurisdiction restrictions are required, the transaction boundary must reject ineligible direct contract calls as well as blocked website interactions.

LAUNCH GATE. If legal review concludes that the proposed paid race cannot be offered in a target jurisdiction, this mechanic must not be deployed there. A disclaimer does not replace product-level compliance.

Recommended Pool Distribution

Recommended pari-mutuel settlement:

User Payout = Distributable Winner Pool × (User Winning Entry ÷ Total Entry on Winning Selection)

The contract should never promise more than the funded race pool. If no valid winner exists, the race should follow a pre-disclosed cancellation/refund rule rather than improvise a payout.

Paid-Race Settlement Lifecycle

• OPEN: entries are accepted until a fixed closing block/time.
• LOCKED: no further entries or edits are accepted.
• RANDOMNESS REQUESTED: winner data is generated from a verifiable randomness source or an independently audited commit-reveal design.
• FINALIZED: the winning selection and distributable pool are fixed.
• CLAIMABLE: winners pull payouts from the contract; development/vault allocations are routed atomically or through pull-based balances.
• ENTRY FAIRNESS: late-entry and transaction-ordering advantage must be simulated before activation; commit/reveal or batching should be considered only if the measured advantage is material.
• MINIMUM ECONOMIC POOL: race creation and minimum pool/coverage rules must prevent repeated randomness/provider costs from being subsidized by uneconomic tiny pools.
• SPARSE POOL RULE: if the drawn winner has no valid entry, the predeclared refund/cancellation path applies; submitted activity must not be counted as settled turnover.
• COST CIRCUIT BREAKER: paid races pause or reject new events when fixed provider/gas costs exceed approved operating thresholds.

The maximum entry should be a disclosed contract parameter, not permanently hard-coded to 10,000 $LUPYN. A fixed token amount can become economically meaningless as token price and liquidity change. Changes should require multisig approval plus a timelock.

5. THE CREW SCOREBOARD

The Crew Scoreboard rewards active competitive participation in recurring 7-day cycles. It is the primary activity-reward system in Phase 1.

• Participants build qualifying performance through LUPYN Racing.
• The scoring rules are published before each scoring version becomes active.
• The Scoreboard finalizes at the end of each 7-day cycle.
• The designated reward allocation is distributed to the published winner set (Top 10 by default, configurable only through disclosed rules).
• The cycle resets and a new weekly competition begins.

Scoring Principles

• The Scoreboard must not be described as a skill ranking unless the game design and data demonstrate meaningful decision advantage beyond attendance and chance.
• Transferable prizes require a selected identity/eligibility architecture where necessary; wallet uniqueness alone does not prove person uniqueness.
• Any challenge/dispute process must have a bounded resolution deadline and a predeclared terminal outcome so one dispute cannot freeze a whole week indefinitely.
• Sponsored or subsidized actions require per-person/per-credential quotas and a hard daily budget.
• Do not award score directly in proportion to wallet balance, wager size, or raw transaction volume.
• Use capped participation points, normalized performance, streaks/achievements and anti-farming penalties.
• Apply per-wallet daily/weekly caps so repeated spam does not dominate the rankings.
• Version the scoring formula. A formula change should not retroactively alter an active week.
• Publish enough data for users to reproduce the finalized rankings.

Recommended Technical Model

Race/game contracts or authoritative event services emit the source events. An indexer ingests those events, a scoring service computes the weekly ranking, and a finalized Merkle root is published to the on-chain Reward Distributor. Users claim with a Merkle proof. This keeps payout integrity on-chain while avoiding continuous on-chain sorting/storage of every leaderboard position.

6. CREATOR-FEE REVENUE & ROUTING

Definition: Net Creator Revenue

“Net Creator Revenue” means the creator-side value actually credited/received from the selected PONS launch after the PONS protocol share, optional buyback settings, creator-tax rules, conversions, sweeps, or other launch-level mechanics that apply to the deployed token. It is not the same as total trading volume or gross trading fees.

Phase 1 Allocation

Phase 2+ Allocation

The Fee Router should account for the asset in which revenue is actually received. For an ETH-paired PONS v2 launch, creator revenue is expected to be denominated in ETH; a custom-pair launch can produce the approved pairing asset instead. The protocol should not silently convert those receipts into $LUPYN.

Fee Collection Dependency

PONS fee mechanics may require fees to accrue, be swept/claimed, and then be routed. The exact adapter must match the deployed PONS version. LUPYN should treat fee collection as an integration dependency and expose pending, claimed and routed balances in the dashboard where technically available.

Upstream Authority & Receipt Timing

The release record must identify every external or project-controlled authority capable of collecting, delaying, redirecting or changing creator-fee receipts. Local multisig/timelock rules must not be described as controlling permissions that remain with PONS or another upstream contract. Rewards are recognized only from assets actually received and reconciled; estimated or uncollected fees do not create user claims.

Delayed receipts must follow a deterministic funded-batch attribution rule that is tested against Crew Lock activation/expiry timing. The project must not be able to choose a convenient recipient cohort by delaying collection.

7. CREW LOCK (APPLICATION-LEVEL $LUPYN LOCKING)

Crew Lock is the recommended name for the longer-term participation layer. Users lock $LUPYN for a defined period and receive a reward weight. Crew Lock is an application mechanic; it does not validate Robinhood Chain transactions or provide network-consensus staking.

Reward Weight = Locked $LUPYN × Lock Multiplier

User Reward = Available Reward Pool × (User Reward Weight ÷ Total Eligible Reward Weight)

Reward Sources

• Phase 2: 30% of Net Creator Revenue, normally in the launch pairing asset unless the deployment specifies otherwise.
• Phase 3, if paid racing is enabled: the designated Race Participation Vault share, denominated in $LUPYN.
• No inflationary token minting and no fixed yield subsidy.

Lock Rules

• No ordinary early withdrawal before expiry. Emergency exits, if implemented, must be narrowly scoped and documented.
• Rewards accrue through weighted accounting; claims must not require looping over all users.
• If multiple reward assets exist, the UI should display each reward asset separately.
• Historical annualized reward metrics may be displayed only from realized rewards with a disclosed lookback window, eligible-day denominator and price source. The UI must also show waiting/commitment duration and make clear that positive token rewards can coexist with a loss in market value.
• Lock multipliers are provisional until beneficial-owner concentration and reward-capture simulations are completed.
• Material discretionary changes affecting an existing locked position must either be prohibited for that position or trigger a narrowly defined opt-out/exit treatment specified in advance.
• Reward accounting must define how delayed receipts, zero-locker periods, carryover and restart backlogs are attributed; backlogs should be reported separately from current-period yield.
• Principal withdrawal must remain possible even if reward processing is backlogged or uneconomic.

8. ECONOMIC MODEL & SUSTAINABILITY

Demand Principle

Token turnover, fixed supply, fee recycling and locked balances are not treated as proof of sustainable demand or valuation. The project must distinguish repeated turnover from new customer spending, external purchases, reward-recipient sales and net holder flows. The token case is supported only by measured user preference and durable economic use.

The system remains reflexive: more users and trading can increase reward funding; declining activity reduces Scoreboard and Crew Lock rewards. The protocol does not guarantee a minimum reward rate and should not subsidize an APY target from undisclosed reserves.

Stress Conditions

9. LIQUIDITY, DEVELOPMENT FUNDS & TREASURY CONTROLS

The project does not require a separate project-controlled LP token allocation under the assumed PONS launch model. However, locked liquidity does not guarantee deep liquidity, low slippage or a stable token price.

Required Controls

• Publish a mutually exclusive token-supply/beneficial-ownership register and related-party unlock schedule before investment solicitation.
• Maintain operating reserves in unrestricted assets that do not depend on selling $LUPYN or spending balances owed to users.
• Replace illustrative operating-cost assumptions with a bottom-up budget covering build, audit, legal/compliance, providers, support, contingency and shutdown.
• Set race/lock exposure and conversion limits using stressed executable market depth and slippage, not merely token price or market capitalization.
• Disclose liquidity positions/controllers and model simultaneous insider, development, player and reward-recipient selling.
• Publish the token contract, pairing asset, PONS launch version/configuration, creator fee recipient and project/development wallet addresses.
• Use a multisig for development funds and contract administration; do not rely on one externally owned wallet for critical control.
• Use a timelock for changes to economic parameters such as paid-race entry caps or supported reward contracts.
• Separate development funds from user reward balances and race escrows.
• Show material protocol balances on a public dashboard.
• Define a liquidity/activity threshold before Phase 3 paid racing can be enabled.

10. USER PARTICIPATION FLOWS

Phase 1 — Play & Compete

$LUPYN holder → connect wallet → meet eligibility rule → enter LUPYN Racing → qualifying result/activity → Crew Scoreboard → weekly finalization → claim reward

Phase 2 — Lock & Participate

$LUPYN holder → choose 7/30/90-day Crew Lock → receive reward weight → activity-funded reward accounting → claim available rewards → withdraw principal after lock expiry

Phase 3 — Conditional Paid Race

$LUPYN holder → enter open race → race locks → verified randomness → pari-mutuel settlement → winner claims → vault/development allocations

11. REVISED TECHNICAL ARCHITECTURE

Component Evidence Register

Every custody, reward and eligibility component must carry a dated status: PROPOSED → IMPLEMENTED → TESTED → INDEPENDENTLY REVIEWED → DEPLOYED/VERIFIED. A whitepaper specification is not evidence that the corresponding control exists in code.

12. SECURITY & OPERATIONAL REQUIREMENTS

Smart-Contract Controls

• Use pull-based claims for user rewards and race payouts where practical.
• Use standard token-transfer safety patterns, reentrancy protection, checks-effects-interactions and explicit accounting invariants.
• Cap per-race exposure and validate all settlement arithmetic against the funded pool.
• Keep user principal/reward balances segregated from development funds.
• Restrict pause authority to emergency-sensitive functions; a pause should not create an undisclosed confiscation capability.
• Do not add mint, arbitrary balance seizure or transfer-blacklist powers unless explicitly required and disclosed — the recommended design does not need them.

Operational Controls

• Where participant eligibility is required, enforce it in the contract entry path or a cryptographically verified authorization adapter; frontend-only blocking is insufficient.
• Benchmark worst-case claim/storage costs and ensure reward-processing failure cannot block principal withdrawal.
• Publish portable claim data/proofs and an independently usable recovery method so valid claims can survive project-frontend shutdown.
• Fund a wind-down reserve appropriate to the selected architecture and operating perimeter.
• Deploy and test on Robinhood Chain testnet before mainnet.
• Use production-grade RPC/indexing infrastructure; public RPC endpoints should not be the sole production dependency.
• Monitor PONS fee accrual/claim state, reward distributor roots, Crew Lock balances and paid-race escrow invariants.
• Create alerts for failed keeper actions, abnormal score patterns, unusual withdrawals and contract pauses.
• Independent contract review/audit is required before Crew Lock and especially before paid racing handles material user value.

Randomness Requirement for Paid Racing

A race that transfers economic value must not derive its winner from block timestamp, block number, predictable blockhash combinations, frontend randomness, or a single project-controlled server. Use a verifiable randomness service available on Robinhood Chain or an independently audited commit-reveal design. Entries must close before the final randomness can be known.

Shutdown / Terminal State Requirement

A single authoritative terminal sequence must define: stop new exposure → settle or refund open races → resolve or close weekly awards → recognize late creator-fee receipts → finalize Crew Lock reward periods → release principal → preserve funded claims. Late receipts, zero-participant carryover and unfinished disputes must each have a predeclared treatment.

13. LAUNCH PLAN & GATES

Evidence to Validate Before Financial Expansion

• Weekly active wallets and unique returning players.
• Races/competitions per active user.
• D1, D7, D30 retention and repeat-session frequency by acquisition cohort.
• Share of users participating without being top reward recipients.
• Willingness to pay and contribution margin from lawful paid tests; creator revenue and rewards reported separately from core product demand.
• Concentration of token ownership and Scoreboard rewards.
• Liquidity depth and typical slippage for realistic user trade sizes.

Numeric thresholds, sample-size rationale, stopping rules and accountable owners should be approved before testing so expansion is not activated merely because it appears on a roadmap.

14. POSITIONING & FIRST-MOVER CLAIMS

LUPYN should not use a broad “first” claim unless verified immediately before publication. The defensible differentiation thesis is the integrated game → competition → transparent activity-funded rewards → optional longer-term participation loop. This is a positioning hypothesis, not a proven competitive moat; user preference, distribution and retention must establish whether it is defensible.

Recommended Positioning Statement

POSITIONING. LUPYN is a game-first token ecosystem built on Robinhood Chain where competitive participation, transparent on-chain activity and ecosystem fees power recurring player rewards and long-term participation — without relying on inflationary token emissions.

Short Form

Play. Compete. Earn from real ecosystem activity. LUPYN brings a race-driven, non-inflationary game economy to Robinhood Chain.

15. ECONOMIC, TECHNICAL & REGULATORY RISK DISCLOSURE

$LUPYN is a speculative crypto asset. Gameplay rewards, creator-fee allocations, Crew Lock rewards and any future paid-race rewards are variable and are not guaranteed income or guaranteed returns.

• Token value and liquidity can decline materially, including to zero.
• Locked liquidity does not guarantee deep liquidity or low slippage.
• Creator-fee revenue depends on actual trading activity and the deployed PONS configuration.
• Crew Lock reward rates depend on realized reward funding and total eligible reward weight.
• Paid racing, if ever launched, may involve loss of tokens used to participate and may be restricted or unavailable in some jurisdictions.
• Smart contracts, PONS integrations, keepers, indexers, RPC providers and frontends may fail or contain vulnerabilities.
• Off-chain scoring services may experience outages or disputes; reward data and scoring rules should therefore be auditable and reproducible.
• Third-party protocols and infrastructure may change their features, access policies, fees, contracts or security posture.
• Robinhood Chain is permissionless; deployment on the chain does not imply Robinhood endorsement of LUPYN.
• Applicable securities, gaming/gambling, consumer-protection, tax, sanctions and other laws may affect availability and design.
• Token ownership does not confer ownership of the operating business under this specification; any financing instrument or contractual right must be separately documented.
• Development/related-party holdings, vesting and unlock concentration can create material sell pressure; no protection should be assumed until verified.
• Naming, character artwork and other content rights must be cleared before public commercial use; a non-affiliation disclaimer does not establish permission.
• Reward rates, market capitalization and historical APR are not equivalent to executable exit value or total investor return.

Nothing in this document constitutes financial, investment, legal, tax or gambling advice. Final production mechanics must be reviewed against deployed smart-contract behavior, current platform documentation and applicable law.

16. TARGET ECONOMY AT FULL DEPLOYMENT

$LUPYN = PROPOSED TOKEN LAYER • LUPYN RACING = VALIDATED GAME FIRST • CREW SCOREBOARD = COMPETITION • CREW LOCK = CONDITIONAL LONG-TERM PARTICIPATION • ACTIVITY FEES = VARIABLE REWARD FUNDING

APPENDIX B — EVIDENCE & ACTIVATION REGISTER

• PONS / launch: verify exact version, pair, creator-tax/buyback settings, fee recipient, collection authority and launch transactions.
• Ownership: reconcile total supply, beneficial controllers, related-party holdings, acquisition terms, vesting and 30/60/90-day unlocks.
• Funding: approve a bottom-up build/operate/audit/legal/shutdown budget and verify unrestricted funding/reserves.
• Product: complete a free prototype, define target users, measure D1/D7/D30 retention and compare tokenless vs LUPYN-enabled participation.
• Scoreboard: finalize scoring, identity/eligibility rules, sponsor limits, dispute terminal state and proof/data-availability design.
• Governance: publish multisig signers/independence, conflict/replacement rules, timelock scope and upstream authorities.
• Infrastructure: select RPC/indexer/keeper/randomness/identity providers and publish failure assumptions, monitoring and cost limits.
• Financial activation: obtain target-market legal clearance, direct-call access controls, independent contract review, liquidity/depth gates, paid-pilot evidence and shutdown readiness.

APPENDIX D — TECHNICAL REFERENCES REVIEWED

Robinhood Chain — About / architecture: https://docs.robinhood.com/chain/

Robinhood Chain — Deploy a Contract: https://docs.robinhood.com/chain/deploy-smart-contracts/

Robinhood Chain — Connecting / production RPC guidance: https://docs.robinhood.com/chain/connecting/

Robinhood Chain — Data Streams / oracle infrastructure: https://docs.robinhood.com/chain/data-streams/

PONS v1 documentation: https://docs.ponsfamily.com/

PONS v2 documentation — launch lifecycle, fees, payouts, contracts, audits: https://docs.ponsfamily.com/v2

Reference note: platform documentation and deployed contracts can change. The final production whitepaper should be reconciled against the actual token contract, PONS launch configuration and Robinhood Chain environment immediately before launch.