How to spot a volume bot scam

Why this category attracts fraud

Three properties make volume services an unusually good target, and understanding them tells you where to look.

The buyer is usually in a hurry. Campaigns get bought around launches, listings and announcements, which are exactly the moments when nobody has time to do diligence. Urgency is the scammer's main asset and it is supplied by your calendar rather than by them.

The product is hard to verify before payment. You cannot test-drive a campaign. Everything you are told about routing, wallet counts and venue coverage is a claim until after the money has moved, which inverts the normal order of trust.

And the payment is final. There is no chargeback on a SOL transfer. Once the transaction confirms, the only leverage you have left is whatever the counterparty cares about losing, which for an anonymous account is usually nothing.

None of that means the category is fraudulent. It means the checks have to happen before the transfer, because afterwards there are none.

Claims that cannot be true

Some promises are not exaggerations, they are mechanically impossible. Any of these should end the conversation.

A service that makes none of these claims has not proven it is competent, but a service that makes any of them has proven something useful in the other direction.

What they ask you for

This is the cleanest signal available, because the legitimate requirements are short and specific.

A volume campaign needs: your token's mint address, which is public information, and a payment. That is the whole list.

It does not need: a private key, a seed phrase, a wallet connection with signing authority over your treasury, your token supply, or access to your liquidity position. If any of those appear, the product being sold is not the product being described.

Watch particularly for the framing that makes access sound technical: needing to "verify ownership" by signing, or needing supply "to seed the routing". Ask which specific instruction requires it. A legitimate operator can answer that question in one sentence; the answer for a volume campaign is that none of them do.

A related tell is vagueness about the mechanism itself. Ask how many wallets a campaign uses, what the swap size band is, and which venues it routes across. Those three numbers determine everything the campaign will produce, and any operator who actually runs one knows them. An answer that stays at the level of "our proprietary algorithm handles that" is not protecting a secret; there is no secret in sending swaps through public pools. It is avoiding a number that could later be checked against the chain. The console on the home page shows all three before anything is submitted, which is the shape that answer should take.

Payment patterns worth refusing

• An address that changes per conversation. Rotating addresses defeat the one form of accountability you have, which is other people recognising the address.
• A price that moves during the conversation. A fee that rises when you hesitate is not a pricing model.
• Pressure framed as scarcity. Slots closing, a rate expiring in ten minutes. Real capacity constraints do not arrive with a countdown.
• Refusal to state a fixed figure. If the fee cannot be written down before you pay, it will not be defensible after.
• Requests to pay outside the stated flow. A different address to the one published, sent by direct message, is the oldest version of this.

Ten checks that take about five minutes

1. Does a site exist, and does it state a method and a fee, or only outcomes?
2. Is the fee a fixed, written number before you commit?
3. Is the payment address published in the same place every time?
4. Does anything in the flow require your keys or your supply?
5. Are any of the impossible claims above being made?
6. Does the service explain what it cannot do, anywhere at all?
7. Can you find the operator tomorrow if something is wrong?
8. Is there a stated minimum, and does it make sense for your pool's depth?
9. Do the wallet counts and swap sizes they quote produce the volume they quote?
10. Does the payment address have any history you can read on-chain?

The tenth one is underused and free. Paste the payment address into an explorer. An address with a long history of ordinary incoming payments looks different from one created this morning, and both are public.

Verifying the work afterwards

If you have already paid, the question shifts from trust to measurement, and measurement is entirely possible because everything happened on a public ledger.

Count the confirmed swaps against your token during the window, not the transaction count. Sum their sizes in both directions and compare against the volume promised. Count the unique addresses that participated and compare against the fleet size quoted. Check how many distinct pools they landed in, because a campaign that hit one venue was not routed anywhere regardless of what was described.

Failed transactions matter here more than people expect: they consume fees and produce no volume, so a provider reporting attempts rather than confirmations is reporting a number that flatters them. The on-chain reading guide walks through each of these checks step by step, and the same method works for evaluating any provider's claims, including ours.

That is the standard worth applying generally. Anyone whose work cannot be checked after the fact should be assumed to be counting on that, and anyone whose work can be checked has given you the tool to hold them to it. Our own measurement policy lists what we refuse to estimate, which is a shorter and more useful document than a list of promises.