Bluue

x402是什么
介绍
x402 是在 2025 年推出的一项开放支付标准，旨在正式激活 HTTP 402 状态码，将其转变为互联网原生的支付机制
由网络基础设施公司 Cloudflare 和加密货币交易所 Coinbase 联合推动的一项技术标准。
相比于传统模式需要创建账户、绑定信用卡或预充值，x402 将支付请求直接嵌入 HTTP 响应中，使客户端（无论是人、机器人，还是 AI agent）都可以自动识别支付信息，并完成结算。 x402 让一次 HTTP 请求同时具备“数据传输”与“价值传输”属性。 只要支付完成，访问权限即可即时打开，无需账号或人工操作。
设计初衷
解决机器对机器（M2M）和人工智能代理（AI Agent）在访问网络服务（如 API）时，需要进行高频、小额、自动化支付的需求。
例如，一个 AI 程序可能需要每秒钟调用上千次数据API，每次支付 0.001 美元。传统支付方式（如信用卡）无法处理这种场景，而 x402 旨在提供一个标准化的解决方案。
历史背景
HTTP 协议自早期标准化以来预留了 402 “Payment Required” 状态码，但一直没用上
原因在于：技术，商业，用户习惯的共同作用
没有统一的规范，没有统一的结算方式等等（例如配套字段）， 消息格式写什么，付给谁，付多少，怎么付，怎么证明等，啥不知道 没有一个公共的轨道，比如区块链，大家就无法达成共识 微支付不经济，比如几美分级别的交易，同样要支付三十美分的固定手续费，亏（信用卡公司的设计） 传统交易有拒付，退款，合规检测等，容易出问题
x402 的参与者
Client（客户端）：发起请求的用户、应用或 AI agent
Server（服务端）/Provider：提供数据或服务的主体（API、网站等）
Facilitator（结算方）：负责验证支付是否完成。当前大多数实现基于区块链，但理论上任何具备可验证结算能力的系统都可接入
狭义和广义的角色
狭义的Provider：资源提供商，理解为发出402账单的服务器
广义的：配套服务商，微x402提供基础和配套的相关者
工具：SDK，钱包插件等 平台：Agent部署，托管等 基建：RPC，索引等
Facilitator
算是一个中间件，作为web和区块链之间的桥梁
假设服务器向一个AI发送了402账单，要求支付 1USDC 那么在哪条链支付？服务器怎么知道真的付钱了？
Facilitator 相当于一个外包，检查链上数据，确认交易真实
生成凭证，发送给服务器 服务器信任这个制定的facilitator，即完成交易 Facilitator的充当角色一般包括 Coinbase CDP，CloudFlare可能会内嵌
web3支付网关，比如USDC 节点服务商 支付巨头：Paypal，Visa 自托管：api提供商自己
实际使用，可能会做KYT 或者风控，针对Facilitator
基本流程
客户端 (Client) → 服务端 (Provider)：请求资源。 比如AI Agent向服务器请求一个付费资源（api 接口） 服务端 (Provider) → 客户端 (Client)：服务端返回 HTTP 402，并附带支付条件（支付资产、金额、接收地址等） 相当于标准化的账单，指明需要支付的金额，数量，货币，地址等 客户端 (Client) → 区块链：客户端使用稳定币（如 USDC）发起支付，区块链完成，附带证明 客户端 (Client) → 协调者 (Facilitator)：客户端拿着 txHash 去请求 Facilitator 的验证地址（即步骤 2 中指定的地址）。 协调者 (Facilitator) → 区块链：Facilitator 检查该 txHash 是否真实、有效、金额正确。 协调者 (Facilitator) → 客户端 (Client)：Facilitator 验证通过后，签发一个有时效性的“新凭证”（例如一个 JWT Token）给客户端。 客户端 (Client) → 服务端 (Provider)：客户端重新请求资源，并在请求头中附上这个由 Facilitator 签发的“新凭证”。 服务端 (Provider)：服务器只验证这个凭证是否是它信任的 Facilitator 签发的。验证
整个过程是可编程的、可以无需人工参与或账户体系。
对比和区别
为什么在当下被提及了
AI 代理需要按次付费，符合需求，高频，小额，自动化 技术成熟：区块链，稳定币
其他状态码
401：未认证，身份认证，比如账号密码
403：禁止访问，权限不够
404：未找到内容
500：服务器内部错误
解决的问题
AI 代理的支付问题 高频，高摩擦的微支付问题
x402之前，假设ai 需要调用100个不同API来完成任务
那么需要首先，人工注册100个api服务的网站 对100个网站添加支付信息 根据支付要求绑定，比如按月，按次等 收到100个账单
相关ERC
EIP-3009： "Transfer ERC-20s with a signature
由 USDC (v2) 率先实现并推广
让持币人先离线签好一次“转账授权”，任何中继或对方都能把这份授权打到链上完成实际转账。目标是Gas可代付、原子结算、避免 allowance 漏洞，适合按次“推送式”付款
Agent (客户端) 在本地用自己的私钥（或会话密钥）签署一个 EIP-3009 格式的消息，内容是：“授权从我的钱包转 0.01 USDC 到 Provider 的钱包”。这个过程是即时的，不花 Gas。 Agent 将这个签名作为“支付证明”发送给 Facilitator。
正常交易是：agent 自己创建，签名，广播一笔交易，同时持有ETH作为Gas，假设Agent只有USDC，就会很麻烦 EIP 3009：本地生成一个签名：我，授权，100 USDC转给B
Agent可以不需要Gas，可以代付，由Facilitator 代付 代付的结果就是，Facilitator 会从这笔支付中拿回补偿：抽成 或者Provider为了抢占市场和提高体验，来代付
核心优势： AI Agent 的钱包完全不需要持有 ETH 来支付 Gas，也不需要管理复杂的链上交易（如 Nonce、Gas Price）。只需要能签名即可。
EIP-2612：Permit: Signature-based ERC-20 Approvals" (通过签名的 ERC-20 授权)
允许用户通过**“链下签名” (Off-chain Signature)** 来完成 ERC-20 代币的 approve() (授权) 操作，而无需为此单独支付 Gas 费。
2612 之前：
USDC——ETH的兑换：授权——兑换，需要两次操作和签名，同时支付两笔gas
2612之后：
授权转变为链下签名：免费，快速 “我授权 Uniswap（Spender）从我（Owner）这里拿走 100 USDC（Value），此签名在（Deadline）前有效”。
Uniswap 拿到签名后，按顺序执行两个事情 签名发给USDC，USDC验证后，即完成授权 调用交易，完成兑换
EIP-2612 告诉合约：“你被允许来我这里拿钱了。”比如签署一份授权书，允许快递员（DApp）明天来取走一个包裹。
EIP-3009 告诉合约：“请立刻把我的钱转给 B。”比如发了一个红包，任何人（中继者）拿走它都能立刻兑现。
在 x402 场景中，一般3009应用更广，因为直接高效。但如果某些稳定币受限，那么可能会用到2612。
隐私问题
x402 由于付款发生在区块链上，本质上一切都是公开的，包括 付款方，收款方，金额，时间等等
对于Facilitator而言，它能看到IP地址，验证哈希 往坏了说，Facilitator 是能够将链下的IP和链上的身份关联起来的 对于Provider 而言，也能看到客户端的 IP 地址以及客户端请求的特定资源（比如具体的api等）
假设Facilitator 和 Provider 串通（或者它们是同一家公司，这在 Cloudflare/Coinbase 生态中很可能发生），它们就拥有了完全的监控能力：谁（IP/钱包）在何时为什么（API 路径）支付了多少钱。
怎么解决问题
ZK：比如在一个隐私的Layer2上支付，比如Azetc？
比如私有的支付通道：类似于闪电网络——避免公链识别，只有最后结果才会记录在链上
中心化，意义不大， 但肯定会有这个方案，比如 客户端将 100 美元预存到他们的“Coinbase Agent 账户”（可以通过链上或信用卡）。
每当 Provider 返回 402 时，Facilitator 只需在其内部数据库中扣除客户端的余额，并记入 Provider 的余额。
FHE：
把想获取的资源加密发送给Provider Provider可直接在加密数据上执行计算
并返回402账单
加密了：数据相关信息 没加密：支付相关的信息
个人观点
x402 有用，但没那么大用，更像是一个垂直领域的解决方式，而不是一个general的范式现在的x402发展更多在web3，但是这件事达成大结果需要web2的更多支持ai agent其实有清晰的边界，可以关注，本质上应该属于payment领域的一部分，但并没有那么大的效果，payment和隐私更底层但是基于“胖应用，瘦协议”的概念，很有可能跑出来几个大哥大短期看好，但长期保留意见，不是概念不合适，是落地（悬）
参考：https://mp.weixin.qq.com/s/gEu1c7WYx2oOFF5uyludpQ

