Polymarket安全事件深度解析：第三方脚本如何触及钱包与签名权限

2026年10月29日，Polymarket国际站因第三方供应商安全事件进入紧急交易限制。平台随后恢复交易并承诺补足受影响用户的损失，但公开证据提出了一个比“又一家加密平台被盗”更具体的问题：如果资金在用户的链上钱包里，为什么一个原本负责网页性能监测的脚本，仍可能成为资产被转走的入口？

这起事件与同一时段的币安事故不是同一案件，也没有已公开证据证明二者来自同一攻击者。金额大小不应决定技术问题值不值得追究。Polymarket案例值得关注，恰恰因为它把风险从“保险柜里的私钥”推进到了用户每天打开的浏览器，以及浏览器已经持有的交易和签名能力。

资料核验截止：2026年10月30日23:30（UTC+8，即15:30 UTC）。 本文围绕10月29日新案，区分官方声明、具名研究、直接链上记录与设计分析。RecodeX使用AI辅助公开资料研究与编辑，核对了官方时间线、当前开发文档及一笔关键交易；未取得平台或供应商内部日志，未运行恶意样本、连接钱包或复算全部受影响地址，也未对全部合约进行安全审计。封面是AI概念插画，不是事故现场或取证截图。

一、先明确结论：目前能确认什么，不能确认什么？

问题	现有材料支持的结论	不能直接推出的结论
是否发生新事故	官方记录确认10月29日国际站第三方供应商安全事件，并实施应急限制	只是把6月旧闻重新传播，或全球所有同品牌服务均被攻破
入口在哪里	公开技术证据把恶意前端脚本与DebugBear监控集成联系起来	供应商具体怎样被攻入、攻击者身份已经查明
是否私钥泄漏	样本研究主要显示对现有交易客户端和签名能力的滥用尝试	已证明所有人的助记词被上传，或已证明任何密钥绝无泄漏
是否合约漏洞	已核交易通过钱包工厂、有效批次与正常资金路由执行	全部合约已被独立证明没有任何漏洞，或必须先攻破合约才能偷到钱
损失多少	第三方给出约250万至273万美元等不同口径，官方未公布最终清算数字	某个接收地址的余额就是总损失，钱包数量就是独立自然人数
是否已经恢复	官方宣布交易重开，状态页将服务事件标为解决	所有旧会话安全、完整复盘公开、全体赔付均已完成

最有分量的一手依据不是社交平台上最大的损失自述，而是Polymarket原生事件页、平台恢复原帖，以及DebugBear要求RUM客户移除嵌入代码的声明。官方信息能确认责任主体怎么说、服务怎么停复，不能独自代替技术取证和资产对账。

二、时间线：构建、停服、重开和赔付是不同节点

以下统一使用UTC。对中国和新加坡读者而言，10月29日18时相当于10月30日凌晨2时。因此中文所说的“昨晚”与国际报道里的“周四”，需要先完成时区换算。

时间：2026年10月29日UTC	可核节点	如何理解
17:59:20	Hudson Rock报告检得移除DebugBear RUM集成的production构建时间	是构建元数据，不是精确部署、全部会话清理或攻击终止时间
18:00:44	本稿核对的一笔钱包批次交易成功上链	只证明该笔执行，不能代表全部受害钱包
18:00:58	DebugBear公开承认正在发生安全事件，要求RUM客户移除嵌入代码	是供应商应急通知，不是完整入侵报告
18:05	Polymarket状态记录进入cancel-only，并暂停relayer动作	应急限制开始；不是攻击一定在此刻才开始
18:12—18:13	Hudson Rock报告两次取得相同恶意脚本	是该研究者的取样窗口，不是所有用户的完整暴露窗口
18:33:12	平台原帖称已定位并修复影响国际站的问题，承诺补足受影响者损失	仍因谨慎暂停交易；不等于技术复盘或赔付完成
18:37	原生事件页更新上述处置口径	网页更新时间与X发帖时间分别记录
18:54:45	平台预告约美国东部15时重新开放	当天对应约19:00 UTC，属于恢复预期
19:00:35	平台宣布交易重新上线	是运营恢复声明
19:05	状态页将服务事件标记为Resolved	服务工单解决，不是整个安全事故的财务、取证与法律结案

