The launch
A launch spans two chains, so it cannot be one transaction. It is a fixed sequence run by the keeper, each step a public transaction. pump.fun comes first: Solana is where the launch starts and where the deposit is, and if anything fails afterwards the coin is left on pump.fun.
How a launch starts
- The creator fills the launch page. The logo goes to
POST /api/metadata, then the parameters toPOST /api/requests. - The keeper answers with a deposit address (its address on Solana), an amount in SOL and a reference. The amount covers both chains: the pump.fun creation, the Pons launch fee and the Robinhood Chain gas at the current rate, and a margin.
- The creator sends the amount in SOL to that address with the reference in a memo instruction, from the Solana address given in the request. The page then sends the transaction signature to
POST /api/requests/:id/deposit. - The keeper reads the transaction on Solana, checks signer, recipient, memo, success and amount, and starts the pipeline. A request that gets no deposit expires after 30 minutes.
The pipeline
| Step | What happens |
|---|---|
pump_create | The keeper wallet creates the coin on pump.fun with create_v2 |
pons_launch | PivotLauncher.launch on Robinhood Chain launches the coin on Pons with the same name, ticker and logo, and a dedicated PivotVault as creator fee recipient. The creator's deposit pays the 0.0005 ETH launch fee, converted to SOL |
fee_share | Two transactions on pump.fun: create_fee_sharing_config, then update_fee_shares_v2, which fixes the shareholders once |
register | The coin is added to the keeper's list and both addresses are returned |
Every step is saved before the next one starts. A crash or a restart resumes where it stopped and never repeats a finished step. A step that fails is retried up to three times. Passes never overlap: a request already being worked on is skipped.
Parameter mapping
| Pivot field | Pons launch | pump.fun |
|---|---|---|
| name, ticker | name, symbol | create_v2 name, symbol |
| logo and metadata | logoIpfs | metadata URI |
| creator fee | creatorFeeBps | fixed 30 bps, shared |
| fee recipient | the vault, then split | sharing config: creator wallet and Pivot |
| optional Robinhood payout | creatorEvm, creatorShareBps | n/a |
Failure modes
The two chains are separate, so there is a window between the steps. Each case is a tested path of the pipeline.
| Failure | Outcome |
|---|---|
| pump.fun creation fails | Nothing else runs, the deposit is refunded in full, in SOL |
| The Pons launch fails after pump.fun | The coin stays on pump.fun, the deposit is refunded minus the costs already spent, in SOL |
| Fee sharing fails | The keeper wallet stays the creator of record of the pump.fun coin, the request needs attention |
| No deposit arrives | The request expires |
| A deposit below the amount, or from another wallet | It does not start the launch |
CarefulThe refunds and the retries are run by the keeper. They are tested, but they are a promise of the operator, not something a contract enforces. See the operator and the trust model.
What stops a bad launch
- The Pons contract checks the creator fee (at most 10 %) and the payout share (at most 100 %).
- The API rejects an invalid name, ticker, address, fee or image before it quotes a deposit.
- The API refuses to quote when the ETH/SOL rate sources disagree.
- Only the keeper can call the launcher.
- At most 12 requests and 20 uploads per hour and address.