DEV Community: Слава Жуланов

Building an on-chain alerts bot in Python without any blockchain library

Слава Жуланов — Sun, 24 May 2026 17:41:18 +0000

PolySignal — my Telegram bot that watches Polymarket — has a small subsystem called chain_watcher. It does one thing: cross-check every trade Polymarket's API reports against what actually happened on Polygon, and complain (via Sentry) when the API is wrong.

It's about 280 lines of Python with one dependency — httpx. No web3.py, no eth-account, no eth-abi. I'm going to walk through how to read public on-chain events from Python with nothing but the standard library and an HTTP client, because (a) I needed to and (b) most tutorials reach for the SDK as the first step when you genuinely don't need it for a read-only watcher.

This isn't an anti-SDK argument. If you're signing transactions, sending funds, or doing serious ABI work, use web3.py. The case here is narrower: for reading specific events from a known contract, you can do it cleanly with httpx + JSON-RPC.

What "watching the chain" actually means

A blockchain node exposes a JSON-RPC API. You can ask it questions:

"What block are you on?" → eth_blockNumber
"Give me all logs matching this filter from blocks N to M" → eth_getLogs
"What's the transaction at this hash?" → eth_getTransactionByHash

For an alerts bot you only need the first two. You repeatedly poll the head of the chain and ask: "any logs from contract X, with this event signature, since the last block I checked?" When new logs come back, decode them and act.

That's it. Forty lines for the polling loop, ten for the JSON-RPC client, twenty for the event decoder, the rest is glue.

The JSON-RPC client

A node listens for HTTP POSTs to its RPC URL. Each call is a single JSON body. You don't need an SDK; you need an HTTP client and a little patience.

class _ChainRPC:
    def __init__(self, url: str, timeout: float = 15.0) -> None:
        self._url = url
        self._client = httpx.AsyncClient(timeout=timeout)
        self._id = 0

    async def _call(self, method: str, params: list) -> object:
        for attempt in range(3):
            self._id += 1
            try:
                resp = await self._client.post(
                    self._url,
                    json={
                        "jsonrpc": "2.0",
                        "id": self._id,
                        "method": method,
                        "params": params,
                    },
                )
                resp.raise_for_status()
                body = resp.json()
                if body.get("error"):
                    raise RuntimeError(f"RPC {method} failed: {body['error']}")
                return body["result"]
            except (httpx.HTTPError, RuntimeError):
                if attempt == 2:
                    raise
                await asyncio.sleep(0.5 * (attempt + 1))
        raise RuntimeError("unreachable")

That's the whole client. Two convenience methods on top:

    async def block_number(self) -> int:
        result = await self._call("eth_blockNumber", [])
        return int(result, 16)  # the node returns hex strings

    async def get_logs(self, address, from_block, to_block, topics):
        return await self._call("eth_getLogs", [{
            "address": address,
            "fromBlock": hex(from_block),
            "toBlock": hex(to_block),
            "topics": topics,
        }])

Why the retries? Public Polygon RPCs (the polygon-rpc.com family and similar) return sporadic 5xx errors. A couple of half-second retries inside one tick smooths that out without stalling.

Filtering the events you actually want

A contract emits events with a known signature. For Polymarket's CTF Exchange V2, the event that matters is OrderFilled:

OrderFilled(
    bytes32 indexed orderHash,
    address indexed maker,
    address indexed taker,
    uint256 side,
    uint256 tokenId,
    uint256 makerAmountFilled,
    uint256 takerAmountFilled,
    uint256 fee
)

The topics field of an Ethereum log carries up to four things:

The Keccak hash of the event signature (topics[0]).
Each indexed parameter, padded to 32 bytes.

For OrderFilled, topics[0] is a known constant, and topics[2] / topics[3] are the maker and taker addresses (left-padded to 32 bytes). To find "any fill involving a watched wallet," I make two eth_getLogs calls — one filtering by the maker topic, one by the taker:

for filter_topics in (
    [ORDER_FILLED_TOPIC, None, watched_address_topics],         # as maker
    [ORDER_FILLED_TOPIC, None, None, watched_address_topics],   # as taker
):
    raw_logs += await rpc.get_logs(CONTRACT, from_block, to_block, filter_topics)

watched_address_topics is a list of 32-byte left-padded addresses. The node does the heavy lifting; you receive only matching logs.

Decoding a log