一个社会如何知道它自己知道什么？
从集市上的重量竞猜，到政治预测市场，再到可以在链上随时参与的短周期 Event Contracts，事件合约经历了一场持续百余年的演化。它的核心始终未变：把人们对未来的不同判断转化为价格，再由结果完成结算。变化的是市场覆盖的事件、参与门槛、交易周期与基础设施。
沿着这条线回看，Polymarket 让预测市场成为全球互联网产品，TurboFlow 则把事件合约进一步带入面向普通交易者的链上交易场景。两者所处的阶段和产品形态不同，共同推动了“交易未来”从经济学实验走向大众化产品。
一、1907—1945：从“群体智慧”到价格发现
事件合约的思想起点，可以追溯到 1907 年。英国统计学家弗朗西斯·高尔顿观察到，一群人在集市上独立估计一头牛的重量时，群体判断非常接近真实结果。这个故事后来被概括为“群体的智慧”：当参与者拥有不同信息，且判断能够相对独立地形成，汇总结果往往比单一个体更接近事实。
后来，经济学家开始进一步思考：如果市场价格能够汇聚关于商品供需的信息，那么它是否也能汇聚关于未来事件的信息？
1945 年，弗里德里希·哈耶克在《知识在社会中的运用》中系统阐释了价格机制的信息功能。现实世界的知识分散在无数个体手中，而市场价格能够把这些分散的判断与信息压缩为持续变化的信号。沿着这一思路，市场不仅可以为商品定价，也可以通过交易汇聚参与者对未来事件的判断。
事件合约将这套逻辑应用于未来结果。假设一份“某事件会发生”的合约当前价格为 0.62 美元，并约定事件发生时按 1 美元结算、未发生时归零，那么 0.62 美元通常可以被理解为市场对该结果给出的概率信号。参与者用资金为自己的判断负责，新信息也会通过交易不断进入价格。
价格依然会受到流动性、参与者结构、市场情绪与交易规则影响，所以它更适合被视为实时市场判断，而非绝对准确的概率。这一点贯穿了事件合约此后的发展。
二、1988：爱荷华电子市场把理论变成实验
现代预测市场的重要起点出现在 1988 年。爱荷华大学的研究者创建了爱荷华政治股票市场，后来发展为爱荷华电子市场（Iowa Electronic Markets，IEM），通过与美国总统选举结果挂钩的合约检验市场能否提升预测质量。
早期市场规模很小，参与金额也受到严格限制。它证明了一件重要的事：即使参与者人数有限，只要他们愿意根据新信息交易，价格也可以形成具有参考价值的集体判断。
1992 年，IEM 获得美国商品期货交易委员会（CFTC）的“不采取行动函”，得以在小额、研究导向的条件下继续运行。事件合约第一次拥有了相对稳定的制度空间。此后多年，IEM 的价格经常被用来与民调比较，也推动预测市场进入经济学研究的主流视野。
三、1999—2013：Intrade 证明商业价值，也暴露监管边界
学术实验之后，商业平台开始出现。TradeSports 与 Intrade 将可交易事件扩展到选举、经济、娱乐和国际局势，并向更广泛的用户开放。
Intrade 的价值在多次美国大选中得到关注。媒体、研究者和公众开始把市场价格当作民调之外的另一种信号。更多资金和参与者带来了更活跃的价格发现，也让预测市场第一次接近大众互联网产品。
监管问题随之放大。2012 年，CFTC 指控 Intrade 向美国用户提供未经注册的商品期权交易。平台随后停止服务，并于 2013 年关闭。Intrade 留下的经验很清晰：事件合约具备真实需求，长期发展需要与交易规模相匹配的合规、清算和市场基础设施。
同一时期，事件合约也触及道德与公共利益边界。2003 年，由美国国防高级研究计划局资助的 Policy Analysis Market 计划，试图通过市场预测中东地区的政治与安全变化。项目因舆论争议迅速取消。这次事件提醒行业，合约能否被交易，还取决于标的设计、公共利益和社会接受度。
四、2014—2020：受限市场延续，加密基础设施开始成熟
Intrade 关闭后，IEM 与 PredictIt 等受限市场继续提供政治事件交易。它们保留了预测市场的研究与产品火种，用户规模、单笔金额和市场数量受到约束。
另一边，稳定币、智能合约、链上钱包和自动化做市逐步成熟。事件合约开始拥有新的技术底座：全球用户可以在统一网络中交易，规则与结算过程可以写入智能合约，市场也可以全天候运行。
这为下一轮增长提供了条件。预测市场开始从“由单一机构维护的网站”，转向可组合、可验证的链上市场。
五、2020—2025：Polymarket 把预测市场带向全球
Polymarket 于 2020 年上线，以稳定币和区块链基础设施提供围绕政治、宏观经济、科技、体育与文化等主题的事件市场。用户交易“Yes”或“No”份额，价格随供需变化，事件结果确定后完成结算。
它带来的变化首先体现在分发方式。预测市场由地域性产品变为全球互联网产品，市场价格也可以被媒体、研究者和社交平台实时引用。2024 年美国大选期间，Polymarket 获得了前所未有的公众关注，事件合约第一次成为全球新闻讨论中的高频数据源。
Polymarket 的发展也伴随合规调整。2022 年，CFTC 就其提供未注册的链上事件合约与平台达成和解，并要求其处理不符合规定的市场。此后，Polymarket 持续建设进入受监管市场的路径。
2025 年，纽约证券交易所母公司洲际交易所（ICE）宣布向 Polymarket 投资至多 20 亿美元，并计划分发其事件驱动数据。这项合作具有象征意义：由市场交易形成的事件概率，开始被传统金融基础设施视为可服务机构客户的数据产品。
Polymarket 完成了事件合约历史中的一次重要迁移——从学术研究、垂直社区和灰色地带，进入全球主流金融与媒体视野。
六、Kalshi 与美国受监管市场的扩张
与链上路径并行，Kalshi 选择从受监管交易所起步。它在 2020 年成为 CFTC 注册的指定合约市场，并围绕经济数据、天气、政治和体育等结果推出事件合约。
2024 年，美国联邦地区法院撤销了 CFTC 对 Kalshi 选举合约的禁止决定。2025 年 5 月，CFTC 撤回上诉，相关案件结束。这推动美国事件合约市场快速扩张，也带来新的联邦与州监管讨论。
进入 2026 年，事件合约已经形成多条并行路线：受监管的中心化市场、面向全球用户的链上预测市场，以及围绕价格变化设计的短周期产品。不同产品对应不同的信息类型、参与方式和风险结构。
七、从“预测公共事件”到“交易市场结果”
事件合约的产品边界正在扩大。早期市场主要回答“谁会赢得选举”“某项政策是否通过”；新的产品也可以回答“在指定时间后，BTC 价格会高于还是低于当前水平”。两类合约都把不确定结果转化为清晰的条件，并在到期后按预先公布的规则结算。
它们聚合的信息不同。政治与宏观事件市场吸收新闻、研究和公共信息，周期通常较长；短周期价格事件吸收实时行情、波动、订单流和交易者对方向的判断，更接近高频市场交易。
这种演化让事件合约成为一种通用产品结构。用户无需处理复杂的仓位参数，也能围绕明确结果表达观点。产品体验因此从“寻找一个值得预测的事件”，延伸到“在熟悉的市场中快速表达方向判断”。
八、TurboFlow：事件合约进入零售链上交易场景
事件合约市场正沿着不同路径演进：一类平台强调制度建设与监管框架，通过标准化规则提升市场可信度；一类平台强调全球可访问性与链上执行，借助公开透明的机制降低地域和基础设施限制；另一类平台则开始探索更短周期、更贴近交易场景的事件产品，以降低参与门槛并提高资金使用效率。
TurboFlow 代表了第三类探索。它是一个面向全球零售用户的链上交易平台，将 Perpetuals（永续合约）、Event Contracts（事件合约）与 Prediction Markets（预测市场）整合在同一交易生态中，尝试让专业交易产品变得更简单、更易参与。
在 TurboFlow 的件合约中，用户可以围绕 BTC、ETH、黄金等资产在指定周期后的价格方向作出判断。最低 2 美元即可参与，最快 30 秒完成一轮交易。清晰的方向选择、确定的到期时间和预先展示的潜在结果，降低了理解和操作门槛。
TurboFlow 也把事件合约放进完整的交易生态中。用户可以根据市场观点选择短周期 Event Contracts，也可以使用永续合约管理更长时间的方向敞口。
在市场基础设施层面，TurboFlow 引入专业做市商提供流动性，并通过链上透明执行支持更具市场驱动特征的交易体验。其产品方向延续了哈耶克所强调的价格发现逻辑：不同参与者的判断进入市场，价格与赔率随供需和信息变化。
TurboFlow 与 Polymarket 展示了事件合约的两种典型场景。Polymarket 让用户交易政治、经济与文化等公共事件，TurboFlow 进一步覆盖短周期市场结果，并把事件合约与永续合约连接起来。事件合约由此拥有更广的时间尺度，也触达更多具有不同经验的用户。
九、事件合约走向主流后，什么仍然重要
回顾这段历史，事件合约的长期价值来自三个要素。
第一，规则需要清晰。标的、观察时间、数据来源和结算条件应当在交易前明确展示。
第二，市场需要流动性。参与者数量、做市质量和订单深度会影响价格能否及时吸收信息，也会影响用户的实际交易体验。
第三，风险需要被正确理解。二元结果意味着收益与损失集中在结算时点，短周期交易还会放大波动与时机判断的影响。市场价格和赔率表达的是交易者在特定规则与流动性环境下形成的判断，不能被当作结果保证。
这些原则连接着 IEM、Polymarket、Kalshi 与 TurboFlow。技术与界面持续变化，可信的规则、透明的执行和充分的流动性始终是事件合约走向更大规模的基础。
结语：从信息市场到日常交易入口
从 1907 年的群体竞猜，到哈耶克对价格机制的解释；从 1988 年的爱荷华电子市场，到 Polymarket 把预测市场带上区块链，再到 TurboFlow 将短周期 Event Contracts 与永续合约整合进同一平台，事件合约完成了从思想、实验、市场到产品的长期演化。
这段历史也揭示了事件合约持续增长的原因：人们始终需要一种简单方式来表达对未来的判断。今天，事件合约已经可以覆盖数月后的政治结果，也可以覆盖 30 秒后的市场方向。时间尺度缩短了，参与方式更轻，价格发现的逻辑仍在延续。
如果说传统预测市场主要通过中长期事件交易汇聚参与者对未来的判断，那么今天的短周期事件合约，则进一步将这种机制延伸至时间更短、频率更高的交易场景。对 TurboFlow 而言，这条演化路径指向一个更具体的目标：让更多普通用户能够参与透明、易懂，并由真实市场流动性支持的链上交易。

