Forem: Слава Жуланов

当三个高水平钱包押向同一边：Polymarket 上的共识信号到底意味着什么

Слава Жуланов — Tue, 26 May 2026 05:12:39 +0000

跟踪 Polymarket 上的特定钱包几周之后，我注意到一个模式。绝大多数时候，一个高水平钱包成交只是一个信号——如果你本来就信这个钱包的判断，那它有意思，不然就是一条数据。但偶尔会出现另一种情况：我标记为高水平的钱包里，有三到四个，会在一天之内押向同一个市场的同一方向。 不同的钱包。不同的规模。同样的方向。

这种巧合比任何单一笔交易都更难用偶然来解释。所以我把它做成了 PolySignal 里独立的一种提醒类型。这篇就来说说什么是共识信号——以及它不是什么。

前提

Polymarket 完全运行在链上。每个仓位都是公开的。常年排在排行榜前列的钱包是可观察的：交易的是哪些市场、什么时候交易、规模多大、最终结算成什么样。这里没有秘密，只是人肉跟踪非常费劲。

当你同时关注一小撮高水平钱包时，他们每一笔交易都携带了关于"该钱包对这件事怎么看"的一点信息。单个交易者的观点是一个数据点。值得问的问题是：当多个相互独立的交易者押向同一边，事情会发生什么变化？

为什么阈值定在三

PolySignal 的共识提醒触发条件是：用户关注的钱包里，至少有三个，在 24 小时窗口内，押向同一个市场、同一个 outcome 的同一方向。

为什么是三？

二是统计基线上的常态巧合。 高水平钱包关注的市场互相重叠；在任何一个活跃日，排行榜里有一半的人都在那两三个热度最高的问题上有仓位。两个钱包同向，几乎只是噪声里的常态。
三个钱包要"碰巧"同向，结构上很难。 它要求三个独立判断在同一个市场、同一个窗口、同一边——而且 Polymarket 上的高水平钱包通常是专才（有人专做政治，有人专做加密，有人专做体育），所以三个钱包跨领域汇流就更稀有。
四个一度也试过，但过滤得太狠。 我宁愿轻度多提醒，也不要错过这种事件。

这个阈值是可配置的。三是默认值，从我观察的几周看，它跑出来的模式是合理的。

它不是什么

共识信号不是预测。不是推荐。它是一种描述：你关注的钱包里有三个、且都拥有可信的历史结算战绩，刚好在同一个市场押向同一边。过去的巧合不保证未来还会相关。这条信号告诉你的是"谁站在了哪一边"；接下来怎么做，是你自己的决定。

之所以要把这句话说清楚，是因为人看到"我关注的三个钱包都押向同一边"时，本能会把它读成"这一边一定会结算正确"的证据。有时确实是。有时不是。这个模式的价值是统计意义上的，不是确定性的。

我在实际跑的过程中观察到两种典型的失败模式：

在"明显的一边"上凑齐共识。 当一个市场拿到一个新闻催化、价格被推到 90 美分时，会有大量钱包在 91 美分扎堆进场，赌剩下的那一点 gap 会闭合。这时三个"高水平"钱包押向明显的那一边，不是信号——他们跟所有人看到的是同一条新闻，只是他们恰好在你的关注列表里。

迟到的共识。 三个钱包押向一个已经走了 30 个点的市场——这告诉你的是共识曾经在哪，而不是它接下来要去哪。当共识在行情走完之后才出现时，它的信号价值会迅速衰减。

事后看，缓解措施很直白：市场安静时提醒更有意思，市场嘈杂时提醒就没那么有意思。我考虑过加一个"当前市场在窗口内已经移动 > X"的抑制器，但目前我宁可把所有共识事件全推出来，让读者自己做判断。

它真正能捕捉到的

共识提醒擅长捕捉的几类模式：

早期进入还没火起来的市场。 一个新市场上线，你关注的三个钱包各自独立地决定"这里值得开一个仓"。市场价格还在 50/50 附近。这类信号是信息含量最稳定的一类。
方向上的协同转折。 一个市场一直在某个价格带里震荡，某一天，你的三个钱包同时押向同一边、几乎同一时刻开仓。多半是发生了什么、他们都注意到了。
长结算周期市场上的高水平钱包卡位。 几个月才结算的市场，有时候会在结算前几周就出现高水平钱包的共识，市场其它部分要再过几周才反应过来。

