Current status

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.

PrepareDeploy a deterministic router with the permanent 70% creator / 30% shared-pool route.

LaunchCall the official Pons V2 factory directly and name that router as creator-fee recipient.

RegisterVerify the Pons deployer and recipient, then create this token's holder pool and enter it into the race.

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.

One shared reward pool

There are no selectable reward modes, votes, locks or vaults. Every registered launch follows the same rule.

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.

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. Official addresses will be added after they are finalized and reviewed.

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.