事件合约把一个未来结果转化为条款明确、可以交易并按规则结算的合约。产品可以围绕重大事件、经济数据、体育比赛、天气或加密资产价格展开。判断平台时，重点需要看六项：合约问题、报价方式、到期时间、能否提前退出、结算数据源和费用。
事件合约是什么？
一份事件合约会提出一个能够核验的问题，并预先规定结果选项和结算条件。常见结构包括： 是/否：例如“某项指标在指定日期前是否达到目标”。 更高/更低：判断到期价格相较入场价格更高或更低。 阈值型：判断最终数值是否高于、低于或不低于某个数值。 多结果型：同一事件设置多个互斥结果，每个结果分别报价。
参与者交易的是合约结果。合约条款通常列明市场问题、截止时间、时区、官方数据源、边界值、取消或延期事件的处理方法，以及获胜合约的兑付金额。标题相似的市场也可能采用不同规则。 事件合约如何运行？
创建市场：平台定义问题、结果、交易截止时间和结算来源。形成报价：订单簿平台由买卖双方报价；采用自动做市机制的产品由做市模型形成报价，并在确认前展示参与金额和回报信息。建立持仓：订单成交后，参与者持有某个结果方向。部分平台允许在市场关闭前卖出，能否成交取决于流动性。停止交易：达到截止时间、事件开始或平台规定的其他条件后，市场停止接受交易。确认结果：平台、交易所或预先指定的预言机依据合约条款和数据源确认结果。完成结算：二元合约通常将获胜一侧按每份1美元结算，失败一侧归零；固定回报产品按照确认时锁定的规则计算。
定价方式：70美分代表什么？
在0至1美元报价的二元合约中，价格经常被理解为市场隐含概率。“是”合约价格为0.70美元，表示当前市场定价大致对应70%的发生概率。
若最终结果为“是”，每份通常兑付1美元，未计费用和点差的毛收益为0.30美元；若结果为“否”，该份合约价值归零，最大损失为投入的0.70美元。 价格会受到新信息、订单簿深度、买卖价差和参与者供需影响。页面显示70%只反映当时的市场价格，无法保证事件真实概率就是70%。采用自动做市机制的固定回报产品还会结合周期、波动和风险参数形成报价并展示回报率，参与者应同时查看本金、预计回报和最大可能损失。
结算规则要看哪些细节？
结算数据源：政府机构、赛事组织方、价格指数、交易所数据或预言机都可能成为最终依据。
比较符号：“高于100”通常要求严格大于100；“100或以上”包含等于100。
时间与时区：结算采用哪个时点、哪个时区，以及价格采样是瞬时值、收盘值还是一段时间的平均值。
异常处理：事件延期、取消、数据更正、价格源中断或结果长期无法确定时如何处理。
争议流程：谁可以提出结果、异议期多长、由谁作出最终决定。
费用与兑付：交易费、平台佣金、链上费用和提现成本都会影响实际回报。
平台产品
Polymarket：连续交易的事件市场 Polymarket是一个围绕事件概率持续交易的预测市场，通过订单簿形成价格，并由UMA预言机参与结果确认。
具体产品：以是/否结果份额为主，市场覆盖政治、宏观、体育、加密资产和文化事件等类别；市场通常持续到事件发生并完成结算。
报价：采用订单簿。页面概率通常显示买一价与卖一价的中间值；当买卖价差超过0.10美元时，页面改用最近成交价。“是”与“否”的匹配报价合计为1美元。
交易与退出：市场开放且有对手方时，可以通过订单簿买入或卖出结果份额。限价单可以控制成交价格，流动性不足时可能无法按预期价格退出。
结算：按照市场预先公布的规则，由UMA乐观预言机处理。结果提出后设有挑战期；最终获胜份额每份兑付1美元，失败份额归零。
费用：官方当前说明为部分市场向吃单方收取费用，挂单方不收费；不同市场类别参数不同，入场前需查看最新费率。
评测：适合希望持续交易事件概率、使用限价单并关注市场深度的用户。主要检查项是规则措辞、买卖价差、链上钱包、预言机争议流程和地区可用性。
Kalshi：标准化是/否事件合约 Kalshi是一个以标准化是/否合约、明确市场规则和订单簿交易为核心的事件市场。
具体产品：以是/否合约和阈值合约为主，单个市场会列出明确的规则摘要、到期条件与结果验证来源。
报价：采用订单簿，合约价格以美分表示。70美分的“是”合约与30美分的“否”合约可以组成1美元；买一价、卖一价和可成交数量会直接影响执行。
交易与退出：可使用订单簿建立仓位，并在市场仍开放且存在流动性时通过卖单退出。挂单未成交时可以取消。 结算：每份合约条款列明采用的信息和来源。合约到期后，Kalshi依据这些条款确认结果；官方说明结算确认可能在闭市后一小时至十二小时以上完成，具体取决于数据来源。
费用：交易费按预期收益等因素计算，部分市场还可能收取挂单方费用。取消未成交挂单不收费，确认订单前应查看市场页面的实际费用。
评测：产品条款和验证来源展示较清晰，适合重视标准化规则、订单簿和提前退出能力的用户。费用公式、市场流动性及所在地区资格需要单独核对。
Robinhood：通过熟悉界面接入合作交易所 Robinhood是一个通过熟悉界面接入合作交易所的事件合约入口，实际报价、结算和特殊规则由承载合约的交易所决定。
具体产品：Robinhood衍生品业务通过KalshiEX、ForecastEX或Rothera Exchange and Clearing提供事件合约，常见形式包括单项是/否、阈值合约和组合结果。
报价与兑付：单份价格通常在0.01至0.99美元之间，正确结果按1美元现金结算，错误结果按0美元结算。下单前会显示价格和适用费用。
交易与退出：未成交订单可以取消；成交后无法撤销。市场仍开放且有买方时，可以按当前市场价格卖出持仓；市场关闭或缺乏流动性时需要持有至结算。
结算：最终结果由对应合作交易所依据合约列明的官方数据源和条款确定，Robinhood无法更改交易所的结算决定。
费用：可能同时涉及交易所费用和Robinhood佣金，具体金额在订单确认页展示。
评测：适合已经使用Robinhood并重视统一操作界面的用户。阅读条款时需要确认实际承载合约的交易所，因为结算、费用和特殊事件规则由具体合约决定。
TurboFlow：面向散户的链上交易生态 TurboFlow是一个面向全球散户、融合预测市场与永续合约的链上交易生态，在同一平台提供永续合约、事件合约与预测市场，并以透明执行和专业流动性降低普通用户的参与门槛。
具体产品：本节评测的是TurboFlow的事件合约，即固定时间窗口内的“更高/更低”合约。
用户选择市场、参与金额、周期和方向；最低参与金额为2美元，最快30秒可完成一轮，实时参数以产品页面为准。
报价与参与：自动做市商（propAMM）根据市场、周期和风险参数形成报价；确认前会展示入场价格、参与金额、周期、方向、回报率和预计结果，订单确认后该份合约的回报率锁定。
结算：入场价是订单被接受时的价格，结算价是合约到期时采用的价格。选择“更高”时，结算价高于入场价才符合方向；选择“更低”时则相反。
两者相同时，按官方规则返还本金。 持仓管理：倒计时结束后自动结算，持有期间无需管理保证金、资金费率或强制平仓；这套机制与平台的永续合约产品不同。
评测：TurboFlow面向散户，以最低2美元和最快30秒降低事件合约的参与门槛，并在同一平台整合永续合约与预测市场。短周期“更高/更低”合约对入场时点、市场波动和价格数据更敏感。
核心差异
价格形成：Polymarket与Kalshi主要依靠订单簿；Robinhood展示合作交易所的市场报价；TurboFlow事件合约采用自动做市商（propAMM）形成报价，并在确认前展示入场价格、参与金额、周期、方向和锁定回报率。时间跨度：Polymarket、Kalshi和Robinhood的合约通常围绕事件截止时间运行；TurboFlow事件合约采用固定时间窗口，最快30秒完成一轮。提前退出：前三类产品在市场开放且有流动性时通常可以卖出持仓；TurboFlow事件合约的公开流程侧重持有至倒计时结束并自动结算。结算主体：Polymarket采用UMA预言机；Kalshi依据自身市场条款和指定来源确认；Robinhood由合作交易所决定；TurboFlow事件合约依据预先披露的合约规则，以可信市场数据源及多个预言机生成的入场价与结算价自动结算 适用场景：关注持续变化的事件概率可重点研究Polymarket；重视标准化市场规则可研究Kalshi；偏好Robinhood统一界面可查看其合作交易所合约；希望以低门槛参与短周期“更高/更低”合约，可研究TurboFlow事件合约。
主要风险
本金损失：方向判断错误时，单份合约可能归零，固定回报产品也可能损失参与金额。规则风险：忽略边界值、时区、数据源或异常条款，可能对结算结果产生错误预期。流动性与点差：页面概率、可成交价格和提前退出价格可能存在明显差异。结算与数据风险：官方数据延迟、更正、预言机争议或价格源异常可能延长结算并触发特殊规则。费用风险：交易费、佣金、链上网络费和出入金费用会降低实际回报。技术与合规风险：账户安全、智能合约、平台运营和地区限制都可能影响产品可用性。
总结
理解事件合约，可以沿着“问题定义—价格形成—交易退出—结果确认—资金结算”五个环节检查。Polymarket、Kalshi、Robinhood与TurboFlow事件合约采用了不同的产品路径；其中TurboFlow本身是融合预测市场与永续合约的链上交易生态，本文评测的只是其事件合约产品。平台名称无法替代对单个合约条款的核对，真正决定结果的是合约写明的时间、数据源、边界条件和异常处理规则。

