What Does a Failed Token-Launch Trade Really Cost?

The signal

The documented mechanics reject a simple successful-trades-only return calculation. Solana explicitly warns that sendTransaction success does not guarantee processing or confirmation. Ethereum charges for computation even when execution fails. Those rules make failed attempts an economic input, not merely a reliability statistic. [2] [5]

Classify the outcome before assigning a fee

Solana’s sendTransaction reference says an accepted RPC request returns a signature immediately and does not guarantee that the cluster processes or confirms it. Preflight simulation is a separate check, and a transaction can expire before landing. A signature displayed by a bot is therefore a tracking reference, not proof of a fill. [2]

For accounting, distinguish a local or preflight rejection, an acknowledged but unresolved submission, a transaction known not to have landed, an included execution failure, and an included success. These states should not share a single failed-trade cost assumption. An unresolved submission also should not be relabelled free merely because a first lookup returns nothing.

The getTransaction documentation says a null response can mean the transaction is not found or not confirmed at the requested commitment. That uncertainty belongs in the evidence record until it is resolved. It is different from a confirmed error and different again from a confirmed token acquisition. [3]

A useful receipt links the attempt ID, signature, route, quote time, submission time, status query and final outcome. If one trading intention generates several distinct signed transactions, retain each. If the same signed transaction is merely rebroadcast, do not automatically count every network request as a new on-chain execution fee. The bill follows what was charged, not the number of lines in a bot log.

A fee ceiling is not the same as the fee paid

Solana’s fee documentation gives a current base charge of 5,000 lamports per signature and explains that a fee is charged when an executed transaction fails. For legacy and v0 transactions, the priority fee uses the requested compute-unit limit multiplied by the price per unit, rounded into lamports. The reviewed page separately describes a v1 format with an absolute priority-fee field. Record the format before applying the formula; this is a documentation distinction, not a claim that every route uses the same version. [1]

For an explicitly hypothetical legacy/v0 example, one signature, a 300,000-unit limit and 10,000 micro-lamports per unit imply a 3,000-lamport priority fee and an 8,000-lamport combined fee. Those input settings are not recommended market bids. Raising a limit is not costless simply because the program eventually consumes less than that allowance.

Ethereum’s gas overview describes the charge as gas used multiplied by the unit price, including failed execution. EIP-1559 distinguishes the fee cap from the effective gas price and returns unused gas. It is therefore incorrect to treat the maximum authorised gas budget as the observed bill for every reverted transaction. [5] [6]

The cross-chain lesson is about accounting discipline. Use the confirmed fee for an observed transaction and identify the applicable rule for a scenario. Do not compare a Solana base fee with an Ethereum maximum budget or leave tips out of one side. Convert native-token costs into the same reporting currency at an explicitly stated time.

Routing changes the contract you are relying on

Jito’s Block Engine documentation describes bundles that execute atomically and says that receipt of a bundle ID does not guarantee landing. It also discusses cases in which transactions from uncled blocks can be rebroadcast outside the original bundle, weakening assumptions about atomic handling. A product label such as revert protection is not a substitute for reading the route’s stated conditions. [7]

The current Jito documentation distinguishes Block Engine submission from Direct Bundle Ingest. The latter has separate allowlisted access and its own auction path. Its page says there is no minimum tip, while the Block Engine low-latency page states a 1,000-lamport minimum for bundles. These are different interfaces, not a reason to select whichever statement makes a cost estimate look smaller. [7] [8]

The practical question is which path the bot actually used. Record service charges and tips that were paid, including any separately landed transfer, instead of assuming that all unsuccessful intentions cost zero. Conversely, do not charge a hypothetical on-chain tip to an unlanded attempt without evidence that the transfer occurred.

A stronger route may reduce a particular failure mode, but its economic value remains conditional. It can still lose an auction, miss the intended price or buy a position that cannot be exited profitably. This review did not compare providers’ measured inclusion rates and does not endorse a route as fastest, safest or most profitable.

Slippage tolerance trades one failure mode for another

Jupiter’s current slippage documentation defines slippage in relation to quoted and received output and explains that its estimator works at order time, not at execution time. The documented routing paths have different ways of selecting tolerance. That is useful evidence about the decision point; it is not a promise that the quote remains available when the transaction lands. [9]

A narrower minimum-output condition can reject a deteriorated trade. That rejection may still carry an execution fee if it occurs on-chain. A wider tolerance may allow more transactions to complete, but it also permits a worse acquisition price. A higher success rate can therefore accompany poorer economics. Success must mean the desired economic result, not simply the absence of an error.

The correct comparison holds the intended trade size and opportunity set constant. Track the tokens actually received, the fees of failures, the time until the position is established and the attainable exit. Comparing only successful fills under two settings systematically hides the rejected attempts in the stricter policy.

There is no universal optimal tolerance in this article. The right choice depends on liquidity, price movement, the cost of failure and the value of declining a bad trade. For a token with no credible exit, reducing the chance of a failed buy may solve the wrong problem. Automation should make that trade-off observable rather than treating every completed purchase as an improvement.

A £100 purchase can require more than £100 of sale value

The calculator models one completed acquisition cycle. Its hypothetical inputs are £100 paid for 1,000 tokens, £2 of successful-entry network and service charges, three included failures costing £0.40 each, two unlanded attempts with £0.05 of external service cost each, and £0.50 of other allocated cost. The acquisition cycle therefore costs £103.80. These are synthetic cash assumptions, not current chain prices or a measured launch sample.

