Visualizing the relationship between supply, demand, and price in automated token markets


PumpPoly Whitepaper v2.1


Integrated Launchpad + Decentralized Exchange Protocol


Solana + Base + Robinhood Chain


1. Overview


PumpPoly is a fully decentralized, non-custodial protocol for permissionless on-chain token creation, bonding-curve trading, graduation, liquidity migration, and decentralized exchange trading through one unified interface. The integrated protocol remains under development and is not yet complete. This document describes its architecture and intended mechanics; consult the roadmap for development status.


PumpPoly combines two previously separate stages of the token lifecycle:


  1. Permissionless token launch and bonding-curve trading.


  2. Post-graduation trading through the native PumpPoly DEX.


Tokens do not need to leave the PumpPoly ecosystem after graduation.


Once protocol-defined graduation conditions are satisfied, eligible liquidity is migrated into a canonical PumpPoly DEX pool according to deterministic protocol rules.


PumpPoly’s initial launch scope includes:


  • Solana.

  • Base.

    Robinhood Chain.


The protocol architecture consists of:


  • Solana Engine.

  • Shared EVM Engine.


The Shared EVM Engine is being developed for Base and Robinhood Chain from the initial launch, with common economic and accounting logic. Additional compatible networks may be introduced later.


PumpPoly is non-custodial.


Users retain control of their wallets, private keys, assets, and transaction approvals.


PumpPoly does not provide financial advice, investment advice, brokerage services, portfolio management, custody services, project endorsement, or guarantees of financial outcomes.


Token creators and users interact with the protocol independently and at their own risk.


2. Core Design Philosophy


PumpPoly is designed around the following principles:


Permissionless access.


Token creation and trading should not depend on discretionary project approval.

Standardization over arbitrary configuration.


Core launch economics are defined by protocol rules rather than configurable creator-controlled token economics.

Deterministic execution.


Supply mechanics, bonding curves, graduation conditions, fee routing, reward accounting, and liquidity migration follow predefined rules.


Non-custodial architecture.


Users interact directly from user-controlled wallets.


One token lifecycle.


Launch, trade, graduate, migrate liquidity, and continue trading without leaving the PumpPoly ecosystem.


Transparent economics.


Fees and reward mechanics should be observable, deterministic, and publicly disclosed.


Accounting security.


No participant may claim more value than the protocol economically generated for that participant.


Bot neutrality.


Automated trading is treated as a normal component of permissionless markets.


The protocol is not designed to punish legitimate bots, market makers, arbitrage systems, automated trading strategies, or high-frequency participants merely because they trade frequently.


Frontend independence.


The frontend is not an authoritative accounting system.


Trading economic state must originate from blockchain execution and verifiable protocol state. Planet Mining uses separate server-recorded participation points, described in Section 31.


3. Protocol Architecture


PumpPoly uses a multi-engine architecture.


3.1 Solana Engine


The Solana Engine handles Solana-native:


  • Token creation.

  • Bonding-curve execution.

  • Trading.

  • Fee routing.

  • Reward accounting.

  • Graduation.

  • Liquidity migration.

  • PumpPoly DEX pools.

  • Post-graduation swaps.


3.2 Shared EVM Engine


The Shared EVM Engine is being developed to support Base and Robinhood Chain at initial launch.


It handles equivalent functionality using EVM-compatible smart contracts.


Base and Robinhood Chain share the planned EVM economic and security architecture while retaining network-specific execution and accounting namespaces. Future compatible networks can reuse that architecture.


3.3 Unified Interface


Users interact through a single PumpPoly interface.


The interface may display:


  • New token launches.

  • Bonding-curve markets.

  • Graduated tokens.

  • PumpPoly DEX markets.

  • Charts.

  • Trades.

  • Creator Rewards.

  • Trader Rewards.

  • Graduation status.

  • Liquidity information.

  • Protocol statistics.

  • Live reward statistics.


The chain-specific execution layer remains abstracted from the primary user experience wherever practical.


