Volume Bot Pricing Models, Compared

What you are actually buying

Almost every price page in this category is one of five structures: a flat charge for a period of time, a percentage of routed volume, a fee per transaction or per wallet, prepaid credit packs, or a share of a measured result. They differ less in how much they cost than in what makes the bill grow, and in who absorbs a transaction that fails.

Read the structure first and the number second. A rate of one percent tells you nothing until somebody names the quantity it applies to. Two operators quoting an identical percentage can produce bills that differ by half, purely because one measures attempted notional and the other measures settled notional. The rest of this page is about finding that sentence and testing it against a run you define yourself.

Why the headline price is never the price

A headline price is a rate without a base. It is the part of the expression that compresses into a large font, and systematically the part carrying least information. The full expression always has more terms than the headline advertises, and the terms left out decide what lands on your invoice.

Four omissions recur. The base is left undefined, so nobody has said whether a failed attempt counts. The floor is unstated, so a monthly minimum lands on an invoice for a run that took two days. Network costs are called small rather than separate. And the renewal term is buried, so a one-off test becomes a recurring charge.

The five ways a bill is expressed

The structures below are classes, not products. Operators combine them freely, and the most common hybrid puts a small floor subscription underneath a usage percentage, which should be read as two terms rather than one blended number. Once you can identify the class in front of you, the recombinations become readable one term at a time.

Flat subscription, charged per period

You pay a fixed amount for access over a window. Nothing in the bill responds to how much you route, how many wallets you fund, or how many transactions land. Predictability is the appeal, and this is the only structure where a heavier run costs nothing extra. A short test still bills the full period.

Percentage of routed volume

The bill is a fraction of the notional your run pushes through the venues, so cost tracks activity and a shortened run costs proportionally less. It is also the structure most sensitive to one word. Routed can mean submitted, filled, or a figure computed internally, and each reading invoices the same run differently.

Per-transaction or per-wallet fee

Here the bill is a count multiplied by a unit price. Transaction counts scale with run intensity, wallet counts scale with fan-out breadth, and the two diverge sharply: a run with few wallets and many transactions is cheap under one and expensive under the other. Both counts can be reconciled against on-chain records.

Prepaid credit packs

You buy internal units in advance and spend them as the run consumes them. Packs usually carry a volume discount, which makes the largest pack cheapest per credit and therefore the one the interface highlights. The discount is real; the assumption behind it is that you consume the whole pack.

Revenue share or performance fee

The operator takes a fraction of a measured outcome rather than a fraction of the work. This is the most attractive model on paper and the hardest to run in practice, because the outcome of a volume run is not naturally observable the way a transaction count is. Whoever defines the measurement controls the invoice.

One run, held constant

Comparing structures properly requires holding the work constant. The two runs below are illustrative assumptions, invented for the arithmetic and not observations of anything. Both of them sit inside one billing month deliberately, because that is what exposes the gap between time-based and usage-based pricing: one line stays still while all the others multiply.

The network cost floor, which no model removes

Underneath every vendor bill sits a cost the chain charges directly. Solana takes a base fee of 5,000 lamports per signature, charged whether the transaction succeeds or fails. Priority fees are additional, set in micro-lamports per compute unit and multiplied by the limit requested, and they move with conditions nobody can quote in advance.

Whether these chain costs reach your vendor invoice or your own wallet depends on the custody arrangement, and the mechanics are set out in the Solana developer documentation. A tool that never holds your keys cannot pay your fees. The full stack, including the floor below which a run stops producing a readable result, is covered in the piece on what budget a volume run needs.

The five models against the same run

The table applies the illustrative rates to both illustrative runs. Read the last two columns before the cost columns. Where the failure risk sits, and which clause governs it, will change your decision more often than the arithmetic will, because arithmetic is easy to redo and a missing clause is not.

Two results stand out. The subscription is the most expensive option on the small run and the cheapest on the large one, which is the shape of every time-based charge. And the credit pack costs more than the plain per-transaction rate on Run A despite a lower advertised unit price, because it was sized for work that did not happen.

Where each model hides cost

Every structure has a place where cost accumulates without appearing in the headline. The same reading test applies to any Solana volume bot platform you open in a browser tab: find the sentence naming the billable base before the number attached to it, and note whether it exists at all.

