TonCalls: from a message to a contract card
An aggregator of TON contracts: cards with a chart and source, 900 subscribers at the peak, and the later sale of the project.
TonCalls was my project for aggregating posts about TON contracts from Telegram channels. Instead of checking several sources by hand, I collected the message, the contract address and the context into one card. The reader got the original quote, the author, a chart and extra counters side by side.
Audience and outcome
At its peak the channel reached 900 subscribers. It grew by word of mouth: readers recommended it to each other. Later I sold TonCalls.
What the result looked like
A finished post combines a preview, the source quote, reactions, the address and buttons. The old channel is closed, but the code and a sample post are on GitHub.
The path of a message
A Telethon userbot read the sources. A separate bot published the formatted message with buttons. This split kept access to source messages and made it possible to control how the final card looked.
1
2
3
4
5
6
7
Telegram sources → Telethon → contract address
↓
metadata and context
↓
chart-proxy → composite preview
↓
Telegram post
The handler extracts the address from the text and then checks the link context. Mentions from wallet explorers are filtered out so that a wallet address does not become a token card. Metadata is requested from DexScreener, and if there is no suitable pair the post is skipped.
Messages arrive through Telethon events plus an extra history check, which covers gaps in the update stream. Processing the original message and counting repeats of a contract are separate: a repeat delivery of the same post must not raise its counter, while a contract appearing in another source adds context.
The card as a separate service
The chart-proxy HTTP service returned HTML with Open Graph markup and composed a PNG with Pillow. Telegram received the preview page and found the image in it. One picture combined the chart, the media from the original post, the author and statistics.
Images had a memory cache and a disk cache, so a chart already fetched could be reused for repeat preview requests. Data fetching and visual assembly lived in different parts of the project, so the card design could change independently of reading messages.
Repeats and counters
SQLite stored processed messages, the history of contract mentions and cached data. The key for contract history combined the address, channel and message number, and a repeat insert was ignored.
Reaction counters were calculated from the author’s recent posts and updated in the background. Next to them the card could show the number of earlier mentions of the same address, which told the reader where a message came from and how often it had been repeated. An optional short LLM comment was available through Ollama or a compatible API.
What I left for reuse
The open version includes two services, a sample post and launch configurations. It shows how to work with Telegram events, SQLite, caching and Open Graph previews. Sources, the account and integration settings are configured separately for each instance.
For me the main result is a working path from scattered messages to a shared view that keeps the source.