4. Permissionless Token Launch


Launching a token on PumpPoly is intended to be free at the protocol launch layer.


Creators define primarily non-economic metadata.


This may include:


  • Token name.

  • Token ticker.

  • Description.

  • Token image or supported media.

  • Social links.

  • Community links.


Core token economics are standardized by protocol rules.


Creators do not independently define:


  • Arbitrary token supply.

  • Hidden transfer taxes.

  • Additional minting rights.

  • Hidden token allocations.

  • Privileged creator pricing.

  • Custom bonding curves.

  • Undisclosed protocol fees.


There is no required free creator token allocation.


Where creator purchasing at launch is supported, the creator participates through the same disclosed economic mechanism applicable to market participants.


5. Standardized Bonding Curve


Before graduation, eligible PumpPoly tokens trade through the protocol bonding curve.


Pricing follows deterministic contract logic.


The bonding curve is responsible for:


  • Executing eligible buys.

  • Executing eligible sells.

  • Determining token price progression.

  • Routing protocol fees.

  • Recording reward-generating activity.

  • Accumulating the capital required by the graduation mechanism.

  • Maintaining protocol-defined graduation state.


The bonding curve is not controlled by frontend price calculations.


Contract execution remains authoritative.


6. Pre-Graduation Fee Model


Before graduation, the total PumpPoly trading fee is:


1.10% per eligible trade.


The fee is divided as follows:


ComponentFeeCreator Rewards0.45%Trader Rewards0.30%PumpPoly protocol0.27%DEX Liquidity


Reserve0.08%Total1.10%


The 0.08% DEX Liquidity Reserve is included inside the 1.10% total fee.


It is not an additional fee.


Example



For an eligible trade with a value of $1,000:


  • Total fee: $11.00.

  • Creator Rewards: $4.50.

  • Trader Rewards: $3.00.

  • PumpPoly protocol: $2.70.

  • DEX Liquidity Reserve: $0.80.


The values above are examples based on the pre-graduation fee schedule.


Actual settlement occurs in the assets and units defined by the relevant chain implementation.


7. DEX Liquidity Reserve

The DEX Liquidity Reserve is a dedicated component of pre-graduation protocol economics.

It is economically separate from:

  • PumpPoly protocol revenue.

  • Creator Rewards.

  • Trader Rewards.

  • Bonding-curve trading capital.

The reserve exists to strengthen the transition between the launch phase and the PumpPoly DEX phase.

Reserve accounting must remain independently identifiable.

Funds assigned to the DEX Liquidity Reserve must not be counted simultaneously as unrestricted protocol revenue.


8. Graduation


Graduation is the deterministic transition from bonding-curve trading to native PumpPoly DEX trading.


When predefined graduation conditions are satisfied, the protocol begins a controlled migration process.


The intended lifecycle is:


Token Launch → Bonding Curve → Graduation → Liquidity Migration → PumpPoly DEX


Graduation must be designed as an accounting-safe state transition.


The same token must not be capable of successfully graduating multiple times.


The protocol must prevent:


  • Duplicate liquidity migration.

  • Duplicate reserve consumption.

  • Double accounting.

  • Replay of completed graduation actions.

  • Multiple canonical pools being created for the same market through the standard graduation path.


Graduation state must be verifiable independently of the frontend.


9. Native PumpPoly DEX


Graduated tokens trade through the native PumpPoly DEX.


PumpPoly is therefore not designed as a launchpad whose completed tokens depend on an unrelated third-party DEX for their primary post-graduation lifecycle.


The PumpPoly DEX is part of the same protocol ecosystem.


This allows PumpPoly to provide a continuous user experience covering:


  • Discovery.

  • Launch.

  • Bonding-curve trading.

  • Graduation.

  • Liquidity migration.

  • Post-graduation trading.

  • Rewards.

  • Analytics.


The canonical PumpPoly DEX pool becomes the primary protocol-defined market for a token after successful graduation.


