Visualizing the relationship between supply, demand, and price in automated token markets
PumpPoly Whitepaper v2.0
Integrated Launchpad + Decentralized Exchange Protocol
Solana + Base
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.
PumpPoly combines two previously separate stages of the token lifecycle:
Permissionless token launch and bonding-curve trading.
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 initially supports:
Solana.
Base.
The protocol architecture consists of:
Solana Engine.
Shared EVM Engine.
The Shared EVM Engine is designed to allow additional compatible networks to be introduced later without duplicating the core economic and accounting architecture.
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.
Economic state must originate from blockchain execution and verifiable protocol state.
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 initially operates on Base.
It handles equivalent functionality using EVM-compatible smart contracts.
The architecture is designed so that future EVM networks can reuse common economic and security logic instead of operating as independent protocol implementations.
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 between Solana and Base 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.
Rewards must originate from economically generated protocol fees.
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 settlement and ownership, blockchain execution is authoritative.
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:
Solana Engine completion and hardening.
Shared EVM Engine / Base completion and hardening.
Native PumpPoly DEX.
Graduation state machine.
Deterministic liquidity migration.
Dynamic post-graduation fee system.
Creator Rewards.
Trader Rewards.
DEX Liquidity Reserve accounting.
Indexer reliability.
PumpPoly Live Rewards Counter.
End-to-end testing.
Fuzz testing.
Invariant testing.
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. Future Network Expansion
PumpPoly initially focuses on:
Solana.
Base.
Additional networks may be introduced later.
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.
