Fee models across Solana launchpads, compared

Launchpad fees come in six components: primary trading fee, creation cost, migration deduction, creator revenue share, destination pool fee and network cost. The venue sets four of them. Comparing venues on the headline trading percentage compares one component out of six, and it is not the component with the largest effect on a token after its primary phase ends.

Six places money leaves a launch

The reason fee comparisons go wrong is that the components are different in kind. Some are charged per trade, some once, some as a share of a total, and some accrue continuously after the launch is over. Adding them requires knowing how much trading occurred, which is unknowable in advance, so any single number quoted as the cost of a launch is either an estimate with hidden assumptions or a marketing figure.

The primary trading fee

This is the number venues put on their landing pages: a percentage taken from each buy and each sell during the curve phase. It is the easiest component to understand and the easiest to over-weight in a comparison, because its total depends on a quantity nobody controls.

The key property is that it compounds against the number of trades rather than against the amount raised. A curve that reaches its graduation condition through one large purchase pays the fee once. A curve that reaches the same condition through a thousand purchases and several hundred sells pays it on every one of those legs, and the total can be a multiple of the first case despite an identical raise.

Symmetry is worth checking rather than assuming. Several venues charge the same rate on buys and sells, some charge only on one side, and a few apply a different rate to each. The documentation is not always explicit and the transaction always is, so a single completed sell settles a question that could otherwise be argued about for an afternoon. The direction that is charged more is also the direction the venue would prefer you traded less, which is occasionally informative about how a venue thinks about its own market.

That has an obvious consequence for anyone deliberately producing activity. A round trip is two legs, so a strategy that buys and sells to generate turnover pays the venue fee twice per round trip and returns approximately to where it started in price terms. Teams evaluating a Solana volume bot for a curve-phase campaign should be modelling exactly that: fee per leg, legs per round trip, round trips required, and nothing about notional turnover, which is an output rather than a cost.

Creation cost and what it selects for

What it costs to bring a token into existence on a venue is usually small, sometimes near zero, and occasionally the most consequential parameter on the list - not for the creator's budget but for the venue's character.

A venue with a negligible creation cost carries an enormous number of launches, because there is no filter. That is a discovery problem rather than a cost problem: the token competes for attention against everything else created that hour, and the discovery surface becomes the binding constraint on visibility. A venue with a meaningful creation cost carries fewer launches and each one has a larger share of the surface.

Neither arrangement is better. They select for different things, and a team should know which selection pressure it is walking into. The creation cost also normally includes rent deposits for the accounts that have to be created, which are refundable in principle if the accounts are ever closed and are frequently mistaken for a fee.

The migration deduction

This is the component with the largest downstream effect and the least prominence in any venue's own material. When the primary phase ends, the accumulated quote reserve is deposited into a destination pool. Some venues deposit all of it. Some retain a portion. Some route a portion to a treasury or to a partner.

Whatever is retained is depth the destination pool never receives. That is not a one-off cost paid by the creator; it is a permanent property of the market the token wakes up in. A pool seeded from a reduced reserve moves further on the same order, produces worse fills for every subsequent trader, and shows a shallower depth profile to anyone assessing the token.

The retention also interacts with the graduation condition in a way teams rarely anticipate. If the condition is denominated in accumulated reserve, and a portion of that reserve is deducted before deposit, then the pool is seeded with less than the threshold that triggered the migration. The number people quote as the graduation level and the number that actually reaches the pool are different numbers, and the gap is a parameter.

The creator revenue share

Several venues route some portion of a fee stream to the account that created the token, sometimes only during the primary phase and sometimes continuing afterwards. Mechanically this is a routing rather than an additional charge: the trader pays what they pay, and the venue splits it differently.

Narratively it is not small at all. A continuing creator share is visible on chain to anyone who looks, and it is read as a statement about incentives. One reader sees alignment, because the creator now benefits from a token that keeps trading rather than from a single exit. Another sees an incentive to manufacture churn. Both readings are defensible and a team does not get to choose which one its audience adopts.