10. Liquidity Migration


At graduation, protocol-defined liquidity is migrated from the launch phase into the canonical PumpPoly DEX pool.


The migration mechanism should be:


  • Deterministic.

  • Atomic where technically practical.

  • Idempotent.

  • Replay resistant.

  • Accounting verifiable.

  • Independently observable.


The migration may include:


  • Protocol-designated bonding-curve capital.

  • DEX Liquidity Reserve funds.

  • Other explicitly disclosed liquidity components defined by the production implementation.


No liquidity component may be counted twice.


Failed or interrupted migration processes must not produce duplicated economic state.


Exact migration behavior may vary between Solana and EVM execution environments while preserving equivalent economic invariants.


11. Post-Graduation Dynamic DEX Fees


After graduation, the fixed pre-graduation 1.10% fee no longer applies.


PumpPoly DEX uses a dynamic fee schedule designed to become progressively more competitive as a market grows.


The current target schedule is:


Market TierTotal DEX Fee1–2×G1.00%2–5×G0.90%5–10×G0.80%10–25×G0.70%25–50×G0.60%50–100×G0.50%100–250×G0.40%≥250×G0.30%


G represents the protocol-defined graduation reference threshold used by the dynamic fee system.


The exact production metric used to determine the applicable multiple of G must be publicly disclosed before activation.


11.1 Manipulation Resistance


Dynamic fee tiers must not rely solely on an instantaneous spot value.


The production implementation may use mechanisms including:


  • Time-weighted average measurements.

  • Hysteresis.

  • Confirmation windows.

  • Minimum tier residence periods.

  • Separate promotion and demotion thresholds.

  • Manipulation-resistant liquidity or market metrics.


A temporary price spike or short-lived liquidity manipulation should not be sufficient by itself to permanently move a market into a cheaper fee tier.


Likewise, small fluctuations around a tier boundary should not cause constant fee oscillation.


12. Creator Rewards


Creator Rewards align creators with actual protocol activity.


Before graduation:


0.45% of eligible trading volume is allocated to Creator Rewards through the pre-graduation fee model.


Creator Rewards originate from real protocol fee generation.


They are not:


  • Guaranteed income.

  • Token emissions representing guaranteed value.

  • Guaranteed investment returns.

  • Guaranteed compensation.


Creator reward eligibility continues according to the active protocol rules applicable to the token's lifecycle.


Post-graduation reward parameters must follow the active PumpPoly DEX fee configuration and must be disclosed separately from the pre-graduation 1.10% schedule.


The protocol should not represent a reward as claimable unless that reward has been economically funded and correctly accounted for.


13. Trader Rewards


Before graduation:


0.30% of eligible trading volume is allocated to Trader Rewards.


Trader Rewards are associated with eligible trading activity according to protocol-defined accounting rules.


The executing wallet may become eligible for rewards according to the active implementation.


Trader Rewards are not guaranteed profit.


Reward accounting must prevent:


  • Double claims.

  • Replayed claims.

  • Duplicate indexing.

  • Duplicate transaction credit.

  • Claiming pending value multiple times.

  • Claiming more than cumulative eligible rewards.

  • Frontend-generated fake reward balances.


The conceptual accounting invariant is:


Claimable Rewards = Cumulative Eligible Rewards − Claimed Rewards − In-Flight Rewards


Reward settlement mechanics may differ across Solana, Base and Robinhood Chain while maintaining equivalent accounting guarantees.


14. Live Rewards Counter


PumpPoly is designed to provide transparent public reward statistics derived from actual protocol activity.

The PumpPoly Live Rewards Counter may display metrics including:


  • Total Rewards Paid.

  • Creator Rewards Paid.

  • Trader Rewards Paid.

  • Rewards Paid During the Last 24 Hours.


These values must originate from verified protocol execution and indexed on-chain data.


The frontend must not manufacture, simulate, increment, or otherwise create authoritative reward totals independently.