A log looks like {topics: [...], data: "0x...", transactionHash: "0x...", ...}. Topics are 32-byte hex; the data field is the concatenation of all non-indexed parameters, each padded to 32 bytes. Decoding doesn't need an ABI library for a known fixed-layout event — slice the hex.

def decode_order_filled(raw: dict) -> OrderFill:
    topics = raw["topics"]
    data = raw["data"].removeprefix("0x")
    words = [data[i : i + 64] for i in range(0, len(data), 64)]
    return OrderFill(
        tx_hash=raw["transactionHash"].lower(),
        order_hash=topics[1],
        maker="0x" + topics[2][-40:].lower(),
        taker="0x" + topics[3][-40:].lower(),
        side=int(words[0], 16),
        token_id=int(words[1], 16),
        maker_amount_filled=int(words[2], 16),
        taker_amount_filled=int(words[3], 16),
    )

That's it. A struct-shaped tuple per event.

Defensive bits worth keeping

Two production realities I built into the watcher:

1. Bounded block span. After an RPC outage, the "from last seen block to now" span can be thousands of blocks. Public nodes reject overlong eth_getLogs queries; the watcher gets stuck. So each tick caps the span at a fixed maximum (1000 blocks for me — about 30 minutes at Polygon's ~2s/block) and the watcher catches up in chunks across successive ticks.

2. Cross-check loop, not duplicate ingestion. I'm not using the chain as my primary data source; I'm using it to verify the API. The watcher records on-chain fills, waits a few minutes for the API to report the same trade, and complains via Sentry if the API never did. A single buggy API response throws a signal I'll see; if the chain were silent and the API were silent, neither layer would notice.

This is the part where SDK-less actually beats SDK: there's no library between me and the bytes. When something goes wrong, the trace is short.

When NOT to skip the SDK

To be honest about the trade:

Don't skip if you're sending transactions. Nonce management, gas estimation, signing — that's exactly what web3.py is for.
Don't skip if you need ABI introspection. Dynamic ABI parsing is genuinely a library-grade problem.
Don't skip if you want one client that handles ETH + several L2s with their quirks. A library normalises that.

For a passive watcher of a single event on a single chain, none of those apply. Eight imports, one HTTP client, ~280 lines.

The watcher in the wild

This runs inside PolySignal, my Telegram bot that alerts users when top wallets on Polymarket make a trade. The chain_watcher is the part that lets me sleep at night when Polymarket's API has its periodic moments.

If you want to read the full module, it's about 280 lines including comments and the cross-check loop. Happy to paste a Gist or answer questions in the comments.

I built a paid Telegram bot. Here's what Telegram Stars actually pay.

Слава Жуланов — Sun, 24 May 2026 17:05:48 +0000

A few months ago I launched a paid Telegram bot. No Stripe, no checkout page, no app-store account. The whole subscription runs on Telegram Stars — Telegram's own in-app virtual currency. People had questions. The most useful answer was the math, which nobody publishes openly. So here it is.

The setup

PolySignal is a Telegram bot that alerts users when top wallets on Polymarket make a trade. It has a free tier and two paid tiers (Signal 150⭐/month, Pro 750⭐/month). Subscriptions are recurring, billed every 30 days, cancellable in two taps inside Telegram. No payment provider, no checkout flow, no shipping address fields.

If you've never sold anything in Telegram: you're missing one of the cleanest payment surfaces on the internet. There's also one inconvenience hidden in the math. Both worth knowing about.

How users pay

A Telegram user buys "Stars" — Telegram's in-app currency — through Apple IAP, Google IAP, or Telegram's web purchase. They cost roughly $0.02 each at retail (e.g., 75⭐ for $1.49, depending on bundle). The user spends those Stars on paid bots. From the user's perspective: tap, confirm, pay with the Apple/Google account already linked to the phone. No friction. No "I need a credit card." Zero fields to fill.

This is, by some distance, the lowest-friction global subscription payment surface I've shipped on. There are users who pay for PolySignal that I'd never have reached with a Stripe checkout — same Telegram, never typed a card number, in the same flow as buying premium stickers.

How the developer gets paid

Here the math gets specific. The user pays via Apple/Google → Apple/Google take 30% → Telegram takes a cut → what remains lands in your Telegram-bot Stars balance. You then withdraw via Fragment (Telegram's marketplace) into TON, the network coin, and convert from there.

The widely cited dev-side rate: about $0.013 per Star — the value of one Star after Apple/Google and Telegram have taken theirs.

Which means:

Signal at 150⭐/month → about $1.95 net to me.
Pro at 750⭐/month → about $9.75 net to me.

If those numbers look small, that's because they are. Two caveats:

The 150 / 750 prices are deliberately low. I'm collecting conversion data on an unproven product; I'd rather see whether people convert at all before optimising revenue per user. The Stars rate is what it is, but my retail price is a knob I'll turn once I have churn data.
Margin on the dev side is real: ~95% gross. There's no per-user infrastructure cost worth mentioning, no support team, no advertising spend. The question is volume, not unit economics.

The payout side: where Stars-billed gets less convenient

Here's the part nobody mentions when they pitch you on Telegram Stars: how you actually withdraw the money is its own story.

Fragment is the bridge from your Telegram-bot Stars balance to actual currency. It works, but:

Minimum withdrawal is 1,000 Stars (~$13).
First-time withdrawals are delayed 21 days — the Stars you earn today won't even be eligible for withdrawal for three weeks.
Payout is in TON, not USD. Fragment sells your Stars for TON; you then convert TON → fiat through an exchange with its own KYC and fees.
Fragment requires Telegram login + a connected TON wallet. Identity verification at higher transaction sizes is "not publicly documented," by which I mean: you'll discover it when you cross a threshold.

If you're used to Stripe — daily payouts, direct deposit, no crypto in the chain — this feels archaic. If you're used to running a crypto-native business — TON is fine, this is just another rail.

The honest summary: convenience for the user, friction for the developer. The user gets a payment so low-friction it almost doesn't feel like one. The developer gets paid through a crypto off-ramp that takes three weeks for the first round.

Why I did this anyway

Three reasons:

1. Global reach with zero compliance overhead. I don't have a legal entity. I haven't talked to a payment processor. I haven't filled in a single "tell us your business model" form. Telegram (with Apple/Google) handles consumer VAT collection at the Stars-purchase point. I don't see card data. I don't see banking details. I can't be liable for things I never received.

2. The product lives in Telegram already. PolySignal's whole user surface is Telegram messages. Asking users to leave the app to enter a credit card on a third-party page would have been a substantial conversion tax — and a meaningful chunk of my audience is in countries where Stripe doesn't even land.

3. The bar for "an indie founder can ship this" was unusually low. Telegram's Bot API documents createInvoiceLink clearly. There's a subscription_period parameter for recurring. Auto-renewal is a 30-day-only fixed period (annoying — no weekly, no yearly recurring). The successful_payment update fires once on the initial charge and again on every monthly renewal, with an is_first_recurring flag. About 200 lines of Python total for the whole billing layer. Stripe would have been more.

What I'd tell another indie founder considering this

If your product lives in Telegram already, Stars are the right rail. The conversion gain from the in-app flow probably outweighs the worse payout mechanics.
If your product lives in a web app or a mobile app, Stars probably isn't worth the funnel detour.
Build the withdrawal pipeline (Fragment → TON → fiat) early, before money is on the table. Discovering payout delays after you've earned $300 is unpleasant.
The 30-day-only subscription period is a real product constraint. Annual plans have to be one-time charges, with manual expiry extension. Plan for it.
Watch what users are actually charged. Apple/Google can adjust the user-side retail price of Stars without changing your developer rate per Star. The number you see in your Telegram dashboard is the number that matters.

And, finally, the bot

PolySignal is the bot I built around all this. It sends Telegram alerts when top wallets on Polymarket make a trade. Free tier, real-time on Signal, consensus alerts on Pro. The Telegram-Stars subscription mechanic above is the same one running in production.

If you're curious to see the user experience side of "billed in Stars": t.me/PolySignalAlertsBot

If you're building a paid Telegram bot of your own and want to compare notes — leave a comment, I'll answer.

How I track Polymarket smart money

Слава Жуланов — Sun, 24 May 2026 08:32:43 +0000

The interesting thing about prediction markets

Polymarket is fully on-chain. Every position, every trade, every win and loss is public information sitting on Polygon. You can look up any user's wallet, see exactly what they've bought, what they've sold, what they've cashed out on. There are no closed funds. There are no protected portfolios.

It's a remarkable property of the platform. Anywhere else — equities, forex, sports — the people who consistently win don't show you their book. On Polymarket, they have no choice.

And yet, most users never look at this data.

That's a small mystery I've been chasing for a few months. Below is what I learned, the signals that actually mattered, and the Telegram bot I ended up building because manually tracking wallets is impossible.

Step 1: who are the sharp wallets?

The first thing is finding wallets worth watching. Polymarket publishes a public leaderboard ranked by realized PnL over different time windows: today, this week, last 30 days, all-time.

A few observations from staring at it for a while:

Lifetime PnL is misleading. A wallet at the top of "all-time" might have ridden one massive market and been quiet since. What you actually want is consistency over a recent window — last 30 days is the right zoom level. Sharp wallets stay near the top across multiple time windows; flash-in-the-pan wallets sit on the all-time list and nothing else.

Win rate without realized PnL is misleading too. A wallet that wins 80% of the time by buying 90¢ favorites is barely coming out ahead. The honest pair is win rate and realized PnL together. Better yet, win rate by category — most sharp Polymarket wallets are specialists. Someone who calls political markets 73% of the time may be 45% on sports.

This is the first lesson: the leaderboard isn't a ranking of "best traders," it's a sampling of "people who happened to do well on the metric and window you picked." Read it as a candidate list, not a verdict.

Step 2: what do you actually look at?

Once you have a few candidate wallets, you click into their profile (polymarket.com/profile/0x...). What's there:

Closed positions — every market they've resolved, with realized PnL per market.
Open positions — what they're currently holding, mark-to-market.
Activity feed — every trade with timestamp, market, side, size and price.

This is more than enough to build a real signal. The trades I learned to notice:

A trade much larger than the wallet's usual size. A whale doing a routine $500 trade is a routine $500 trade. The same wallet putting on its largest position of the quarter — that's the moment worth knowing about. The simplest version of "conviction" is just the multiple of the wallet's recent median trade size.
A trade in a market that isn't moving yet. Sharp wallets often enter days before a market starts to shift. By the time the headline lands, they're already positioned. Watching the price chart against the wallet's entry timestamp is genuinely informative.
Multiple sharp wallets converging on the same side of a market. When one wallet has a view, it's one signal. When five wallets you've identified as sharp all take the same side within a short window — that's a pattern. It's not a guarantee of anything, but it's hard for any one of them to fake.
Position exits. "Smart money is leaving" gets less attention than "smart money is entering," but it's just as informative. A wallet that sized up then quietly unwound usually saw something.

None of this is novel. It's how anyone watches markets where the book is public.

Step 3: why this is unsustainable manually

For about a month I tried to track ten wallets by hand — bookmarks, a spreadsheet, refreshing pages, an ad-hoc Telegram group with myself.

It doesn't work. Polymarket trades around the clock. The signal you cared about happens while you're asleep, or at lunch, or in a meeting. By the time you refresh, the trade is hours old and the price has moved.

The on-chain transparency turns into a curse: the data is public, but the only way to use it is to stare at it continuously, which no human will do. What's missing is the boring infrastructure to watch for you.

What I built

PolySignal is a Telegram bot that does the watching. You pick wallets from the live leaderboard (one tap each), and it pings your Telegram the moment they trade. Each alert carries:

Wallet, side, outcome, market.
Size and price.
The wallet's track record from its closed positions: win rate, realized PnL, ROI.
A "conviction" line when the trade is materially bigger than the wallet's usual size.
A line confirming the data is on-chain on Polygon — the source is verifiable.

It's read-only. It doesn't connect to your wallet, it doesn't trade, it doesn't ask for keys. It's an information service over public data — closer in spirit to a market-data terminal than to a typical crypto-Telegram tip channel.

Two features matter more than they look:

The activation moment. A new user follows five wallets in one tap and immediately sees a representative alert, so they understand the product before any trade happens. The hardest part of an alert tool is the empty-watchlist day-one experience.

Consensus alerts. When three or more of the wallets you follow take the same side and outcome of the same market within a day, you get a single consolidated alert. This is the signal you can't easily get from looking at any individual profile.

The free tier batches trades every 15 minutes. The paid tiers (priced cheaply on Telegram Stars while we collect conversion data) get real-time alerts, category filters, a daily digest, and custom alert rules.

A small honest note

I've tried to position PolySignal as what it actually is: an information tool, not advice. Polymarket isn't available in every region — that's the user's responsibility to check, and the bot says so. Past results of any wallet are past results. None of this is a prediction or a recommendation.

If you find the public-on-chain-data observation interesting and you've been on Polymarket: try the bot. Tell me what's broken. The link is t.me/PolySignalAlertsBot?start=devto — feedback comes to me directly.