它捕捉不到的：

钱包在离场。 离场和入场一样有信息量，甚至更高——但入场端的共识检测不能直接显示"大家都在拆仓"。后面我大概会单独加一种离场共识提醒。
单一钱包的高信念交易。 一个高水平钱包在几个月内下了它最大的一仓——这是行为意义上的高信念信号——属于另一类信号；PolySignal 里把它处理成单笔交易上的标签，不放进共识。

实现

技术好奇的同学可以看一下：检测逻辑是每条要推送的提醒上跑一次 DB 查询。对每一笔新交易，我查这位用户关注的其它钱包里，最近窗口内有没有 (市场, 方向, outcome) 完全一致的新交易。如果不同钱包计数跨过阈值，就触发共识提醒；在消息发出之前，先把一条 SentConsensus 记录提交进库，这样即使发送失败也不会重复推送。

代码不多——真正费心思的是阈值和窗口的选择，而不是实现本身。

我自己用它的方式

每次共识提醒出现在我的 Telegram 时，我把它当成一个 flag，不是一个指令。我会问自己：这三个钱包看到了什么、是我还没看到的？也许他们读了我错过的报道。也许他们在某个领域里有专业判断，市场还没定价进去。也许他们三个看的是同一个不完整的图景——那么问题就变成，我对这件事有没有自己更强的独立判断。

信号是一个问题的开头。答案，是你自己的。

跑在哪里

如果你看到这里、又想在自己的 Telegram 里看到共识信号：我做的 PolySignal 就是为了让我不用再在 Excel 表里人肉关联那些交易。共识提醒是 Pro 档功能，bot 的其它部分免费。

诚实声明：PolySignal 报告的是公开的链上活动。本服务为信息工具，不提供任何投资建议，不保管资金或私钥。Polymarket 并非在所有国家/地区可用，请自行确认。

不引入任何区块链库，用 Python 写一个链上提醒 bot

Слава Жуланов — Mon, 25 May 2026 21:41:01 +0000

PolySignal——我那个监控 Polymarket 的 Telegram bot——里有一个小子系统叫 chain_watcher。它只做一件事：把 Polymarket API 报上来的每一笔交易，和 Polygon 链上真实发生的事情做交叉核对，一旦 API 数据对不上就通过 Sentry 报警。

大约 280 行 Python，唯一依赖是 httpx。没有 web3.py，没有 eth-account，也没有 eth-abi。下面我会把"从 Python 里只用标准库 + 一个 HTTP 客户端读公开链上事件"这件事走一遍，因为 (a) 我自己确实需要做，(b) 大多数教程一上来就让你去装 SDK，但对于只读型的监听场景，SDK 完全不必。

这不是一篇反 SDK 的檄文。如果你要签交易、发资金、做严肃的 ABI 工作，请用 web3.py。我这里的边界很窄：只是从一个已知合约里读特定事件，纯 httpx + JSON-RPC 就能干得很干净。

"监听链上"到底是在干什么

一个区块链节点对外暴露 JSON-RPC 接口。你可以向它问问题：

"你当前在哪个 block？" → eth_blockNumber
"把符合这个 filter、区块号 N 到 M 之间的全部 log 给我" → eth_getLogs
"这个 hash 对应的交易长什么样？" → eth_getTransactionByHash

对一个提醒 bot 而言，只需要前两个。你反复轮询链顶，问："从我上次检查过的那个 block 开始到现在，合约 X 里有没有符合这个事件签名的新 log？"如果回来有新 log，解码、推消息，就这样。

四十行轮询循环，十行 JSON-RPC 客户端，二十行事件解码，剩下都是粘合逻辑。

JSON-RPC 客户端

一个节点就是一个监听 HTTP POST 的 RPC URL。每次调用就是一个 JSON body。你不需要 SDK，只需要一个 HTTP 客户端和一点耐心。

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")

整个客户端就是这些。上面再加两个简便方法：

    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,
        }])

为什么要做重试？公共 Polygon RPC（polygon-rpc.com 那一类）会零零散散返回 5xx。在同一个 tick 内做两次半秒级重试，可以平滑掉这种波动，又不会把整个轮询卡住。

过滤你真正想要的事件