Where indexer state temporarily differs from blockchain state, the underlying blockchain records remain authoritative.


15. Indexing and Protocol Data


PumpPoly uses indexing infrastructure to provide fast discovery, analytics, charts, feeds, histories, and aggregated protocol statistics.


Indexer infrastructure is not authoritative for ownership or settlement.


The blockchain remains the settlement layer.


Indexer design should account for:


  • Chain reorganizations where applicable.

  • Duplicate events.

  • Replayed events.

  • Finality differences.

  • Idempotent event processing.

  • Missing block recovery.

  • Transaction uniqueness.

  • Cross-chain namespace separation.


User balances and reward eligibility must never depend solely on mutable frontend state.


16. Bot-Neutral Market Design


PumpPoly is designed to be automation-friendly.


The protocol does not consider automated trading inherently malicious.


Normal market participants may include:


  • Manual traders.

  • Trading bots.

  • Arbitrage systems.

  • Market makers.

  • Snipers.

  • Automated portfolio systems.

  • High-frequency strategies.

  • Smart contract integrations.


PumpPoly should not arbitrarily deny rewards or trading access merely because a wallet operates automatically or generates high transaction volume.


The primary security requirement is economic validity.


Every trade must correctly fund the fees and rewards generated by that trade.


Automation must never allow:


  • Creation of unfunded rewards.

  • Double reward credit.

  • Replay-generated rewards.

  • Accounting overflow.

  • Rounding exploitation.

  • Reward withdrawal above economically generated value.


17. Security Invariants


PumpPoly is designed around explicit protocol invariants.


Critical invariants include:


No double claims.

A reward unit may be paid no more than once.

No replay.

Previously settled trades, claims, graduations, or migrations must not generate duplicate value.

No frontend-authoritative accounting.

The frontend cannot create protocol balances.

No unfunded rewards.

Creator Rewards and Trader Rewards must originate from economically generated protocol fees. Planet Mining Points are a separate finite community allocation, not trading-fee rewards.

No duplicate graduation.

A token cannot complete the canonical graduation process more than once.

No duplicate liquidity migration.

The same migration capital cannot be transferred into multiple canonical pools.

Conservation of value.

Protocol accounting must reconcile inputs, outputs, fees, reserves, rewards, and balances according to the defined execution model.

Safe rounding.

Rounding rules must not allow repeated extraction of value.

Chain separation.


Solana and EVM accounting namespaces must not create cross-chain replay or identity collisions.


Security validation should include:


  • Unit tests.

  • Integration tests.

  • End-to-end tests.

  • Fuzz testing.

  • Property testing.

  • Invariant testing.

  • Failure-path testing.

  • Replay testing.

  • Migration testing.

  • Reward-accounting testing.


18. Liquidity Lock Configuration


Where supported, token creators may choose from disclosed liquidity lock configurations.


Target options include:


  • No lock.

  • One year.

  • Two years.

  • Permanent lock.


The selected configuration must be visible to users.


A liquidity lock does not guarantee:


  • Token quality.

  • Price appreciation.

  • Market demand.

  • Trading volume.

  • Creator reliability.

  • Protection from loss.


19. PumpPoly Reward Flywheel


PumpPoly's core economic model is designed around protocol activity rather than dependence on a native token.

The intended flywheel is:


Free Launch

↓

Trading

↓

Creator Rewards + Trader Rewards

↓

Higher creator and trader retention

↓

More community activity and promotion

↓

Higher volume

↓

Graduation

↓

Native PumpPoly DEX

↓

Progressively lower dynamic DEX fees

↓

Greater liquidity and trading competitiveness

↓

More users, creators, launches, and volume


The economic foundation of PumpPoly is protocol usage.


A future native asset is not required for this flywheel to operate.


20. PPOLY


PumpPoly may introduce PPOLY as an optional protocol ecosystem asset.

PPOLY is not required to:


  • Launch a token.

  • Trade on the bonding curve.

  • Graduate a token.

  • Trade through the PumpPoly DEX.

  • Receive the core PumpPoly user experience.