原帖可分别查看18:33处置说明、恢复预告和19:00恢复声明。原生事件页另保留分钟级的状态更新；两种时点不应被强行压成同一个数字。平台状态记录涉及国际站，不能未经验证就扩写为每个地区实体、产品或客户端均受同样影响。

官方状态历史还列有当天更早的计划维护。维护、认证故障与晚间安全事件有各自记录，不能把页面上的所有异常拼成“全天持续失窃”。同理，状态页目前显示可用，也只代表平台自报的服务状态，不是对每位用户资金或每条提现路径的独立实测。

三、先看正常业务：钱、持仓、订单与钱包并不是一层

Polymarket不是简单地把每个用户的买卖意愿全部写进一张中心化余额表。理解其正常路径，才能看清这次事件为什么可能发生在合约之外。

第一层是抵押资产与持仓。 当前官方文档把pUSD描述为用于交易的抵押代币；用户买到的预测持仓则对应结果份额。现金余额、某个结果的份额数量，以及该份额的市场价值，是不同概念。不能因为持有一万份预测代币，就把它们一律计成已经兑现的一万美元。其收益取决于价格和最终结算，部分市场还存在分割赔付情形，详见持仓与代币说明。

第二层是订单。 按订单生命周期文档，订单在链下创建和撮合，再交由链上合约结算；订单本身使用结构化签名。快速网页交互，并不等于放弃钱包授权和链上验证。但客户端收到订单、订单撮合、交易入块与最终确认，也不是同一个状态。

第三层是用户的钱包和签名器。 钱包文档说明，2026年5月4日起新部署的账户钱包默认使用Deposit Wallet，旧Proxy Wallet及由外部签名者创建的旧Safe Wallet仍有适用情形。登录方式、签名器与资金所在的钱包合约，不能直接画等号。因此，“用了邮箱登录”“用了外部钱包”并不足以单独判断某个账户这次走了哪条路径。

第四层是中继。 Relayer帮助用户支付网络手续费并提交已获授权的钱包动作。它提供执行便利，但不是替用户判断每笔交易商业目的的万能仲裁者。网站展示“免Gas”，也不是“无需任何授权”或“没有资金风险”的同义词。

这四层之间最重要的连接点，是用户已经建立的签名和交易能力。即使资金不在平台的一把统一私钥下，用户通过什么页面表达意图、页面能调用什么签名能力，仍决定了资产安全的一大部分。

四、为什么一个性能监控脚本能碰到交易？

RUM是Real User Monitoring，即真实用户监测。它通常用于观察网页加载、响应和访问体验，看起来与提款无关。问题不在于“监控”这个名称，而在于它通过什么方式进入页面，以及运行时究竟拥有哪些能力。

普通浏览器页面直接加载的第三方JavaScript，并不会因为文件来自另一个公司的域名，就自动被隔离成一个只能读性能数据的小房间。OWASP的第三方JavaScript管理指南指出，这类集成可能获得宿主页面的权限，并存在供应商内容在集成之后被动态改变的风险。HTTPS保证传输链路和连接目标，不保证供应商此刻返回的代码仍然是先前审核过的内容。

可以把它理解为：网站请来一个“测量大厅温度的设备”，却让设备的软件进入了同一间能接触业务操作台的房间。设备原本的用途很有限，不意味着它所获得的执行权限同样有限。若软件被替换，风险就取决于权限边界，而不是产品说明书上的善意用途。

由此得到的设计判断是：把第三方脚本接入已登录、可签名的交易页面，本质上是在扩大能够影响资金操作的代码集合。 这不自动构成对某一家公司的法律责任认定，但在安全评估中，必须把它按“可能接触金融权限的供应链”来审，而不是当作与资金无关的装饰组件。

即使某个密钥没有以明文暴露在网页存储里，页面中已经存在的签名接口也可能成为攻击目标。窃取钥匙和借用一个仍能盖章的操作台，是两条不同的攻击路线；只检查有没有下载助记词，无法覆盖后者。

五、公开恶意样本证明了什么？

Hudson Rock的原始研究报告，两次取得同一15,187字节脚本：代码读取登录上下文，寻找页面交易客户端和签名器，并按分支尝试转移持仓，或卖出后转走余额。它没有把全部账户都放进同一条“先卖仓”路径，也未在所审样本中找到将密码、助记词或私钥发送出去的例程。研究者没有运行样本，不把签名请求当作已静默签成。

