Telegraft

Cost

What a crypto bot costs

Crypto bots run twelve to twenty-eight delivery days, and the distribution of that work is unlike any other category: verification, key handling and adversarial testing outweigh feature building. A defect here is an irreversible loss rather than a support ticket, and the estimate is shaped by that single fact.

What a crypto bot costs: effort, cost and what moves it

Fixed price
$8,820 USD
Delivery
Awaiting sign-off
Effort
21 delivery days
Biggest cost driver
Threat modelling and chain verification, not the wallet UI
Commercial basis
Fixed price agreed before work starts; scope changes quoted separately
Year one, beyond the build
Support retainer, Managed hosting, plus chain data provider, identity verification, network fees

As of 2025-10-01, Telegram Bot API 13.4

Why this costs what it costs

The feature list of a crypto bot rarely justifies its price on paper. Connect a wallet, show a balance, accept a payment, gate a group — none of that reads as expensive. The cost is in a property that does not appear in the feature list at all: every mistake is final. A booking bot that double-books is embarrassing and fixable in an afternoon. A bot that credits an unconfirmed transfer has given away an asset nobody can recall.

The specific discipline this demands is that the client is never a source of truth. A wallet reporting a successful send is making a claim, and a claim is not a settlement. The only acceptable confirmation is the chain itself, read by your own backend, at a confirmation depth you decided in advance, matched against an amount and a destination you control. Every crypto bot we build treats client callbacks as hints that trigger verification and never as evidence, and that architecture is a substantial share of the estimate.

Key handling is the second concentration of cost. The right default is that the bot holds no user keys at all — wallets connect, users sign, and the bot verifies. Custody changes the project into something else entirely, with a security model, an operational procedure and a regulatory question attached, and we scope that separately rather than folding it into a build like this. Saying no to custody is usually the most valuable advice in the first conversation.

Then there is the regulatory layer, which in the UAE is unusually concrete. Virtual asset activity in Dubai sits under VARA, and whether your product touches a regulated activity changes the scope before any code is written — it decides whether identity verification is in the build, what records must be kept, and in several cases whether the product can be offered here at all. This is a question for your counsel, not for us, but it is one we raise on day one because the answer moves the estimate more than any technical decision does.

The breakdown

WorkDaysCostWhat it covers
Threat model and scope2$840What an attacker gains, what is irreversible, what the bot must never hold, and which regulated activities the product touches. Written down and agreed before anything is built.
Wallet connection2$840Connection, signature challenge and proof of control, so an address is something the user demonstrated rather than something they typed.
Chain verification3$1,260Backend confirmation against the chain at a chosen depth, matched on amount, destination and memo. The single most important line here and the one cheap builds omit.
Product logic5$2,100Whatever the bot exists to do — storefront, quest, access gate, alerting — built on top of verified state rather than on reported state.
Abuse resistance3$1,260Multi-account detection, replay protection, rate limits, and the specific exploit paths named in the threat model, each with a test that attempts it.
Adversarial testing3$1,260Deliberate attempts to break the flows: replayed confirmations, forged callbacks, reorgs, and race conditions on double claims. Findings fixed and retested.
Operational runbook1$420What to do during a chain outage, a stuck transaction or a suspected exploit, including who can pause the bot and how. Written for people acting under pressure.
Deployment and monitoring2$840Alerting on verification failures, unusual claim rates and balance drift, because the first sign of an exploit is a pattern rather than an error.
Total21$8,820Fixed on signature. Scope changes are quoted separately, never absorbed silently.

What moves the number

A client reporting a successful transaction is not evidence that one occurred.

Every credit, unlock or delivery is gated on backend chain verification. This is architectural rather than a validation step, and retrofitting it into a bot built the other way is close to a rewrite.

Confirmation depth is a product decision with a cost attached.

Waiting longer is safer and feels slower, and the correct depth depends on what a reversal would cost you. It is decided in the threat model and written into the flow, not chosen by whoever writes the handler.

Custody of user keys changes both the security model and the regulatory position.

Non-custodial designs are the default here. If custody is genuinely required, it is a separate engagement with its own scope, and your legal counsel is involved before the estimate is meaningful.