The practical advice is only this: know whether the venue you chose has this feature, know whether it continues past graduation, and be able to explain the arrangement in one sentence when somebody asks. Being surprised by your own fee routing in public is a worse outcome than either interpretation.

The fees no launchpad controls

Transaction fees, priority fees and rent deposits belong to the protocol and its validators. No venue sets them, no venue receives them, and they are assessed identically regardless of which launchpad a transaction touches. The mechanics are set out in the Solana documentation.

For a single launch these are a rounding error. For any programme that submits many transactions they are not, because they scale with transaction count rather than with value. Priority fees are the volatile component: during periods of congestion the fee required to land promptly rises, and a strategy calibrated during a quiet period will behave differently during a busy one.

Rent deposits deserve a separate mention because they are consistently misread as costs. Creating an account on Solana requires a deposit proportional to the account size; the deposit is held, not spent, and is returned if the account is ever closed. A launch that creates several accounts has committed capital, not consumed it.

Two arrangements on one launch

Who actually pays each component

Fee incidence is not the same as fee payment, and conflating the two produces bad decisions. The creator pays the creation cost directly. Traders pay the primary trading fee directly. But the migration deduction is paid by nobody in particular and borne by everyone who trades the token afterwards, in the form of worse fills against a thinner pool.

The creator revenue share is the mirror image. It is paid by traders and received by the creator, but because it is carved out of a fee the trader was already paying, its incidence is on the venue's own revenue rather than on the trader. That is why venues can offer it without raising the headline rate.

• Creation cost: paid by the creator, borne by the creator.
• Primary trading fee: paid by traders, borne by traders, sized by trade count.
• Migration deduction: paid from the reserve, borne by every future trader through depth.
• Creator share: paid by traders, borne by the venue's revenue split.
• Destination pool fee: paid by swappers, borne partly by liquidity providers through the price they face.
• Network cost: paid by whoever signs, borne by whoever signs.

Verifying a fee model from the chain

1. Open a completed primary buy for a token on the venue in a block explorer such as Solana Explorer and read the balance changes rather than the summary.
2. Compare what left the buyer with what reached the reserve. The difference is the fee, expressed in the unit that was actually charged.
3. Identify the receiving account and check whether it is a venue account, a creator account, or split between them. This settles the creator share question directly.
4. Repeat on a completed sell, because several venues charge asymmetrically and the documentation does not always say so.
5. Open a completed migration for a graduated token on the same venue and compare the reserve immediately before it with the amount deposited into the destination pool. The gap is the migration deduction.
6. Check the destination pool's own fee tier, which belongs to the AMM and is a separate charge from anything the launchpad applies.

Comparing fee models honestly

An honest comparison states its assumptions and shows its working, which sounds obvious and is almost never done. The reason is that the honest version produces a range rather than a number, and a range is harder to put in a table. A venue is cheaper under some trade counts and more expensive under others, and where the crossover sits is the only genuinely interesting output of the exercise.

• Compare all six components or say plainly which ones you left out.
• State the trade count you assumed, because the trading fee total is meaningless without it.
• Treat the migration deduction as a permanent change to the destination pool, not as a one-off charge.
• Separate what the venue charges from what the destination AMM charges after graduation.
• Keep rent deposits out of the fee total; they are committed capital, not expenditure.
• Date the comparison, because every rate in it is a setting somebody can change.

Fee models are revised, and quietly

Every fee parameter described here is held by whoever operates the venue. Several venues have adjusted their rates, their splits or their migration treatment since launching, sometimes with an announcement and sometimes not. A page that printed current values would be a document that stops being true without ever saying so.

The defensive habit is simple. When a fee matters to a decision, read it from the venue on the day, and read a completed transaction to confirm the venue is doing what its documentation says. Those two checks take fifteen minutes and are the difference between knowing a fee model and remembering one.

The comparative habit is just as simple. Ask which component a venue is quiet about. Venues do not hide their competitive numbers; they hide the ones where they are not competitive, and the silence is a reliable indicator of where to look next.

Questions this desk is asked