BleepingComputer独立分析的副本也观察到，代码试图借用已登录交易会话，按账户情况处理持仓和余额，并利用相关供应商基础设施交换指令及目标账户数据。这支持“监控集成被用于资产盗取”的判断，而不是一个只有名称可疑、没有业务行为证据的猜测。

但读这些材料时，必须留住三道证据门：

代码意图： 文件里写了卖仓、请求签名、转账等逻辑，能证明它试图做什么。
授权是否成功： 签名器是否弹窗、拒绝，或在既有会话规则下允许，取决于具体账户与运行状态，不能由静态代码统一证明。
资产是否真正移动： 要看订单和链上执行的结果，不能只看函数调用或中继返回pending。

因此，“打开页面就能无提示偷走所有钱包”“所有账户私钥都泄漏了”“只有一个API Key就能任意提现”，都超出了现有证据。相反，若只因没有找到私钥外传代码，就说账户安全没有受损，同样没有回答现有签名能力是否被错误使用。

六、API Key、登录会话、Session Key与钱包签名，必须分开

这次事件最值得深入解释的，不是名词越多越专业，而是每种能力究竟能做什么、不能做什么。

能力或组件	正常职责	容易出现的误读
登录会话	让网页识别当前账户，并访问该会话可用的功能	已登录就等于用户同意此后的任意资金动作
CLOB的L2 API凭证	用HMAC认证私有接口请求	拿到API Key就必然获得任意钱包提款权
钱包签名器	对具体订单或钱包动作产生签名	签名在密码学上有效，就必然符合用户真实意图
限权Session Key	在规定范围和期限内进行允许的交易	所有被称为“会话”的东西都能直接提款
Relayer	为已签名动作代付Gas、提交执行	由官方中继发送，就一定是正常用户操作

API文档将鉴权分成L1钱包签名证明和L2 API请求认证，下单本身还需要钱包签名。这里的L1/L2是鉴权层级，不是在区分区块链的主链与扩容层。两道门回答的问题不同：接口是否接受你的请求，不等于钱包已经授权任意资产去向。恶意页面若同时能接触业务客户端和更强的签名能力，问题也就不再只是API凭证是否保密。

还要避免一个特别容易写错的结论。当前官方Session Keys文档明确说明，该功能为Beta，只适用于Deposit Wallet，授权具有范围和期限，Session Key不能提款。不能因为本案出现了“当前会话”，就把它自动归罪于这项限权机制，更不能宣称限权Session Key天然拥有钱包所有者的全部权限。

这也不意味着“只能交易”就没有经济损失：不当交易仍可能改变价格风险与持仓。但阻止任意提款与约束恶意交易，本来就是不同控制目标。安全设计应该明确每个签名者的权限，而不是在一次登录后，用一个模糊的“已授权”覆盖所有动作。

七、一笔真实链上交易，揭示了怎样的执行路径？

RecodeX核对了这笔Polygon交易：2026年10月29日18:00:44 UTC，区块96394310，状态为Success。交易交互对象被浏览器标记为Polymarket Deposit Wallet Factory Proxy，钱包批次记录中可见nonce为4的执行事件。

在该笔记录中，可以看到约358,369.451585 pUSD的解除包装相关转移，涉及USDC.e资产路径；随后约3,681,681.36343 POL经Relay Router流向公开研究关联的接收地址。这是同一笔资金路径中的资产转换，不应把pUSD、稳定币与最终POL各算一次失窃。

核对项	本笔交易能证明什么	不能替代什么
Success与区块记录	该交易成功执行，而不只是网页提交请求	全部受影响账户的成功率与最终净损失
钱包工厂与批次事件	执行经过现有钱包批次机制	是哪位真人、哪个页面或哪种会话产生了签名
资产转移与接收地址	能沿该笔记录查看具体数量和去向	所有后续地址的归属、全案追回金额或攻击者真实身份
当前美元估值	浏览器此刻如何给资产估价	案发时价格、真实成交成本或统一的赔付标准

