Bot type
Governance where the discussion already is
A Telegram DAO governance bot runs proposals, computes voting weight from a block snapshot, collects signed votes and publishes results anyone can verify independently. It moves governance to where discussion happens. It does not execute on-chain, and it cannot make a quorum appear.
DAO governance bots: price, timeline and limits
- Fixed price
- $8,000 USD
- Delivery
- 32 calendar days from kickoff
- Signatures
- Prove control of an address; they execute nothing on-chain
- Snapshot block
- Required — balances change continuously, so weight is meaningless without one
- Account binding
- Telegram cannot cryptographically bind an account to a wallet
- Per-group ceiling
- ~20 messages/minute into a single group
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Almost every DAO has the same split. Discussion happens in Telegram, where the members are. Voting happens on a governance platform, where the members are not. The result is that debate and decision are disconnected: proposals get argued about at length by people who then do not vote, and pass or fail on turnout from a different, smaller group.
Bringing the vote to the discussion sounds obvious and has one hard requirement: the result must be verifiable by someone who does not trust the operator. A vote tallied inside a bot, with no way to check the weights or recount the ballots, is a poll. It might be perfectly honest and it carries no authority, which becomes apparent the first time a close result is contested.
What makes it real is snapshot-based weight and signed ballots. Voting power is computed from token holdings at a block number fixed when the proposal opens, so buying tokens after seeing a proposal changes nothing. Each vote is signed by the holder's wallet, so a third party can recount independently from public data. The bot then becomes a convenient interface to a verifiable process rather than the authority itself — which is the only version worth building.
How the build runs
A proposal is drafted and discussed before it can be voted on
A mandatory discussion period before the voting window opens. Proposals that go straight to a vote get decided by whoever was awake, and the debate happens afterwards in the form of complaints.
forum-topicsThe snapshot block is fixed when voting opens
Voting weight is computed from holdings at that block and published with it. Fixing it at open rather than at close removes any advantage from acquiring tokens after reading the proposal.
webhookMembers vote by signing with their wallet
A signature over the proposal id and choice, produced in the wallet the member already uses. It costs no gas because nothing is submitted on-chain, and it is verifiable by anyone.
web-app-initdataThe running tally is visible but the ballots are not attributable until close
Totals update live; individual votes are revealed at close. Live attribution turns governance into a bandwagon, where late voters follow whichever side is ahead.
inline-keyboardQuorum and threshold are checked against the published rules
A proposal that passes the threshold but misses quorum fails, and says so with the numbers. Rules applied inconsistently once destroy the process permanently.
commandsResults publish with everything needed to recount
Snapshot block, weights, signatures and choices. Anyone can rerun the tally from public data, which is what gives the outcome authority the bot itself cannot confer.
webhook
What Telegram will and will not let you do
A wallet signature proves control of an address; it does not execute anything on-chain.
Voting is off-chain and gasless, and execution remains a separate step by whoever holds that authority. A bot that claimed to execute would need the keys, which is a different and much larger trust question.
Token balances change continuously, so weight is meaningless without a fixed block.
The snapshot block is published with the proposal. Without it, weight computed at close lets a member buy influence after reading the argument.
A Telegram account cannot be cryptographically bound to a wallet by Telegram itself.
Binding is established by a signed challenge and stored. Anyone re-binding is re-challenged, since an unverified binding would let a member vote another's weight.
Telegram messages can be edited by their sender after posting.
Proposal text is hashed at creation and the hash published. Otherwise a proposal could be reworded after votes were cast, which is the governance equivalent of moving the goalposts.
A bot may send roughly 20 messages per minute into a single group.
Vote confirmations are sent privately rather than announced in the group, which would throttle during any active vote and flood the discussion regardless.
When not to build this
- Your governance must execute on-chain automatically. Off-chain signing does not execute anything, and a bot holding execution keys is a different trust model entirely.
- You have no quorum problem. If turnout is already healthy on an existing platform, moving the vote adds a system without solving anything.
- Your token distribution is highly concentrated. Making voting convenient does not change an outcome three wallets already determine, and it makes that fact more visible.
- You are unwilling to publish full ballot data. Without it the result is a poll, and a poll presented as governance fails at the first contested vote.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, proposal flow and forum-topic discussion threads. |
| TON Connect | 2.x | Wallet binding and off-chain vote signatures. |
| Cloudflare Workers | current | Runtime, snapshot computation and signature verification. |
| Cloudflare D1 | current | Proposals, snapshots, ballots and published results. |
| TypeScript | 5.9 | Strict mode, with voting weights as integers rather than floats. |
Questions people ask before committing
Does voting cost gas?
No. Votes are wallet signatures over the proposal id and choice, verified off-chain. Nothing is submitted to the network, so participation costs nothing — which matters, because gas-cost voting systematically excludes smaller holders.
How can someone verify the result independently?
The snapshot block, every weight, every signature and every choice are published at close. A third party can recompute the tally from public data without trusting the bot, which is what gives the outcome authority.
Why fix the snapshot when voting opens rather than when it closes?
So that reading a proposal and then buying tokens changes nothing. A snapshot at close makes influence purchasable after the argument has been made, which is the most obvious way to game a governance system.
Can the bot execute a passed proposal on-chain?
No, and it should not. Execution requires keys, and a bot holding them is a substantially larger trust question than a bot that tallies signatures. Execution stays with whoever your model gives that authority to.
What stops someone voting with a wallet that is not theirs?
Binding requires a signed challenge from that wallet, so control must be demonstrated. Re-binding re-challenges, because an unverified binding would let one member cast another's weight.
Are individual votes visible while voting is open?
Totals are; attribution is not, until close. Live attribution produces bandwagon voting where late voters follow whichever side is ahead, which is a real effect and worth designing out.