合约触发的事件带有一个固定签名。对 Polymarket 的 CTF Exchange V2 来说，我关心的是 OrderFilled：

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

以太坊 log 的 topics 字段最多承载四个东西：

事件签名的 Keccak 哈希（topics[0]）。
每一个 indexed 参数，左侧补齐到 32 字节。

对 OrderFilled 来说，topics[0] 是一个已知常量，topics[2] / topics[3] 是 maker 和 taker 地址（左侧补到 32 字节）。要找"任何涉及到我关注钱包的成交"，我会发两次 eth_getLogs——一次按 maker topic 过滤，一次按 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 是一组左侧补齐到 32 字节的地址 hex。重活节点替你干，你拿到的只有命中的那些 log。

解码一条 log

一条 log 大致长成 {topics: [...], data: "0x...", transactionHash: "0x...", ...}。topics 是若干个 32 字节 hex；data 字段是所有非 indexed 参数顺序拼接的 hex，每个参数补到 32 字节。对一个布局已知、固定字段的事件来说，解码不需要任何 ABI 库——直接切 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),
    )

就这样。每个事件返回一个 struct 风格的 tuple。

一些值得保留的"防御性细节"

两个我在 watcher 里专门处理过的生产现实：

1. 给区块跨度设上限。 RPC 抖动恢复后，"从上次看过的 block 到现在"可能跨好几千个 block。公共节点会拒绝过大的 eth_getLogs 请求，watcher 就会卡在那。所以每个 tick 把跨度封顶（我用的是 1000 个 block——按 Polygon 大约每 2 秒一个 block 算，差不多 30 分钟），watcher 在后续多个 tick 里分段追上来。

2. 这是一个交叉核对循环，不是重复入库。 我不是把链当作主数据源，而是用链来*核对*API。watcher 把链上成交记录下来，等几分钟让 API 报上同一笔交易，如果 API 一直没有，就通过 Sentry 报警。一次有 bug 的 API 响应会触发一个我能看见的信号；如果链和 API 都静默，任何一层都看不出问题，那就麻烦了。

这一段恰好是"没有 SDK"反而比"有 SDK"更强的地方：我和字节之间没有任何库。出问题的时候，trace 很短。

什么时候不应该跳过 SDK

诚实地把代价说清楚：

要签发交易就别跳过。 Nonce 管理、gas 估算、签名——这就是 web3.py 存在的意义。
要做 ABI 内省就别跳过。 动态 ABI 解析确实是个库级别的问题。
要一个客户端同时跑 ETH 加好几条 L2 还要处理各自怪癖，就别跳过。 库会替你把这些差异抹平。

对一个只盯单链单事件的被动监听器来说，以上几条都不成立。八行 import，一个 HTTP 客户端，~280 行代码。

跑在哪里

这套逻辑跑在 PolySignal 里——这是我做的 Telegram bot，会在 Polymarket 上高水平钱包成交时给用户发提醒。chain_watcher 是它里面让我能睡得着觉的那一层——尤其在 Polymarket API 偶尔抽风的时候。

如果你想看完整模块，含注释和交叉核对循环大约 280 行。乐意贴 Gist，也欢迎在评论里问问题。

我做了个付费 Telegram bot。Telegram Stars 实际给开发者多少钱，我算了一笔账。

Слава Жуланов — Mon, 25 May 2026 20:18:20 +0000

几个月前我上线了一个付费 Telegram bot。没有 Stripe，没有 checkout 页面，没有任何 app store 账号。整个订阅完全跑在 Telegram Stars 上——Telegram 自己的内置虚拟货币。后来收到了挺多问题，最有意思的答案其实是那笔数学账，但没人公开写过。所以我来写。

背景

PolySignal 是一个 Telegram bot，当 Polymarket 上的高水平钱包有新成交时，它会给关注者发提醒。有免费版，也有两个付费档（Signal 150⭐/月，Pro 750⭐/月）。订阅按 30 天循环计费，在 Telegram 里两下就能取消。没有支付服务商，没有收银台流程，连收货地址都不需要填。

如果你从来没在 Telegram 里卖过东西：你错过的是互联网上最干净的支付界面之一。但同时，账本里也藏着一处不太方便的地方。这两件事都值得知道。

用户怎么付钱