PPOLY must not become a dependency required for PumpPoly's underlying economic model to function.

Possible future uses may include:

  • Ecosystem coordination.

  • Selected non-core functionality.

  • Community participation.

  • Access to optional features.

  • Governance signaling.

  • Ecosystem programs.


PPOLY does not inherently represent:


  • Equity.

  • Ownership of PumpPoly.

  • Guaranteed revenue.

  • Guaranteed dividends.

  • Guaranteed yield.

  • Redemption rights.

  • Guaranteed financial returns.


Any future PPOLY tokenomics or distribution model must be documented separately.


21. User Experience


PumpPoly is designed as one integrated interface rather than separate disconnected products.


Users should be able to:


  • Launch tokens.

  • Discover launches.

  • Trade bonding-curve tokens.

  • Monitor graduation progress.

  • Trade graduated tokens on PumpPoly DEX.

  • View charts.

  • View transaction activity.

  • Track Creator Rewards.

  • Track Trader Rewards.

  • View liquidity information.

  • View public protocol statistics.


The distinction between launchpad and DEX exists at the execution layer but should remain intuitive to the user.


22. What PumpPoly Is Not


PumpPoly is not:


  • A custodian.

  • A broker.

  • An investment adviser.

  • A portfolio manager.

  • A guarantee of token quality.

  • A guarantee of liquidity.

  • A guarantee of profitability.

  • A guarantee of creator behavior.

  • A project endorsement service.


The existence of a token on PumpPoly does not constitute an endorsement, verification, recommendation, or investment opinion by PumpPoly.


Token creators and token communities are independent participants.


23. Risk


Digital assets involve significant risk.


Risks include, but are not limited to:


  • Full loss of funds.

  • Extreme price volatility.

  • Liquidity loss.

  • Smart contract vulnerabilities.

  • Failed transactions.

  • Network congestion.

  • Blockchain outages.

  • Oracle failures where applicable.

  • Indexing delays.

  • Wallet errors.

  • Phishing.

  • Malicious token creators.

  • Social engineering.

  • Bot activity.

  • Sniping.

  • Automated trading.

  • Coordinated trading.

  • Market manipulation.

  • Rapid liquidity changes.

  • Community abandonment.

  • Regulatory uncertainty.


Neither standardization nor decentralization eliminates market risk.


Users remain responsible for reviewing and approving their own blockchain transactions.


PumpPoly will never require users to disclose:


  • Seed phrases.

  • Private keys.

  • Recovery words.

  • Wallet passwords.


24. Decentralization and Non-Custodial Operation


PumpPoly is designed as a fully decentralized, non-custodial protocol.


Users transact through user-controlled wallets.


PumpPoly does not take custody of user private keys.


PumpPoly does not control user wallets.


Core protocol economic behavior should be encoded in transparent on-chain logic wherever technically practical.


Any administrative, upgrade, emergency, or deployment permissions that exist during protocol development or transition should be minimized, secured, and transparently documented.


The long-term architecture is designed to progressively minimize discretionary control over core protocol execution.


25. Legal and Compliance Positioning


PumpPoly provides decentralized software infrastructure.


PumpPoly does not provide:


  • Financial advice.

  • Investment advice.

  • Brokerage recommendations.

  • Portfolio management.

  • Custody of user assets.

  • Guaranteed financial outcomes.

  • Project investment ratings.


Users remain responsible for:


  • Their own wallet security.

  • Their transaction approvals.

  • Their trading decisions.

  • Their tax obligations.

  • Their regulatory obligations.

  • Determining whether use of the protocol is permitted in their jurisdiction.


Protocol availability does not constitute a representation that every activity available through blockchain infrastructure is lawful in every jurisdiction.


26. Protocol Source of Truth


PumpPoly may consist of several technical layers:


  • Smart contracts or programs.

  • Blockchain state.

  • Indexers.

  • APIs.

  • Web interfaces.

  • Analytics services.


