# Developer Platform Welcome to your team’s developer platform

Polypump – Predictive Markets Platform

Overview

Polypump is a predictive markets platform built on Solana within the pump.fun crypto-meme ecosystem. It allows users to create and participate in prediction markets on meme coins and tokens launched on pump.fun. Polypump supports both SOL (Solana’s native coin) and $POLYPUMP (the platform’s utility token) for betting. The platform is designed with a deflationary reward model: a portion of every market’s payouts is burned (reducing $POLYPUMP supply) and a portion is allocated as developer rewards. This mechanism incentivizes participation while maintaining token scarcity and funding ongoing development.

In this example, users can bet on whether more than 500 "shitcoins" will migrate today. The interface shows a Yes/No question with dynamic odds (Yes at $0.75, No at $0.25), indicating implied probabilities based on current bets. Users can choose their stake (paid in $POLYPUMP here) and side before confirming the bet.

Polypump’s architecture is technical and on-chain: markets are created via smart contracts that track bets and outcomes. Each prediction market is associated with a specific token (identified by its Solana token address) and a condition to be evaluated (for example, a target market capitalization or an event like a token migration). Participants connect their Solana wallets to place bets on the outcome (typically a Yes/No outcome for a given question). Once the market reaches its conclusion (the pre-set end time or event trigger), the outcome is determined automatically by checking on-chain data or oracle feeds for the condition. Winners are paid out trustlessly by the smart contract, while the built-in burn and developer fee mechanisms redistribute a fraction of the pot to bolster the token’s value and support the project’s development.