Telegram 用户先去买"Stars"——Telegram 内置虚拟货币——通过 Apple 内购、Google 内购，或 Telegram 网页内购。零售价大致是每颗 0.02 美元（比如 75⭐ 卖 1.49 美元，具体看 bundle）。然后用户拿这些 Stars 在付费 bot 里消费。在用户视角里：点一下、确认、用手机上已经绑定好的 Apple/Google 账户付款。没有摩擦。没有"我得去翻卡片"。零字段。

这就是迄今我做过的产品里，全球范围内摩擦最低的订阅支付界面。有些用户能为 PolySignal 付费，但如果让他们走 Stripe checkout，我根本接触不到这些人——同一个 Telegram，从来没输入过卡号，整个流程跟买高级表情包是同一种感觉。

开发者拿到多少

这里才是具体的数学。用户通过 Apple/Google 付款 → Apple/Google 抽 30% → Telegram 再抽一刀 → 剩下的进到你 Telegram bot 的 Stars 余额。之后你用 Fragment（Telegram 自己的市场）把 Stars 提到 TON（TON 是 Telegram 关联的网络代币），再从 TON 换成法币。

业内常引用的开发者端汇率是：约每颗 Star 0.013 美元——这是 Apple/Google 和 Telegram 各自抽完之后，一颗 Star 在开发者手里值多少。

也就是说：

Signal 150⭐/月 → 我大约净拿到 1.95 美元。
Pro 750⭐/月 → 我大约净拿到 9.75 美元。

数字看着小，因为它就是这么小。两点说明：

150 / 750 这两个定价是故意定低的。产品还没被验证，我现在收集的是转化数据；在优化每用户收入之前，我更想先看看到底有没有人愿意转化。Stars 的折算率是固定的，但我自己的零售定价是个旋钮，等我手里有了留存/流失数据再去拧它。
开发者侧的毛利是真实的：约 95%。没有什么值得提的人均基础设施成本，没有客服团队，没有广告预算。问题在量，不在单位经济模型。

提现这一边：Stars 收款不那么方便的部分

下面这部分是给 Telegram Stars 站台的人通常不会说的：真正把钱提出来的过程，本身就是一个故事。

Fragment 是从你 Telegram bot Stars 余额到真实货币之间的桥。能用，但是：

最低提现 1,000 Stars（约 13 美元）。
首次提现要延迟 21 天 — 今天赚到的 Stars，要等三周后才有资格被提出来。
结算用的是 TON，不是美元。 Fragment 把你的 Stars 卖成 TON；接下来你自己把 TON 通过有 KYC 和手续费的交易所换成法币。
Fragment 要求 Telegram 登录 + 一个绑定的 TON 钱包。交易金额到某个阈值之后还会需要身份验证——这块"没有公开文档"，意思就是：你跨过门槛那天就会发现。

如果你之前用惯了 Stripe——每日打款、直接进银行账户、链路里没有任何加密资产——这套东西会让你觉得过于古旧。但如果你本来就在做加密原生业务——TON 完全 OK，就是又一条通道而已。

最诚实的总结是：用户端方便，开发者端不方便。 用户拿到的是一个低到几乎感受不到的支付流程；开发者拿到的是一条加密 off-ramp，第一轮要走三周。

那我为什么还是这么做了

三个原因：

1. 全球触达 + 零合规负担。 我没有公司主体。我没和任何支付服务商打过交道。我没填过一张"请告诉我们你的业务模式"的表。Telegram（连同 Apple/Google）在用户买 Stars 的那个节点上就把消费 VAT 收掉了。我看不到卡数据。我看不到银行账户信息。我也无法对从来没经过我手的东西承担责任。

2. 产品本来就活在 Telegram 里。 PolySignal 的全部用户界面都是 Telegram 消息。让用户跳出 app、去某个第三方页面填信用卡，会是一笔相当重的转化税——而且我的目标用户里有相当一部分在 Stripe 根本进不去的国家。

3. "一个独立开发者能不能做出来"这条门槛异常低。 Telegram 的 Bot API 把 createInvoiceLink 写得很清楚。循环订阅有 subscription_period 参数。自动续费固定按 30 天一档（这点烦人——没有周付、没有年付的循环订阅）。successful_payment 这条 update 会在首次扣款和每个月的续费时各触发一次，并带一个 is_first_recurring 标记。整个计费层加起来大约 200 行 Python。Stripe 会更多。

