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 logo goes to
POST /api/metadata, then the parameters toPOST /api/requests. - The keeper answers with a deposit address (its address on Robinhood Chain), an amount in ETH and a reference. The amount covers both chains: the Pons launch fee, the Robinhood Chain gas, the pump.fun creation at the current rate, and a margin.
- The creator sends the amount in ETH to that address with the reference as the transaction data, from the MetaMask address given in the request. The page then sends the transaction hash to
POST /api/requests/:id/deposit. - The keeper reads the transaction on Robinhood Chain, checks recipient, sender, reference, success and amount, and starts the pipeline. A request that gets no deposit expires after 30 minutes.
The pipeline
| Step | What happens |
|---|---|
pons_launch | HingeLauncher.launch on Robinhood Chain launches the coin on Pons with a dedicated HingeVault as creator fee recipient. The creator's deposit pays the 0.0005 ETH launch fee |
pump_create | The keeper wallet creates the coin on pump.fun with create_v2, same name, ticker and logo |
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
| Hinge 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 Hinge |
| 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 |
| 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.