这里还应留意代币身份。pUSD官方文档的具体包装和解除包装接口列有USDC.e路径。本笔交易里实际出现的USDC.e，不能为了简化叙述就偷换成原生USDC；同样，POL是这笔路由最后收到的资产，不能由此反推所有受害者原来都持有POL。

钱包批次通常把调用目标、动作、顺序编号和截止条件纳入授权。官方钱包文档也描述了这样的批次。顺序编号主要防止已用授权被重复使用，截止条件限制何时还能执行；它们并不自行回答“这个陌生收款地址是否符合用户意图”。一份全新的、格式正确的恶意业务请求，仍可能通过只验证签名与格式的检查。

本稿没有从一笔样本外推全量。链上记录还不能单独恢复签名时的浏览器界面、弹窗内容、用户是否点击，以及供应商系统内部的入侵过程。这些需要额外日志和取证，而不是用“交易有效”四个字一笔带过。

八、219万、257万、273万美元：统计的到底是什么？

不同报道的数字，不一定谁对谁错，也可能根本不是在统计同一对象。

来源	公开数字或对象	使用边界
Hudson Rock	截图所示接收地址约219万美元持仓	是余额快照，不是该机构独立核清的全案损失
BleepingComputer	约2,860万POL转往另外三个钱包，当时约257万美元	是其追踪与估值口径，不能与同一资金的后续余额相加
Bitquery	其调查识别约273万美元、737个钱包，数据读至10月29日19:49 UTC	是研究机构统计，不是平台最终清算；钱包不等于独立自然人
Polymarket官方	承认第三方事件并承诺补偿	截止所核材料未给最终损失、完整受影响名单或已赔付总额

Bitquery的调查将追踪范围、估值假设和读取截止另列。其资金流描述包括POL分拆与部分跨向以太坊；那是10月29日的快照，不能写成本稿发布时实时余额。本文未独立复算其737个钱包，也不继承其“全部合约未被攻破”等超出本稿验证范围的绝对表述。

核算至少要把四个概念分开：受害者原始资产流出、攻击地址收到多少、换币后还剩多少，以及最终追回或补偿多少。它们中间会有手续费、价格变化和未完成路径。预测持仓还需独立估值，不能一律按最高可能赔付面值计价。

社交平台上的大额自述也不能直接补进聚合数字：同一个人可能有多个地址，同一笔资金可能被研究机构重复覆盖，持仓估值又可能和现金流出不同。没有逐笔映射，给数字做加法只会把不确定性包装成精确。

九、到底是哪一层出了问题？把根因拆成四个问题

“第三方被攻陷”说明了一个重要入口，却不是端到端的全部解释。更完整的事故复盘应回答四个独立问题。

一是上游如何失守。 攻击者控制了供应商的什么：管理账户、代码发布、配置接口、分发节点，还是其他系统？目前的公开声明和样本不足以选择其中一种，更不能据此指认具体员工、国家或团伙。供应商域名出现恶意内容，也不自动证明它的所有产品与所有客户都遭到同样影响。

二是危险代码如何进入资金操作页面。 需要准确的投递版本、时间、页面范围、缓存与已打开标签页状态。一个构建里删除了脚本引用，能支持该版本做过移除，却不能覆盖每个已在运行的页面。构建时间尤其不能冒充“从此刻起所有客户端安全”的回执。

三是代码获得了多强的能力。 仅读市场数据、认证接口、提交订单、调用所有者签名和发起钱包批次，应当是不同级别。样本寻找到某个对象，与该对象最终允许哪些请求也需要分开。应披露具体钱包类型与签名路径，而不是用“非托管”或者“私钥不出设备”概括过去。

四是异常为什么没有被独立制动。 这不是在断言平台当时完全没有风控，而是提出取证问题：连续资产外流、同一陌生接收方、异常卖仓与资产转换，当时分别触发了什么规则？哪些动作被拦截、哪些已获授权并进入执行队列？只有这些记录，才能评估控制有效性。

现有材料最支持的归纳是：第三方前端供应链与登录后资金权限之间的边界，是本案的关键分析对象；平台合约被攻破或所有私钥被导出，都不是目前可以直接盖章的结论。 “不需要先破解密码学”不等于攻击简单，而是说明攻击者可以选择更接近用户意图输入端的路径。

十、为什么暂停Relayer与“停止新订单”不是一回事？