At an assumed executable sale price of £0.11 per token, gross exit value is £110. A 1% sale charge and £1 fixed exit expense leave £107.90. Net profit is £4.10, or approximately 3.95% of the £103.80 acquisition outlay. The apparently simple 10% rise from £0.10 to £0.11 is not the return earned on the whole cycle.

The break-even gross exit price is approximately £0.105859 per token. It solves for the sale value needed to recover acquisition outlay and the fixed exit cost after the proportional sale charge. If included failures rise from three to ten at the same £0.40 average, acquisition outlay rises to £106.60 and profit falls to £1.30 at the same exit. No probabilities are assigned to either case.

If there are no retries, no service expenses and no sale fees, the calculation reduces to the familiar price-change result. That is a useful boundary check. It does not establish that those costs are absent in practice. The tool rejects zero tokens received because its break-even question concerns a completed acquisition; a cycle with no purchase should instead report its paid attempts as a standalone loss.

Reconstruct the ledger without counting costs twice

Solana’s documented transaction metadata includes an error field, a fee field, and pre- and post-transaction token balances. These provide building blocks for a receipt-based audit, subject to metadata availability and the response mode. A quoted output belongs beside those observations; it should not replace them. [4]

Separate token purchase consideration from network fees, routing charges and other transfers. If a swap quote already incorporates pool fees, subtracting those fees again from the realised token amount would double count them. The calculator asks for the tokens actually received and for costs not already embedded in the purchase or exit price. A user working from an all-in net sale quote should not add the same percentage fee a second time.

Keep capital movements separate from expenses. A refundable balance or account deposit is not automatically a permanent fee. Likewise, transfers between your own wallets are not trading losses. Reconcile the total wallet changes with the intended position and explicitly mark amounts whose eventual recovery remains uncertain.

For a strategy comparison, retain the full set of intentions selected before outcomes were known. Include abandoned launches and cycles with no purchase. Report missing receipts rather than estimating them as zero. A complete ledger can still show an attractive result, but it earns that conclusion by including the costs that a successful-fill screenshot omits.

The decision is whether another attempt is still worth making

Past fees are already incurred; they should be included when reporting total performance. They should not become a reason to keep retrying a deteriorating opportunity. The next attempt needs its own prospective comparison between the remaining executable value and its additional costs and risks. Trying to recover sunk fees can turn a bounded experiment into an open-ended purchase policy.

Before another submission, update the quote, remaining budget and exit assumptions. Ask whether the intended token amount is still obtainable, whether an exit route is available, and whether the new attempt could duplicate an unresolved earlier submission. The operational and economic checks belong together.

DN’s existing Telegram-bot article focuses on who controls the wallet and recovery. This article addresses the next layer: what the complete trade cycle cost. A sound custody model does not make a poor entry profitable, and a profitable-looking entry does not establish that signing authority is appropriate.

The independent finding is modest but decisive. Speed and inclusion are intermediate outcomes. Net proceeds after all paid attempts are the economic outcome. A launch bot deserves evaluation on that complete record, with transaction format and routing assumptions visible, rather than on a collection of purchases that happened to succeed.

The evidence, side by side

Token-Launch Attempt-Cycle Break-Even

Synthetic acquisition-cycle example. No token launch was traded or backtested.

Purchase cash and tokens received strictly positive. Counts must be integers from 0 to 100000. Other cash values non-negative; exit percentage a fraction from 0 inclusive to 1 exclusive; all inputs finite.

No inclusion probability, token-price forecast or route ranking. A cycle with no acquired tokens requires a separate paid-attempt loss record. A full exit at the entered price is an assumption unless supported by execution evidence.

Scenarios to watch

Illustrative three included failures

£103.80 acquisition outlay and £107.90 net exit proceeds produce £4.10 profit, approximately 3.95%, with break-even gross exit near £0.105859 per token.

Illustrative ten included failures

At £0.40 each, ten included failures raise acquisition outlay to £106.60. The unchanged exit then leaves £1.30 profit; no frequency is forecast.

Method and limitations

Read nine primary documents covering Solana, Ethereum/EIP-1559, Jito and Jupiter on 14 November 2026. The comparison concerns documented mechanisms and their accounting implications.

No transaction was submitted, wallet connected, live launch dataset collected or routing service benchmarked. All cost scenarios are synthetic.

The calculator separates included-failure charges from external costs of unlanded attempts, then uses actual or explicitly assumed token quantity and exit value for a completed acquisition.

Official documentation is not a live fee quote or guarantee of inclusion. Transaction versions and submission services can have different conditions.

A missing transaction response is not conclusive proof of a final unlanded outcome. Commitment level, provider coverage and missing metadata require resolution.

The tool assumes an executable full exit and excludes tax, leverage, token restrictions and unmodelled transfer effects. It does not assess whether a launch or token is legitimate.

Primary sources and evidence register

Source dates and reporting periods differ. Several documents from one issuer are one source family, not independent confirmations. The evidence download contains the observations used in this article.

Frequently asked questions

Does a failed transaction always cost money?

The answer depends on the state and route. Included execution failures can incur chain fees. A request that never lands has different economics, although external services may still charge. Do not use a single fee for every failure label.

Does a returned signature mean I bought the token?

No. Solana explicitly distinguishes RPC receipt from processing and confirmation. Resolve the status and inspect the resulting token balances. [2] [3] [4]

Should I increase slippage until the trade succeeds?

Success rate alone is an incomplete objective. A wider tolerance may permit worse pricing. Compare the added probability of completion with the resulting acquisition and exit economics; this article estimates neither probability.

Why does the calculator reject zero tokens received?

Its break-even sale price divides by an acquired position. With no tokens, there is no sale price that recovers the cycle; report paid attempt costs separately rather than manufacture a denominator.