Comparisons: how classes of tool differ

This desk compares classes, not products. A comparison between two named tools ages the moment either one ships a change, and it depends on numbers neither of us can verify. A comparison between two structures - a subscription against a percentage of routed volume, a chat interface against a console, your own server against someone else's - stays true for as long as the structures exist, and it transfers to every product that adopts one.

Each piece here isolates what genuinely differs, names what does not differ despite the marketing, and states the trade-off you are accepting when you pick a side. None of them ends with a winner, because the right answer depends on facts about you rather than facts about the software.

3 pieces in this section

Class-level comparisons rather than product rankings. Pricing structures, interface models and hosting models, each with the trade-off it hides.

Pricing models compared

Flat subscription, percentage of routed volume, per-transaction fee, credit packs and revenue share, each modelled against the same illustrative run.

Telegram bot vs web console

The interface is not cosmetic. It determines what you can audit, what you can automate, and what happens to your keys. A capability matrix for both models.

Self-hosted vs managed

Running the engine yourself moves cost from a subscription line to your own time and infrastructure. A total-cost frame and a decision tree for the choice.

What each comparison actually settles

The most common mistake is treating a surface difference as a structural one. This table separates the two before you read any of the pieces.

Comparison	What genuinely differs	What does not differ	The usual error
Pricing models	What scales the bill, and who absorbs the cost of a failed transaction	The underlying network fees, which you pay in every model	Comparing headline prices instead of the full price expression
Interface model	Where the key lives, what you can export, and what a session grants	The venues reachable on chain, which are the same for everyone	Assuming a dashboard is safer than a chat bot because it looks like software
Hosting model	Who carries operations, upgrades, incidents and key custody	The economics of the trades themselves once orders are on chain	Counting the licence saved and not the hours spent

Where this section sits

Once you know which structure you are buying, the criteria section tells you what to verify inside it, and the buying guide covers the sequence between a shortlist and a first paid run.

Criteria

The measurable properties of a volume tool: custody, venue coverage, control surface, failure reporting and the questions that expose each one.

CRI

Buying guide

What to do between shortlisting and paying: size a first budget, run a controlled test, and check the warning signs that predate most complaints.

BUY