官方事件页同时提到cancel-only与暂停relayer。这不是多写了一个技术名词，而是在收紧两条不同的执行路径。

Cancel-only主要限制新交易意图进入订单系统，并保留可取消订单的处置空间；Relayer则关系到已签名的钱包动作如何被提交。即使网页已经不准创建新买卖，既存签名、已提交批次、待广播交易和直接链上动作，也未必因此一同失效。反过来，停止一个中继服务，也不应被写成整个Polygon网络停止转账。

从应急设计上，应该逐条标明：哪些请求只是被页面按钮禁用，哪些在服务端被拒，哪些已经进入队列，哪些已经签好但尚未执行，哪些可由其他路径广播。否则，“已经暂停”容易只是一句人类可读的口号，而不是资金系统可执行的边界。

这也解释了为什么不能只按上链时间评判补丁。若一笔转移晚于修复声明，需要继续区分预先签名、排队广播、旧页面仍运行、恢复后新授权等可能性。时间相邻提出了需要追查的问题，却不自行证明因果。本文没有用未独立定位哈希的“晚期转移”转述，直接宣布修复已经失效。

十一、重开交易之后，安全事件还剩哪些尾部风险？

运营恢复、技术遏制、权限清理与资金补偿，应当分别交付证据。

阶段	可以核验的材料	单凭什么还不够
恢复服务	按组件的状态更新、交易与接口实际结果	一张全站绿色截图
切断投递	修复版本、资源清单、已验证的代码与分发策略	仅看到首页不再引用某个文件
清理暴露权限	会话、凭证、签名授权和既存批次的处理范围	只让用户刷新网页或改密码
审计资金	明确时点、地址、币种、持仓及去重方法	一个攻击地址的当前余额
完成补偿	公开规则、受影响者认定、估值与实际到账回执	承诺“全赔”或宣布交易恢复

已打开的标签页值得特别提及。服务器提供了新版本，不代表旧页面里的代码已经消失；用户在设备之间的会话状态也可能不同。这里讨论的是普遍的客户端处置边界，不是在没有证据的情况下声称恶意代码目前仍在运行。

同样，更换API凭证不能自动回滚已经转出的资产；断开钱包连接也不等同撤销所有链上权限。每一步都应说明作用对象和有效时间。把这些动作统称“重新登录即可”，可能给用户一种超出实际控制能力的确定感。

十二、“全额补偿”需要怎样的价值与权利说明？

平台在原帖中承诺补足所有受影响者损失，这是一项明确的对外承诺，但不是全体用户已到账的证据。AP对当日事件的报道也记录了补偿与移交执法的说法；报道不等于英国执法机关已公开确认侦破或资产已返还。

关于具体条件，公开报道和用户投诉出现了不同层次的信息。ChainCatcher转述的赔付争议等材料提到身份披露及settlement/release；另有对CNBC的转述称小于1万美元的损失预计在10月30日恢复，更大的损失涉及签署文件。本稿未取得可核的完整官方政策或协议全文，不能据此断言所有人必须签、恰好1万美元如何处理、某项条款违法，或已完成何种权利放弃。

比“会不会赔”更具体的问题，是“按什么标准恢复到什么状态”。如果用户的预测持仓被非自愿卖出，补现金、补同等份额、按某个时点市价恢复，可能产生不同结果。以下只是解释差异的假设例子，不是本案实际赔付政策：

某人持有1,000份结果代币，事前报价0.60，异常卖出均价0.55。那么，报价价值600、卖出所得550，以及最终事件若获胜时可能对应的1,000，并非同一个损失数字。不能把未来可能收益直接当已确定现金，也不能不解释价差、手续费与持仓被迫改变的时间风险。

因此，一份可核的赔付说明至少需要交代：事故快照、受影响范围、现金与持仓如何分别估值、执行成本、市场后续变化如何处理、身份与协议要求，以及到账后的核对和纠错机制。本文不替用户判断具体协议是否应签；涉及实质权利的文件，应核实完整文本并在需要时寻求独立专业意见。

十三、不要把6月旧案、个人账户投诉和这次事件混在一起

搜索Polymarket安全事件，很容易找到类似的旧标题：第三方供应商、恶意脚本、用户资产、退款承诺。这种相似性是误报的高发来源。