For on-chain trading settlement and asset ownership, blockchain execution is authoritative. Planet Mining point balances are recorded separately by the campaign server under Section 31.


The user interface is a presentation layer.


If an interface displays information that conflicts with finalized on-chain state, the finalized on-chain state takes precedence.


Current live protocol parameters should be publicly observable or disclosed through official PumpPoly interfaces and documentation.


27. Development Priorities


The current protocol development priorities are:


  1. Solana Engine completion and hardening.

  2. Shared EVM Engine / Base and Robinhood Chain completion and hardening for initial launch.

  3. Native PumpPoly DEX.

  4. Graduation state machine.

  5. Deterministic liquidity migration.

  6. Dynamic post-graduation fee system.

  7. Creator Rewards.

  8. Trader Rewards.

  9. DEX Liquidity Reserve accounting.

  10. Indexer reliability.

  11. PumpPoly Live Rewards Counter.

  12. End-to-end testing.

  13. Fuzz testing.

  14. Invariant testing.

  15. Security review and mainnet hardening.


After the core protocol is stable, additional product layers may include:


  • Portfolio.

  • Push Notifications.

  • Social and crypto identity.

  • Live video.

  • Watchlists.

  • Creator reputation.

  • Moderation and administrative tooling.


These features are secondary to the correctness and security of the trading and accounting infrastructure.


28. Launch Networks and Future Expansion


PumpPoly’s initial launch scope includes:

  • Solana.

  • Base.

    Robinhood Chain.

Networks beyond Solana, Base and Robinhood Chain may be introduced after the initial launch.


Future network expansion must not reduce the security or accounting guarantees of existing implementations.


New networks should meet requirements relating to:

  • Execution reliability.

  • Wallet infrastructure.

  • Liquidity.

  • Security.

  • Indexing.

  • Cross-chain accounting separation.

  • Long-term ecosystem relevance.


The Shared EVM Engine is intended to reduce duplicated implementation risk when adding compatible EVM networks.


29. Protocol Evolution


PumpPoly will continue to evolve.


Fee mechanics, reward systems, graduation parameters, liquidity mechanisms, security controls, supported chains, and optional ecosystem features may change through future protocol versions.


Material changes should be publicly documented.


The production implementation and live on-chain parameters take precedence over outdated documentation.

No whitepaper should be interpreted as overriding actual smart contract execution.


30. Conclusion


PumpPoly combines permissionless token creation, bonding-curve trading, graduation, liquidity migration, and native decentralized exchange trading into one protocol ecosystem.


The core lifecycle is:


Launch → Trade → Rewards → Graduation → PumpPoly DEX → Dynamic Fees → Liquidity → Growth


Before graduation, eligible trading uses a transparent 1.10% fee structure funding:


  • Creator Rewards.

  • Trader Rewards.

  • PumpPoly protocol operations.

  • DEX Liquidity Reserve.


After graduation, tokens transition into the native PumpPoly DEX and use progressively lower dynamic fees as the market grows.


PumpPoly is designed to remain:

  • Non-custodial.

  • Permissionless.

  • Bot-neutral.

  • Automation-friendly.

  • Accounting-secure.

  • Multi-chain.

  • Transparent.

  • Scalable.


Creator and Trader Rewards are intended to align platform participants around real protocol activity.

The native DEX keeps graduated liquidity and trading inside the PumpPoly ecosystem.


PPOLY, if introduced, remains an optional ecosystem component rather than the foundation of PumpPoly economics.


PumpPoly is building an integrated token lifecycle:


Launch here. Trade here. Graduate here. Stay here.

31. Planet Mining and the PPOLY Community Campaign

31.1 A separate community feature

PumpPoly is building a fully decentralized, non-custodial launchpad and native DEX with Solana, Base and Robinhood Chain in its initial launch scope. The on-chain protocol remains under development.

