2026-08-09 23:14:31
前情提要：
我会总结分析一下最近半年来，我们团队做项目遇到的种种困难。总的来说，现在项目仍然没有找到 PMF、没有达到用户自增长的状态。与以前的项目经历不同，我可以毫不掩饰地说这个项目的官网是：http://virae.ai/
在这个项目上，团队一直在以最少的人员配置 + 最低的硬件成本去做。这种低成本主要也是为了试错。至少我是这么理解的。
一开始想要切入预测市场、做一个预测市场生态上的项目时，我们就看到了一个新闻，一个叫 Polycule 的 TG Bot 项目，算是 Polymarket 生态比较头部和知名的一个项目，因为服务器被黑客攻击、一度损失资金甚至传闻跑路，目前也已经改名换姓、整个产品换了方向。
当时忌惮这种托管私钥方面的安全问题，团队对于项目的约束是，不要做这种托管私钥类型的交易工具。
那么不做交易工具做什么呢？主要在这几个方向上徘徊：
另外还有一个团队自己发掘出来的方向：预测市场事件的语义搜索。因为无论是从 news 文本-> 提醒，还是从链上数据-> 提醒，都绕不开一个关键环节：怎么精确找到自己想找的事件？我看到一个特朗普的新闻，但是并不知道与这条新闻相关的预测市场事件是哪个、去哪里下注。
然后我告诉你为什么这几个方向没做起来：
我一开始提到我们在硬件投入上也是维持在低成本模式。有多低呢，现在整个 Virae 的后端服务器，一共用了 3 vCPU、6 GB 内存，100 GB 数据，在 AWS 上。
我并不是说这样的配置不够用，而是在这样的成本约束下，自建节点、自建 SubGraph 一类的服务自然是做不了的。举个直观的对比，运行一个以太坊节点的配置，是 8 vCPU、32 GB 内存、1 TB 磁盘、且要 IOPS 大于 10k 的固态硬盘。
这是在可以做交易工具之后、首先比较看好的方向，比如用户需要在 NBA 相关赛事下注，需要同时打开 NBA 比赛以及 Polymarket 的事件下注页面。我们能不能做一个交易终端，同时展示体育赛事的信息、以及聚合 Polymarket 的下注交易能力？
这个方向上有明确的竞品，包括 Crypto 领域的 GMGN、Axiom，预测市场领域的 Betmoar、Areas、stand.trade。
结果就是没有人用。
至于为什么没有人用，是我们一直都在反思但是不知道答案的问题。
顺便提一下，所有在 Polymarket 生态的项目，都在 Polymarket 的 Builder 榜单上。Polymarket 官方提供的榜单只有交易量总额，没有更多信息。因此我做了一个辅助网站 https://poly.dark20.xyz/ ，这些数据都是从 Polymarket 官方的公开接口拿到的，列出了每一个项目方的交易额、交易人数、甚至具体的每一笔交易的详情。由于交易接口方面的约束，同赛道的项目方一定都在这个榜单上，反之，不在这个榜单上的项目方一定不是 Polymarket 生态的项目。
在 Crypto 领域有很多 TG Bot，提供 snipe 代币的功能，或者很简便的贴一个代币的 CA 地址就可以开始交易。那么在预测市场是否需要一种 copy trading bot 来一键复制别人的交易行为呢？
比较头部的竞品很多，做的也都不错，除了之前提到的 Polycule、还有 PolyCop、Kreo、PolyBot 等。
结果也是没有人用。
至于为什么没有人用，能找到一些原因：
世界杯期间，项目准备了一些预算做活动，交易就给钱那种，来了不少来自印度的撸毛用户。当时有一个发现，大多数用户都是在手机上操作，要么在手机浏览器里打开网页，要么在 TG bot 里操作。很少有用电脑直接操作。
这一点和我们的预期有很大偏差，因为一直以来，都是在做专业的交易终端，而交易终端一定是电脑网页，也因此几乎没有刻意做什么移动端的适配。
再后来，又关注到一个用户数量很多的项目 polymtrade，是一个手机 App，在苹果商店能搜到那种。这个项目页面非常简陋、而且不支持高频交易，但是月活跃交易用户在1000以上、交易额在百万美元以上。我调查过，这个项目没有融资背景、只有 3 个开发者。
所以我们后来一方面优化移动端网页、另一方面适配了 TG Mini App，希望用户可以直接在 TG 上面打开 Mini App、就能拥有完整的体验。
结果也是依然没有人用。
高频交易就是给专业交易员操作用的，比如现在下单后、看 K 线、发现几秒钟的动量、马上操作卖出，或者同时挂很多订单、止盈止损、频繁操作。这种就要求界面操作要流畅、下单速度要快、交易反馈要准确。与之相应的，技术难度高。
低频交易是指那些佛系散户，比如今天看到什么新闻、想去某个事件上下一单、明天想起来就又下一单、下单之后也不看 K 线也不看流动性、甚至不操作不卖出，就纯粹等半年后的结算。
这两种交易频率的不同，也是产品方向上的分歧。高频交易注定使用者专业、数量少、交易量大。低频交易也许用户量多、但是交易量会很少。
有研究报告指出，整个 Polymarket 有80%的散户交易总额在100美元以下。而且这是整个 Polymarket 生态的，其中 Polymarket 官网的交易人数和交易量占了90%左右，留给第三方项目方的交易量只有10%。（研究报告原文找不到了，大概是这个数字，你不相信的话可以让 AI 重新调研一次。）
这个数据如果靠谱的话，那么 Polymarket 生态的项目会过得比较惨。看起来预测市场的交易量和收入年年新高，但是跟第三方项目方有什么关系呢？
随着项目功能越做越多，后来逐渐发现一个误区：再做一个官网。
当时正是世界杯，Polymarket 和 Kalshi 都出了 combo 交易的功能，我们就在看能不能从接口接入这种 combo 交易的能力。后来发现官方提供的 API 不支持。
这就导致一个尴尬的现象：专业的交易终端本应该是功能增强版本的 Polymarket，结果 Polymarket 出了新功能、第三方交易终端跟不上！
这也突然带来一个警醒：Polymarket 是中心化平台、不是去中心化协议！
CLOB v1 版本的时候也许还能看到一点去中心化的影子，自从 CLOB v2 之后，就实锤 Polymarket 是中心化平台了，毫无疑问。
也因此后来 Polymarket 出了 perps 交易的功能，我们根本不去看能不能接入了。接入了也没人用。
再后来，Kalshi 还出了官网版本的交易终端 Kalshi Pro，杀死比赛。
总之再做一个官网绝对是行不通的方向。
后来看 Agentic Trading 的方向比较火，很多交易所相继出了这方面的功能，我们也开始往自动交易、代理交易方向转型。转型的结果就是，目前平台上支持 BTC/ETH 的 15m/1h 市场的尾盘策略，可以配置参数一键启动。这个方向上目前看到最直接的竞品是 EVPLUS。
这里有一个考量在于，是做执行工具还是做策略？执行工具就是用户自己设定策略参数、我们只管执行；做策略就是我们找到稳健的策略或者策略参数、推荐给用户运行。对于用户来说，肯定是希望直接给策略，而对于项目方来说，因为考虑到策略风险，只能是做工具比较稳妥。
并且我诚实的告诉你，我们的项目也没有 edge；不但我们的项目没有，而且我可以负责任的告诉你，我们的竞品 EVPLUS 也没有，因为它的策略源码是公开的。
然后为了推广现在的这个 Auto Trade 功能，还开发了针对 Auto Trade 的 Paper Trading 账户和排行榜，希望做一场活动、让用户免费参与、最终 PNL 高的用户可以获得 100 USD 的奖励、培养用户习惯。
原本计划明天周一开始这个模拟盘交易大赛活动的，后来一个团队外部的成员，以命令式的语气、在没有经过团队讨论的情况下、就直接告诉运营人员推迟这个模拟盘交易大赛的活动。也因此我现在甚至不知道这个活动还搞不搞、什么时候开始。（你会不会没看懂，什么叫团队外的 “成员”？）
事实证明经过了预测市场的大热点世界杯，我们在预测市场辅助工具这个方向上没有做起来。后来又开始考虑做更多领域的集成，比如前段时间看 Robinhood Chain 比较火，就集成了 Robinhood 的 Memecoins 交易。
再后来又看到 Robinhood Chain 上有一个叫 SLVR 的链上游戏很火、交易量很高，我就直接把他们公开的合约源码拿下来、自己开发前后端、直接出了一个类似的仿盘出来 VORE（只是演示，千万不要玩）。这个 VORE 是为了证明我们能做出和 SLVR 一样的链上游戏。同时也在考虑 SLVR 这种游戏的玩法有没有什么 Virae 能够借鉴的。
总之就是这个阶段已经不局限于预测市场，而是开始打 Memecoins 或者其他链上热点项目的主意了。
为什么我现在可以做这样一个总结呢，因为你能看到，我们尝试了各种各样的产品方向，结果都不太尽人意。我作为开发者的角度，已经没有灵感下一步还能做什么了。因为很明显，不管做什么新功能，都不会有更多人来用，这已经不是开发层面的问题。
我其实之前反复跟团队说一个道理，如果 100 个用户进来了、用着不好用、功能有 bug、走了，那是产品或者开发的问题，我们就可以去优化产品、修复 bug、提高用户留存率。但事实上是，根本没有 100 个用户进来，连来都没有来。所以问题在哪里？
2026-08-03 00:32:47
今天有一个 “重大” 发现想要分享：PySonar2 可以大幅度降低 AI 在执行 Python 项目修改的时候的 Token 消耗。
这是 ChatGPT 运行出来的 benchmark 结果：
补充一下这个 benchmark 任务的定义：
具体任务有 2 个：
概括来说，就是基于一个测试专用的大型 Python 项目，设定两个方向的任务，一个任务横跨多个目录和文件，另一个任务目标明确、不需要跨文件定义，然后分别用 skill 和不用 skill 执行。
结果如你所见，使用了 skill 之后，速度略微有提高，token 消耗量则直接减少 30%！
说明一下，刚才提到的 skill，是指基于 PySonar2 源码封装的、符合 AI Skills 规范的 skill，你可以直接告诉 ChatGPT：
帮我安装这个 skill 到用户级目录：https://github.com/smallyunet/pysonar2
就可以了。
这个 PySonar2 的仓库是 fork 出来的，因为原版的 PySonar2 仓库是王垠 13 年前的项目，已经有一些工程和特性方面的 “过时”，所以做了一点点新的工程方面的包装。当然 PySonar2 最核心的词法分析、类型推断是没有过时的。
除了这个 AI skill，我还把 PySonar2 以 VS Code 插件的形式发布了，安装后可以在 VS Code 上打开 Python 代码之后，鼠标 hover 上去看到 PySonar2 的类型推断：
解释一下为什么 PySonar2 可以帮助 AI 节省。
如果你是程序员并且经常让 AI 写代码，一定会看到 AI 会使用大量的 rg，每一次任务都会把各种代码文件看一遍，然后继续执行代码修改。而 PySonar2 可以提供一种基于代码语义的、基于 AST 结构分析出来的这种内容：
{ "symbol": "User", "definitions": [ {"file": "models.py", "startLine": 12} ], "references": [ {"file": "service.py", "startLine": 48}, {"file": "tests/test_service.py", "startLine": 31} ], "affectedFiles": [ "models.py", "service.py", "tests/test_service.py" ]}直接在一个文件里把每个变量定义的来龙去脉、相关源码文件总结出来。相当于本地建立了一个索引，AI 直接看索引，而不需要每次看一遍全部代码。
因为任何 AI 工具目前都有两方面限制：
那么 PySonar2 现在是否还具有某些独特的价值呢？答案是有：
很多同类型的、号称节省 Token 的项目，都是基于关键词匹配、甚至 embedding 的匹配，与 PySonar2 的语义分析不在一个层面。
不过毕竟已经过去了 13 年，PySonar2 已经 13 年没有在学术理论上继续更新，要说 PySonar2 仍然处于世界前沿是不可能的。但是 PySonar2 因为开源、代码轻量、逻辑清晰，在 Agent 适配方面也许会有独特的优势和潜力：
既然针对 Python 项目，PySonar2 可以帮助 AI 节省大量的 Token 消耗，那么其他语言的项目呢？JavaScript 是否可以借鉴同样的思路？以及更多脚本语言？同样的思路，已经不局限于 PySonar2 这个工具了。
比起让 PySonar2 这个古老的项目重新发挥价值，我更在意的事情是：在 AI 时代，还有哪些代码工具是有价值的？
因为人已经不需要写代码了，甚至不需要看代码了。但是 PySonar2 在这个场景下发挥了巨大的作用，让我看到了不一样的希望：
（与此同时，我还在优化另外一个项目：EchoEVM。基于 EchoEVM 的 EVM 解释器底座，让 AI 能够在编写 Solidity 脚本的时候、有能力看到脚本文件字节码级别的执行过程。这种 debug 工具对人类没什么用，但是对于 AI 极其有用，因为人类看不懂字节码、AI 可以）
PySonar2 作为拥有学术级别原理的工具，在人类已经不需要写代码的今天，仍然能够发挥价值、让 AI 节省 Token、给使用者省钱，这是真正意义上的效率工具。
如果你不了解 PySonar2 的背景，分享几篇相关文章可以看一下：
要补充说明的是，原文中对于节省 40% 的 Token 消耗，仅限于某些特定的、大量跨文件、变量名重叠、语义不清晰的任务。经过后来更丰富的测试，最新的 benchmark 结果 显示，很多通用任务中，如果强制使用 Pysonar2，消耗的 Token 和时长反而是增加的。不过由于 PySonar2 提供的精准语义分析能力，在 benchmark 中使用了 PySonar2 的准确率能达到 100%，给 AI 提供语义级别的事实证据是 Pysonar2 目前对于 AI 最明确的增强。
至于 “先给代码建立语义索引、修改代码直接使用索引” 的方式是否能够提交效率、节省 Token，我后来创建了单独的项目 code-engram 来进一步测试。目前 code-engram 主要支持 TypeScript 以及适配了 Pysonar2，唯一正向的 benchmark 数据是，在大型项目的 rename 任务中，Token 消耗节省 60%。但是对于小型项目或者其他通用任务，Token 消耗反而是增加的。这一点和 Pysonar2 单个仓库的结果类似。所以 code-engram 这个项目也仍然在继续探索中……
2026-07-28 00:50:05
在 bitcointalk 上看到一个帖子：How to handle weak scripts?
这个帖子说明了一种 Taproot 脚本的漏洞，无需经过签名验证，任何人都可以花费在这个 UTXO 上的余额。在 mempool 浏览器的界面上可以清晰看到，这笔 f460...5bc2 交易转出的一方有一个 unsigned 的标识，这个标识在比特币网络上并不多见：
帖子中描述的 Taproot 脚本的逻辑是这样，这也是 f460...5bc2 交易真实执行的脚本过程：
OP_PUSHBYTES_32 fa9b5ec193f735c41b804fc6ace1d28e81a299fc815c0f5009dd2dd7d0293c3bOP_CHECKSIGOP_IFOP_PUSHBYTES_32 ff1275b635cd160914cfe1bc516f521abde0fc8ae3fd92ae01ca16449e4758e9OP_ENDIF可以简化为：
<pubkey A>OP_CHECKSIGOP_IF <pubkey B>OP_ENDIF比特币的 Taproot 是基于栈结构的脚本，理解起来需要绕弯，把这个脚本翻译为 JavaScript 代码的话，大概是这个意思：
function isTrue(...params){ var pubkeyA = params[-1]; params--; if (checkSign(pubkeyA)) { return true; } else { // } return params[-1];}从代码来看，在正常使用流程下，假如输入的参数是 [pubkeyA]，那么 checkSign(pubkeyA) 为 true，最终 return true，这个是合理的。
假如输入的参数是 [pubkeyC]，那么 checkSign(pubkeyA) 为 false，下面的 else 分支什么都不做，最终 return null，依然不是 true，这个也合理。
这个脚本的漏洞在哪里呢，在于 params 是一个数组，用户未必只输入一个参数。
在漏洞逻辑下，可以输入非预期的参数组合 [true, pubkeyC]，那么按照后面的执行流程，当进入 else 分支什么都不做之后，return params[0] 会把 true 给返回出来。
这里面存在几个基础的问题：
所以很简单，这个所谓的脚本漏洞，实际上是作者自己写了不严谨的代码导致的。要注意这里指的不是比特币的作者，仅仅只是比特币的用户。比特币的 Taproot 相当于以太坊的智能合约，任何人都可以写一些脚本规则，来决定钱怎么控制、怎么花。只不过比特币的脚本写起来复杂，而且不是图灵完备，所以很多人忽略了比特币可以自己写脚本这件事情。
很明显这不是一个比特币协议级别的漏洞，比特币的共识只负责按照脚本规则正确执行，而脚本逻辑是否有漏洞，跟协议无关。
而且事实上无论是比特币钱包还是比特币生态的项目，如果依赖于 Taproot 的脚本逻辑，一定会经过审计公司来审核代码，这种低级错误出现在主网上的情况恐怕会非常少。
另外 Taproot 这种脚本设计的隐私性其实很强，我们只能知道比特币地址 bc1p 开头是 Taproot 脚本，0xc0 开头的是当前版本号，但是一个 UTXO 在没有被花费之前，网络上是无法看到脚本具体内容的。而在被花费的那一刻，大概率全部的钱都已经被转走了。一个 P2TR UTXO 被创建的时候，链上只保存这棵树结构的根节点哈希，任何可以解锁 root 的路径都是有效输入，这些有效输入只有在花费的时候，链上才需要根据具体的 leaf 和 key path 去验证。而且即使某一个 leaf 被公开，链上也只能看到其中一个，看不到同一个 root 下的其他 leaf。
比特币从设计之初，就提倡每一笔转账都使用一个新的地址，实际上大多数靠谱的钱包也是这么设计的，这本身就很大程度规避了漏洞脚本被再次利用的风险。
所以无论是从技术上和商业逻辑上，这种漏洞脚本的出现都是极其小概率的个例，完全就是脚本作者自己写错了。主网上存在漏洞脚本的可能性很小。
有没有可能网路上真的存在这种漏洞脚本，不需要验证签名就可以把钱转走的？
先从 bc1p...cn8z 这个例子入手，有几个问题：
这显然不是钱包 App 提供的功能，而且比特币的交易比较麻烦，得把 UTXO 来源的交易和编号都作为参数才能构造出交易。这是一个示例脚本 taproot-script-path-demo.mjs，可以这样来运行：
TXID='0618d93bc4eef77f4b47c4b4b188011f95c7ccb929e6226df2774b88b5d4693d'VOUT='0'INPUT_SATS='15000'DESTINATION='bc1px6jn77jd4tplp94q46svkuutc53wtn24dk34wxp4dfur6tvez89swvlcmj'FEE_SATS='1000'node outputs/taproot-script-path-demo.mjs \ "$TXID" \ "$VOUT" \ "$INPUT_SATS" \ "$DESTINATION" \ "$FEE_SATS"如果你不小心把钱打到了地址 bc1p...cn8z 上，就可以用这个脚本，在没有私钥的情况下，把钱转出来。但是要小心脚本里的 xOnlyKey 和 payload 都是硬编码，如果换一个目标地址，这两个值就不一样了，得用另外的值。那么这个值应该是什么呢？这个值只有在 P2TR 被花费过之后才能知道。
这也就意味着，即使我们知道链上某一个地址有余额、脚本有漏洞，因为不知道整个树结构、拿不到 xOnlyKey 和 payload 的值，我们也无法动这个地址上的钱。从这个角度看，比特币上的资产安全程度还是很高的。
同样有一个示例脚本来干这个事情：audit-taproot-neighborhood.mjs，结果就是，没有。这个作者把全部关联地址的钱都转走了，不存在这种低级漏洞。
这个程序可以扫描整个比特币网络上类似的脚本漏洞：tapscript_weak_finder
扫描逻辑是这样：
0xc0
[01, <empty signatrue>] 的排列组合，处理 0 个参数、1 个参数、2 个参数的情况，一共 12 种01, <empty signatrue>，扩展到小整数和一些常量，比如 02, 03, true, false 等[[data, sigA, sigB]]，尝试变换组合，比如 [data, "", sigB]、[data, sigA, ""] 等OP_SUCCESS80的脚本，或者目前规范还没有定义的公钥类型，会记录到数据库当然我会告诉你运行结果。如果你运行了这个开源程序，会得到和我一样的结果和结论。我的启动参数是从区块高度 709632 开始，这是比特币主网启用 Taproot 的高度，到 959701 高度结束，也就是最新的区块高度。
一共扫描了 71037 个区块，扫描了 127119410 笔交易，扫描到 1000061 个 Taproot 地址，其中 427378 个属于当前程序没识别出问题的脚本，12 是有可能有漏洞的弱脚本。
在 12 个有可能有漏洞的脚本中，8 个属于不需要签名的弱脚本，1 个属于始终返回 OP_SUCCESS80 的非漏洞脚本，3 个属于包含扫描程序解释器不支持操作码的非漏洞脚本。
来逐个分析一下扫描到的有可能是 weak script 的交易。最终输出的、未经加工的结果数据在这个文件：result_report.json，可以还原出我下面提到的地址和交易、脚本。
首先扫描到的这个 taproot 地址出现在 758737 区块：bc1p...2354
这个地址出现了 2 笔异常交易：
先说结论，这 2 笔交易是非常专业的开发者在演示比特币主网的 BIP342 规范而发起的。
第一笔交易 00c1...c40e 包含 2 个 witness 参数，是用来测试交易的。
第二笔交易 73be...2a7e 就离谱了，包含 500001 个 witness 参数，OP_RETURN 的内容解码后得到 “you’ll run cln. and you’ll be happy.” 的文本。
TapScript 的规定是，初始栈最多只能有 1000 个元素，但是第二笔交易出现了 500001 个元素而且交易成功了，是因为 BIP342 规范定义，如果脚本中出现 OP_SUCCESSx，则无论脚本包含多少元素，一律视作成功。因为 OP_SUCCESSx 属于目前还未明确支持、但是预留给未来有可能使用的操作码，所以 BIP342 这样来规定了。
很明显第二笔交易就是用来演示这种状况的。也因为这笔交易包含大量参数，花费了超过 700 美元的手续费。
其次扫描到的地址出现在 771740 区块；
这 3 个脚本对应的交易包含了 OP_CHECKSEQUENCEVERIFY 操作码，扫描程序没有处理这个操作码，所以认为是异常给挑出来了。OP_CHECKSEQUENCEVERIFY 操作码的含义是，必须等待多少个区块，才可以使用地址里的资金。属于是典型的 TimeLock 脚本。
在区块高度 775722，扫描到了这个地址：bc1p...amq6
这是一个真正有逻辑漏洞的脚本，不需要任何签名就可以转移资金。这个脚本明显是一个 Ordinals 数据结构的封装，可能是某个开发者在尝试自己开发类似 Ordinals 的协议。当然这个地址上的钱当时就被全部转走了，现在没有余额。
另外还有几个地址，数量不多，大多数是 Ordinals 的测试交易，就不一一详细解释了：
bc1p...3hu0，区块高度 777335，一个 Ordinals PNG 图片bc1p...xgdr，区块高度 777617，一个加法运算，没有校验签名bc1p...gq7d，区块高度 777681，一个测试脚本，固定返回 truebc1p...9x3t，一个 Ordinals 的 Hello World 脚本已经扫描了从 Taproot 脚本功能上线到至今为止全部的区块和交易，真的出现了少量 How to handle weak scripts? 中描述的类似的脚本漏洞，不过那些地址上都已经没有余额了。
这件事情另外的启发：
2026-07-10 19:53:28
现在做 Crypto 方向的项目，一般会选择 Privy.io 或 Turnkey 来作为钱包的基础设施提供商。这些钱包设施提供了注册登录方面的集成，可以用传统方式邮箱、Google 登录，也可以用 web3 一点的方式，比如 MetaMask 钱包或者 OKX 钱包登录。更重要的是这些钱包设施解决了钱包安全的问题，允许给用户创建 embedded wallet，如果不使用这些钱包服务，项目方需要自己在服务器上保存用户的私钥，这是很危险的，尤其是对于中小团队来说，安全问题是很沉重的负担。Privy 或者 Turnkey 的解决方案是，私钥由他们来保管，储存在 TEE 一类的加密硬件中，项目方只需要通过 API 来访问和使用钱包。
至于 Privy 还是 Turnkey 的取舍问题，比如我们经常在看的 Kreo、PolyCop、polymtrade 等项目都在用 Privy。这些项目列表都在 Polymarket Builder 榜单 上。Polymarket 的这个 Builder 榜单上，列出了每一个 Polymarket 生态的项目方交易量排名。GMGN 也用的 Privy。
用 Turnkey 的项目也有，比如 Axiom、alchemy 等。我们当时用了 Turnkey。一开始是因为 Turnkey 从定位上对自动化运行的 Trading Bot 更加友善，Privy 定位上有很重的对前端界面 SDK 的依赖。后来又发现了一个 Privy 和 Turnkey 比较大的区别：是否支持 Telegram 注册登录。
Privy 支持 TG 登录，Turnkey 不支持，为什么呢？
因为 TG 没有像 Google 那样成熟的 OAuth 体系，TG 账号本身无法像 email 或者 wallet 一样给 Privy/Turnkey 一个 identity provider。Privy 针对这种场景做了简化，你用 TG 登录，登录后 Privy 代替你去通过 API 请求钱包的操作，实际上此时 Privy 后端 “就是你”，假如 Privy 后端的服务器被黑了，你的钱包权限会完全暴露在黑客手里。而 Turnkey 比较生硬，无法提供 identity provider，就不能让你操作钱包，Turnkey 的后端不愿意代替用户承担这种权限风险。
所以这是我们发现的 Privy 和 Turnkey 之间比较大的场景支持程度上的差异。如果想要用 Turnkey 并且支持 TG 登录，就得专门做一个 TG Miniapp，登录的时候唤起 Miniapp 来完成。
Polymarket 上的订单系统叫 CLOB，下单等行为都是在和 CLOB API 交互。4月28日，Polymarket 正式启用 CLOB V2。对于我们这种下游项目来说，最大的变动是需要换掉一些合约地址信息，比如 Copy Trading 功能需要扫描链上交易，以前监听的是 V1 版本的合约，迁移后监听的是 V2 版本的合约。此外如果下游不适配也是可以的，因为大体上兼容旧版本的订单参数。
而 CLOB V2 也引入了 FAK、FOK 等 Market Order 在使用的参数，这些参数直到一个多月以后我才发现它们的差异。因为在 V1 版本订单如果没有立即成交，会把没成交的部分自动挂单为 Limit Order，但同时又要求 Limit Order 的 shares 数量必须大于 5。所以用户有时会遇到一个奇怪的错误，为什么订单 shares 数量必须最小是 5？又为什么有时候会提醒最小订单金额是 1 美元？为什么有时候能成功有时候失败了，最小金额不是固定的？用上 FAK 参数的话倒是没有这种旧的问题了。
5月4日，Polymarket 发公告说启用新的 Deposit Wallet，不再使用旧版本的 Safe wallet。这是一个 breaking change，所有旧的用户依然兼容，但是新的尤其是通过 api 操作的钱包，都将使用新的 Deposit Wallet，也就是说下游项目必须兼容。
这个时间点非常微妙，因为我们原本计划项目 Beta 版本上线的日期是 5月5日。也因此当时连续两三天我紧赶慢赶去适配这个 Deposit Wallet 的迁移。这本身不是一件特别难的事情，但是由于突然升级带来的措手不及，以及上线的 delay，还是有一点点压力。
至于集成过程中遇到的唯一挫折，是 Polymarket 的 Migration 文档里没有写新的 Deposit Wallet Implementation 地址。在用 Factory 合约创建钱包的时候，需要一个 implement 合约作为参数，不同的 implement 合约出来的钱包地址是完全不一样的。而重点不只是我们用哪个地址，而是 Polymarket 的 Relayer api 用哪个，因为在新的这种 Deposit Wallet 模式下，所有的钱包操作都会通过官方的 Relayer api 了。以前用的 Safe wallet，其实我们可以自己直接去链上调合约的。Polymarket 的这个改动，反而让钱包体系更加不那么去中心化。至于正确的 implement 的值，则是需要直接从 Polymarket 发布的 SDK 里去读。而且当时还遇到个小坑就是 Polymarket 发布的不同 SDK 之间用的 implement 地址还不一样。不是同一个 SDK 不同版本，而是那种不同 SDK，比如 client-sdk, server-sdk 这种。当时 Discord 群里遇到这个集成问题的开发者非常多。
刚才提到新的 Deposit Wallet 必须要通过 Polymarket 官方的 Relayer API。我们在迁移后并且项目上线一段时间、做活动，紧接着就遇到了另一个坑：Unverified 状态的 Builder API 只有每天 100次的请求额度。
看出 Polymarket 的阴险之处了吧，先是要求所有新用户都用 Deposit Wallet，而新的 Deposit Wallet 自然必须通过 Relayer API 来操作钱包，再然后你会发现，Relayer API 的请求是有额度限制的！如果是原本的 Safe wallet 可以直接链上操作绕过 Polymarket 的 API 额度限制。现在不行了。
这个 Relayer API，每次创建新的钱包都要用、每一次从钱包里 withdraw 钱要用，所以这是一个高频率会用到的接口。
针对这个限制的缓兵之计是，Polymarket 默认用 Builder API 来对 Relayer API 授权，但是 Relayer API 却没有要求 Builder API 具体是哪一个。所以我注册了 10个账号、每一个账号都创建了 builder api，配置到服务器里，用来暂时缓解 relayer api 的额度限制问题。每个账号每天100次请求额度，也就意味着 10 个账号一天有 1000 次额度。因为 verified 从提交到审核需要两到四周的时间，是一个很长的周期。
当然最终还是通过了 Verified，现在我们的项目已经出现在 Polymarket Builder 榜单上，并且状态是 Verified。
7月6日，又是 Deposit Wallet 的问题。我们发现了一个很严重的 bug，自从 7月1日以来注册的全部用户，创建钱包都失败了！而因为用户反馈少，出问题很多天我们才发现这个问题。也就是说，新注册的用户，注册完之后如果充值，会把钱充值到错误的地址上。
为什么会出现这个 bug 呢，因为 7月1日，Polymarket 直接修改了创建钱包的逻辑，用上了 beacon 的方式去创建代理钱包，而且连公告都没发，直接改变 API 接口的行为。这种改动，是需要下游项目方主动适配的。
我们也有错误，我们的错误之处就在于没能及时发现这种异常，并且在程序前后端加上足够的保护性、防御措施。针对这次事故所有用户充值钱到错误地址的，全部金额都赔了，好在金额不大。
Polymarket 针对世界杯的市场，新出了一个叫 combos 的功能。我们就开始评估是否可以接入这个 combos 的功能。结果就是，从 combos 文档 上看，API 只提供了针对做市商提交 quote 的接口，没有提供作为普通用户作为 taker 角色去下单的接口。
Polymarket 从 6月4日开始运作 combos 的接口，看起来也是在辛苦 build 中。
7月10日，用户反馈遇到了订单交易失败的问题。经过排查后发现是订单的 tick size 有了变化，所有的世界杯市场都支持 0.0025 (0.25¢) 级别精度的 tick size。在此之前 tick size 只有固定 4 种，这个 0.25¢ 属于第 5 种（枚举类型）。
同样的，这个变动其实 Polymarket 早在 7月2日就上线了，但是我们直到 7月10日才发现 bug。
所以你看到了，一直以来，我们都在不断的追随 Polymarket 的脚步，一直不断的响应 Polymarket 的功能更新和变化。
也因此，在构建项目的过程中，我们也开始逐渐意识到这样的项目误区：再做一个官网。
如果定位是 “再做一个官网”，项目方就会陷入非常被动的处境。而且 Polymarket 家大业大，官网 UI 做的也好，有功能都是第一时间上官网，再者官网自家的服务器，下单速度也快。我们的订单速度再快也不可能快过 Polymarket 官网。
这是一件尴尬的事情，如果想要做的比官网使用体验好，客观上难度是很高的。Polymarket 不是 memecoins，一般 memecoins 没有官网至少不会有官方钱包、官方 DEX，但是 Polymarket 有官网、有官方解决方案。Polymarket Builder 的定位，从来都不是说，Polymarket 是一个开放的去中心化协议，大家都来建设项目去玩。
与之相反，Polymarket 最近的功能更新上也越来越往中心化的方向走，定位更像是中心化交易所，比如 Binance 这种，Polymarket API，就是 Binance API。做 Polymarket 生态的项目，就有点像是做 Binance 的 Trading Bot 一类事情。
2026-07-05 01:32:20
更新比较频繁，谨慎使用。是我自己实际在运行的代码，虽然策略简单但是开发量并不小，如果想尝试可以直接使用。另外如果你不相信我接下来对于策略的判断，则务必亲自尝试 🐶
顺便说一个开发体会是，X 上很多玩预测市场的人，在通过 Vibe Coding 的方式来写策略 Bot、自己执行。从我的感受来看，非程序员群体想要实现出能运行的策略，基本不可能可靠（高素质具备逻辑能力除外）。
有些策略包括我接下来说的策略，看起来和理解起来是异常简单的，但是落实到代码上，有很多具体的问题。比如重复下单的问题、退出策略是否正常执行、线上突然多了一堆订单属于策略内还是程序异常，这些都需要反复调试。不是说非程序员想不清楚，而是这个调试的过程非常磨人，得不断调参数、看效果、效果不好改策略、再看效果。这实际上就是程序开发每天在干的事情，现在虽然不需要自己动手写代码了，但是结果还得自己看。
对于下一场还未开始的 BTC 5分钟市场，提前直接挂单 limit order，以 45c 的价格买入 Up，同时以 45c 的价格买入 Down。如果两个挂单都成交，则结算的时候因为 0.45+0.45 < 1，所以必然得到本金 10% 的收益。一旦两个订单都成交，收益必然锁定，不需要任何后续操作。
损失风险也很明确，如果开盘后进入单边行情，价格在整个 5 分钟的周期内都没有震荡超过 55%，则策略遭受 50% 本金损失。这也就意味着，每次输 1 场，需要赢 5 场才能够转亏为盈。
为了减少损失，策略也包含两个止损机制：
这个策略从纯粹的逻辑和量化的角度，显然是站不住脚的，风险很大也很明确，而且没有程序化的规避方式，策略本身也没有足够的回测数据做支撑。所以这个策略很大程度上是主观的，我要解释的是，为什么我主观上认为这个策略可行？
btc5m 这种市场，行情分两种，一种是这个策略双边同时开单能够获利的震荡行情，另一种就是一旦开盘就已经锁定了结算方向、价格一去不复返的单边行情。
那么反过来想，假如单边行情多于震荡行情，是否意味着，在开盘后几秒内，直接买入价格高于 55c 的一边，就可以拿着等待结算了？单次收益率超过 80%。然后结合单边行情概率上多于震荡行情这一点，只要简单执行跟风买入的操作，就是一种能稳定赚钱的策略了。这是一种 “超级尾盘” 策略，因为尾盘一般在接近结算的价格比如 99c 才入场，而现在概率告诉你，55c 就足以入场。
但是事实上，大家交易的体感上，btc5m 结算前 5 秒钟结果大反转的场次都很频繁。别说单边买入，尾盘买入都会亏的很惨。而且我也不太相信赚钱可以简单到持续单边买入就可以，过于违反直觉。
所以再正过来想，既然不可能单边行情多于震荡行情，那么就应该是震荡行情居多。
既然刚才的判断是纯主观，那么是否可以通过判断 BTC 的价格动量，来预测 BTC 是否会在接下来 5 分钟内大幅波动呢？
这个测试我已经做过了，从 Binance 的 wss api 去获取实时价格信息、判断下一个轮次开始前 120 秒内价格是否在某一个中间线上下波动，并且还加了复杂的评分系统，需要至少上下横穿 2 次、并且价格波动幅度在 12bps 以上、信号连续持续出现 3 次、以及根据 Polymarket 上 orderbook 本场的波动情况等等各种条件，甚至还考虑拿一下 Binance 上的资金费率、Polymarket 上下一场的 Top holder 等数据来辅助判断。
也尝试过一些动态调整参数方面的优化，比如根据评分结果的高低来动态调整入场价格和入场金额，分数高一点就 42c, 1.2*amount，分数低一点就 46c, 0.8*amount 之类。
结果就是，不但能经过层层筛选的场次非常少，会导致下单的场次也非常少。而且主要是没有明显的效果。假如闭着眼睛不判断，直接下单，可能 10 场里有 9 场是 paired 状态（盈利的）、还有 1 场是 single 状态（亏损的）。而经过一系列评分系统最后高于波动率才下单的做法，可能一天下单 10 场，这 10 场里还是有 1 场 single。高的评分并没有减少 single 状态的风险，反而还大幅减少了下单的场次。
当然，你肯定会觉得，是我的量化思维不够专业，写不出足够专业有效的模型去预测下一场价格的波动情况。那我承认……
即使这个策略真的有效可以赚钱，收益也是有上限的。从最近几场 Polymarket 上的流动性深度来看，每一次下单的金额，单腿金额在 100 美元左右还是安全的，如果到 200 美元以上，就会出现买单不够、无法成交的风险。
这一点其实违反直觉，也许你觉得 Polymarket 交易量那么大（百亿美元级别）、玩 btc5m 的人应该很多才对吧？从官网上可以直接看到每一场的 Top holder 和 Top PNL，持有者最多在几千个 shares，收益最高的在几百、几千美元的区间。
那么一天有 288 个 5 分钟，假如真的每一场都是赚的，按照 200 美元的本金算，每一场收益是 10% 也就是 20 美元，一天的收益是 5760 美元。这个是理论上限。当然不可能每一场都赢，大概率赢 9 场输 1 场，收益率减半，一旦多 1 场输，就抹平 5 场的收益，收益打一折，再然后……
既然 btc5m 市场可以用这样的做法，那么 btc15m, btc1h, btc4h, btc1d，eth15m, sol1h…… 是不是也都可以用这样的策略？显然是可以的。
这是一个 200 美元买来的教训。其实我早就应该明白、或者已经明白这个道理：策略不可以赚钱。但是由于工作原因，以及可能受到一些其他影响，我突发奇想开始去尝试 Polymarket 上的策略。
真正试验这个策略的过程要远比文章写出来的复杂，花费了大量的时间和精力。但是在经过这样的尝试后，反而更加佐证了这个结论：策略不可以赚钱。也许周期性可以依靠运气赚钱，但是长期来看一定是负期望。
我没有时间和耐心去写复盘，就让 ChatGPT 完整总结了一下前因后果：
《我们是怎么把一个看起来能赚钱的 BTC 5 分钟策略，跑到最终停服的》
最后我再解释和强调一下这里说的 “教训” 是指：不要抱有侥幸心理。当你知道 “策略不可以赚钱” 之后，也许偶然会想再试试、也许这一次会不一样、也许这样那样就可以，然后就会发现，最终不但没赚到钱，还赔了钱。这就是教训。
策略还在继续维护中，只是现在会更加谨慎；结合之前急于求成的教训，现在仅运行模拟盘、然后分析回归测试出来的数据；有新的发现和结果会再更新。
2026-06-29 14:24:59
团队的项目在 Go to Market 环节遇到了困难，所以找了有经验的 BD（商务拓展）来提供指导意见。对方给出的策略是：每个人都去 DM KOL 谈合作。
具体做法是直接在 X 上找到相关领域的 KOL，然后跟对方聊天、套近乎、问需求、谈合作。
这个策略能够达到的目的是（转述）：
这个策略是 BD 给出的、在他的理解中最为可行的、用户转化率、留存率最高的方案。
说实话我没有 GTM 的经验，所以我也在不断反思，这个策略好不好、对不对、为什么专业的有经验的 BD 唯一认可的是这个策略。当然我早就想明白了结论，只是现在把这个结论写出来。我来跟你解释一下为什么。
我的结论是：这个策略一定是对的，但未必是有结果的。
很简单的道理，如果一个学生问老师，怎么提高学习成绩？老师会说，课前预习、上课好好听讲做笔记、课后认真完成作业、有不会的题要请教同学和老师。这一套学习方面的方法论，亘古不变。
但是很明显，我们都知道，同一个班级、同样的老师、同样的课本、同样的作业，学生的成绩就是天差地别。
为什么呢，因为策略方向是对的，但是具体到执行上每个学生都不一样，每个人的行为差异会被放大。
所以只要策略方向足够大、足够宽泛，策略就一定 “正确”。只是正确未必有用，因为策略需要具体的人来执行，而每一个人都是有差异的，只要不能机械化到代码程序可以重复执行，结果就肯定有差异。
也因此，你学习成绩不好不能怪老师吧？怎么有的学生人家就是成绩好呢？老师讲的东西都一样，你不能说老师讲的道理不对吧？
李笑来在 2022 年之后就不再做投资了，专职做家庭教育、写书、卖课、讲课。我喜欢李笑来的《财富自由之路》和《韭菜的自我修养》两本书，现在也时不时留意李笑来的新书和课程。
他最近几年的观点，非常明显有一个共同点，就是非常 “基础”、非常 “简单”，简单到像跟 6 岁小孩子讲道理一样，比如我们跟孩子说要诚实、勇敢、善良等，李笑来讲的观点，也都类似这种，比如 “生产是财富的来源”、“要学会复利”、“知识是可以迁移的、只要有时间就学习”、“自我暗示非常有力量” 等等。
他讲的这些内容，感觉都简单到 “是个人知道”，他讲的每一点，简单到 “每一个普通人都可以做到”。
然而事实上，世界上只有一个李笑来，真正财富自由的只有李笑来。他的课程并没能把那些 “真理” 一样的道理教给别人、让别人变得富有。
我也经常反思这个问题，为什么呢，为什么李笑来这样经历丰富的人，最终总结出的各种道理，反而异常朴实、基础、简单？我相信他不是刻意隐瞒，而是真心实意相信自己的那套东西。
所以现在直接能串联起来了。就跟学生问老师成绩怎么变好一样。很多人问李笑来，怎么变有钱，怎么变富有？然后李笑来告诉你，要坚持，要努力，要学习，要产出，要……
明白这里面的漏洞了吗？策略方向一定对，具体执行因人而异。还是那句话，只要策略方向足够大、足够宽泛，策略就一定 “正确”。
回到 DM KOL 这个策略，我来拆解两个问题：
很大。从一开始转述的、期望达到的 3 个效果来看，其实包含了市场调研、功能反馈、寻找合作 3 种目的。对于大公司来说这可能是 3 件事情，只是小团队就直接聚合为一件事情、全都放在 “DM KOL” 这句话里了。
只看这几个词可能不够直观，具体来说，我们期望问 KOL：
当然前提是对方愿意回信息。因为实际上大多数 KOL 不会回消息，或者上来就报价。而这个 DM KOL 策略的重点，实际上在于建立关系、跟人搭讪，先建立联系、然后表述出目的。
从这个描述能听出问题所在不。这就全部依赖于个人的社交能力了，而且是通过网络打字社交。BD 也跟我们说，要持续骚扰对方到骂你为止。
也很差。不过我要分享的，是我们团队面对的最大问题，以及为什么效果不好：因为执行成本高。
很多交易所，长期招聘 BD、而且 BD 没有无责底薪、说开除就开除，随便去任何一个招聘群，都能看到类似的吐槽。
很多项目方，在小红书上招聘实习生，一个月 3000块人民币，实习生就愿意辛辛苦苦任劳任怨干一个月，天天在 X 上刷流量、发广告。
而 DM KOL 的策略，属于周期长、反馈慢的策略，可能 DM 1000 个 KOL，其中能有 10 个给出反馈、有 1 个能达成合作。这还得是你花心思认真跟对方接触的情况下。
如果对这个过程没有实际感受，可以回想一下找工作的过程。比如我找工作的频率就很高，深刻理解这种状态。在找工作的时候，可能联系几百个 HR，然后面试几十家公司，最终找到一份合适的工作。
对于 BD 或者销售人员来说，DM KOL 就是他们的工作呀，他们不但能用整天的时间来干这件事情，而且有足够的时间去思考、总结相关的经验。
至于我所在的团队，所有成员中，目测时间成本没有比我低的。每个人都戴着 “金手铐”。毕竟不是专业的 BD 人员，也都有自己职业方向的事情需要做，能够用于 DM 的时间很少，更重要的是，DM 是一件反馈周期长、不确定性很高的事情。花一整天的时间去 DM，可能都什么反馈都不会得到。而在自己熟悉的道路上，总是能有一些结果的。
所以让成员兼职去 DM KOL 这件事情，如果想要得到可观的结果，难度不亚于先让成员做一次职业转型，然后再统一做长时间刻苦的执行后，才能有结果。
如果不那样，要么有人能认真把这件事情做好，要么什么都做不好。我个人是不相信，有人能顺带做一件事情，不用心也不总结，就能比专业的人做出更好的效果。
毕竟哪怕是专业的 BD 团队，同样完全正确的策略下，10 个 BD 成员里得到的结果想必也天差地别，有的人被开除了，有的人成为金牌员工了。这种事情谁说得准呢。
所以你应该看出来了，我写这些的目的并不是在吐槽，而是在分析和分享。
重要的是我明白了一个道理：为什么看起来正确的策略，却得不到好的结果？
不知道我讲清楚了吗？