How the launch becomes an intent.

Every coin launched here mints on pump.fun's bonding curve exactly like any other pump coin. It trades on pump.fun, on aggregators, and on the AMM after migration. Nothing about the token is different.

What is different is who launched it. On pump.fun the launcher's wallet is the fee payer and the creator, visible forever. On nearlaunch the fee payer and creator is a launch wallet that receives its SOL through a NEAR Intent and has no other history. The payment that funded it happened on whatever chain you chose, to a one-time deposit address, and is joined to the mint only inside the intent.

A bridge moves an asset. An intent moves an outcome. That distinction is what makes the launch private and what makes it work from anywhere.

1Click, the distribution API on top of intents.near, takes a request of the form "deliver exactly N SOL to this Solana address, paid in X on chain Y" and returns a one-time deposit address. A network of solvers competes to fill it. The best fill settles on Solana. The deposit on chain Y and the delivery on Solana are separate transactions from separate parties; the only record that ties them together is the intent itself.

For a launchpad that means: pay from a Bitcoin wallet, from an exchange withdrawal, from a shielded Zcash pool, from USDC on Base. It also means the SOL that mints the coin was never in your Solana wallet, because you do not need one.

Six steps, all visible on the session page as they happen.

If you close the tab, nothing stops. A keeper process watches every open launch and runs the mint the moment a wallet is funded. Return to the session link at any time; it is the only key to the session.

The form lists the assets 1Click can move. The catalogue is reconciled with the live token list, so anything solvers stop supporting drops off automatically.

Shielded Zcash is the strongest option: a payment from the shielded pool has no visible sender at all. Bitcoin and EVM chains are pseudonymous; the deposit is visible on that chain but unconnected to Solana. SOL from another wallet also goes through the intent: you pay a one-time deposit address and a solver, not your wallet, funds the launch wallet. Solvers do quote SOL for SOL, at roughly one percent all in. Only if that quote is refused does the site fall back to a direct deposit into the launch wallet, and the session page says so.

Every quote needs a refund address on the paying chain. If solvers cannot fill within the window, or you sent less than quoted, the deposit is returned there.

Each launch derives a keypair from the operator's keeper secret and a random per-launch salt. The salt lives on the launch row and never leaves the server; the keypair is recomputed whenever it has to sign. No private key per launch is ever written anywhere.

The launch wallet plays every role a launcher's wallet would:

It is your wallet. If a wallet was connected when the launch was opened, that wallet owns the launch: sign a short message on the session page and the launch wallet's private key is shown to you, once. Import it into Phantom or any Solana wallet and the dev buy and the creator fees are yours to move directly. Without a connected wallet, the claim secret exports the key the same way.

Be precise about what this does and does not hide.

What the operator holds: the launch row, including the deposit address and the refund address you typed, and the keeper secret that derives every launch wallet. That is the trust in the system. The operator can see which chain paid and where refunds would go; they cannot see a shielded Zcash sender either. The claim secret is stored only as a hash.

What 1Click holds: the intent, the deposit and the delivery. Read their documentation for their data practices.

pump.fun credits 30 basis points of every buy and sell to the coin's creator, on the curve and on the AMM after migration. Here the creator is the launch wallet, so the fees accrue to a vault only that wallet can claim.

At launch you are shown a claim secret, once. It looks like nl_…. Presenting it on the creator fees page is the whole proof of ownership. A payout:

1. 1. Collects the vault into the launch wallet (collect_creator_fee).
2. 2. Quotes an EXACT_INPUT intent: that SOL, to the asset and address you name.
3. 3. Sends the SOL from the launch wallet to the one-time deposit address.
4. 4. Marks the payout settled when the destination chain confirms.

The launch wallet must receive enough SOL for the mint, the network, a small reserve for later fee collection, and the initial buy. The funding intent is EXACT_OUTPUT on this total.

If solvers deliver slightly less than the total, the initial buy shrinks to fit rather than failing the launch. If they deliver less than the fixed total, the launch waits as funded for the keeper or an operator to resolve it.

The repository is a Next.js app plus one keeper process. Copy .env.example, run supabase/schema.sql, generate a keeper key with pnpm keeper:init, and run pnpm keeper next to the site. The README covers each variable.

The keeper secret is the root of custody. Every launch wallet, every funded-but-unlaunched balance, and every coin's creator fees derive from it. Back it up before the first launch, and never reuse it across deployments.

/admin lists every launch in every status with its wallet balance and unclaimed fees, and can retry a failed mint, hide a coin, or sweep a wallet to a Solana address.