最值得直接对照的是2026年6月25日平台原帖，它确实提到第三方供应商受侵、前端恶意脚本与移除依赖。但该帖的原生发布时间是6月25日，不是10月29日。旧案媒体中的约300万美元、少数账户及退款进度，均不能搬来充当本次新案的官方统计。

其他日期涉及认证工具、订单或运营钱包的材料，也需要各自原证。不能因为多个案件都出现“第三方”，就认定同一家供应商、同一个漏洞、同一组攻击者或同一次未修补的入侵。若要判断平台是否存在反复的供应链治理问题，需要的是每次事故的控制清单、整改记录和验证范围，而不是把不同损失数排成一列后直接定案。

社区预警有价值，但也不等同资产审计。本稿不把单个大额损失自述作为总额锚点；即使相关帖子后来删除，也不能据此认定自述造假。对受害者和被质疑者都适用同一标准：具体资金、地址归属与事件关联，需要证据，不能由转发量裁决。

十四、与币安事故相比，真正相通和不同的是什么？

在币安事件的公开资料分析中，一个重要问题是有效签名与业务授权之间的距离。Polymarket让这个问题在另一个层面显现：即使钱包和签名检查按设计运作，用户表达交易意图的页面仍可能被污染。

对照维度	币安案的公开关注点	Polymarket本案的公开关注点
入口与环境	生产权限、签名流程及多链钱包运营链路	第三方前端脚本、用户登录页与现有签名能力
资金组织	平台管理的热钱包与客户账本关系	多类用户钱包、抵押资产与结果持仓
技术证据边界	不能将一条以太坊支线直接推广到全部链	不能从一份静态样本推导所有账户无提示签名
共同的风险问题	谁能让签名系统认可错误的业务请求	谁能让用户会话发出错误的业务请求
真正的收尾	安全修复、资产覆盖、服务恢复分别核验	投递切断、权限处置、持仓补偿分别核验

这不是在说两案具有共同攻击者或相同技术根因，也不把币安案中的EIP-7702套到Polymarket。EIP-712结构化签名、普通API认证、账户代码委托，是不同机制，名称相近不能互换。

更普遍的教训是：密码学只能验证特定授权是否符合规则，不能自动理解屏幕前的人原本想做什么。 信任链一旦从界面、会话或调用权限处被改变，合法签名也可能服务于非法目的。这个问题既存在于中心化交易所，也存在于强调自托管的应用，只是控制对象和责任边界不同。

十五、哪些工程措施有针对性，又分别有什么局限？

以下是基于公开证据与威胁模型的设计建议，不是断言平台事发时每一项都不存在，更不是配置一项就能绝对防盗。

控制层	更有针对性的做法	必须说明的边界
第三方代码	登录后、签名、提款页面移除非必要任意脚本；采集需求与资金操作隔离	在同一高权限页面换一家监控商，不等于自动完成隔离
内容完整性	对可固定资源做版本与字节校验，受控审核更新或自托管	自托管不证明代码本身安全；动态加载的后续内容仍需纳入
浏览器策略	收紧可加载来源及连接面，配合隔离机制	允许域名返回的内容被篡改时，单纯域名白名单可能仍放行
签名能力	交易、提款、授权管理分权；关键资金动作有可信显示与新确认	一次登录或一次历史同意，不能覆盖未来所有目标与金额
钱包策略	范围、额度、期限、收款方及异常行为约束	防重放不等于防错误授权；只能交易也仍有交易风险
服务端制动	订单、中继、钱包批次与待执行动作分别有可审计的停机边界	UI按钮禁用不是服务器拒绝，暂停一个入口不是所有路径零写
监测与处置	对异常批量卖仓、新接收方集中流出及资金路径变化独立告警	格式合法、签名有效、官方中继发送，不足以排除业务异常

MDN的SRI说明介绍了浏览器对预期资源哈希的校验。它能发现固定资源的字节被更换，但不是“证明程序没有恶意”的证书；跨域条件、供应商更新方式和动态资源还要实际验证。OWASP的相关指南则把第三方代码变更、权限和隔离一起看待，不能用“网站有CSP”代替整个权限评估。