Skyfire 由两位前 Ripple 高管 @AmirSarhangi 和 DeWitt 联合创立，二人在 Ripple 期间负责跨境支付网络建设，曾参与处理超过 500 亿美元交易流水。
融资情况
2024 年，Skyfire 完成约 850 万美元种子轮融资，投资方包括 Circle、Ripple、Gemini、Tim Draper 相关基金等加密与金融机构。随后获得了 Coinbase Ventures 和 a16z (Andreessen Horowitz) Crypto Startup Accelerator (CSX) 的额外投资，总共950 万美元
背景
随着人工智能从内容生成转向自主代理，现有的金融和身份基础设施开始水土不服。
身份验证： 现在的身份验证依赖于人类特征（手机号、生物识别、CAPTCHA）。AI 代理没有法律人格，无法通过这些验证，甚至被视为“恶意机器人”并遭到拦截 。
服务商也很委屈，识别不出来这到底是正经 AI Agent 还是恶意爬虫甚至是 DDOS。
Gemini（对不起，我无法访问 xxx 网页）
支付： 现有的支付工具（信用卡）不适合机器使用。
极易触发风控，且无法支持典型的高频微支付（如 0.01 美元的 API 调用）。而且直接把信用卡授权给 AI，也不够放心。
所以这里的核心是让机器，能够区分三个角色：人 / AI Agent / 恶意攻击机器人（脚本等）
身份认证 KYAPay /区别 KYC
KYAPay 是 Skyfire 及其合作伙伴（如 Visa、Coinbase）共同推动的开放标准，旨在定义 AI 代理之间如何通过标准的 JWT（JSON Web Token）格式传输身份和支付意图 。
“身份即支付”（Identity-linked Payment）。
在传统电商中，登录（身份验证）和结账（支付）是两个步骤。
在 KYAPay 中，这两者被压缩到了同一个数据包中，在一次 HTTP 请求中同时完成 “我是谁”和“我要付钱”
KYA 分为三种不同的权限，以适应不同场景。
一个标准的 JWT 字段：
签发者，Skyfire 平台
买方 ID
接收方 ID
过期时间
唯一编号，避免重放攻击
------（以下是专用字段）------
买方认证信息
支付金额
货币单位
服务的单价
服务的 项目 ID
一般流程：去中心化验证机制（JWKS）
Skyfire 采用了类似 OAuth 的公钥验证机制：
签名： 买方代理使用 Skyfire 分发的私钥（或通过 API 请求 Skyfire 签名）生成 JWT。验证： 卖方服务通过 Skyfire 提供的标准 JSON Web Key Set (JWKS) 端点获取公钥。本地校验： 卖方在本地服务器上校验 JWT 的签名是否合法、是否过期、接收方是否匹配。
资金结算/身份认证
稳定币： 统一使用 USDC（USD Coin）作为结算货币
Skyfire 主要部署在 Polygon 和 Base（Coinbase 的 L2 网络）上 ，主要原因自然是价格比较低+账户抽象，同时 coinbase 也是投资人大哥。
Agent 的身份认证：KYA（Know Your Agent）
每个 AI 代理的数字身份都通过密码学方式绑定到其所有者（Controller）的现实法律身份上。skyfire 颁发的身份令牌，类似于“数字护照”，包含：验证状态： 该代理是否经过 Skyfire 或第三方（如 Trulioo）的验证
代码指纹： 代理的软件版本哈希值，确保与之交互的是未经篡改的程序
信誉评分： 基于链上历史交易数据的信用分
蓝标认证： 类似于社交媒体的认证（币安 OTC 神盾商户）
整个流程的参与角色 (Participants & Roles)
用户/Agent 控制者 ：AI 开发者、企业或部署代理的个人。
需要完成 KYC/KYB，承担法律责任提供法币和入金渠道给 Agent设定权限，比如预算，白名单商家
买方代理：执行具体采购任务的 AI 实体
可以是运行在云端的自主程序、本地的 CLI 工具（如 OpenCode），或者是浏览器中的插件。拥有 Skyfire 分配的唯一 Agent ID 和 API Key（或 MPC 钱包分片）。主要是根据设定任务，自主决定需要的服务，并发起付款买方代理，拥有的核心是 【资金使用权】
卖方代理 / 服务提供商：提供资源，可以是 API 提供商，或者另一个代理
设定服务价格在其 API 网关前部署 Skyfire 的验证中间件（Middleware），用于拦截和校验传入的 JWT验证通过后，向买方代理提供数据或执行任务收款，将买方的承诺变现为钱包中的 USDC
Skyfire ：连接上述三方的信任中枢和基础设施提供商。
签发 KYA 证书协调链下的账本记录与链上的资金结算监控全网交易，识别异常模式（如洗钱、DDoS 攻击），并实施熔断维护平台，帮助买卖双方建立连接 。
举个例子
一个名为 "Analyst-Bot" 的 AI 代理需要购买一份实时的金融数据报告，价格为 0.5 USDC。
账户创建： 控制者（某金融公司）在 Skyfire 注册，完成企业认证（KYB）。创建代理： 在仪表盘中创建 "Analyst-Bot" 实例。系统为其生成唯一的 Agent_ID: uuid-1234 和 API Key。资金与策略： 公司向 Skyfire 充值 1000 USDC，并为 "Analyst-Bot" 设定策略：“每日预算上限 $50，单笔交易上限 $2” 。环境集成： 开发者将 Skyfire 的 MCP Server 配置到 "Analyst-Bot" 的运行环境中（如 Composio 或 LangChain），使其具备调用支付工具的能力 。任务触发： "Analyst-Bot" 接收到用户指令：“分析最新的 Apple 股票走势”。服务发现： 代理查询 Skyfire 目录，发现 "MarketData-Provider" 提供的服务符合需求，且接受 Skyfire 支付。获取报价： 代理调用卖方的元数据端点，确认为 price: 0.50, currency: USD。自主决策： 代理内部逻辑判断 0.50 USDC 在预算范围内，决定发起购买。请求令牌： "Analyst-Bot" 向 Skyfire API 发送请求：“我要向 Seller_ID: 5678 支付 0.50 USDC”。平台风控（关键步骤）： Skyfire 核心引擎接收请求，执行以下检查： 代理是否被冻结？（否） ◦ 母账户余额是否充足？（是） ◦ 今日已用额度 + 0.50 是否超过 $50？（否） ◦ 交易对象是否在黑名单？（否）签发 JWT： 检查通过后，Skyfire 生成一个加密签名的 kya+pay JWT，并锁定（Reserve）母账户中的 0.50 USDC，防止双花。这个 JWT 被返回给 "Analyst-Bot"。发送请求： "Analyst-Bot" 向 "MarketData-Provider" 的 API 发送 HTTP GET 请求，将获取到的 JWT 放入 Header： Authorization: Bearer <sk_token_...> Skyfire-Payment: <jwt_payload>本地验证： "MarketData-Provider" 的服务器收到请求。通过 Skyfire 的公钥（JWKS）验证 JWT 签名。验证成功意味着： ◦ 该请求确实来自一个合法的 Skyfire 代理。 ◦ Skyfire 承诺支付 0.50 USDC。 ◦ 令牌未过期。服务交付： 卖方服务器处理请求，将最新的金融数据 JSON 返回给 "Analyst-Bot"。捕获（Capture）： 服务交付后，卖方调用 Skyfire 的 charge API，提交该 JWT。资金划转： Skyfire 确认该 JWT 有效且未被结算过，随即执行转账操作。
链下记账： 大多数情况下，Skyfire 先在内部数据库更新余额（买方 -0.50，卖方 +0.50），实现即时到账。
链上结算： 定期或根据阈值，Skyfire 会在 Polygon/Base 链上批量执行 USDC 转账，确保资金的最终所有权转移 。审计记录： 交易详情被写入不可篡改的日志
流程拆分比较复杂，但实际完成其实很快。
利润
交易佣金
每当 AI 代理通过 Skyfire 协议支付费用（如购买算力、数据或订阅 API 服务）时，平台会从中抽取一定比例的手续费。
阶梯收费：
小额交易（$250 以下）： 2.5%
大额交易：1%
KYA（身份验证）服务费
开发者或公司需要为旗下的 AI 代理申请经过验证的数字身份，以通过各大平台的防机器人检查。Skyfire 对这些身份认证和维护服务收取费用。类似于 SSL 证书或企业认证