给同样在考虑这条路的独立开发者一些话

如果你的产品本来就活在 Telegram 里，Stars 是正确的通道。 内嵌支付带来的转化收益，多半能盖过比较麻烦的提现机制。
如果你的产品在 web app 或独立移动 app 里，Stars 多半不值得为它绕个支付弯子。
提现链路（Fragment → TON → 法币）请在没钱进来之前就先打通。等钱已经在账上时才发现要等三周，体验非常糟。
"只能 30 天循环"是一个真实的产品约束。年付计划必须做成一次性扣款，到期后手动延期。提前为这件事在产品上做好设计。
留意用户那边实际被扣了多少。Apple/Google 可以在不改变开发者侧每 Star 折算率的前提下，单方面调整 Stars 的用户零售定价。你在 Telegram 后台看到的数字才是关键。

最后，说回那个 bot

PolySignal 就是我围绕这一整套折腾出来的 bot。当 Polymarket 上的高水平钱包有新成交时，它把提醒推到 Telegram。免费版有；Signal 档实时推送；Pro 档有共识提醒。文章上面讲到的整套 Telegram Stars 订阅机制，就是这个产品里正在跑的同一套。

如果你想从用户视角感受一下"完全用 Stars 计费"是什么样：t.me/PolySignalAlertsBot

如果你也在做付费 Telegram bot，想交换一下经验——评论区留言，我会回。

我是怎么跟踪 Polymarket 上的聪明钱的

Слава Жуланов — Mon, 25 May 2026 19:57:16 +0000

预测市场最有意思的地方

Polymarket 完全运行在链上。每一笔仓位、每一笔成交、每一次盈亏，都是公开信息，静静地躺在 Polygon 上。任何人的钱包你都能查：买了什么、卖了什么、最后从哪个市场拿走多少钱。这里没有封闭的基金，没有"受保护的"投资组合。

这是个非常少见的属性。换到别处——股票、外汇、体育——那些真正常年赢钱的人是绝对不会把账本摊给你看的。在 Polymarket 上，他们没得选。

但绝大多数用户，从来没认真看过这堆数据。

我盯了这件事好几个月，下面是我学到的东西、真正有信号意义的几类信号，以及最后我自己写出来的那个 Telegram bot——因为人肉跟踪钱包这件事根本做不下去。

第一步：哪些是高水平钱包？

第一步是先找出值得关注的钱包。Polymarket 自己有一个公开排行榜，按已实现盈亏（realized PnL）排序，可以切换今日、本周、近 30 天、历史全部几个时间窗。

盯着这个榜看了一段时间之后，有几点观察：

历史总盈亏会骗人。 历史榜首位的钱包，可能是靠一个超大市场吃了一波，之后就再没动静。你真正想看的是最近一段时间的稳定性——"近 30 天"是合适的窗口。优质钱包在多个时间窗里都靠前；昙花一现的钱包只在历史榜上有名字。

只看胜率、不看已实现盈亏也会骗人。 一个钱包靠买 90 美分的大热门赢 80%，账面上其实没赚到什么。诚实的看法是胜率和已实现盈亏一起看。更进一步，按市场类别拆分胜率——Polymarket 上的优质钱包多数是专才。某个钱包政治类市场胜率 73%，到了体育类可能只有 45%。

这是第一个教训：排行榜不是"最强交易者排行"，它只是"按你选的指标和时间窗，恰好排得靠前的人"的一份样本。把它当候选名单来读，不要当成定论。

第二步：进去要看什么？

锁定几个候选钱包之后，就进到它的资料页（polymarket.com/profile/0x...）。里面有：

已结仓位 — 每个结算完的市场，对应的已实现盈亏。
持仓中 — 当前还在持有的仓位，按当前市价标记。
活动流 — 每一笔交易，带时间戳、市场、方向、规模、价格。

这点信息已经足够搭出真正有用的信号。我慢慢留意的几类交易是：