安全确认界面同样必须在威胁模型里。如果同一段受污染的页面既选择目的地址，又负责画出“安全提示”，多一个普通页面弹窗未必增加独立信任。真正需要的是用户能够核实的交易语义与受约束的签名能力，而不是让用户在更快出现的弹窗中继续点击同意。

十六、普通用户应怎样核对，而不是落入二次“退款”骗局？

首先，保留可核记录：异常发生时间、订单、资产与持仓变化、交易哈希、平台工单和通知。把“我看到余额下降”进一步对应到订单执行、钱包转移或市场价格变化，才能避免把不同问题混为一个金额。

其次，通过自行确认的官方入口核查会话、API凭证和钱包权限，按平台的安全指引处理。不要因为熟悉的网站名称、官方风格页面或正在显示的账户余额，就批准自己没有发起、不能理解目的地址和资产去向的请求。

再次，关闭可疑标签页、切换干净会话和调整权限，是不同层面的动作，不应被宣传成恢复已转走资产的万能办法。若关键设备本身可能受污染，应先解决环境可信度，再输入新的敏感信息。本文没有验证任何账户当前是否安全，也不建议用一笔主动转账来“测试有没有被盗”。

最后，退款信息应当与已确认的支持渠道、案件范围和完整文件核对。不要向私信中的“客服”“追回团队”提供助记词、私钥或远程控制；不要为了领取补偿，先向陌生地址付款、授权任意支出，或签署看不懂的资金动作。识别用户身份与索要钱包控制权，是两件完全不同的事。

十七、判断这起事件是否真正收尾，需要补齐哪几项证据？

一份有意义的后续披露，至少应回答以下问题，而不是只重复“问题已解决”：

供应商入口： 最初被攻入的系统和权限是什么，攻击者如何改变客户收到的脚本？
投递范围： 哪些资源版本、页面、时间和客户受到影响，如何处理缓存与已经打开的会话？
签名路径： 不同登录方式与钱包类型，哪些能力实际可被调用，哪些请求弹窗、拒绝或成功？
交易结果： 资金流与持仓转移怎样去重，如何区分失败、pending、成功与后来返还？
应急边界： 订单、中继和已签批次在何时分别被限制，恢复基于哪些安全验证？
赔付账本： 谁被认定受影响、按什么价值与时间恢复，完成比例与纠错机制如何？
复发防线： 哪些第三方执行权限被移除或隔离，关键签名动作获得了哪些独立约束？
调查与归因： 哪些是平台或供应商自述，哪些有外部验证，执法机构实际确认到了哪一步？

没有公开这些材料，不等于可以认定它们不存在；但外部读者也没有理由把服务恢复绿灯，自动升级为全部问题已经被证明解决。安全报道的职责，是保留这段证据距离。

结语：非托管的资金，也需要可信的意图入口

Polymarket本案最值得记住的，不是“监控工具突然有了金融功能”，而是原本用于体验测量的一条代码供应链，可能与真实资金权限处于过近的执行环境。被改变的未必先是区块链规则，而可能是向规则提交请求的人机界面。

对用户来说，钱包仍归自己控制，不等于日常使用的钱包前端不值得信任评估；对平台来说，“合约正常运行”和“第三方出了问题”，都不能替代对完整业务权限链的解释。只有把代码从哪来、能调用什么、谁确认资产去向，以及异常如何被独立制动连起来，才能回答“到底哪里出了问题”。

这也是本稿采用克制结论的原因：新案已确认，前端供应链与会话权限风险有实质证据，但最终损失、所有签名路径、供应商初始入侵和赔付完成度仍需继续核验。把未知写成已知，既不会帮助受害者，也不会让下一套系统更安全。

资料索引与研究说明

官方声明与事件身份

取证报告、链上记录与报道

产品机制与防御标准

旧案对照与延伸阅读

官方帖子、状态页、供应商声明和媒体引用可能来自同一原始信息，本文不把转载次数当作独立验证次数。当前开发文档用于解释能力边界，不当作事发时所有账户配置的证明。个别X长帖通过公开元数据、全文镜像与原生状态页交叉核对；未直接取得完整赔付政策或供应商内部取证材料。本文不提供投资、交易、个案法律判断或资产追回服务；若出现正式复盘、可核赔付明细或新的交易证据，应按新材料另行更新。