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. Pons comes first: Robinhood Chain is home, and if anything fails afterwards the coin is left on the chain that matters most.
How a launch starts
- The creator fills the launch page. The site calls the keeper's API (
POST /api/requests) with the coin's parameters. - The keeper answers with a deposit address, an amount in SOL (the alignment buy plus a margin, at the current rate) and a reference.
- The creator sends the amount to that address with the reference in a Memo.
- The keeper finds the deposit on Solana and starts the pipeline. A request that gets no deposit expires after 30 minutes.
The pipeline
| Step | What happens |
|---|---|
pons_launch | GlintLauncher.launch on Robinhood Chain launches the coin on Pons with a dedicated GlintVault as creator fee recipient. The pool pays the 0.0005 ETH launch fee and funds the vault |
pump_create | The keeper wallet creates the coin on pump.fun with create_v2, same name, ticker and logo |
align | The keeper reads both curves and the rate and buys on the cheaper side until the two prices in dollars match |
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 the maker starts watching it |
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.
Parameter mapping
| Glint 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 pad |
| 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 |
|---|---|
| Pons launch fails | Nothing else runs, the deposit is refunded in full |
| pump.fun creation fails after Pons | The coin stays on Pons, the deposit is refunded minus the costs already spent |
| Alignment fails | The coin exists on both chains at different prices, the maker is not armed, the request is marked as needing attention and no refund is made |
| Fee sharing fails | Same: the keeper wallet stays the creator of record, the request needs attention |
| No deposit arrives | The request expires |
| A deposit below the amount | 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 band before it quotes a deposit.
- The API refuses to quote when the SOL/ETH rate sources disagree.
- Only the keeper can call the launcher.