Planet Mining is a separate community feature with authenticated accounts and a shared, persistent planet. PumpPoly servers record its progress and point balances. These off-chain account records are separate from on-chain trading, Creator Rewards and Trader Rewards.

31.2 One planet, one finite supply

The planet contains 60,000,000 blocks. Exactly 1,100,000 different blocks contain one PumpPoly Point each. The server generates this random allocation before mining opens, and the committed allocation remains fixed throughout the campaign.

There is one continuous campaign. It has no recurring reward periods, daily point budgets, replenishment or scheduled reset. Mining ends when every point-bearing block has been discovered. Empty blocks award no points.

31.3 Your contribution determines your share

Players mine through manual interactions. Only valid hits accepted by the server count toward a block’s destruction and reward allocation.

When a rewarded block is destroyed, its one point is shared among the contributing accounts in proportion to their accepted hits on that block. Contributions from earlier expeditions remain eligible. The final hit receives no additional reward.

Shares use up to six decimal places. A fixed rounding rule ensures that all shares from a rewarded block add up to exactly one point. For example, a player responsible for three of a block’s four accepted hits receives 0.75 points; the other contributor receives 0.25 points.

Mining Score records gameplay progress separately. Team membership, reactor levels, Mining Score and additional linked wallets do not multiply points or improve a block’s reward probability.

31.4 Hidden rewards and campaign verification

A block’s reward remains hidden until its destruction is confirmed. Reward placement is independent of block hardness. Cracks, colour, sound, position, mineral type and visual effects do not indicate whether it contains a point.

A cryptographic commitment to the complete reward map is published before mining opens. After all campaign points have been discovered, the complete map and verification information become available so that anyone can check whether the revealed map matches the original commitment.

This verification happens after the campaign ends. It is not an immediate independent proof for each block and does not make the server-operated campaign decentralized.

31.5 Account balances and reviews

The server confirms block destruction and point assignment together. Repeating a request cannot destroy the block again or award its point twice. The browser cannot create authoritative balances, and training does not award campaign points.

Assigned shares remain linked to their authenticated accounts. Shares held for a security review remain reserved within the same finite supply; they are not redistributed to other players. Account reviews and appeals are handled separately from gameplay progress.

31.6 Planned PPOLY airdrop

Verified PumpPoly Point balances will form the basis of the planned PPOLY airdrop after every campaign point has been mined and the PumpPoly token has launched.

The token allocation, point-to-token conversion, distribution network and distribution date will be documented separately before distribution. A point balance records participation in the campaign; it is not a completed token transfer.

PPOLY remains an optional part of the PumpPoly ecosystem. Planet Mining does not change the launchpad or DEX fee schedules, trading reward accounting or the protocol’s neutrality toward legitimate trading automation.

31.7 Current availability

Status — 27 September 2026: Planet Mining is temporarily suspended until the PumpPoly (PPOLY) token launches. Shared mining, point assignment, training and mining-related pages are unavailable during this pause. Existing accounts, verified points, teams and planet progress are preserved. The campaign remains one shared planet with 60,000,000 blocks and a fixed supply of 1,100,000 PumpPoly Points. Wallet verification remains paused. The PPOLY airdrop remains a separate planned distribution after all campaign points are mined and the token launches.

Visit Planet Mining for the pause notice and future reopening information.


PumpPoly is building a fully decentralized, non-custodial launchpad and native DEX for launch on Solana, Base and Robinhood Chain. The integrated on-chain protocol remains under development. Users retain control of their wallets and authorize their own blockchain transactions.

PumpPoly does not take custody of user assets or private keys and does not provide financial advice, investment services, or guarantees of outcomes.

Tokens launched through the protocol are created and managed independently by third parties. PumpPoly does not endorse, recommend, verify, or guarantee any token, creator, or project.

Users interact with the protocol at their own discretion and are solely responsible for their wallets, transactions, and decisions. Digital assets involve significant risk, including the possible loss of funds.

PumpPolyEnter app