远超该钱包平时规模的一笔交易。 一个鲸鱼做一笔 500 美元的常规交易，那就是常规交易。但同一个钱包突然下了它这个季度最大的一笔仓位——这个时刻才是值得关注的。最朴素版本的"信念度"就是：当前交易规模相对该钱包近期中位数交易规模的倍数。
进入了一个还没开始动的市场。 优质钱包经常在市场开始波动前的几天就进场。等到新闻打到台面上时，他们已经站好位了。把价格曲线和钱包进场时间戳叠在一起看，信息量是真实存在的。
多个高水平钱包同时押向同一个市场的同一方向。 单一钱包有一个观点，那是一个信号。但你识别出来的五个高水平钱包，在很短窗口里全押向同一边——这就是一个模式。这不代表任何确定性，但他们五个里没有人能单独伪造这种共振。
离场。 "聪明钱在进场"比"聪明钱在离场"得到的关注多得多，但两者的信息含量其实差不多。一个先放大仓位、后又悄悄拆掉的钱包，多半是看见了什么。

这些观察都不新鲜，公开账本类的市场里，看市的人本来就这么看。

第三步：为什么手动跟根本撑不下去

我用一个多月时间试着人肉跟踪十个钱包——浏览器书签、Excel 表、刷新页面、自己跟自己开的 Telegram 群。

这件事不可持续。Polymarket 是 24 小时不停的。你想看的那个信号，往往出现在你睡觉、吃饭、开会的时候。等你下次刷新页面，那笔交易已经过去几个小时，价格也走完了。

链上透明性反而成了一种诅咒：数据是公开的，但唯一用得起来的方式是不停盯着它看，而没有任何一个真人能这么干。缺的，是那种枯燥的、替你盯着的基础设施。

我做了什么

PolySignal 是一个 Telegram bot，负责替你盯。你从实时排行榜里挑钱包（每个一键加入），它就在这些钱包成交的那一刻把消息推到你的 Telegram。每条提醒里有：

钱包、方向、对应的 outcome、市场。
仓位规模和成交价格。
这个钱包从已结仓位算出的历史表现：胜率、已实现盈亏、ROI。
当本笔交易明显大于该钱包平时规模时，附一行"信念度"标签。
一行说明数据来源是 Polygon 上的链上记录——可验证。

它是只读的。它不连接你的钱包，不下任何单，也不要求私钥。它是建立在公开数据之上的信息工具——气质上更接近一台行情终端，而不是常见的 Telegram 喊单频道。

有两个功能比看上去更重要：

启动那一刻。 新用户一键关注五个钱包，立刻就能看到一条样例提醒，让人在任何真实交易发生之前就理解了产品是怎么用的。提醒类工具最难处理的就是"刚加完关注，钱包还没动"的第一天体验。

共识提醒。 当你关注的钱包里有三个或更多，在一天之内押向同一个市场的同一方向、同一个结果，你只会收到一条合并好的提醒。这是你从任何单个钱包资料页里都不容易拼出来的信号。

免费版每 15 分钟批量推一次。付费版（用 Telegram Stars 计费，前期价格定得很低，方便我先收集转化数据）能拿到实时提醒、按类别过滤、每日摘要，以及自定义提醒规则。

一点诚实声明

我一直试着按 PolySignal 实际的样子来定位它：一个信息工具，不是任何形式的建议。Polymarket 并非在所有国家/地区都可用——这一点请使用者自行确认，bot 里也写明了。任何钱包的过去结果只是过去结果。这里没有预测、没有推荐。

如果你觉得"链上数据全部公开"这件事本身有意思，又恰好在 Polymarket 上有交易：试试这个 bot，告诉我哪里不好用。地址是 t.me/PolySignalAlertsBot——反馈直接到我手上。

When three sharp wallets agree: what consensus signals on Polymarket actually mean

Слава Жуланов — Mon, 25 May 2026 06:46:31 +0000

A few weeks into watching specific wallets on Polymarket, I noticed a pattern. Most of the time, a sharp wallet making a trade is one signal — interesting if you already trust that wallet's read, otherwise just data. Occasionally something else happens: three or four of the wallets I'd identified as sharp would all take the same side of the same market within a day. Different wallets. Different sizes. Same direction.

That coincidence is harder to explain away than any single trade. So I built it into PolySignal as its own alert type. This piece is about what consensus signals are — and what they aren't.

The premise

Polymarket is fully on-chain. Every position is public. The wallets that consistently top the leaderboard are observable: which markets they trade, when, in what size, with what eventual outcome. None of this is secret; it's just labour-intensive to track manually.

