区块链
SpaceXAI 与 Starlink 账号异常后的 SCATMAN 流动性退出与增发抛售
公开警报与保留截图显示, @SpaceXAI 与 @Starlink 出现把品牌关注引向 SCATMAN 的异常转发;链上管理员取回权限,22 秒后完成主要抛售,而最后 11 秒内,10 万亿枚新代币令 pair 向 router 输出 WETH,router 在同一交易解包,并把完全同量原生 ETH 付给卖方。

文章导航
1 公开证据沿账号传播和 Robinhood Chain 两条时间线汇合
1.1 00:41 UTC,真正有用的第一个信号不是价格,而是品牌账号做了不像自己的事
2026 年 7 月 13 日 00:41:49 UTC,WuBlockchain 发布了涉及 @SpaceXAI、@Starlink 与 SCATMAN 的异常活动警报。00:47:42,Lookonchain 跟进,明确提醒不要购买该代币,并给出 Robinhood Chain 上的完整合约地址。两条警报只相隔 5 分 52 秒,距离事件很近;这使我们能够赶在后来的新闻摘要把“账号异常”“代币交易”和“攻击者身份”压成一句话前,将三者按各自证据分开记录。
当时流传的截图显示,这两个账号似乎曾转发或放大围绕“Scam Altman”叙事制作的 SCATMAN 内容。BeInCrypto 发稿时,相关转发已经无法在账号页面看到。删除改变了普通访问者眼前的平台状态,却没有抹去报道者的 status ID、时间、保留截图,也没有改变警报中指出的合约地址。调查因此从一个会消失的平台对象出发,立即转向那些不依赖页面当前状态的记录。
一个经过认证的品牌账号出现未预期转发,是账号安全信号,却还不是根因结论。它可能来自密码泄露、会话令牌被盗、OAuth 授权、邮箱恢复链、委派发布权限、第三方社媒工具、运营终端失陷,也可能是有权限人员滥用。到本文 7 月 15 日的复核节点,SpaceX、Starlink 与 X 都没有公开入口、会话和持续时间的技术说明。公开证据足以启动“账号被异常使用”的调查,却不能替平台和企业日志选择一种入口。
1.2 被推广的合约是证据连接键,不是“同一人控制全部对象”的证明
截图与实时警报固定了三个字段:账号名称、狭窄的公开观察窗口,以及被推广对象。Lookonchain 给出的完整地址是 0x9beF0a6E2717957F6c51551dE892553C3Fb86604。它比“SCATMAN”这个名字或代币符号更可靠,因为名称可以在不同链、不同合约上重复;网络加完整地址则指向唯一部署字节码、交易历史、状态和事件流。
Robinhood Chain 随后提供第二只时钟。区块记录保留了合约部署、建池、LP token 去向、管理员状态变化、代币增发、router 授权、交换、后建流动性与资金归集。这条链上时间线从公开账号警报前约八小时就已开始。链不能告诉我们谁登录了 X,却能说明被推广的市场早已准备就绪,也能说明特权管理员后来使用了一个快照式安全徽章可能漏掉的恢复路径。
图中的红线表示证据关联,不表示归因捷径。“这两个账号推广了这个合约”与“这些钱包操作了这个合约和市场”是两条可以分别复核的命题。要进一步写成“同一个人控制账号和钱包”,还需要平台、桥、交易所、托管商或设备记录。把缺失的那条边保留下来,是事件重建与现实身份归因之间最重要的区别。
三类证据回答不同问题,也必须保留各自的时钟。账号公开记录回答外界看到了什么:哪个经过认证的账号展示了内容、放大什么对象、观察者何时捕获、内容后来是否仍可见。平台记录才回答它如何发生:会话建立、源网络、设备、认证方式、委派角色、应用授权、恢复事件以及删除动作。公开截图不能替代这些私有控制面日志。
链上记录回答市场对象做了什么。交易哈希固定调用者、接收者、input、成功或回滚、区块时间、日志与资产变化;runtime bytecode 与 storage 读取则固定可执行权限路径,即便源码未验证。浏览器标签有助于导航,但标签本身不是最终证据;可复现对象是字节码、calldata、receipt、block、storage 与余额。
服务商记录才可能回答资金入口和出口背后是谁。桥可以确认源交易及其保留的账户资料,交易所或托管商可在合法流程下把充值地址映射到账号,X 可保存会话和授权应用,企业身份与终端系统则能指出执行账号动作的设备或 token。缺少这些记录时,共同归集地址是强链上联系,但不是身份证明。
因此,本文范围可以说得很清楚:公开证据支持 @SpaceXAI 与 @Starlink 出现与 SCATMAN 有关的异常传播;Robinhood Chain 支持预先准备、可逆的管理员隐藏、特权增发、经 router 卖出、后续流动性管理和钱包归集。企业网络、Starlink 卫星控制面、用户终端与 X 平台级漏洞都不在当前公开取证范围内。明确这些范围不会削弱结论,反而让已经确认的链条更牢。
保全记录不需要用“黑客证据”这样的宽标签,而应固定来源、对象、来源原生时间和一条可检验断言。WuBlockchain 与 Lookonchain 的 status ID 分别解析为 00:41:49.776 和 00:47:42.191 UTC;这两处时间只说明警报何时发布,并不等于账号异常使用或转发最早出现的时刻。截图应保留未裁剪画面、来源 URL、像素尺寸、文件元数据和捕获方法;缺少来源或时间的二次转发图,只能作为低权重背景。
推广对象则由 Robinhood Chain、chain ID 4663 与完整合约地址共同固定。两个来源若只共享“SCATMAN”一词,关联很弱;都指向同一网络和地址,链上对象才真正可复现。以后拿到平台导出、X 会话、交易所或终端记录时,应只更新它们能够补强的那条联系,而不能据此改写既有区块历史,也不能反推两个账号的动作顺序、共享工具或会话控制。
2 删掉的转发很短,链上的故事却从部署一直延伸到第二次撤池
2.1 桥接资金到账 14 秒后部署,11 秒后市场已经可以成交
下文统一使用 UTC。Robinhood Chain 是使用 ETH 支付 gas 的 Arbitrum Layer 2,主网 chain ID 为 4663。7 月 12 日 16:35:54,主操作地址 0xfEE50d4ce48F2D05f520CE04c875647e4870a8ba 通过带有 Arbitrum L1-to-L2 地址别名特征的路径收到 5.535 ETH。14 秒后,它部署 SCATMAN;再过 11 秒,10 亿枚初始代币与 5 ETH 被放入 V2 风格交易对。
地址别名必须窄化解释。Arbitrum 会在特定 L1 发送方映射到 L2 时加入固定偏移,因此两个十六进制地址可能因协议规则呈现数学关系。这有助于追踪跨层资金,却不是某个人的指纹,本文也不以别名公式把钱包归入同一主体。这里能确认的是:主地址在收到原生资产后立刻拥有了部署合约和建立首轮流动性的能力。
部署到建池的时间说明,这不是一个先放着、等社区以后再启动的实验合约。初始供应、交易对和价格发现通道被组合成一段连续操作;到 16:36:19,任何能够访问网络并得到 pair 地址的人都可以交易。后来的账号传播没有创建代币或市场,而是把更强的品牌信任引向已经运行的基础设施。
第一次公开账号警报出现在约八小时后的 7 月 13 日 00:41:49。这个提前量不能证明操作者当时已经取得两个账号,却能确认市场准备早于公众警报,也符合“推广出现时马上可买”的操作条件。负责任的重建只说明这层时间关系,除非账号会话证据补上因果边,否则不把它写成既定的提前接管。
下面的表没有从最吸睛的 10 万亿增发开始,而是保留完整顺序。只有从头读,首轮 LP 销毁、可恢复管理员冷却、第二钱包的早期入场、管理员认领、第二个流动性头寸,以及公开警报后的继续管理才会落在同一条故事线上。
| UTC 时间 | 链上动作 | 它改变了什么 |
|---|---|---|
| 7 月 12 日 16:35:54 | 主操作地址 0xfEE5…a8ba 经桥接别名收到 5.535 ETH | 为部署和首轮流动性准备原生资产;桥接别名只证明资金进入该地址。 |
| 16:36:08 | 部署 SCATMAN,初始供应 10 亿枚 | 创建字节码、管理员状态和初始余额;合约源码没有在 Blockscout 或 Sourcify 验证。 |
| 16:36:19 | 向 V2 风格池加入 10 亿枚 SCATMAN 与 5 ETH | 建立首个可交易市场,交易对地址为 0x137A…89b8。 |
| 16:38:38 | 把除最小锁定量外的首批 LP 代币转入死亡地址 | 首个 LP 头寸不能由该地址正常赎回;这没有改变 SCATMAN 合约的增发权限。 |
| 16:38:44 | 调用 beginCooldown(300) | 管理员槽暂时清零,原管理员保存在另一状态槽,最早可在 16:43:44 后取回。 |
| 16:39:38–16:48:26 | 第二钱包 0xDD9F…Ba89 两次买入并先卖出 95.5 万枚 | 该地址在首个池建立后约三分钟入场,早于公开推广警报。 |
| 17:15:29 | 第二钱包卖出约 5927.687 万枚 | Pair 向 router 输出 14.729642457926006985 WETH;router 调用 withdraw,并在同一交易向卖方支付完全同量原生 ETH。 |
| 17:22:23 | 调用 claimAdmin() | 原管理员从保存槽回到管理员槽;“管理员为零”的页面状态至此结束。 |
| 17:22:34–17:22:45 | 增发 10 万亿枚、授权路由器并全部卖入池 | 11 秒内把供应量放大四个数量级;pair 向 router 输出 59.085639498469409057 WETH,router 解包后向卖方支付同量原生 ETH。 |
| 17:25:39–17:25:50 | 再增发 50 亿枚,并以约 18.4339 亿枚加 0.27 ETH 建立新 LP | 第一次“烧 LP”没有阻止创建第二个、独立的流动性头寸。 |
| 17:36:00–17:37:20 | 主地址与第二钱包分别向 0xf252…e5B8 转入 59.3067 与 7.7022 ETH | 共同归集构成强链上运营关联;现实身份仍需交易所、桥和平台记录确认。 |
| 7 月 13 日 09:22:58 | 主地址移除第二个流动性头寸 | 后建 LP 被正常撤出,事件并未在第一次巨额抛售后立刻结束。 |
2.2 第一个市场同时展示了两个令人放心的快照,却留下最危险的能力
16:38:38,初始 10 亿枚 SCATMAN 与 5 ETH 头寸对应的绝大多数可用 LP token 被转到死亡地址。对行情界面来说,这个动作很像一种承诺:提供者不再持有通过常规 pair 路径赎回该头寸所需的凭证。六秒后,beginCooldown(300) 又把当前管理员槽清零。一个只抓单点 storage 的页面,此时可能同时显示“LP 已烧毁”和“owner/admin = 0”。
这两项观察都不是伪造的。LP 凭证确实被转走,slot 5 也确实变成零。问题在于它们都不完整。LP 转移没有回答代币能否制造新供应;slot 5 清零没有回答 slot 6 保存了谁,也没有检查 claimAdmin() 是否可达。当安全标签把两个局部真相合成“控制权已经放弃”这一全局结论时,标签才开始误导。
五分钟冷却在 16:43:44 结束。从那一刻起,保存地址即可恢复自己,但它一直等到 17:22:23 才操作,中间约 39 分钟。这个间隔很重要:管理员并不需要在截止时间到达的瞬间回来,因此 16:45、17:00 或 17:20 采样的扫描器仍会看到零。快照分析问“现在是谁”,可达性分析问“谁以后能把系统带回有权限的状态”。
管理员看似缺席期间,钱包 0xDD9F6d3E16Ebda7F35cB694ceAdb50Af3EEbBa89 已经进入市场。它在建池后不久分别投入 0.2 ETH 与 0.12145299431379584 ETH,并先卖出 95.5 万枚。17:15:29,它又卖出约 5927.687 万枚:pair 向 router 输出准确的 14.729642457926006985 WETH,router 经 withdraw 销毁这批 WETH,并在同一交易向卖方支付完全同量原生 ETH;主要退出比管理员回来早了近七分钟。
这组顺序比“推广之后才出现的普通钱包”更有调查价值。该地址在市场刚建立时参与,在管理员显示为零的阶段持有大量代币,又在特权增发破坏原供应关系之前完成主要退出。时间本身依然不能识别控制者,但足以说明这个钱包应被放进准备与退出图;若简单归到晚到的公开买家,关键时序就会丢失。
拼接时间线前必须归一化时钟,同时保留所有原始时间。社交与链上记录使用不同时间权威:X status ID 编码创建时间,观察者记录捕获或发布时刻,新闻页面另有发稿时刻,区块则提供网络时间。合格的事件表应先存原值和来源,再换算 UTC。把所有记录四舍五入成“午夜左右”,会抹掉两条警报之间的五分多钟,也会让后续顺序无法审计。
一项链上操作内部也有多层时钟:交易有区块时间戳,日志继承同一区块并有顺序,trace 决定内部调用先后,浏览器可能稍后才完成索引。本文的“11 秒”比较三个确认区块时间:17:22:34 增发、17:22:39 授权、17:22:45 交换。它不代表人工键入耗时,也不判断交易是否预签、自动化或通过私有基础设施提交。
资金准备也可以闭环,但不能把每个差额随手写成成本或利润。主地址收到 5.535 ETH,向首轮流动性投入 5 ETH,同时还执行部署和其他交易。剩余余额参与 gas 与后来活动,精确成本账必须使用真实交易费和后续转账。用 5.535 减 5 只能做合理性校验,不是最终会计结论。
17:36:00,主地址向 0xf252b1CBDA23b3DCa3223D237a37171DAA9Ae5B8 发送 59.30669483459594 ETH;约 80 秒后,第二钱包向同一归集地址发送 7.702168160337135 ETH。这些金额与两名卖方在各自主交易同一交易内收到的精确原生 ETH 不同,因为钱包还支付 gas、保留余额并进行其他活动;这里不存在卖方稍后再 unwrap WETH 的过程。事件表不能用归集到账额替换主要卖出到账额。
次日 09:22:58,主地址移除了巨额抛售后新建的第二个流动性头寸。这发生在公开警报之后,也发生在报道确认转发消失之后,说明运营窗口比多数快讯覆盖的时间更长。只保留推广窗口的调查,会漏掉后续 LP 撤出、资金归集与可能的服务商入口。
3 未验证合约仍可从字节码、状态与交易恢复执行逻辑
代码定位与处置先看部署对象本身:Robinhood Chain 合约 0x9beF0a6E2717957F6c51551dE892553C3Fb86604 的 4,779 字节 runtime 由本文列出的 SHA-256 固定;beginCooldown(uint256) 把管理员从 slot 5 暂存到 slot 6,claimAdmin() 在 slot 7 的时间条件后恢复权限,rebalance(address,uint256) 再增加 slot 2 总供应和接收者余额。三条分支已有成功交易与状态变化见证,因此不能用“LP 已烧毁”或“owner = 0”作为安全结论。账号侧应撤销会话、应用和恢复路径,链上侧则持续监测 slot 5–7、零地址增发、授权、swap 与后来 LP 变化。
3.1 源码验证失败后,部署对象本身就是分析基准
合约页面显示 is_verified: false,Sourcify 对 chain ID 4663 的 full match 与 partial match 均为空。链上保存了创建字节码、运行时代码、每次 calldata、storage、日志和执行结果;开发者本机的文件名、变量名、注释、测试与 Git 历史不属于链上数据。编译器元数据表明产物由 Solidity 0.8.20 生成,并包含一个 IPFS 内容标识;复核期间多个网关均未返回相应源码。下文的函数名来自 selector 解析,状态变量名为便于讨论而设置的语义名称。
这层区别可以防止一种常见取证错误:分析者搜索 selector,找到带相似函数名的公开合约,便把那份源码当成本案部署版本。selector 碰撞、模板复制、编译选项和部署后的版本差异都会让这种做法失真。没有 verified match 时,接近 Solidity 的伪代码只能是解释模型,其中每条分支都必须回到不可变 runtime,并由成功或回滚交易作见证。
为便于后续研究者复现同一部署对象,本文固定了两份代码产物的指纹:
- 运行时代码由
eth_getCode返回,共 4,779 字节;SHA-256 为7F13E3B7。F75F8971 A7213320 A818A7DB 97F1DE9D 39E86421 8BC5BAD4 3EC0DCB3 - 部署交易的创建输入共 6,781 字节;SHA-256 为
7EA4C46E。0EC8FC8B E34BD54D A0F10EF0 F828F661 7D6B5382 B2B0AF2D 624EFC25 - 元数据指向 Solidity 0.8.20 与 IPFS CID
QmYzTHFH6H3fzmfhCBE7BeVLCzSRv8uyCLg1qBYgH2HqcM;该 CID 在复核时不可取回,源码验证状态仍为未验证。
两枚哈希回答的问题不同。creation input 包含只在部署时运行的 constructor 逻辑与参数;runtime 是以后每次调用真正执行的代码。浏览器重新索引、标签变化或前端下线,都无法改变这两组 byte。重新取得部署 input 与该地址的 eth_getCode 返回值并计算哈希,就能确认讨论的是完全相同的对象。
编译器元数据能缩小来源范围,却不能替代源码。Solidity 0.8.20 可以解释 checked arithmetic 和 metadata 结构,IPFS CID 则是构建时嵌入的内容引用。CID 不可取回意味着原始文件名、注释、开发者意图和 Git commit 仍无从确认;“源码未验证”说明缺失的是原始文件,对可执行授权的分析仍可继续。
3.2 Storage 把一个令人放心的零值还原成可达权限图
EVM dispatcher 读取 calldata 前四字节并跳到对应分支;各分支对状态槽的 SLOAD/SSTORE、映射键的 KECCAK256、算术检查、revert 字符串和 LOG3 事件均可观察。SOSEC 将 selector 解析结果与成功交易逐条对照,恢复出八个核心槽:slot 0 是余额映射,slot 1 是授权映射,slot 2 是总供应,slot 3 与 4 是名称和符号,slot 5 是当前管理员,slot 6 保存可重新认领管理员,slot 7 是冷却结束时间。
Slot 0 与 slot 1 采用由地址推导键的 mapping 结构,并非平铺的地址清单。读取余额需要用补齐后的账户地址与 mapping 槽推导 storage key;allowance 还要在 owner 根下继续推导 spender。Slot 2 是标量总供应。这些关系之所以能恢复,是因为普通 ERC-20 查询和已观察转账反复使用相同位置。即使没有源码变量名 balances,仍可证明特权分支修改的正是 balanceOf 查询的映射。
Slot 5、6、7 共同构成权限状态机。只看 slot 5,回答的是“当前状态谁能调用管理员分支”;把三槽与 dispatcher 一起读,回答的是更重要的“哪个地址以后能把合约带回可调用该分支的状态”。保存地址和已过 deadline 让零值只是暂时显示,权限并未被不可逆放弃。
在最新复核状态,slot 5 与 slot 6 都解析为 0xfEE50d4ce48F2D05f520CE04c875647e4870a8ba,slot 7 仍保存 7 月 12 日 16:43:44 UTC,slot 2 则是 10,006,000,000,000 枚。直接 storage 读取与历史调用、零地址 Transfer 相互吻合,给出了当前权限和供应的三重视角。
| 入口 | 字节码确认的状态变化 | 链上见证 |
|---|---|---|
0x3da9b9d0rebalance(address,uint256) | 要求调用者等于 slot 5;增加 slot 2;增加 keccak256(to, 0) 对应余额;发出 from 为零地址的 Transfer。 | 17:22:34 增发 10 万亿枚;17:25:39 再增发 50 亿枚。 |
0xab92831dbeginCooldown(uint256) | 要求当前管理员调用;把 slot 5 复制到 slot 6;清空 slot 5;把 block.timestamp + delay 写入 slot 7。 | 16:38:44 传入 300;管理员页面随后显示零地址。 |
0x77f50f97claimAdmin() | 要求调用者等于 slot 6,且当前时间大于 slot 7;再把 slot 6 写回 slot 5。 | 17:22:23 成功,11 秒后第一次巨额增发。 |
3.3 成功交易把 selector 猜测变成有状态变化作证的行为
函数签名来自 selector 解析,变量名是便于阅读的语义命名;真正具有证据力的是下面的状态读写。把字节码还原成接近 Solidity 的伪代码后,权限关系十分直接:
rebalance(to, amount):
require(msg.sender == storage[5], "!admin")
storage[2] = checked_add(storage[2], amount)
balances[to] = checked_add(balances[to], amount)
emit Transfer(address(0), to, amount)
beginCooldown(delay):
require(msg.sender == storage[5], "!admin")
storage[6] = storage[5]
storage[5] = address(0)
storage[7] = checked_add(block.timestamp, delay)
claimAdmin():
require(msg.sender == storage[6], "!nominated")
require(block.timestamp > storage[7], "cooldown")
storage[5] = storage[6]
rebalance 这个名字听起来像组合再平衡,分支执行的却是增发语义:要求 slot 5 管理员,增加总供应,增加任意接收者余额,并发出标准零地址转出事件;没有任何对应账户被扣减。17:22:34 交易把主操作地址作为接收者、把 10 万亿作为数量,因此 calldata、storage delta 与事件数量都指向同一次特权发行。
beginCooldown 没有销毁钥匙,也没有写入不可达地址。它先复制当前管理员,再清零活动槽,最后设置时间条件。claimAdmin 检查保存地址与 deadline 后把活动槽恢复。把三条分支连起来读,便能解释为什么无需任何新 nomination 交易,原地址就能回来:恢复路径一直由合约自己保存。
该流程属于可恢复管理员机制。活动管理员清零时,同一地址仍保存在 slot 6;五分钟结束后即可重新写回 slot 5。事件中的实际认领发生在 17:22:23,比最早可认领时刻 16:43:44 晚约 39 分钟。仅抓取当前 owner/admin 的行情页面会在这段窗口显示零地址,完整权限审计还需读取关联槽并计算可达状态。
独立复现无需先反编译整份合约。第一步取得 runtime,核对 4,779 字节长度和 SHA-256;第二步固定 cooldown、claim 与 mint 的 receipt 和 block;第三步读取三笔交易前后的 slot 5–7;第四步解码增发产生的零地址转账;最后用只读调用或 trace 证明接收者余额与总供应按同一数量增加。
这组交叉检查还能主动暴露错误。如果 selector 库给错签名,calldata 长度或参数位置会与状态变化冲突;如果 storage 语义命名错误,前后读取不会对应交易效果;如果浏览器按 decimals 展示出错,原始事件数量与 slot 算术仍保留整数。复现不是给浏览器截图盖章,而是让多个独立观察在同一状态转换上闭环。
回滚 selector 只能说明尝试过控制,不能证明部署能力。认领管理员后,操作方先后发送 0x5ed7ca5b 与 0x046f7da2;selector 库常将其显示为 halt() 和 resume(),runtime dispatcher 却没有对应成功分支,两笔执行都回滚。因此,暂停能力没有在部署字节码中得到确认,权限清单必须以成功分支、状态访问与执行结果为准。
这些失败调用仍有行为价值:它们证明主地址在恢复权限后提交过相应 calldata,却不能证明操作者相信函数存在、接口复制正确或曾控制另一个实现。失败尝试应连同 revert 状态写进时间线,不能从“调用过”升级为“合约拥有此功能”。
对缺失功能也采用同一纪律。本文确认 mint 与恢复能力,是因为分支、状态和交易共同作证;不会因为代币合约常见 upgrade、blacklist、税率或 pause,就把这些能力顺手加入结论。每一项附加权限都必须从 runtime 控制流或成功状态变化中单独证明。
复现还要固定取数规则和区块高度。JSON-RPC 返回的十六进制字符串应先去掉 0x 前缀并解码,再计算字节长度与 SHA-256;历史状态则读取相关交易的 parent block 与 resulting block,或使用保留 pre/post state 的 trace。主地址的 slot 0 余额、router 的 slot 1 allowance、slot 2 总供应和零地址 Transfer 必须与 balanceOf、allowance 及 receipt 相互吻合,才能把“清空”“恢复”和“增发”落成可测量的状态差。
Selector 名称仍带解析置信度:四字节前缀可能对应多个候选,最终要由参数长度、ABI 偏移、revert 行为、分支读写和成功交易效果共同筛选。这里的 rebalance、beginCooldown 与 claimAdmin 同时符合 calldata 和状态见证;即使未来取得源码后发现开发者使用了别的名字,执行效果也不变。4,779 字节 runtime 及其哈希限定了本文讨论的代码对象,后续若同地址读到不同代码,应先排查代理、销毁重部署、网络或采集差异,再沿用结论。
4 销毁的是第一张取款凭证,留下的是制造新筹码的钥匙
4.1 池储备、LP 凭证与代币权限是三个不同的控制面
rebalance 制造 10 万亿枚并经 router 卖入池;pair 向 router 输出 WETH,router 在同一交易解包后向卖方支付原生 ETH。LP 销毁只约束首批流动性份额;slot 5/6 控制的增发能力保持可达。自动做市池里至少有两种完全不同的资产。SCATMAN 与 WETH 是池内储备;LP token 是提供流动性后得到的份额凭证。把 LP token 转到不可用地址,会使对应份额难以正常赎回,却不会修改 SCATMAN 合约自身的字节码和 storage。只要代币管理员仍能增发,就可以制造远超池内储备的新筹码,再沿路由器卖给同一个池。
可以把区别理解成三本账。代币合约记录账户余额、allowance、总供应和管理员状态;pair 记录两侧储备,并发行代表比例权益的 LP 凭证;router 负责组织 transfer 与 pair 调用,却不会消除代币层权限。一本账里的安心动作,不能自动约束另外两本。
加入初始流动性时,pair 收到 10 亿枚 SCATMAN 和由 5 ETH 包装而来的资产,并向提供者发行 LP token,另有 pair 可能永久锁定的最小数量。提供者随后把绝大多数可用凭证转入死亡地址。这个动作使首个比例赎回权难以再由提供者使用,却没有把池内储备直接送去死亡地址,也没有改变 SCATMAN 的 slot 5 或 slot 6。
因此,“流动性已烧毁”比“市场不可能被抽走”窄得多。前者通常只描述一条路径:销毁 LP 凭证并按比例取回储备。特权增发者拥有另一条路径:在 pair 外制造代币库存,给 router 授权,再用该库存交换池内 WETH。本案两笔主要卖出都由普通 swap 把 pair 持有的 WETH 送给 router,再由 router 在同一交易调用 withdraw 并把原生 ETH 付给卖方;LP 赎回没有参与。
4.2 死亡地址只约束旧凭证,不能约束未来供应和新凭证
LP 销毁发生在 16:38:38,距建池 2 分 19 秒;六秒后 slot 5 显示没有活动管理员。运行时代码当时已经否定“控制权全部交出”的宽泛解释:rebalance 可在 slot 5 有值时增加供应,冷却路径可从 slot 6 恢复 slot 5。完整交易前审查要分别问谁能赎回当前 LP、谁能改变供应、缺席管理员能否回来、能否再发行 LP。死亡地址结论也只到证据边界:首个头寸的绝大多数可用凭证由发送者无法正常赎回;未知私钥或实现特有恢复仍需额外证据,而实际退出使用新铸 SCATMAN,本就不依赖旧凭证。
后续存款证明结论必须限定批次。17:25:39 的第二次 rebalance 增发 50 亿枚;11 秒后,主地址用 1,843,391,573.398149076868715556 枚左右加 0.27 ETH 建池,取得新 LP 凭证,并在次日 09:22:58 移除该头寸。这是可替代 LP 记账的正常结果,不是第一次销毁的例外:旧凭证进入死亡地址既不禁止新存款,也不决定新凭证去向。第二次增发、注资、发行和公开警报后撤出,还把市场管理窗口延伸到主要卖出之后。
5 管理员恢复 22 秒后,pair 的 WETH 已变成卖方 ETH
5.1 认领、增发、授权与交换连成一句可执行的话
17:22:23,保存管理员调用 claimAdmin(),把自己重新写回 slot 5。11 秒后的 17:22:34,同一个主地址调用 rebalance,接收者也是自己,数量恰好是 10 万亿枚 SCATMAN。交易同时增加总供应和主地址余额,并发出零地址转出事件。潜伏在状态机里的权限,至此变成可卖库存。
17:22:39,也就是增发五秒后,主地址授权 router 使用新币。ERC-20 approve 不会把代币立即移入池,只会在 owner 与 spender 下面写入 allowance。这个中间步骤说明 swap 没有依赖隐藏的 pair 权限;操作者使用的是 router 预期的标准代币授权,只是被授权的库存来自管理员专属的发行分支。
17:22:45,授权六秒后、增发 11 秒后,router 路径卖出恰好 10 万亿枚 SCATMAN。Pair 向 router 发送 59.085639498469409057 WETH;router 调用 WETH withdraw 销毁该数量,并在同一交易向卖方支付准确的 59.085639498469409057 原生 ETH。增发、授权和卖出数量一致,卖方 WETH 余额增量则为零。
从 claimAdmin() 到 swap 共 22 秒,从 mint 到 swap 共 11 秒,两种说法回答不同问题。22 秒衡量权限恢复到市场退出,11 秒衡量新供应变成卖出库存的速度。摘要同时写明两个间隔,正文与时间线则保留连接它们的四笔交易。
紧密时间间隔不能说明交易由人工点击、脚本、bundle 还是预先签名完成。它证明的是操作协调性,不是某个自动化框架。防守上可以得出更实用的结论:只靠 swap 后的价格或供应监控几乎没有预防窗口;更早的信号应放在管理员恢复、零地址发行和异常大额 allowance。
5.2 Router 没有创造退出机制,它只是把特权库存带进普通 pair
V2 风格恒定乘积 pair 持有两侧储备,并在手续费与 invariant 约束下成交。初始池只有 10 亿枚 SCATMAN,特权卖出却输入 10 万亿枚,是初始数量的 1 万倍,WETH 因而成为限制储备。精确输出取决于即时交易前状态、期间交易、费率和整数运算;receipt 与 trace 固定最终结果:59.085639498469409057 WETH 从 pair 进入 router,同一交易内又有准确的 59.085639498469409057 原生 ETH 从 router 进入卖方。
Pair 无需知道 SCATMAN 来自普通转账、其他市场买入还是管理员增发。Router 取得 allowance 并把可替代 ERC-20 库存送入 pair 后,pair 只检查余额、储备、输出与 invariant。失败发生在无限特权发行与市场信任的组合中,并非 pair 合约被未解释漏洞绕过。
WETH 是原生资产的 ERC-20 包装形式,适合作为 pair 储备;router 在同一交易调用 withdraw,销毁 pair 输出并为每名卖方生成原生 ETH。两名卖方的 WETH 增量都是零,两条主交易都不存在卖方稍后再解包。会计应把两种表示保留为同一价值流的两条腿——pair WETH 流出与等额卖方原生 ETH 到账——而把后来金额不同的归集转账只作为关联,不再计为主要卖出收入。
5.3 供应算术在调用、事件、余额与 storage 四个视角闭合
合约初始供应 10 亿枚,第一次特权调用增加 10 万亿,17:25:39 的第二次 rebalance 再增加 50 亿,合计 10,006,000,000,000,与复核时 slot 2 完全相等。这个加法很简单,却很关键:它证明已观察的两次特权事件可以解释当前供应,不需要依赖行情页的市值或四舍五入显示。
每次增发都能从四个角度检查:解码 rebalance input 得到接收者和整数数量;查看零地址 Transfer;比较接收者前后余额;比较 total supply 前后值。四个差值一致时,结论不依赖 selector 的人类可读名字。若不一致,就应先排查解码、decimals、proxy、rebase 或事件假设,再发布结论。
Decimals 只影响展示,不改变底层授权状态。浏览器会按代币 decimals 缩放原始整数,文章则用“亿”“万亿”帮助阅读。研究记录必须保留原始整数、确认 decimals,并写清每一次单位换算。本文的供应整数等式、pair 侧精确 WETH 输出与相等的 router 原生 ETH 付款,是后续复现不随页面格式变化的锚点。
第二次 50 亿增发与第一次 10 万亿增发承担不同操作角色。第一次发行通过 router 作为主要抛售库存;第二次发行中约 1,843,391,573.398149076868715556 枚与 0.27 ETH 结合,形成新流动性。把两笔调用分开,才能解释为什么总供应大于卖出的 10 万亿,也解释为什么首批 LP 被烧后还能出现可撤出的后建凭证。
Pair WETH 流出与 router 支付的卖方 ETH 应分资产列,却共享同一资金流 ID。后来向归集地址发送的 59.30669483459594 ETH 和 7.702168160337135 ETH 属于不同交易和金额,应与完整余额、gas、留存价值及其他活动对账,不能虚构后续解包。检测顺序也很紧凑:claimAdmin() 恢复发行权,rebalance 制造库存,approve 委派支出,swap 改变储备并由 router 为卖方实现原生 ETH;覆盖巨额增发的新 allowance 本身就是独立告警信号。
证据支持普通成功的 V2 风格 swap,不支持“pair 失灵”。关系型检测可以在零地址增发远超此前供应、刚恢复的管理员短时增发、新 allowance 覆盖库存或余额进入浅流动性 pair 时告警。区块顺序证明 claim、mint、approve、swap 的执行次序,却不能说明是人工、自动化、private relay 还是 direct sequencer path;监测应基于已确认状态推进,不猜投递栈。
6 第二钱包与主操作地址形成同一链上调查簇
6.1 第二钱包在市场刚出生时就已出现,并在管理员恢复前完成主要退出
0xDD9F…Ba89 在首个池建立约三分钟后就分两次投入 0.32145299431379584 ETH,时间早于公开账号警报。它先卖出 95.5 万枚,又在 17:15:29 卖出约 5927.687 万枚;这笔主交易让准确的 14.729642457926006985 WETH 从 pair 进入 router,随后经同一交易 withdraw 变成准确的 14.729642457926006985 原生 ETH 付给卖方。这个钱包的入场和两次卖出都早于主地址恢复管理员。
两次买入应保留为两条观察,而不只是合计成本。它们把钱包放在流动性建立后的最初几分钟;此时发现一个新 pair 通常需要监控、协调或偶然。后来的主要卖出说明,它在早期阶段一直持有更大的代币余额,并选择在 10 万亿增发彻底改变供应和价格之前退出。
这组顺序提高调查优先级,却不会让分析者变得全知。它没有说明钱包是从建池交易得知 pair、监控 factory 合约、收到链下通知,还是由部署者控制;但若把它当作普通公开受众,就会忽略异常早的时间、有利的增发前退出和后续共同归集。
6.2 同一归集地址、中间钱包回流和紧邻时间共同加强关联
资金终点进一步加强了关联。主地址在 17:36:00 向 0xf252b1CBDA23b3DCa3223D237a37171DAA9Ae5B8 发送 59.30669483459594 ETH;第二钱包约 80 秒后向同一地址发送 7.702168160337135 ETH。第二钱包还向中间钱包 0x87d13e0719d67567687a1DFa6Cc5bEaA9354213A 转账,后者随后向主地址回送 ETH。共同归集、时间邻近和回流足以把两个钱包归入同一链上运营调查簇。现实主体识别需要继续调取交易所、桥接服务、托管商和平台账户资料。
因此,合理结论是强链上运营簇;这并不表示“所有私钥都放在同一设备”。团队可以拆分钱包,自动化服务可以代发交易,托管商也可能代表账户持有人控制私钥;若共同终点最终被证实为共享服务钱包,身份关联权重还会下降。本文所说“共同运营”是指在服务商记录解释前,应把行为视为协调调查对象;它不会把密钥托管、受益所有权与现实身份压成一个概念。
这条中间路径可以由两笔转账复现。7 月 12 日 17:39:43,第二钱包通过 0x5f6f2103acd01f6a19aea47b4629e8d99f79e24f13ef97ab13d34511809b2cf1 向 0x87d13e0719d67567687a1DFa6Cc5bEaA9354213A 发送 7.03837116 ETH;7 月 13 日 09:20:03,该中间钱包又通过 0x278f01430564526e7eb625457a3eaf7a72b5ab0be6ab0d7605609a34eca99472 向主地址回送 0.00112335 ETH。回流金额虽小,方向关系却不同于两个钱包仅仅调用同一个公共合约。完整解释仍需取得钱包全历史,并独立核实任何服务标签。
6.3 交易对输出、卖方到账、净利润与交易者损失回答不同问题
两次主要卖出在 router 转换两侧都形成可复现的 73.815281956395416042:pair 流出的 59.085639498469409057 与 14.729642457926006985 WETH 相加,两个卖方各自在同一交易收到完全同量原生 ETH。WETH 接收者是 router,它调用 withdraw;卖方 WETH 余额增量均为零,也没有卖方稍后解包。这个总数因此定义为 pair WETH 流出与相等的卖方原生 ETH 到账,不是卖方 WETH 收入、运营净利润或受影响交易者损失。
复算时解码两条 pair-to-router WETH Transfer,保留 18 位原始整数,并在各自 trace 核对相等的 WETH 销毁与 router-to-seller 原生价值调用,最后只加一次。净利润还需要完整地址集与期初期末余额、部署和桥接成本、初始 5 ETH 流动性、第二钱包 0.32145299431379584 ETH 买入、后建 LP 的 0.27 ETH 及撤出、gas、剩余资产、服务与链下成本。后来金额不同的归集转账只证明归集,不能再计一次主交易到账。
交易者损失必须另行定义钱包范围、截止时刻、成本基础、买入/卖出/转账、剩余持仓、回收与估值方法。池储备由初始 LP 和变化价格下的交易共同塑造,因此崩塌市值与运营侧资产流都不等于用户已实现损失。公开报道还使用了随 ETH 与选定时刻变化的美元换算;本文以精确链上数量为主,法币等值只作带日期背景。
最终记录把直接事实、强关联与未决假设分开:
| 证据层级 | 记录支持什么 | 尚不支持什么 |
|---|---|---|
| 公开或链上直接事实 | 警报与保留截图把两个账号和 SCATMAN 传播关联;固定合约、调用、storage、日志、swap、LP 事件与转账在所列时间发生。 | 它们不能披露 X 入口、会话控制者、设备或企业内部影响。 |
| 强链上推断 | 极早参与、增发前退出、80 秒内共同归集和中间钱包回流,使主地址与第二钱包进入同一运营调查簇。 | 这些边本身不能命名个人、公司、国家或密钥托管模式。 |
| 未决假设 | 密码、会话、OAuth、邮箱恢复、委派权限、工具失陷和内部滥用都是响应者应测试的路径。 | 没有平台、身份、邮箱或终端证据时,任何一条都不能公开成既定根因。 |
“接管”与品牌影响也受证据层级约束。认证账号出现未预期行为和当时警报足以启动失陷调查,但 BeInCrypto 无法独立确认控制并已寻求回应;技术入口仍须 X 与企业证据确认。火箭与卫星图像表达品牌信任,不代表发射系统、航天器、卫星控制、计费、终端或客户流量被访问。以后平台或服务商记录可以补上一条已命名缺口,而不改写不可变链上顺序。
7 如果今天负责这两个账号,处置要同时保住平台证据和链上证据
7.1 在止损再次改变页面前,先保全正在消失的账号证据
删除异常内容只能停止继续曝光,不能完成事件响应。成熟的处置应由账号、身份、终端、传播和链上五条工作线并行推进,并在每一步记录执行人、时间、对象和结果。
第一响应者面对真实冲突:让未授权转发继续可见,会把更多用户置于风险;立刻删除,又会改变可观察的平台状态。实际做法是快速保全后马上处置:抓取 URL、post/repost ID、账号、完整 UTC、媒体、回复与引用上下文、可见互动、通知邮件和截图设备时钟,再按平台与法律流程隐藏或删除。
截图应尽可能和机器可读标识一起保存。裁剪图片可能丢掉账号名、时间戳或上下文,像素也很难直接和平台日志连接。记录谁在何时、从登录视图还是公开视图捕获,计算文件哈希。如果平台以后提供导出文件,保留原始导出,并把它与早期公开证据并列映射,不覆盖原件。
对外沟通应使用不依赖可疑会话的独立信任渠道。企业官网、状态页或另一套独立控制账号可以在受影响账号处置期间提醒用户不要交互。第一次通报必须给出精确网络、合约地址和窗口,不必编造入口。快速而准确,比快速而武断更安全。
7.2 处置要撤销所有仍能发布、恢复或委派的路径
- 先冻结发布能力,再保全异常窗口。 暂停自动发布、广告和第三方社媒工具;记录异常转发的 post ID、URL、首见/末见时间、截图、通知邮件和可见互动。若业务必须继续发声,先用独立官网或另一已验证渠道发布简短状态,避免在尚未确认安全的会话里反复操作。
- 撤销会话与应用授权,不只修改密码。 在受控设备上重置账号密码,退出全部会话,移除不认识的已授权应用、API token、委派成员和恢复方式;同时保护绑定邮箱。重新开放前,至少由两名负责人复核登录邮箱、手机号、硬件密钥/passkey、团队角色、广告账户和 API 客户端清单。
- 从身份提供方和邮箱向前追入口。 导出覆盖异常前后至少 72 小时的 IdP 登录、MFA、设备注册、风险事件、OAuth 授权、邮箱登录、转发规则、恢复信息变化和管理员审计日志。把时间、源 IP、ASN、设备/浏览器、会话标识、认证方法、挑战结果与执行动作放进同一张事件表;不要只搜索一次“失败登录”。
- 检查运营终端与密钥保管。 对使用过品牌账号的工作站和移动设备保全 EDR 时间线、浏览器扩展清单、下载、进程、网络连接和令牌保管方式。轮换社媒调度平台、密码库、CI 发布任务和营销自动化中能够发帖的密钥;旧令牌必须在服务端失效,终端侧删除作为后续清理动作。
- 向 X 提交可核对的事件包。 提供账号、异常 post/repost ID、UTC 窗口、已撤销会话、已知管理员和可联系的企业域名邮箱,请求平台保全并返回可提供的登录、会话、授权应用与设置变更记录。若平台记录与企业 IdP 不同源,保留两套原始时间戳再做归一化。
- 公开更正必须写明地址与已知事实。 在恢复控制后,用账号本身和官网双渠道声明未授权内容的准确时间、SCATMAN 合约地址、品牌未参与该代币,并说明调查仍在进行。不要承诺尚未证明的入口或损失数字;后续有新事实再更新同一公告。
- 把链上监测从“价格告警”升级为权限告警。 对本文合约、主地址、第二钱包、共同归集地址和交易对持续记录来自零地址的
Transfer、slot 5/6/7 变化、LPMint/Burn、大额Swap与 WETH 转账。任何声称固定供应的项目一旦出现零地址增发,或临时零管理员存在可达恢复路径,都应触发高优先级复核。 - 给高影响账号建立双人发布与恢复演练。 把硬件密钥作为首选 MFA,个人恢复方式与企业账号分离,高风险转发、置顶和广告由第二人批准;每季度验证离职移权、设备丢失、邮箱失陷和第三方工具撤销流程。每次演练应交付撤销时间、残留会话数和独立渠道公告耗时,作为明确的验收记录。
7.3 链上处置的目标是观察、保全与服务协调,不是撤回交易
公开 EVM 交易不能像转发一样删除,因此链上处置要保全完整关系图,用准确网络与合约警告用户,监测后续移动并协调服务商。部署者、代币、pair、router、两名卖方、中间钱包、归集地址、LP 事件和桥或交易所终点应作为不同实体追踪。固定区块查询要保存 RPC 服务商、chain ID、区块号、请求方法、原始 JSON 与证据包哈希,让核心状态不依赖浏览器前端也能复现。
告警应覆盖 slot 5–7、claimAdmin()、未来 rebalance、零地址增发、大额授权、pair swap、pair 向 router 转移 WETH、同交易 WETH withdraw 与卖方原生 ETH 到账、LP mint/burn、新 pair 和归集地址出账。管理员认领先于主交易 22 秒,增发先于主交易 11 秒。资金若进入桥、交易所或托管商,保全请求要给出源地址、入账哈希、网络、资产形式、数量与区块时间,解释它与调查簇的关系,并请服务商确认控制与依法保存账户记录,不能把第三方标签当所有权证明。
恢复只有经测试才算完成。账号所有者要核对已批准的会话、应用、恢复方式、角色和设备,逐条测试授权发布路径,证明移除路径不能发帖,监测重放,并保留独立沟通渠道。链上证据包要固定合约产物、交易与回执、storage 快照、时间归一化、钱包图和事实/推断边界,监测清单还要有负责人和保留期限。行情界面则应以源码状态、可写与可恢复权限、历史增发和后来 LP 创建,取代孤立的“LP 已烧毁”“owner = 0x0”绿色徽章。
8 短时品牌传播留下了可长期复核的链上证据
8.1 决定性线索不是一笔戏剧化交易,而是一串普通操作的顺序
品牌账号传播发生时,SCATMAN 市场早已运行;首批 LP 销毁与零管理员快照又形成控制权减弱的外观。转发后来消失,但完整合约地址打开了更早的链上历史:桥接资金、部署、建池、LP 凭证处置、保存的可恢复管理员,以及关联钱包的早期入场和增发前退出。账号证据解释信任与曝光,字节码、状态、回执和 trace 解释可执行权限与资产移动,两者都不能单独识别账号入口。
退出不需要神秘的 pair 漏洞。管理员经 slot 6 恢复,增发 10 万亿枚并授权 router;pair 随后向 router 输出 59.085639498469409057 WETH,router 在同一交易通过 withdraw 销毁它,并向主卖方支付完全同量原生 ETH。关联钱包的主交易也按同一路径处理 14.729642457926006985,两名卖方 WETH 增量均为零。两者相加的 73.815281956395416042 是 pair WETH 流出与相等的卖方 ETH 到账;后来归集转账属于金额和交易均不同的关联证据。第二次增发、新 LP 凭证与次日移除还说明,首批烧毁凭证从未限制后来库存或流动性。
8.2 最强的结论会把仍未回答的边留在读者眼前
公开报道与保留截图支持账号侧结论:@SpaceXAI 与 @Starlink 出现了异常 SCATMAN 传播;它们不能证明谁控制了账号,也不能证明任何入口方式。Robinhood Chain 记录独立确认管理员可逆恢复、特权增发与卖出,双钱包运营簇则仍是依据资金流得出的强推断,不等于现实身份已经确认。现有证据也没有证明托管关系、受影响交易者损失,或 SpaceX 内部与 Starlink 运营系统被访问;这些问题要等平台、身份、终端、桥、交易所、托管商或逐笔交易者记录补上具体证据边。
持久修复是按时间审查控制。行情界面应同时展示源码验证、可达增发与管理员恢复、历史供应变化和已识别 LP 凭证批次,而不是孤立绿色快照。账号团队在撤销全部发布和恢复路径前,保全 X 会话、OAuth 授权、恢复与委派变化、邮箱、身份和终端记录;独立渠道更正写明账号、观察窗口、Robinhood Chain、完整合约地址、品牌未背书与更新位置。链上团队保留原始 RPC、代码产物、回执、trace、storage 与钱包图,并对 slot 5–7、claimAdmin()、零地址增发、大额授权、pair-to-router WETH、router withdraw/卖方 ETH、新 LP、撤池和归集地址后续移动告警。
收尾交付的是证据,不是几小时平静:批准的会话、应用、恢复方式、角色和设备清单已经测试;链上监测有负责人和保留期限;服务商确认收到包含网络、地址、哈希、资产与时间的精确保全线索;更正已经发布;每个入口、托管和损失问题都有负责人和截止时间。平台记录以后可以确认授权与入口,服务商记录可以修订托管关联,定义清楚的交易者账本可以计算损失;每种新证据只改变它能回答的结论。在此之前,短暂账号观察与持久链上记录足以指导遏制和追踪,却不足以声称所有人物和损失已经命名。
研究记录
9证据、对象与来源
下面保留本文实际使用的标识、时间和原始材料,便于继续调查。
9.1可检索观测值
来自引用材料或本次调查的值,并附有使用这些值所需的上下文。
| 类型 | 值 | 说明 | 操作 |
|---|---|---|---|
| 合约地址 | 0x9beF0a6E2717957F6c51551dE892553C3Fb86604 | SCATMAN 合约:源码未验证,应结合运行时字节码、storage 与事件复核 | |
| 钱包地址 | 0xfEE50d4ce48F2D05f520CE04c875647e4870a8ba | 主要链上操作地址:部署合约、提供首轮流动性、重新认领管理员、执行两次增发并卖出 10 万亿枚代币 | |
| 钱包地址 | 0xDD9F6d3E16Ebda7F35cB694ceAdb50Af3EEbBa89 | 关联链上钱包:早期买入、卖出约 5927.687 万枚,并与主地址汇入同一归集地址 | |
| 钱包地址 | 0xf252b1CBDA23b3DCa3223D237a37171DAA9Ae5B8 | 共同归集地址:同时收到两个钱包转入的 ETH,构成链上运营关联;现实身份待服务商记录确认 | |
| 钱包地址 | 0x87d13e0719d67567687a1DFa6Cc5bEaA9354213A | 中间钱包:从关联钱包收到 7.03837116 ETH,后来向主地址回送 0.00112335 ETH | |
| 合约地址 | 0x137A7B1256FBF4c71E024015AB8e2Efb120989b8 | 交易对合约:SCATMAN/WETH V2 风格交易对;首个头寸绝大多数可用 LP token 被转入死亡地址,后续又新建并移除一笔流动性 | |
| 交易哈希 | 0x2e1e56514fd2ffb9531c553c0d9b1e0eac303ae6d46fdf821d85c92e1a7b553a | 部署交易:创建未验证的 SCATMAN 合约并分配初始 10 亿枚代币 | |
| 交易哈希 | 0x593a784d0020b143e2d12689b7021106e0b007b68a27f5cbdf522d00359c7b65 | LP 销毁交易:把首个头寸的绝大多数 LP token 转入死亡地址,但不影响代币增发权限 | |
| 交易哈希 | 0xf4b0ee31a6bc81398c92e947ad5eb15b76f6336e586831b6322271f1f2f3d8a0 | 冷却交易:调用 beginCooldown(300),清空当前管理员的同时保留可认领地址 | |
| 交易哈希 | 0x681e15abe2febe38f2510c0f20f5e37397def86fe6c14bdbe15bde6581741435 | 管理员认领交易:由保存在认领槽中的同一地址调用 claimAdmin() | |
| 交易哈希 | 0x42b1b262ef7387f925f97fc91c8a8b309d0e68652eb5fdf850200d913875d40f | 10 万亿枚增发交易:rebalance 向主地址增发代币,并发出零地址 Transfer | |
| 交易哈希 | 0xfa78817afa75437fc80ff46ebebc204a87b6938a37bea20e04e71a77559c1822 | 主地址卖出:pair 向 router 输出 59.085639498469409057 WETH;同交易 withdraw/burn 后向卖方支付准确的 59.085639498469409057 原生 ETH,卖方 WETH 增量为零 | |
| 交易哈希 | 0xdfb7264f2df2d5115c17fe85fa37d5cdf9270aca7dfe6f28715113d839b43157 | 关联钱包主要卖出:pair 向 router 输出 14.729642457926006985 WETH;同交易 withdraw/burn 后向卖方支付准确的 14.729642457926006985 原生 ETH,卖方 WETH 增量为零 | |
| 交易哈希 | 0x5f6f2103acd01f6a19aea47b4629e8d99f79e24f13ef97ab13d34511809b2cf1 | 关联钱包向中间钱包发送 7.03837116 ETH | |
| 交易哈希 | 0x278f01430564526e7eb625457a3eaf7a72b5ab0be6ab0d7605609a34eca99472 | 中间钱包向主地址回送 0.00112335 ETH |
9.2事件时间
- SCATMAN 部署并建立首个池
初始 10 亿枚与 5 ETH 形成交易市场。
- 首批 LP 销毁,管理员进入冷却
LP 凭证被转入死亡地址;管理员地址保存到另一槽,300 秒后可恢复。
- 关联钱包完成主要卖出
Pair 向 router 输出 14.729642457926006985 WETH,router 在同一交易解包并向卖方支付同量原生 ETH。
- 管理员恢复并增发抛售
认领、10 万亿增发、授权、pair-to-router WETH 输出和 router-to-seller 原生 ETH 付款在 22 秒内完成。
- 第二次增发与新 LP
再增发 50 亿枚,并建立独立于首批烧毁凭证的新流动性头寸。
- 公开账号异常警报出现
WuBlockchain 与 Lookonchain 先后提醒 SpaceXAI、Starlink 账号与 SCATMAN 推广风险。
- 第二个流动性头寸被移除
主操作地址撤出后建 LP,说明事件在主抛售后仍有后续管理动作。
- SOSEC 完成字节码和资金流复核
恢复特权函数与状态槽,区分可证事实、强关联和未知账号入口。
9.3来源与材料
- Robinhood Chain:主网 chain ID、RPC 与区块浏览器https://docs.robinhood.com/chain/connecting/
- Blockscout:SCATMAN 合约、字节码、交易与状态https://robinhoodchain.blockscout.com/address/0x9beF0a6E2717957F6c51551dE892553C3Fb86604
- Blockscout:10 万亿枚 rebalance 增发交易https://robinhoodchain.blockscout.com/tx/0x42b1b262ef7387f925f97fc91c8a8b309d0e68652eb5fdf850200d913875d40f
- Blockscout:主地址 10 万亿枚抛售交易https://robinhoodchain.blockscout.com/tx/0xfa78817afa75437fc80ff46ebebc204a87b6938a37bea20e04e71a77559c1822
- Blockscout:关联钱包向中间钱包转账https://robinhoodchain.blockscout.com/tx/0x5f6f2103acd01f6a19aea47b4629e8d99f79e24f13ef97ab13d34511809b2cf1
- Blockscout:中间钱包向主地址回流https://robinhoodchain.blockscout.com/tx/0x278f01430564526e7eb625457a3eaf7a72b5ab0be6ab0d7605609a34eca99472
- Blockscout:关联钱包主要抛售交易https://robinhoodchain.blockscout.com/tx/0xdfb7264f2df2d5115c17fe85fa37d5cdf9270aca7dfe6f28715113d839b43157
- Sourcify:SCATMAN 源码匹配状态查询https://sourcify.dev/server/v2/contract/4663/0x9beF0a6E2717957F6c51551dE892553C3Fb86604?fields=all
- Solidity:状态变量、映射与 storage 布局https://docs.soliditylang.org/en/latest/internals/layout_in_storage.html
- Lookonchain:SCATMAN 风险警报与合约地址https://x.com/lookonchain/status/2076468576400359783
- WuBlockchain:SpaceXAI 与 Starlink 账号异常警报https://x.com/wublockchain12/status/2076467098264728055
- BeInCrypto:公开截图、转发消失与独立验证记录https://beincrypto.com/spacex-starlink-scatman-rug-pull-hack/
- Blockaid:冒充 SpaceX 的投资诈骗与钱包风险背景https://www.blockaid.io/blog/wallet-drainers-and-investment-scams-impersonating-spacex-and-the-fifa-world-cup
- X 帮助中心:账号失陷后的会话、应用、邮箱与密码处置https://help.x.com/en/safety-and-security/x-account-compromised