A Pump.fun Launch Strategy That Survives Contact
Four phases, a short list of decisions in each, and a written boundary between the parts of a launch you run and the parts nobody runs. A plan is a set of commitments with deadlines and names on them, not a prediction about how the market will behave.
What a bonding-curve launch is as a process
A Pump.fun launch strategy is an operating plan in four phases: preparation, launch day, the curve, and the period after graduation. Each phase owns a handful of decisions with real deadlines. The plan cannot decide whether anyone buys. What it decides is what you have ready, who is accountable for each call, and how you behave during the hours when nothing at all is happening.
Mechanically, a bonding-curve launchpad collapses several jobs into one transaction. You supply metadata, the contract mints a supply, and a pricing rule begins quoting immediately. There is no listing application, no market maker to appoint, no orderbook to seed. Price moves as a function of how much has been bought against the curve, and it moves in both directions with equal willingness.
That compression is both the appeal and the hazard. Because setup is cheap, most teams spend almost nothing on it, and the launch then inherits every decision they never made. Because the curve is live from the first block, there is no soft opening and no rehearsal. Whatever the token page says at minute zero is what a stranger reads and judges.
Bonding curve, plainly
A bonding curve is a pricing rule held in a contract. Each purchase moves the quoted price along a fixed path and each sale moves it back. No counterparty has to be found and nobody is quoting against you. Current thresholds and the fee schedule are published by the launchpad itself, and those are numbers to read at source rather than take from any article, including this one.
Operationally that means your work sits on either side of the contract and never inside it. Before the mint you control identity, budget, staffing and message. After the mint you control response time, honesty and pace. The curve is indifferent to all of it. Treating the curve as a participant you can persuade is the first error in a long and repetitive list.
Settlement speed shapes the day more than people expect. Solana produces blocks in well under a second, which means the first minutes of a launch generate a record faster than any human can read it. The Solana network documentation covers the mechanics. The practical consequence is that you plan what to look at in advance, because live is too late to decide.
The four phases and what each one owns
Phases are useful only if they close. A phase that stays open forever is just a to-do list wearing a better name. The test is whether some set of facts becomes fixed at the end of it. Preparation ends when the mint is signed. Launch day ends when your staffed window closes. The curve phase ends when it completes or when you stop funding it.
| Phase | Decisions it owns | Fixed when it closes | Still open afterwards |
|---|---|---|---|
| Preparation | Identity, wallet policy, budget ceiling, staffing rota, abort conditions | Name, ticker, image, supply, the mint signature itself | Description edits where the launchpad allows them, social accounts, positioning |
| Launch day | Running order, opening position, who answers what, publishing sequence | Your first impression and the shape of the early holder list | Community handling, later buying, follow-up communications |
| The curve | Spend pacing, whether to keep funding, when to stop | How much of the budget is committed and unrecoverable | Whether the curve completes, and on what timescale |
| After graduation | Pool handling, reporting rhythm, the week-one plan | The migration event and the liquidity arrangement it creates | Everything about how the token trades from that point on |
Preparation is the only phase where mistakes are cheap, which is exactly why it gets skipped. Everything in it is reversible until the mint transaction lands, and almost nothing is reversible afterwards. The sign-off discipline for that phase is set out in the pre-launch checklist, which groups the work by owner rather than by topic so nothing sits in the gap between two people.
Launch day owns the running order and very little else. It is a production job: publish in a fixed sequence, watch a fixed set of screens, answer in a fixed voice. The launch day timeline lays that out hour by hour. What matters for the strategy document is simply that the day has a start, an end, and named people awake at both.
The curve phase is where discipline is tested, because it is mostly waiting. The decisions available to you are narrow: keep spending on the plan, pause, or stop. New decisions invented under pressure are almost always worse than the ones written down while calm. If a curve goes quiet, the honest sequence is diagnosis before spending, not the reverse.
The fourth phase only exists if the third one completes, and it may not. That is not pessimism, it is scheduling. Work that assumes graduation should be written but not paid for in advance, and the mechanics of the migration step are covered in planning for graduation. A plan that has no branch for a curve that never completes is not a plan.
Decision ownership: who signs, and by when
Most launch failures are not analytical failures. They are ownership failures: a decision that everyone assumed someone else had made, discovered as a gap at the worst possible moment. The cure is boring and effective. Write each decision down once, give it a deadline relative to mint, and put one name against it. Consultation is welcome; ownership is singular.
| Decision | Phase | Deadline | Accountable | If it is not made |
|---|---|---|---|---|
| Final name, ticker and image | Preparation | 48 hours before mint | Identity owner | The mint is postponed; these fields do not get a second attempt |
| Wallet and key policy | Preparation | 48 hours before mint | Treasury owner | Funds move from an unagreed wallet and the record becomes unreadable |
| Budget ceiling and its lines | Preparation | 24 hours before mint | Treasury owner | Spending becomes reactive and the ceiling is discovered by hitting it |
| Publishing sequence and copy | Preparation | 24 hours before mint | Comms owner | Copy gets written live, in public, under time pressure |
| Staffing rota for the window | Preparation | 24 hours before mint | Launch lead | Coverage collapses in hour three and questions go unanswered |
| Opening position size | Launch day | Before the mint is signed | Treasury owner | The first number is chosen emotionally in the first minute |
| Continue, pause or stop | The curve | At each pre-set review point | Launch lead | The budget drains by default rather than by decision |
| Migration readiness | After graduation | Written before launch, executed if it happens | Launch lead | The busiest hour arrives with nothing prepared for it |
Deadlines here are relative, not calendar dates, because launches slip and a rota anchored to a date rots the moment the date moves. Anchor everything to mint. Forty-eight hours out, twenty-four hours out, two hours out, T-0. When the mint moves, the whole sheet moves with it and nothing has to be rewritten.
Put names on the sheet, not roles
Roles are comfortable and useless under pressure. Write the actual person against each line, including when that person is you three times over. A solo launch with one name repeated eight times is still an honest document, and it makes the coverage problem visible before launch day rather than during it.
One person, two people, five people
The same plan runs at three very different scales, and the difference is not ambition but what gets dropped. Every launch has four standing jobs during the staffed window: watching the chain record, answering people, publishing on schedule, and holding the money decisions. A team smaller than four is not a failure. It is a team that must choose in advance what it will not do.
- One person. You cannot watch, answer, publish and decide at once. Choose two jobs to do well and schedule the others. Publishing can be prepared in advance and released on a timer. Money decisions can be reduced to written rules so that no live judgement is required. Watching and answering are the two that genuinely need a person present.
- Two people. The first configuration that works. One holds the desk and the record, one holds the room and the replies. The money rules stay written, and the person on the desk executes them without renegotiating. Two people can also cover a longer window in shifts, which matters more than any individual skill either brings.
- Five people. Coverage stops being the problem and coordination becomes it. Five people can staff a full day, but only with one named decision maker and a single channel where decisions are recorded. Without that, you get five parallel opinions, two contradictory public messages, and a budget spent twice.
Notice what does not change with size. The decision list is identical, the deadlines are identical, and the boundary of control is identical. What changes is how many of the standing jobs can run at the same time. Scaling a launch team is a scheduling exercise rather than a capability upgrade, and pretending otherwise produces expensive, over-staffed launches that still miss the basics.
There is also a quieter benefit to naming the jobs. When a launch goes badly, teams argue about judgement when the real fault was coverage: nobody was watching at the moment something happened. A rota makes that discoverable afterwards, which is the only way a second launch is better than a first rather than merely different.
Inside your control and outside it
A plan that quietly assumes it controls demand is a wish with a table of contents. Write the boundary down before launch, in the plan itself, so that every claim you make later is disciplined by it. The list is short on both sides, which is uncomfortable but useful. Most of what determines a launch outcome sits on the second list.
- Inside your control: the metadata you submit and how carefully it was checked
- Inside your control: how much you are willing to spend and where the ceiling sits
- Inside your control: who is awake, for how long, and what they are watching
- Inside your control: what you publish, in what order, and how quickly you answer
- Inside your control: whether you correct a mistake in public or hope nobody noticed
- Inside your control: the conditions under which you stop
- Outside your control: who buys, how much, and whether they hold for an hour or a week
- Outside your control: when attention arrives, if it arrives at all
- Outside your control: whether the curve completes
- Outside your control: what the wider market is doing on the day you happened to choose
- Outside your control: what other launches are competing for the same attention that hour
Keeping those lists honest has a practical effect on language. If nobody controls whether a curve completes, then no sentence in your own communications should imply otherwise, and no tool you buy should be described to your community as though it does. The discipline is not modesty for its own sake. It is what keeps a plan usable when the second list behaves badly.
The limit of any operating plan
Everything in this document improves preparation, coverage and spending discipline. None of it produces buyers. A well-run launch with no audience still ends with a quiet curve, and a badly run launch with an audience can still complete. Planning narrows the range of self-inflicted outcomes; it does not move the market, and any framing that suggests it does is selling something.
Reading activity on a live curve
Once the curve is live, the only honest source of truth is the chain record. Every buy and sell against the curve is a transaction with a signature, a signer, an amount and a slot. Front ends summarise that record with a delay and with opinions baked in. Reading the record directly is slower, and it is the only way to know what actually happened.
What you are looking for is narrow. How many distinct addresses have interacted with the curve, how much each of them committed, whether buying is arriving in a steady trickle or in one burst, and whether the same handful of addresses accounts for most of the movement. A block explorer such as Solscan shows that at the transaction level without interpretation.
Because activity is visible, an industry of tools exists that points at live curves and routes trades through them. A Pump.fun volume bot is the common example: software that executes buys and sells across multiple wallets so that a curve shows recorded trading activity rather than a flat, empty record. It is worth being precise about what that is and is not.
Such tooling produces transactions. Transactions are real, they cost fees, they appear in the record, and they change the chart. What they do not produce is demand. Nobody is obliged to arrive because a chart is busy, the tool does not decide whether the curve completes, and the money spent on activity is spent whether or not a single independent buyer follows. Treat it as a line in a budget with an uncertain return, not as a mechanism.
The reading discipline matters more than the tooling question. Set, before launch, the two or three things you will actually check and the interval at which you will check them. Anything else is refreshing a page. How to interpret what you find when the record is thin is the subject of the desk triage material, and it starts with diagnosis rather than spending.
The category of automated market activity
Step back from any single product and the category is easy to describe. Automated market activity on Solana means software holding keys to a set of wallets, submitting trades against a venue on a schedule or a pattern, and paying network fees to do so. It is legal, ordinary, widely used, and frequently oversold by the people selling it.
The honest case for it is narrow but not zero. A completely flat record tells a visitor nothing, and some teams want a live venue to look live while they do the actual work of finding an audience. Vendors in the space, including services marketed as Solana volume automation, sell exactly that: routed trades, spread across wallets, at a pace you configure.
The dishonest case is everything beyond it. Automated activity does not create interest, does not attract holders, does not decide whether a curve completes, and does not change what your token is. It converts SOL into recorded transactions and fees. If you buy it, buy it with that sentence in front of you, size it as a fixed line in the budget, and never let it substitute for the parts of the launch that involve talking to people.
There is a second-order cost that vendors rarely mention. Activity generated by a small set of related wallets is visible to anyone reading the chain, and readers of a holder list draw conclusions from concentration whether or not those conclusions are fair. The distribution question is a real one, and the desk covers it separately, but the short version is that the record is public and permanent.
What none of this changes
No tool in this category removes the central uncertainty of a launch, which is whether anyone else turns up. If a plan only works when the tooling works, it is not a plan. Write the version of your launch in which you spend nothing on automation at all, and make sure that version is still coherent before you consider adding it.
Deciding what done and stop mean
Two definitions belong in the plan before the mint, and almost nobody writes them. The first is what done looks like, so you can recognise a finished launch instead of drifting into an indefinite one. The second is what stop looks like, so that ending is a decision you make rather than a state you arrive at when the money runs out.
- Write the done condition as an observable event, not a feeling. Examples: the staffed window has closed and the handover note is written; the curve has completed and the migration steps have been executed; the week-one reporting rhythm has started.
- Write two or three stop conditions with numbers attached to your own budget, not to the market. A spend ceiling reached is a stop condition. A staffed window ended with no change in the record is a stop condition.
- Write one factual stop condition that overrides everything else: a material error in what you have published that cannot be corrected. That one is not about money.
- Name the person who calls each condition. It should be the same person for all of them.
- Agree in advance what the team does after a stop is called: what is said publicly, what is written internally, and what is preserved for the next attempt.
- Store the document where every person on the rota can open it during the window, not in the launch lead private notes.
Stop conditions written in advance do a specific job. In the middle of a slow curve, every instinct pushes toward spending more to change the picture, and that instinct is at its strongest exactly when your judgement is at its weakest. A written ceiling is the only reliable defence, because it was set by a calmer version of the same person.
Done conditions do a quieter job. Without one, a launch never formally ends; it just becomes a background source of guilt and unplanned spending for weeks. Declaring a launch finished, internally, on the terms you set in advance, is what makes it possible to review it honestly and start the next one from something other than a shrug.
Both definitions belong to the preparation phase, alongside the rest of the material collected in the preparation hub. They cost an hour to write and they are the two lines of the plan most likely to be referred to under pressure. Everything else on the sheet describes what you intend to do; these describe when you are allowed to stop doing it.
An illustrative budget and time example
Numbers here are illustrative and chosen only to show how the arithmetic fits together. They are not a recommendation, they are not benchmarks, and they carry no claim about what any amount achieves. Substitute your own figures. The point is the structure: a ceiling divided into named lines, each with a rule attached, decided before the mint rather than during the curve.
As an illustration, suppose a team of two sets a ceiling of 40 SOL and a staffed window of six hours. The ceiling divides into five lines: 12 SOL for the opening position, 8 SOL held for the staffed window, 6 SOL held back for the migration step if it ever arrives, 4 SOL for network fees and failed transactions, and 10 SOL left untouched as the line they do not spend.
| Marker | On the desk | Money rule in force | Cumulative committed |
|---|---|---|---|
| T-2h | Both awake. Copy already written and queued. Wallets funded and confirmed. | Nothing spent beyond funding transfers | 0 SOL |
| T-0 | Mint signed. Publishing sequence released in its fixed order. | Opening position executed at the pre-agreed size | 12 SOL |
| T+1h | Person A on the record, person B answering. First review point. | Up to 4 SOL of the window reserve may be used | 12 to 16 SOL |
| T+3h | Shift change. Handover note written even if nothing has happened. | Second review point; remaining 4 SOL of reserve unlocked or not | 12 to 20 SOL |
| T+6h | Window closes. Continue, pause or stop is called and recorded. | Fee line reconciled; 6 SOL migration contingency stays untouched | up to 24 SOL, plus fees |
| T+24h | Review against the done and stop conditions written before launch. | 10 SOL untouched line remains untouched by definition | ceiling not exceeded |
Check the arithmetic, because a budget that does not add up is worse than no budget. The five lines total 12 plus 8 plus 6 plus 4 plus 10, which is 40. The maximum that can be committed inside the staffed window is 12 plus 8, or 20 SOL, plus whatever the fee line absorbs. The remaining 16 SOL is not available to a decision made at hour four.
That last constraint is the entire value of the exercise. The 10 SOL untouched line exists to be argued about at hour five and to survive the argument. The 6 SOL contingency exists because the busiest hour of a launch, if it comes, is the one where you have the least time to think about funding. How to size lines like these against your own circumstances is worked through in budgeting the curve.
- PHASES
- Four, each closing on a fixed set of facts rather than a feeling
- DEADLINES
- Relative to mint, so the sheet survives a slipped launch date
- OWNERS
- One name per decision, repeated names allowed on a solo launch
- CEILING
- Set before the mint, divided into named lines, never renegotiated live
- OUTSIDE CONTROL
- Who buys, when attention arrives, whether the curve completes
- SOURCE OF TRUTH
- The chain record, read directly, at intervals decided in advance
Read the plan once more the day before the mint, out loud if you can stand it. Anything you cannot say plainly is either not decided or not true. What remains should be a short document that a tired person can follow at hour five, which is the only test of an operating plan that has ever mattered.
Questions the desk is asked
What is a Pump.fun launch strategy?
It is an operating plan covering four phases: preparation, launch day, the curve, and the period after graduation. Each phase owns a small set of decisions, each decision has a deadline and a named owner, and the plan states in writing which outcomes are outside anyone control. It is a schedule of commitments, not a forecast.
How far ahead should preparation start?
Long enough that nothing on the sign-off sheet is being written on mint day. In practice that means the identity work, the wallet policy, the budget ceiling and the staffing rota are all settled and reviewed while there is still time to change your mind cheaply, because after the mint several of those fields are permanent.
Can a launch plan make a curve complete?
No. Whether a curve completes depends on how much buying arrives, and buying is a decision made by strangers. A plan improves how prepared you are, how quickly you answer, and how carefully you spend. It does not create demand and no honest operator will tell you otherwise.
How many people do you need to run a launch?
One person can run a small launch if they accept that some jobs will be dropped. Two people is the first configuration where the desk can stay staffed while someone answers questions. Beyond about five, coordination cost grows faster than coverage, and the plan needs a single named decision maker to stay coherent.
What should the budget cover?
Treat the budget as a ceiling with named lines rather than a pot you dip into. Typical lines are the opening position, a reserve for the staffed window, a contingency held back for the migration step, and an allowance for fees and failed transactions. The arithmetic behind each line is covered in the budgeting article.
When should a launch be stopped?
When a written stop condition is met. Deciding those conditions in advance is the point, because the moment you need them is exactly the moment your judgement is worst. Common conditions are a spend ceiling reached, a staffed window ended with no change, or a factual problem in the token page that cannot be fixed.
Does Launch Desk have any relationship with Pump.fun?
No. Launch Desk is an independent editorial desk. It has no partnership, no affiliation and no privileged access to any launchpad. Protocol behaviour described here comes from public documentation, and current thresholds and fee schedules should be read at the launchpad itself rather than taken from an article.
Filed in Preparation by The Launch Desk. Protocol behaviour on this page is described from public documentation; every figure that is not a protocol fact is labelled illustrative. How the desk handles numbers and corrections is set out in the editorial policy.