# Market Creation ## Any user can create a new prediction market by specifying a question and parameters for the event. The key parameter is a **token address** – this links the market to a particular pump.fun token and allows the platform to fetch relevant data (price, market cap, holder counts, etc.) for evaluating the outcome. For example, a market could be *“Will Token X reach a market cap of 1,000 SOL by Oct 31, 2025?”* with Token X’s address provided to track its market capitalization. When creating a market, the creator defines the outcomes (typically **Yes** or **No**) and an expiration time or block height when the market will resolve. An initial stake (in SOL or $POLYPUMP) may be required from the creator to seed the market’s liquidity and signal confidence in the event.
# Placing Bets
## Once a market is live, any user can place a bet on either outcome. Bets are placed by staking either SOL or $POLYPUMP tokens, giving flexibility to participants. Polypump uses an automated market-making logic to calculate odds dynamically based on the current stakes on each side. As more users bet on “Yes” versus “No,” the price (or implied probability) of each outcome shifts. For instance, if a large majority of stakes are on “Yes,” the cost to bet on “Yes” increases and its potential payout decreases (and conversely, “No” becomes cheaper with a higher potential payout). This dynamic is often displayed as odds or prices (e.g., 75¢ vs 25¢ for Yes/No), representing the fraction of the pot one share of that outcome would win. The underlying math can be thought of as a **pari-mutuel pool** or an AMM (automated market maker) curve that always balances the two sides – effectively, odds = (stake\_on\_side / total\_stake). There is no house; payouts come from the pool of bets. Users can place multiple bets and even add more to a side as long as the market is open. # Market Resolution Logic: ## Each market has a predefined condition that must be checked at resolution. Polypump’s backend will automatically **verify the market condition** once the expiration time is reached (or immediately when a triggering event occurs, if it’s an event-driven market). This verification is done by retrieving on-chain data or via an oracle: * For a market about **price or market cap**, Polypump queries the token’s on-chain trading data and supply. For example, it can multiply the token’s current price (from a DEX or oracle like Pyth) by its circulating supply to get market capitalization at the deadline, then compare it to the target value. * For a market about **token events** (such as migrations, listings, or holder counts), the platform checks the relevant on-chain registry or smart contract. In pump.fun’s context, a “migration” might refer to tokens graduating from the pump.fun bonding curve to a public market or moving to another network. The system can count how many tokens have migrated on that day by reading event logs or a dedicated counter in the pump.fun program. * Other conditions (e.g., “Did token X achieve Y number of holders?” or “Was a new contract deployed for token Y?”) are similarly verified through on-chain data or trusted oracle feeds that Polypump integrates with. ### If the condition is met, the outcome is **Yes**, otherwise **No**. Importantly, this check is trustless and automatic — once the smart contract or oracle confirms the data, the outcome is decided without manual intervention. # Payout Calculation ## After determining the winning outcome, Polypump’s smart contract calculates payouts. All bettors on the winning side will split the combined pot of stakes from both sides, **minus the fees**. The payout for each user is proportional to their contribution relative to the total on the winning side. For example, if you staked 10 $POLYPUMP on the winning outcome and the total winning-side stake was 100 $POLYPUMP, you get 10% of the losers’ pool in addition to your original stake. The platform automatically handles this math, crediting winnings to users’ wallets immediately upon resolution. # Burning and Developer Rewards ## Polypump’s reward mechanism takes effect at the moment of payout:
1. A fixed percentage (for instance, 5% of the total losing pool) is **burned**. If bets were placed in $POLYPUMP, those tokens are permanently destroyed, reducing the overall supply. If bets were in SOL, the protocol may convert the fee into $POLYPUMP (via a swap) and then burn those tokens, ensuring that every market contributes to deflation of the $POLYPUMP token. This burn not only supports the token’s value but also serves as an incentive for long-term holders. 2. Another small percentage (e.g. 5%) is allocated as **developer rewards**. This cut is sent to the project’s treasury or a developer wallet. It funds ongoing development, maintenance, and could also be used to reward community contributors or the market creator. In the future, this might evolve into a community-governed treasury or a reward for the user who created the market (to encourage users to propose interesting markets). ### The remainder (\~90% of the pot) is distributed to the winners. Losers forfeit their stake entirely, but because the outcomes are binary and the process is transparent, participants understand the risk-reward tradeoff when betting. All transactions (bets, payouts, burns, and fees) occur on-chain, providing transparency and allowing anyone to verify the outcomes and reward distribution. # Market Creation ### The process begins with a user (or developer) creating a new prediction market. The creator formulates a yes/no question about a specific token or event, sets an expiration time, and attaches the relevant **token address**. Attaching the token’s address allows Polypump’s systems to monitor that token’s data for the condition. Upon creation, the creator stakes an initial amount of currency (which can be SOL or $POLYPUMP) into the market to open it. This initial stake can serve as the first bet (for example, the creator might stake on “Yes” if they believe the event will happen) and also provides initial liquidity so that other users can start betting against it. The market is now live and visible to the community. # Betting Phase #### Once the market is open, multiple participants can join in. Users connect their wallets and choose a side (**Yes** or **No**) to bet on. They stake their chosen currency (the market will indicate which currencies are accepted; many markets allow SOL, $POLYPUMP, or even both). The Polypump smart contract records each bet, updating the total stakes on each side. As bets accumulate, the odds (prices of Yes vs No shares) update in real-time according to the amounts staked, as described in the previous section. This phase continues until the market’s deadline is reached (or until an event occurs that would prematurely decide the outcome). Users can enter or exit positions while the market is open (though in the current version, bets are typically locked in until resolution; a future update might allow selling your position early on a secondary market). Throughout the betting phase, the question’s progress can be tracked (for example, if the prediction is about reaching a certain metric, users might watch live data to inform their bets). # Outcome Resolution ### At the predetermined expiration time (or trigger moment), the market closes and no further bets are allowed. Polypump’s resolution mechanism now kicks in. The system checks the condition attached to the token’s address: * If the condition is **met**, the outcome is determined to be “Yes.” * If the condition is **not met**, the outcome is “No.” ### For instance, if the market question was about a token’s market cap and the target was surpassed by the deadline, that yields a “Yes” outcome. If not, “No” wins. This check is done automatically via on-chain queries or an oracle, ensuring fairness and accuracy. In our example screenshot question “Will more than 500 shitcoins migrate today?”, at the end of the day the system would count the actual number of token migrations that occurred on pump.fun that day by reading the platform’s contract state. Based on that count, it would resolve the market to Yes or No accordingly. # Payout and Settlement ### Once the outcome is finalized, Polypump’s smart contract immediately settles the market: * All stakes on the **losing side** are collected. A predetermined fraction of that total is taken out for fees (burn + dev reward). * The remaining portion of the losing side’s stake becomes the reward pool for the winners. * Participants who bet on the **winning side** receive their payout automatically. Each winner receives their initial stake back *plus* a share of the losers’ stakes proportional to their contribution to the winning side. This is handled in a single transaction per winner or can be claimed by the user through the platform UI. * The **burn mechanism** is executed: the fee portion reserved for burning is used to reduce supply. If the market was in $POLYPUMP, those tokens are directly burned. If it was in SOL, the equivalent value could be converted to $POLYPUMP (via a swap on a DEX) and then burned, or in some cases SOL could be sent to an unrecoverable address. This deflationary action increases scarcity of $POLYPUMP, benefiting all token holders. * The **developer reward** portion is transferred to the designated developer/treasury address. This could be in the form of SOL or $POLYPUMP depending on the market currency and how the fee policy is set. These funds support the platform’s development and maintenance. (In future, this fund might also be partially redistributed as community incentives or used to bootstrap new markets.) ### Finally, the market is marked as **resolved**. The outcome (Yes/No) is recorded and visible. Users can see the final statistics — for example, “Yes won with 1500 $POLYPUMP vs 500 $POLYPUMP staked on No.” The platform might also display the factual outcome (e.g., “600 tokens migrated today, so the result is YES”). All of this happens seamlessly through the Polypump program on Solana, ensuring trustless execution. Users can withdraw their winnings, and the market is closed to further activity. The entire lifecycle from creation to payout is managed on-chain, with the Polypump UI and API providing a user-friendly way to interact with the contracts. # API ### Polypump provides a RESTful API for developers and advanced users to integrate with the platform. Below is a reference for the main endpoints, including example requests and responses. (Note: these endpoints are imaginary but reflect how a real API might be structured for Polypump. All requests and responses use JSON format. In practice, authorized requests would require the user’s wallet signature or an API key to authenticate actions like creating markets or placing bets.) # Authentication & Base URL ### All endpoints are prefixed with a base URL, e.g., `https://api.polypump.fun/` Endpoints that modify data (like creating markets or placing bets) require authentication. Since Polypump is on a blockchain, **authentication is handled via wallet signatures** rather than traditional login. For example, the API might expect a signed message proving ownership of the wallet address making the request. For simplicity, the examples below omit auth headers and focus on functionality. # Create a Market `POST /markets` – Create a new prediction market. * **Request:** Send a JSON object with the market details. You must specify the question, the token address of the asset or coin the market is about, the outcome options (usually fixed to \["Yes","No"] for binary markets), the expiration time, and the currency denomination for bets. ```json POST /markets Content-Type: application/json { "question": "Will Token X reach a market cap of 1,000,000 USD by 2025-12-31?", "tokenAddress": "7GHsz...EByX" , /* Solana token address for Token X */ "outcomes": ["Yes", "No"], "expireAt": "2025-12-31T00:00:00Z", "currency": "POLYPUMP" } ``` * **Response:** If successful, returns a JSON object with the created market’s details, including a unique market `id` and initial state. The `status` will be "open" (active for betting). The `odds` for each outcome start at 0.5 (50%) if no initial stake, or may reflect the creator’s initial stake if provided (in this example, the creator did not favor either side, so initial odds are equal). The `feePercentage` fields show the fee rates for burn and rewards. ```json { "id": "market_8a9f5b2c", "question": "Will Token X reach a market cap of 1,000,000 USD by 2025-12-31?", "tokenAddress": "7GHsz...EByX", "outcomes": [ { "name": "Yes", "odds": 0.5, "totalStake": 0 }, { "name": "No", "odds": 0.5, "totalStake": 0 } ], "currency": "POLYPUMP", "expireAt": "2025-12-31T00:00:00Z", "status": "open", "createdAt": "2025-09-10T13:45:30Z", "creator": "Fx1...abc", /* wallet address of creator */ "feePercentage": { "burn": 0.05, "developer": 0.05 } } ``` In this response: * `id` is the unique identifier for the market (used for querying or betting). * `outcomes` lists the possible outcomes with current odds (0.5 means 50% – these will change once people bet). * `totalStake` is how much has been staked on each side so far (initially 0 or some amount if creator provided an initial stake). * `currency` indicates this market is using $POLYPUMP tokens for bets. * `expireAt` is the cutoff time for the event. * `feePercentage` shows the fee rates for burning and dev reward (in this case 5% each, meaning 10% total is taken from the losing side at resolution). **Error cases:** If required fields are missing or invalid (e.g. tokenAddress not a valid Solana address, or expireAt is a past time), the API returns an error response, for example: ```json { "error": "Invalid token address" } ``` (HTTP 400 Bad Request). #### **List Markets / View Market** `GET /markets` – Retrieve a list of active markets (and possibly recently closed ones). * **Request:** No body needed. You can filter or paginate via query parameters (for example, `GET /markets?status=open` to get only open markets, or `?limit=20&offset=0` for pagination). * **Response:** An array of market summary objects. For brevity, assume we get two markets: ```json [ { "id": "market_8a9f5b2c", "question": "Will Token X reach a market cap of 1,000,000 USD by 2025-12-31?", "tokenAddress": "7GHsz...EByX", "currency": "POLYPUMP", "status": "open", "expireAt": "2025-12-31T00:00:00Z", "odds": { "Yes": 0.5, "No": 0.5 } }, { "id": "market_b7c3d1e0", "question": "Will more than 500 tokens migrate on pump.fun by end of today?", "tokenAddress": null, "currency": "SOL", "status": "open", "expireAt": "2025-09-10T23:59:00Z", "odds": { "Yes": 0.75, "No": 0.25 } } ] ``` Each entry provides a snapshot: `id`, the question text, which token it’s about (if applicable; in the second example the condition is a global event, so `tokenAddress` might be null or a special indicator), the currency used for bets, current status (open or resolved), expiration, and the current odds for quick insight. `GET /markets/{id}` – Retrieve detailed info for a specific market. * **Request:** Provide the market ID in the URL path. * **Response:** A detailed market object, similar to the creation response but updated with current data. For example, for `market_b7c3d1e0` above: ```json { "id": "market_b7c3d1e0", "question": "Will more than 500 tokens migrate on pump.fun by end of today?", "tokenAddress": null, "details": "This market tracks the number of new token migrations on pump.fun on 2025-09-10.", "currency": "SOL", "status": "open", "createdAt": "2025-09-10T00:00:00Z", "expireAt": "2025-09-10T23:59:00Z", "creator": "8PJ...efe", "outcomes": [ { "name": "Yes", "odds": 0.75, "totalStake": 150.0 }, { "name": "No", "odds": 0.25, "totalStake": 50.0 } ], "totalVolume": 200.0, "feePercentage": { "burn": 0.05, "developer": 0.05 } } ``` This shows that currently 150 SOL is staked on "Yes" and 50 SOL on "No", hence the odds 0.75 vs 0.25 (implying Yes is favored). `totalVolume` is the sum of all stakes. The `details` field (optional) can provide a human-readable description of the condition. Once the market is resolved, the same endpoint will return updated information: * `status` will change to `"resolved"`. * An additional field like `"result"` or `"winningOutcome"` will indicate which side won. * Payout info might be summarized (e.g. how much was paid out to winners). For example, after resolution the above market might look like: ```json { "id": "market_b7c3d1e0", "question": "Will more than 500 tokens migrate on pump.fun by end of today?", "tokenAddress": null, "currency": "SOL", "status": "resolved", "expireAt": "2025-09-10T23:59:00Z", "resolvedAt": "2025-09-11T00:10:00Z", "winningOutcome": "Yes", "outcomes": [ { "name": "Yes", "totalStake": 150.0 }, { "name": "No", "totalStake": 50.0 } ], "payoutRatio": { "Yes": 1.3333, "No": 0 }, "feesCollected": { "burned": "9.5 POLYPUMP", "developer": "9.5 POLYPUMP" } } ``` Here, `winningOutcome` is "Yes". The `payoutRatio` for Yes indicates each 1 SOL bet on Yes yields \~1.3333 SOL back (which matches splitting 50 SOL losers among 150 SOL winners after fees). `feesCollected` shows how the 10% fee (20 SOL from the 200 SOL total pool) was handled: in this hypothetical case, 20 SOL was converted to 19 $POLYPUMP (split equally for burning and dev rewards). The specifics of fee conversion might vary, but the API reports what was burned and sent to dev. (Note: actual implementation might show fees in SOL or in USD value, but we show $POLYPUMP here to illustrate the burn.) **Checking Conditions:** There isn’t usually a separate public endpoint solely for “checking” a market’s condition, since resolution is automatic. However, developers might use the data from a market to monitor progress. For instance, the `details` or a separate field could include the threshold and current value if the market is still open. In our example, one could imagine an endpoint or field: ```json "conditionProgress": { "currentCount": 420, "target": 500, "unit": "migrations" } ``` This would indicate, while the market is live, that currently 420 migrations have happened today out of the 500 needed. Such information could also be derived by the developer manually via other data sources. Typically, the Polypump API focuses on market state; actual real-time metrics may come from external APIs (pump.fun’s core API for token stats). In summary, to **check the outcome condition**, one normally waits for the market to resolve and then reads `winningOutcome`. If developers want to proactively check how close an event is, they would query pump.fun or blockchain data directly (outside the Polypump API scope), or Polypump could expose a convenience endpoint for certain metrics in future. # Place a Bet `POST /markets/{id}/bets` – Place a bet on a market outcome. * **Request:** Provide the market ID in the URL. The JSON body should include the outcome you want to bet on and the amount (and optionally the currency if needed). The request must be signed by the user’s wallet (or the user must have authenticated via an API key tied to their wallet) to ensure the bet is authorized and the funds are available. ```json POST /markets/market_b7c3d1e0/bets Content-Type: application/json { "outcome": "No", "amount": 10, "currency": "SOL" } ``` This example means the user is betting 10 SOL on the "No" outcome for market\_b7c3d1e0. * **Response:** On success, the API returns a confirmation with the updated state for that market (or at least the parts affected): ```json { "marketId": "market_b7c3d1e0", "outcome": "No", "amountStaked": 10.0, "newTotalStake": { "Yes": 150.0, "No": 60.0 }, "newOdds": { "Yes": 0.7143, "No": 0.2857 }, "transactionId": "5gHk...zFt", "message": "Bet placed successfully." } ``` Now the "No" side has a total of 60 SOL (previously 50 + this 10), and the "Yes" side remains 150, so the odds have shifted slightly (Yes down to \~0.714, No up to \~0.286). The response also includes a `transactionId` for the on-chain transaction that recorded the bet, which can be looked up on Solana’s explorer for verification. If the request fails (e.g., insufficient funds, invalid outcome name, market already closed), an error is returned: ```json { "error": "Bet placement failed: market is already resolved or closed." } ``` or a relevant message. **Note:** In a real scenario, placing a bet would involve transferring the amount from the user’s wallet to the smart contract. The API call might return immediately with a pending status while the transaction is confirmed on-chain. A websocket or polling mechanism could be used to confirm when the bet is finalized. The above simplified flow assumes the bet goes through successfully. #### **Retrieve Results** As mentioned, once a market is resolved, the outcome and payouts are visible via `GET /markets/{id}`. There may not be a separate “result” endpoint; clients can just fetch the market data to see who won. However, for convenience, an endpoint could exist to specifically fetch resolved outcome and user-specific payout info: For example, `GET /markets/{id}/result` might return: ```json { "marketId": "market_b7c3d1e0", "winningOutcome": "Yes", "resolvedAt": "2025-09-11T00:10:00Z", "yourWinnings": 0, "claimable": false } ``` Where `yourWinnings` is what the requesting user won (if the API is authenticated and knows the user’s wallet) and `claimable` indicates if the user still needs to claim (in Polypump, winnings could be automatically sent, so likely claimable is false and funds were auto-transferred). If the user lost, `yourWinnings` would be 0 (as in this example). **API Usage Notes:** All monetary values are typically given in SOL or in smallest units (LAMPORTS for SOL, or smallest $POLYPUMP unit if applicable). In the examples above, we used floating numbers for readability, but actual API might use strings or integer values (e.g., `"15000000000"` lamports for 15 SOL) to avoid floating-point issues. The Polypump API is versioned (hence v1 in the base path), and future changes (v2, etc.) might introduce more complex query capabilities, multi-currency support improvements, and endpoints for historical data or leaderboard stats. Always check the latest API documentation for up-to-date information on parameters and responses. # Community & Support Building a strong community is crucial for Polypump’s success, as the platform’s value comes from active users and their collective wisdom in predictions. There are several channels available for support, feedback, and discussion: * **Telegram Community:** Join the Polypump community on Telegram to discuss market ideas, share tips, and get help. (For example, the **Polypump Official Chat** is available at `t.me/polypumpbot` – link to the actual group). In this group, you can interact directly with the development team and other users. It’s a great place to ask questions if you’re unsure how to use the platform, or to propose new features and market suggestions. The Telegram bot mentioned earlier is also often present in the chat for quick queries. * **Twitter (X):** Follow **@Polypumpfun** on X (Twitter) for announcements and updates. Official news, such as new feature releases, scheduled maintenance, or interesting market highlights, will be posted there. The team also shares educational threads on how to use Polypump effectively and retweets community content (for instance, a user’s analysis of a particular prediction market). If you create content about Polypump, don’t hesitate to tag the account – they often engage and might feature your insights. * **Developer Channels:** For those interested in the technical side or contributing, Polypump has a presence on developer communities. Code updates and technical discussions are shared via a **GitHub repository** (planned to be opened to public soon). There is also a **Discord server** in the works for more in-depth dev talk, troubleshooting integration issues, and coordinating open-source contributions. The link to join will be provided on the official channels once ready. * **Feedback and Beta Testing:** Polypump is currently in **beta**, and the team actively welcomes feedback. If you encounter bugs or have suggestions, you can report them through a GitBook feedback form or a GitHub issues page (whichever is provided). Additionally, there’s a **Beta Feedback Form** link on the docs site where early users can submit their experiences and suggestions. The developers reward constructive feedback – active beta testers might receive $POLYPUMP tokens or other perks as a thank you. * **Pump.fun Ecosystem Support:** Since Polypump is part of pump.fun, the broader pump.fun support resources are also at your disposal. The pump.fun support portal (Telegram channel soon) is a hub for general questions about the ecosystem (coin launches, bonding curve issues, etc.), and they can direct Polypump-specific questions to the right place. There’s also an official pump.fun blog and Medium where periodic ecosystem updates are posted, and Polypump is featured in those when major milestones are achieved. **Community Growth Plans:** Looking forward, Polypump aims to implement a **governance model** where $POLYPUMP holders can propose and vote on platform changes (for example, adjusting fee percentages or adding new types of markets). As the user base grows, community-driven initiatives like prediction tournaments, leaderboards (to showcase top predictors), and referral programs will be introduced to encourage growth. Educational content – such as tutorials, webinars, and possibly “Polypump University” articles – are planned to help users of all experience levels get comfortable with predictive markets. Remember, we’re all experimenting with this new form of meme coin prediction market. **Your feedback is invaluable**. Whether it’s a suggestion for a new feature or reporting a glitch in the interface, the Polypump team is listening. Join the conversation on Telegram or X, and help shape the future of predictive markets in the pump.fun ecosystem!