When you watch a handful of sharp wallets, each individual trade carries some information about that wallet's view. One trader's view is one data point. The question worth asking is: what changes when independent traders converge?

Three wallets is the threshold I picked

The PolySignal consensus alert fires when at least three of a user's followed wallets have taken the same side, in the same outcome, of the same market, within a 24-hour window.

Why three?

Two is the modal coincidence. Sharp wallets watch overlapping markets; on any active day, half the leaderboard has positions in the two or three most-trafficked questions. Two wallets agreeing is barely above baseline.
Three is structurally hard to coordinate accidentally. It requires three independent reads to land on the same side, in the same window, on the same market. Sharp Polymarket wallets are also specialised — some focus on politics, others on crypto, others on sports — so three converging across specialties is rarer still.
Four was tempting, but it filtered too aggressively. I'd rather over-alert lightly than miss the event entirely.

That threshold is configurable. Three is the launch default and it has produced sensible patterns in the few weeks of observation I have.

What it isn't

A consensus signal is not a prediction. It's not a recommendation. It's a description: three wallets with strong closed-market track records have just taken the same side of one market. Past coincidence does not guarantee future correlation. The signal is information about who's positioned where; what you do with it is your own decision.

This matters because the temptation when you see "three of your wallets agree" is to read it as evidence the side will resolve correctly. Sometimes it does. Sometimes it doesn't. The pattern's value is statistical, not deterministic.

Two failure modes I've watched in real time:

Consensus on the obvious side. When a market gets a news catalyst that pushes prices to 90¢, a lot of wallets will pile in at 91¢ expecting the gap to close. Three "sharp" wallets converging on the obvious side after the news isn't a signal — it's the same news everyone else read, expressed by people who happen to be on your watchlist.

Late-arriving consensus. Three wallets converging on a market that's already moved 30 points is information about where the consensus was, not where it's going next. The signal value of consensus drops sharply when it arrives after the move.

The mitigations are obvious in hindsight: the alert is more interesting when the market is quiet, and less interesting when it's noisy. I've thought about adding a "market is currently moving > X over the window" suppressor; for now I'd rather show all consensus events and let readers exercise their own judgement.

What it actually catches

The patterns the consensus alert catches well:

Early entries into not-yet-popular markets. A new market launches; three of your watched wallets each independently decide it's worth a position. The market is still 50/50 in price terms. This is the signal class with the most consistent information value.
Coordinated direction shifts. A market has been trading in a band; one day, three of your wallets all open positions on the same side at the same time. Something changed that they all noticed.
Sharp-wallet positions on long-resolution questions. Markets that resolve in months sometimes show consensus from sharp wallets weeks before the rest of the market catches on.

The patterns it doesn't catch:

Wallets exiting a market. Exits are as informative as entries, often more so, but consensus on the entry side doesn't surface "everyone unwinding." I'll probably add a separate exit-consensus alert eventually.
Single-wallet conviction trades. A single sharp wallet putting on its largest position in months — the signal of behavioural conviction — is its own thing; PolySignal handles it as a per-trade tag, not as consensus.

The mechanics

For the technically curious: detection is one DB query per delivered trade alert. For each new trade I check the user's followed wallets and look for other recent trades that share (market, side, outcome) within the window. If the distinct-wallet count crosses the threshold, the consensus alert fires; a SentConsensus row is committed before the message is sent so a failed delivery never produces a duplicate.

It's a small piece of code — most of the cleverness is in the choice of threshold and window, not in the implementation.

The frame I actually use

When a consensus alert lands in my Telegram, I treat it as a flag, not an instruction. The question I ask is what do these three wallets see that I don't yet? Maybe they read a story I missed. Maybe they have domain expertise the market hasn't priced in. Maybe they're all reading the same incomplete picture — in which case the question becomes whether I have a stronger read of my own.

The signal is the start of a question. The answer is your own.

Where this runs

If you've read this far and want to see consensus signals in your own Telegram: I built PolySignal precisely so I'd stop manually correlating trades in a spreadsheet. The consensus alert is a Pro-tier feature; the rest of the bot is free.

Honest disclosure: PolySignal reports on public on-chain activity. It is an information service, not financial advice. Polymarket isn't available in every region — check yours.

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.