Questions to Ask a Volume Bot Vendor
Thirty questions grouped by the property each one tests, with the answer shape that passes and the answer shape that fails set side by side. Open it in a second tab while you are talking to support.
What this page settles
- A question earns its place only when the answer can be checked against something other than the person answering it: a signature, a clause, an exported file.
- Refusing to describe server architecture is a legitimate boundary. Refusing to say who holds the key that can move your funds is not a boundary, it is an answer.
- Good answers are a reason to run a small paid test, not a reason to skip one. Everything said before payment is a claim until the chain agrees with it.
What the questions are for
Ask a vendor thirty questions, grouped by the six properties that carry almost all of the risk: custody and keys, venues and routing, pricing and billing, controls and limits, records and reporting, and contract and support. Each question below is paired with the answer shape that passes and the answer shape that fails, so you can grade a reply while it is in front of you rather than afterwards.
A question list is a filter rather than an interrogation. It exists to move a conversation off marketing surface and onto things that either exist or do not: a key location, a transaction signature, a clause, a numeric cap. The measurable properties underneath these questions are set out in the nine criteria this desk evaluates against, and the questions here are the spoken form of that same framework.
Two neighbouring pages do different work. Behaviour that should end a conversation regardless of what is said is catalogued in the warning signs that precede most complaints, and the procedure for converting good answers into evidence is the controlled first-run protocol. This page sits between them in the criteria hub and covers only the exchange itself.
Asking so the answer is checkable
Wording decides whether you receive an answer or an impression. A question that can be satisfied with reassurance will be satisfied with reassurance, every time. Phrase each one so the reply has to contain a noun you can look up: a location, a named party, a number, a document, a signature. If the honest answer is unflattering, a well-shaped question forces the vendor either to say it plainly or to decline visibly.
checkable question = specific noun + stated condition + a way to verifyReassurance satisfies none of the three parts, which is exactly why it is the default reply.Sequence matters nearly as much as wording. Ask about custody first, because a bad answer there ends the evaluation and saves you the remaining twenty-five questions. Ask about billing before controls, because the cost of a mistake determines how much protection the control surface actually has to provide. Keep the whole exchange in one channel so that the record stays in one place and nothing depends on your memory.
- Open with custody. Put the key question first, before rapport builds and before you have spent an hour that you feel reluctant to write off.
- Send one question per message. Bundled questions invite a single paragraph that answers the easiest one and quietly drops the rest.
- Repeat the answer back in your own words. Ask for a yes or a correction. This is where vague answers either firm up or dissolve.
- Ask for exactly one artefact. A signature, a clause, a sample export. One concrete object is worth more than five confident paragraphs.
If the conversation is short, or the vendor answers on a call and there is no time to work through six groups, three questions carry most of the diagnostic weight. Each is difficult to answer well without either telling the truth or making a statement that you can check later against the chain or against the contract you are being asked to accept.
- Who can move funds from the wallets this tool uses, and can I move everything out without your cooperation?
- Am I charged your fee on transactions that fail on chain, and how do I see the failure count separately from the success count?
- Can you send me a transaction signature from a real run that I can look up myself?
Group one: custody and keys
Custody is the only group where a wrong answer cannot be compensated for by anything else on the list. A tool that holds keys capable of moving your funds has a different risk profile from one that signs locally, no matter how similar the two look in a screenshot. The aim here is not to force a non-custodial answer but to establish which model you are buying, so the rest of the evaluation is priced correctly.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 1 | Who can move funds from the wallets this tool uses? | Names the parties by role and states plainly whether the operator is one of them. | "Your funds are always safe" with no party named. |
| 2 | Do I generate the keys, or does the tool generate them for me? | A direct answer either way, with the point of generation described. | Describes the encryption instead of answering who generates. |
| 3 | Where does a private key sit while a run is live? | Names a location: your browser, your machine, their server, a signing service. | "Bank-grade security" with no location named at all. |
| 4 | What happens to keys and leftover balances when I cancel? | A described path: sweep to an address you control, then deletion, with timing. | "Just contact support" with no path and no timing. |
| 5 | Can I move every lamport out without your cooperation? | Yes plus the mechanism, or an honest no plus the dependency it creates. | "Nobody has ever had a problem withdrawing." |
Group two: venues and routing
Venue questions separate coverage that is claimed from coverage that is demonstrated. A logo row on a landing page costs nothing to produce and commits the vendor to nothing, whereas a signature from a trade routed through a named venue is checkable in under a minute. Routing behaviour also determines what happens on a bad day, which is the case most vendors have not thought about and most buyers forget to raise.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 6 | Which Solana venues does the engine route to this week? | A specific list, including any venue currently disabled and why. | A logo wall, or "all the major DEXs". |
| 7 | How is a venue chosen for a given order? | A stated rule: pool depth, configuration, or your explicit selection. | "The algorithm optimises it" with no inputs named. |
| 8 | What happens mid-run if a venue stops accepting orders? | Names the behaviour - halt, skip, reroute - and whether you are told. | Treats the case as hypothetical and moves on. |
| 9 | Can you show a signature for a trade routed on each venue? | One or more signatures you can paste into an explorer yourself. | A dashboard screenshot offered in place of a signature. |
| 10 | How does a new venue get added, and who decides? | A process, a rough cadence, and who is allowed to request it. | "Soon", or a roadmap graphic with no dates attached. |
Group three: pricing and billing
Pricing questions are not about whether a tool is expensive. They are about whether the number you were quoted is the number you will pay, and what the difference between the two depends on. The most common gap is failure handling, because the base fee of 5,000 lamports per signature is charged whether a transaction succeeds or fails, and vendor fees may follow the same rule without saying so.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 11 | What is the full price, including everything the headline excludes? | An itemised expression plus a statement of what is not covered. | The headline number repeated with more emphasis. |
| 12 | Am I charged your fee on transactions that fail on chain? | A yes or no, plus the definition of failure their billing uses. | "Failures are rare", which answers a different question. |
| 13 | Who funds the network fee and the priority fee, and is it marked up? | Says who funds it and whether the pass-through is at cost. | Conflates network fees with the service fee. |
| 14 | When is money taken, and what does the invoice line read? | A charge point, a currency, and a sample line item you can see. | "You just top up a balance" with no record described. |
| 15 | What is the smallest spend that still produces a readable result? | A floor with a reason attached to it. | Steers you immediately to the largest package. |
Illustrative
Take a run that attempts 1,000 transactions and assume 120 of them fail on chain. At 5,000 lamports per signature, charged either way, those failures cost 600,000 lamports, or 0.0006 SOL, in network fees. That part is trivial. The number that is not trivial is the vendor's own per-transaction fee: if it applies to all 1,000 attempts rather than the 880 that landed, then 12 percent of your fee budget bought nothing. Both counts are invented to show the shape of the exposure and are not observed data.
Group four: controls and limits
Control questions establish how much of the run is yours. A tool with a wide parameter surface and no hard cap is more dangerous than one with fewer options and a ceiling that the engine cannot cross. Some of this can be checked without asking anybody, because a public interface either exposes a configuration screen or it does not, and opening a SOL volume bot console shows which parameters are presented as yours to set.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 16 | Which parameters can I set, and which are fixed by you? | Two lists, clearly separated: mine and theirs. | "Fully customisable", which names nothing. |
| 17 | Can I set a hard cap the engine cannot exceed? | Names the cap, where it is stored, and what the engine does on reaching it. | "You can stop it whenever you like", which is not a cap. |
| 18 | How do I stop a run in progress, and how long does stopping take? | A stop control plus an honest account of in-flight transactions. | Claims an instant stop and never mentions in-flight work. |
| 19 | What happens if my session drops or I close the interface? | States whether the run continues server-side or dies with the session. | Has evidently not considered the case before. |
| 20 | Can I run a restricted first pass on parameters I choose? | Yes, with the restrictions you are permitted to impose. | Offers only a demo that the vendor drives. |
Group five: records and reporting
Reporting questions decide whether you will be able to tell what happened. A dashboard number is a claim made by the party being paid, and it becomes evidence only when it can be reconciled against the chain by someone else. Signatures are the hinge: with them you can verify a run on a public Solana explorer without the vendor's help, and without them you are trusting a counter.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 21 | Can I get transaction signatures for everything the engine does? | Signatures, exportable, covering successes and failures alike. | Aggregate counts only, with signatures withheld. |
| 22 | Are failed transactions shown and counted separately from successes? | A separate count, visible during the run and after it. | Only a success figure is ever displayed. |
| 23 | What can I export, in which format, and how long do you retain it? | A format, a scope, and a stated retention period. | "You can screenshot the dashboard." |
| 24 | Does the volume figure come from the chain or from your own counter? | Says which, and explains how the counter is derived. | Does not distinguish between the two sources. |
| 25 | Can I reconcile your report against an explorer without your help? | Yes, with the identifiers that let the two line up. | Argues that reconciliation is not meaningful here. |
Group six: contract and support
The final group is about the bad day rather than the good one. Refund conditions, the channel of record and the identity of the counterparty all become relevant at the same moment, which is the moment they are hardest to negotiate. Ask them while you are still a prospect and the answers are cheap; ask them during a dispute and you are asking someone to concede a position they already hold.
| # | Question | An answer that passes | An answer that fails |
|---|---|---|---|
| 26 | What are the refund conditions in writing, before I pay? | A clause you can read, with the covered failure cases named. | "We always look after our customers." |
| 27 | Which channel is the record if we disagree later? | A named channel that persists and cannot be cleared by one side. | A chat that either party can wipe without a trace. |
| 28 | Which entity am I contracting with? | An entity and a jurisdiction, or an honest statement that there is neither. | Presents anonymity itself as a feature you should want. |
| 29 | What do you tell customers when a run fails or the service is down? | A described disclosure practice, and somewhere it has been used. | Asserts that outages do not happen here. |
| 30 | How long has this engine been running, and what changed most recently? | A history plus a specific recent change, described concretely. | Launch-day language only, with no history of any kind. |
Reading a non-answer
Most answers you receive will not be lies. They will be non-answers, which are harder to notice because they arrive in a friendly tone and at a reasonable speed. Four patterns cover nearly all of them: deflection, where a neighbouring question is answered instead; volume of jargon, where technical vocabulary substitutes for a fact; the proprietary shield; and the pivot to results, where a question about mechanism is answered with a claim about outcomes.
Deflection is the easiest to catch if you have written the question down, because you can hold the reply against the words you actually sent. Jargon is caught by asking for the same answer in one sentence without any acronyms; a vendor who understands their own system can do this, and one who is reciting cannot. The pivot to results is caught by noticing that nothing in the reply could ever be false.
A refusal is not automatically an evasion. "We do not publish our server topology or our RPC providers" is a normal boundary and tells you nothing bad. "We cannot say who holds the signing key" is not a boundary, because it concerns a fact about your money rather than a fact about their infrastructure. Sort every refusal into one of those two boxes before you react.
The distinction is worth stating precisely, because vendors sometimes borrow the language of one to cover the other. Legitimate confidentiality protects the vendor from competitors and attackers without changing your exposure. An evasion protects the vendor from you, and always concerns something you would price differently if you knew it. If a refusal changes what you would pay, it is not confidentiality, whatever it is being called.
What to record, and what good answers do not settle
Record more than the answers. Keep the exact question you asked, the reply in the vendor's own words rather than your summary, the channel, who answered, and which questions were left unanswered when the thread moved on. Unanswered questions are data, and they are the first thing you lose if you write up the conversation from memory a day later.
Then re-ask two or three of them a week afterwards, ideally the ones about custody and billing, phrased slightly differently. Consistent answers across time and across staff are a genuine signal, and they cost the vendor nothing to give if the first answers were true. Inconsistency is not proof of bad faith, but it tells you the answer was improvised rather than drawn from something written down internally.
Even a clean sweep leaves the main question open. Everything on this page tests what a vendor says, and nothing on it tests what the software does, which are different objects. Good answers should change the shape of your first paid run - what you watch, which records you demand, where you set the cap - rather than remove the need for one. Buy the small test first, and let the chain settle the rest.
Frequently asked questions
Do I need to ask all thirty questions?
No. Thirty is a menu, not a script. Custody is mandatory because a bad answer there ends the evaluation on its own. After that, ask the group that matches your largest exposure: billing if the spend is significant, records if you have to report the result to someone else, contract if the amount is large enough that a dispute would be worth pursuing.
Is it fair to expect a vendor to answer technical questions before I pay?
Every question on this page is about the terms of the transaction rather than the internals of the product. Who can move your funds, what you are billed for, what you can export and who you are contracting with are all things a buyer is entitled to know before payment. A vendor who treats those as intrusive has told you something useful.
What counts as a legitimate refusal to answer?
Anything that would expose the vendor to competitors or attackers without changing your risk: server topology, RPC providers, source code, staffing, the specific logic behind order sizing. A refusal stops being legitimate the moment it covers a fact about your money or your rights, such as who holds signing authority or what the refund clause says.
Should I ask in chat or on a call?
Ask in writing wherever possible, and use a channel that neither side can silently delete. If the vendor prefers a call, take the call, then send a written summary of what you heard and ask for confirmation. That converts a verbal answer into a record without accusing anyone of anything, and inconsistencies show up in the reply.
What if every answer is good?
Then you have a shortlist entry, not a purchase. Answers are claims about future behaviour, and the only thing that tests them is a small run with money you can afford to lose, fixed parameters and pass conditions written down before you start. Good answers change what you look for during that run rather than removing the need for it.
Does a fast, confident reply indicate a better vendor?
Not by itself. Speed before payment is the cheapest thing to fake and the least predictive signal available, because pre-sale support and post-sale support are frequently different people with different incentives. What predicts a dispute going well is specificity: named parties, named locations, quoted clauses and artefacts you can verify without the vendor present.
Which single question matters most?
Who can move funds from the wallets this tool uses. Everything else describes how a service performs; that question describes what happens on the worst day. A vendor who answers it plainly, including an unflattering answer such as holding keys on your behalf, has given you something you can price. A vendor who cannot answer it has ended the conversation.
Filed under Criteria by The Volume Bot Review Desk. Every figure on this page is either a protocol fact or arithmetic explicitly labelled illustrative. How we handle numbers is set out in the editorial policy.