Virtual asset activity in Dubai falls under VARA supervision.

Whether your product touches a regulated activity determines whether identity verification and record keeping are in scope. Get the legal answer before the build starts; it can change the product, not just the price.

Stablecoin transfers settle in the token the user actually sent.

Pricing in a fiat amount and accepting a token means quoting a rate with an expiry and handling under- and over-payment explicitly. Every crypto storefront hits this and it is not a rounding concern.

Card acquirers will not underwrite virtual asset businesses in the UAE.

A crypto product cannot fall back to a card gateway when the chain rail proves inconvenient. There is no second rail to add later, so the first one has to be right.

What year one actually costs

Running costYear oneDetail
Support retainer$3,480/yrEffectively mandatory in this category. Abuse patterns evolve continuously, and a crypto bot without someone watching it is a standing invitation.
Managed hosting$660/yrRuntime, verification records and the audit log, backed up and restorable. The record of what was verified and when is the evidence trail after an incident.
Chain data providerbilled by the providerIndexer or node access billed by request on your own account. Verification-heavy products call it far more than feature-count suggests, so model it against confirmations rather than users.
Identity verificationbilled by the providerPriced per verification by your KYC provider, under your own contract. Applies only where the regulatory answer requires it.
Network feesbilled by the providerPaid on-chain, and whether your users or your treasury pays them is a product decision that changes both the flow and the unit economics.

Buying the same thing elsewhere

Where you buy itWhat the money buysWhat you carry
A crypto-native freelancerDeep familiarity with the chain, fast iteration, and often a genuinely good feel for what the community expects. Real advantages for a launch on a deadline.Adversarial testing and operational procedure are the parts most often skipped under time pressure, and they are the parts that matter when something is irreversible. Ask specifically what was tested and how.
A smart contract audit firmRigorous review of on-chain code by people who do only this, and a report you can publish. Worth every dirham if you are deploying contracts.Different scope from a bot build. The bot, its verification logic and its abuse surface usually sit outside an audit engagement, which is where most Telegram-side incidents actually originate.
A launchpad or community bot templateImmediate deployment for a fraction of a build, with quest and gating features already present. Sensible for a short campaign with nothing valuable behind it.Shared code with widely known behaviour, and abuse patterns tested at scale against every other deployment. Fine for a giveaway, not for anything holding value.

Questions about the money

Why is this so much more expensive than a booking bot?

Because a booking bot's worst day is a double booking and this one's is an irreversible loss. The extra days are threat modelling, chain verification, abuse resistance and adversarial testing — none of which appear in the interface, and all of which are the reason it can be trusted with value.

Do you hold our users' keys?

No. The default is non-custodial: wallets connect, users sign, the backend verifies. Custody changes the security model and the regulatory position, and it is scoped as a separate engagement with your counsel involved rather than folded into a build.

Which chain do you build on?

TON, primarily, because it is where Telegram-native products live and where wallet connection is closest to frictionless for users already in the app. Other chains are possible and are quoted against how mature their tooling is, which varies more than most clients expect.

Does this need a licence in Dubai?

That is a question for your legal counsel and it depends on which activity you are performing rather than on the technology. Virtual asset activity here is supervised by VARA. We raise it on day one because the answer can change the product, and we do not give legal advice.

How do you stop people gaming a quest or airdrop?

Multi-account detection, proof-of-control signatures rather than typed addresses, rate limits, and eligibility rules that are verified server-side and cannot be replayed. Perfect prevention does not exist; the goal is making abuse cost more than the reward is worth.

What happens if the chain is congested or an indexer goes down?

The bot degrades openly — it tells users verification is delayed and queues the work rather than guessing. Guessing during an outage is how a bot credits something that never settled, and the runbook covers exactly this case.

Can we accept both crypto and cards?

Rarely, and the obstacle is commercial rather than technical: UAE card acquirers do not underwrite virtual asset businesses. If your product genuinely spans both, the usual answer is two separate entities with separate rails, which is a corporate structuring question before it is an engineering one.

Related reading