• Subscription: the unused period. A plan bought for a two-day test bills the whole month, and auto-renewal makes that recurring.
• Percentage: the base. Attempted rather than settled notional, or a computed figure with no export you can check.
• Per-transaction: retries. An engine that retries hard to improve landing rates also multiplies a billable count.
• Credit packs: expiry and pack size, which convert your forecasting error into vendor revenue.
• Revenue share: the measurement. Not the rate, but who computes the number and whether you can reproduce it.
• Hybrid: double counting, where the floor is called included but does not reduce the usage line it appears to prepay.

Hosting is the line most often left out of the comparison entirely, because it never appears on a vendor invoice. A self-hosted engine trades a subscription for infrastructure and your own time, while a managed service folds both into the price and removes the option of tuning them. That trade is set out in the comparison of running the engine yourself against paying someone to run it.

What a failed transaction does to the bill

Failures are not an edge case on Solana; they are an ordinary operating condition, and a pricing discussion that ignores them is incomplete. The chain settles the question without ambiguity. A base fee of 5,000 lamports per signature is charged whether the transaction succeeds or fails, so network cost tracks attempts rather than confirmations.

Vendor models are far less consistent. Some bill attempts, reasoning that constructing, signing and submitting a transaction is the work being sold. Others bill only confirmed successes, reasoning that a failure delivered nothing. Both positions can be argued; what cannot be defended is leaving the choice unstated until the invoice arrives.

Ask a second question straight after that one: are failures reported to you at all. A model that bills attempts while displaying only successes has made the billable quantity invisible inside its own interface, which leaves you unable to check an invoice against anything. Signature-level records you can look up independently turn a dispute into arithmetic.

Refunds, proration and cancellation

Pricing structure and refund policy are usually written by the same person and should be read together. Each model creates its own characteristic dispute, and the contract language either anticipates that dispute or leaves it open. Reading the two documents separately is how buyers end up with a price they understand and a remedy they do not.

Subscriptions raise proration: if you cancel mid-period, is the remainder returned, does access continue to the end of the paid period, or does cancellation bite immediately with no credit. Percentage models raise recomputation, when a routed figure is corrected downwards afterwards. Credit packs raise the hardest question, which is whether unspent units are still money you own.

• Does cancellation stop future charges immediately, and through what mechanism.
• Is a partial period refunded, credited against the next period, or forfeited.
• Do unused credits expire, and does changing plan reset or destroy them.
• If the operator stops a run rather than you, what proportion returns.
• Is a refund paid in the asset you paid with, or converted at their rate.
• Which record governs when the published page and a support message disagree.

That last item deserves more weight than it usually gets. Terms published on a website can be edited at any moment and rarely carry a version history, whereas a message sent to you sits in your own records with a timestamp. Keep the message: it is the only part of the agreement you hold an independent copy of.

Getting the full price expression in writing

The sequence below is the practical output of this page. It produces one artefact: a written statement of every term in the pricing expression, from the operator, before money moves. It works because the questions are specific enough that a vague answer is visibly a non-answer rather than a stylistic choice.

1. Write down your own run first. Fix the routed notional, transaction count, wallet count and duration you intend before you look at any rate card. Without this every quote sounds reasonable.
2. Classify the quote. Assign it to one of the five structures, or to the hybrid. If it fits none of them, pursue that, because a novel structure usually encodes a novel asymmetry.
3. Name the billable base out loud. Ask what quantity the rate multiplies and whether it is measured on attempts or confirmations. Accept only a sentence a third party could use to reach the same number.
4. Ask what the quote excludes. Network fees, priority fees, rent-exempt deposits, minimums, setup and withdrawal charges. Ask for exclusions as a list rather than asking whether any exist.
5. Compute both runs yourself. Apply the expression at your expected size and at twice that size, so you see how the structure behaves when a run goes further than planned.
6. Get it in one message. Ask for rate, base, failure treatment, exclusions, minimums, renewal and refund terms in one written reply. A partial answer tells you which term is contested.

Price is one criterion among several and rarely deserves to decide the outcome alone, because custody, venue coverage and failure reporting all constrain what a price even means. The order for assembling those into a decision, ending in a small paid test, is set out in the guide to choosing a Solana volume bot without guessing.

Comparisons of this kind sit together in the comparisons section, written as class comparisons rather than rankings, because rankings age badly while structural trade-offs do not. If you can write your bill as one expression with every symbol defined, you understand the price; if a symbol resolves to a quantity only the operator can see, you are pricing trust.

Frequently asked questions