PONS V2 LAUNCHPAD
Launch a coin. Enter the shared reward race.
Ponsium launches through Pons V2, verifies the result onchain and sends a fixed part of every launch's creator-fee revenue into one shared pool. The strongest fee-producing launches win rewards for their token holders.
Current status
The project token and temporary launchpad trial are live on Robinhood Chain. The contracts pass local lifecycle tests and the live trial has verified launch registration and fee routing, but they have not received an independent audit or production approval.
How a launch works
The normal flow uses three visible transactions. This keeps the user as the deployer recorded by Pons V2 and makes the reward route independently verifiable.
If registration is interrupted, the token still exists and the same verified campaign can be registered later. Fees already received remain in its deterministic router.
Trading-fee routing
Pons V2 creates the market and accrues its creator-fee stream. Its escrow credits the launch's LaunchFeeRouter. Anyone can trigger a harvest; only assets received during that escrow claim count, and the caller cannot change the split or recipients.
- 70% is credited to the coin creator and stays withdrawable only by that creator.
- 30% enters the shared pool under the launched token's identity.
- The split is fixed in contract code and is identical for every registered launch, including the foundation coin after bootstrap.
- Native ETH and each ERC-20 quote asset are accounted for and ranked separately.
- The router cannot spend holder funds or choose a winner.
The router divides only creator-fee revenue that Pons V2 actually sends to it. It does not take unrelated token revenue or control Pons's own protocol share. Amounts shown as “this epoch” are based on fees received by the shared pool during that epoch.
One shared reward pool
There are no selectable reward modes, votes, locks or vaults. Every registered launch follows the same rule.
Real fees enter
Each router labels its 30% contribution with the exact token that produced it.
Input: received creator-fee revenueTop three win
For each reward asset, the contract continuously ranks the three largest launch contributions during the 30-minute epoch.
Rule: no voting or manual choiceHolders receive
After the epoch ends, anyone can finalize it. The pot is divided among the top three in proportion to their winning contributions.
Destination: each winner's holder poolRank is based on revenue received by the pool during the epoch, not advertised volume. A delayed harvest counts when it is received. Production automation should harvest regularly so timing is consistent.
Holder payouts
Epoch finalization funds the winning token's holder pool. A snapshot service reconstructs launched-token balances at a finalized block. The publisher signs the cumulative Merkle root once; after the review delay, a restricted keeper automatically activates that exact root and submits payouts directly to holders. Holders and publishers do not need to return for activation or claims.
A reward comes only from fee revenue that arrived. Low trading means low rewards; losing an epoch means no reward from that epoch. Holding a token never guarantees profit.
Snapshot and payout rules
- Snapshots use a finalized historical RPC block, not the live balance at claim time.
- The public manifest records that external RPC height. It is not compared with Solidity's
block.number, because Arbitrum-based chains can use different RPC and execution block-number namespaces. - Holder weight is the launched-token balance at the published snapshot block.
- Each holder receives floor(new rewards × holder balance ÷ total eligible balance). Rounding dust stays funded.
- Leaves include chain ID, distributor, pool, reward asset, account and cumulative amount, then are double-hashed.
- A proposed root waits through the configured review delay before permissionless activation.
- Each proof pays only the proven account unless that holder explicitly redirects their own payout.
- A sponsored batch is capped at 80 claims and skips failed recipients without blocking valid holders.
Root publisher trust
The contract proves a claim belongs to an activated root and aggregate payouts cannot exceed funded allocation. It cannot independently enumerate every ERC-20 holder. The root publisher could omit or misweight a holder, so manifests must be public, reproducible and governed by a separated multisig.
Wallet connection
Privy provides the wallet-only connection interface. The preferred list includes Rabby, MetaMask, Coinbase Wallet and other compatible wallets.
- The site asks only for a public account during connection.
- The site never asks for a private key or seed phrase.
- Connecting alone does not launch a token or move funds.
- Every signature or transaction appears separately inside the wallet.
Contracts
The contract system is part of these docs rather than a separate product page. Each module has one narrow job, and the live trial addresses should be treated as unaudited test infrastructure.
Important public functions
Permissions
- Creators can withdraw only their own recorded 70% balance.
- Anyone can harvest fees and finalize an ended round; callers cannot redirect rewards.
- The publisher can propose holder allocations only up to funding already received.
- The guardian can pause or cancel a pending root but cannot withdraw holder funds.
- The contracts have not received an independent security audit.
Important risks
- No independent audit has been completed.
- The root publisher is trusted for correct holder data even though it cannot exceed funded allocation.
- Harvest timing affects which epoch receives fees and therefore requires reliable automation.
- The Pons owner has a documented delayed override over creator-fee recipients.
- Token prices and liquidity can fall sharply.
- Trading-fee revenue is unpredictable and may be zero.
- No address should be trusted until it is published here and verified on the chain explorer.