SCATMAN Liquidity Exit and Mint Selloff After SpaceXAI and Starlink Account Anomalies

1 The public record joins an account-amplification timeline to an independently preserved Robinhood Chain timeline

1.1 At 00:41 UTC, the first useful signal was a brand account behaving unlike itself

At 00:41:49 UTC on July 13, 2026, WuBlockchain published an alert about unusual activity involving @SpaceXAI, @Starlink, and a token called SCATMAN. Lookonchain followed at 00:47:42—five minutes and 52 seconds later—warned readers not to buy the token, and supplied the Robinhood Chain contract address. The interval matters because both notices were close to the event, before later summaries could collapse account behavior, token trading, and attribution into one undifferentiated “hack.”

Contemporary screenshots appeared to show the two accounts reposting or amplifying SCATMAN material built around a “Scam Altman” theme. By the time BeInCrypto published its report, the reposts were no longer visible. Deletion changed what a casual visitor could see, but it did not erase the reporters' post identifiers, their timestamps, the retained screenshots, or the contract address named in the warning. The investigation therefore begins with a disappearing platform object and immediately asks which independent records survived it.

An unexpected repost from an authenticated brand account is an account-security signal, but it is not a complete root-cause finding. It can result from a stolen password, a stolen session, an OAuth grant, mailbox-assisted recovery, delegated publishing access, a compromised social-media tool, an operator endpoint, or an authorized person misusing access. No public SpaceX, Starlink, or X technical statement had identified the entry path, sessions, or duration by the article's July 15 review point. The public record supports “abnormal account use”; it does not select one acquisition mechanism.

1.2 The promoted token is the join key; it is not proof that one person controlled every object

The screenshots and real-time alerts fix three useful fields: the account names, a narrow public-observation window, and the promoted object. Lookonchain's warning supplies the full SCATMAN address, 0x9beF0a6E2717957F6c51551dE892553C3Fb86604. That address is more durable than a token name or ticker. Names can be copied across chains and contracts; one network-and-address pair selects a specific deployed bytecode object, transaction history, storage state, and event stream.

Robinhood Chain then contributes a second clock. Its blocks preserve contract deployment, pool creation, LP-token movement, administrator-state changes, token issuance, router approval, swaps, later liquidity, and proceeds consolidation. Those events begin roughly eight hours before the public account alert. The chain does not reveal who signed into X, but it shows that the promoted market was prepared before the alert and that its privileged administrator later exercised precisely the authority that a snapshot badge could miss.

The red thread in the figure represents an evidentiary join, not an attribution shortcut. “These accounts promoted this contract” and “these wallets operated this contract and market” are separately testable claims. Moving from those claims to “the same human controlled the accounts and wallets” requires platform, bridge, exchange, custodian, or device records. The article keeps that missing edge visible because it is the difference between reconstructing an incident and naming an actor.

Three evidence classes answer different questions and must retain their own clocks. The account record answers what the public saw: which authenticated accounts displayed the material, what object they amplified, when observers captured it, and whether the content later remained visible. Platform records would answer how it happened: session creation, source network, device, authentication method, delegated role, application grant, recovery event, and deletion actor. Public screenshots cannot substitute for those private control-plane records.

The chain record answers what the market object did. Transaction hashes fix caller, recipient, input, success or revert status, block time, logs, and value transfer. Runtime bytecode and storage reads fix the executable authorization path even though the source is unverified. Explorer labels help navigate the data but are not the evidence themselves; the reproducible objects are bytecode, calldata, receipts, blocks, storage, and balances.

The service-provider record would answer who sits behind funding and exit points. A bridge can confirm the originating transaction and account data it retained; an exchange or custodian can map a deposit address to an account under lawful process; X can preserve sessions and authorized applications; enterprise identity and endpoint systems can identify the workstation or token that performed the account action. Without those records, a common collector is a strong on-chain link but not a civil identity.

The two records support different findings. Public evidence supports unusual SCATMAN amplification involving @SpaceXAI and @Starlink. Robinhood Chain preserves preparation, reversible administrator concealment, privileged issuance, sale through a router, later liquidity management, and wallet consolidation. It contains no evidence of access to corporate networks, Starlink satellite control, customer terminals, or a platform-wide X vulnerability. Keeping those claims separate prevents a social-account event from being retold as an infrastructure breach.

Preservation works better with four plain fields—source, object, source-native time, and one testable assertion—than with a broad label such as “hack proof.” WuBlockchain's and Lookonchain's status IDs resolve to 00:41:49.776 and 00:47:42.191 UTC. Those timestamps record alert publication, not necessarily the first abnormal account use or the first appearance of a repost. Screenshots should retain the uncropped frame, source URL, pixel dimensions, metadata, and capture method; a recompressed image with no source or time remains low-weight context.

The promoted object is fixed by Robinhood Chain, chain ID 4663, and the full contract address. Two sources sharing only the word “SCATMAN” form a weak join; the same network-and-address pair makes the object reproducible. Later platform exports, X sessions, exchange responses, or endpoint telemetry should strengthen only the edge they can actually answer. They do not rewrite block history or retroactively establish account order, shared tooling, or common session control.

2 The reposts were brief; the chain records deployment through a second liquidity exit

2.1 Fourteen seconds separated bridge funding from deployment, and eleven more created a market

All times below are UTC. Robinhood Chain mainnet is an Arbitrum Layer 2 with chain ID 4663 and ETH as its native gas token. At 16:35:54 on July 12, the main operating address 0xfEE50d4ce48F2D05f520CE04c875647e4870a8ba received 5.535 ETH through an address pattern produced by Arbitrum L1-to-L2 aliasing. Fourteen seconds later it deployed SCATMAN. Eleven seconds after deployment, one billion tokens and 5 ETH were placed into a V2-style pair.

The aliasing pattern deserves a narrow interpretation. Arbitrum adds a fixed offset when certain L1 senders are represented on L2, so an address can look related to a different hexadecimal value by construction. That transformation is useful for tracing a bridge path; it is not a fingerprint of a person and is not used here to cluster wallets. The supported claim is simply that the main address obtained enough native asset to deploy the contract and seed the first market immediately.

The deployment-to-pool interval shows that the contract was not an inert experiment waiting for a later community launch. The initial supply, pair, and price-discovery venue were assembled as one sequence. By 16:36:19, anyone with network access and the pair address could trade. The subsequent account amplification did not create the contract or market; it directed a much larger trust signal toward infrastructure that was already live.

The first public alert arrived about eight hours later, at 00:41:49 on July 13. That lead time does not prove advance access to either account. It does show operational preparation consistent with a campaign that wanted trades to be executable as soon as promotional content appeared. A responsible reconstruction states the temporal relationship and stops there until account-session evidence supplies the missing causal edge.

The table preserves the full sequence instead of starting at the spectacular 10-trillion mint. Reading from the beginning is essential: it reveals the first LP burn, the reversible administrator cooldown, an early second wallet, the later claim, a second liquidity position, and continued management after the public alert.

2.2 The first market presented two reassuring snapshots while preserving the dangerous capability

At 16:38:38, almost all usable LP tokens from the initial one-billion-SCATMAN and 5-ETH position were transferred to a dead address. To a market interface, that transfer can look like a commitment: the sender no longer holds the receipt required to redeem that specific position through the normal pair path. Six seconds later, beginCooldown(300) cleared the visible administrator slot. A second interface taking a single storage snapshot could now display both “LP burned” and “owner/admin zero.”

Neither observation was fabricated. The LP receipt really moved, and slot 5 really became zero. The problem was incompleteness. The LP transfer said nothing about whether the token could issue new inventory. The zero slot said nothing about the saved address in slot 6 or the reachable claimAdmin() branch. Security labels became misleading when they converted two local truths into a global conclusion about control.

The five-minute deadline ended at 16:43:44. From then on, the saved address could restore itself, but it waited until 17:22:23. That 39-minute gap is important. The administrator was not forced to return at the deadline, so a scanner sampling the contract at 16:45, 17:00, or 17:20 would still see zero. Reachability analysis asks whether authority can return; snapshot analysis asks only whether it is present now.

While the admin appeared absent, wallet 0xDD9F6d3E16Ebda7F35cB694ceAdb50Af3EEbBa89 entered the market. It bought with 0.2 ETH and 0.12145299431379584 ETH shortly after liquidity was created, then sold an initial 955,000 tokens. At 17:15:29 it sold roughly 59.27687 million more: the pair sent exactly 14.729642457926006985 WETH to the router, which burned that WETH through withdraw and paid the seller the identical amount in native ETH in the same transaction. Its principal exit preceded the administrator's return by nearly seven minutes.

That order is stronger than a wallet appearing only after a public promotion. The address participated near market birth, carried a large position while the admin was apparently zero, and realized its main sale before the privileged mint destroyed the prior supply relationship. Timing alone still cannot identify the controller, but it tells investigators that this wallet belongs in the preparation-and-exit graph, not merely in a list of ordinary late buyers.

Investigators must normalize clocks before joining them, then preserve every original timestamp. The social and chain timelines use different timestamp authorities. X status identifiers encode creation time, observers record capture or publication time, media pages add their own publication time, and blocks provide network timestamps. A defensible incident table stores each raw value and its source before conversion to UTC. Rounding everything to “around midnight” would hide the five-minute alert interval and make later sequence claims impossible to audit.

The chain likewise contains several event clocks inside one operation. A transaction has a block timestamp; logs inherit its ordering; internal calls establish a trace sequence; off-chain explorers may index the result later. The 11-second statement in this report compares three confirmed block times: mint at 17:22:34, approval at 17:22:39, and swap at 17:22:45. It does not claim eleven seconds of human typing or reveal whether transactions were pre-signed, automated, or submitted through private infrastructure.

The funding sequence can be reconciled without treating every difference as profit or cost. The main address received 5.535 ETH and placed 5 ETH into initial liquidity while also deploying and transacting. The remaining balance participated in gas and later activity, but a precise cost ledger must use actual transaction fees and subsequent transfers. Subtracting 5 from 5.535 is a useful sanity check, not a final accounting result.

At 17:36:00 the main address transferred 59.30669483459594 ETH to 0xf252b1CBDA23b3DCa3223D237a37171DAA9Ae5B8. About 80 seconds later, the second wallet sent 7.702168160337135 ETH to the same collector. Those values differ from the sellers' exact same-transaction native-ETH receipts because the wallets paid gas, retained balances, and conducted other activity; there was no later seller-side WETH unwrap to explain the difference. An evidence table must not substitute collector receipts for principal-sale receipts.

The next morning, at 09:22:58, the main address removed the second liquidity position created after the giant sale. That action occurred after the public alerts and after the reposts were reported missing. It extends the operational window beyond the moment most news summaries ended. Investigators who preserve only the promotional window risk missing later LP removal, consolidation, and any onward service deposits.

3 Unverified bytecode still exposes state transitions and executable authority

The code and response path begins with the deployed object itself. The 4,779-byte runtime at Robinhood Chain contract 0x9beF0a6E2717957F6c51551dE892553C3Fb86604 is fixed by the SHA-256 listed below. beginCooldown(uint256) moves the administrator from slot 5 into slot 6, claimAdmin() restores authority after the slot-7 time condition, and rebalance(address,uint256) increases slot-2 supply and the recipient balance. Successful transactions and state changes witness all three branches, so neither “LP burned” nor “owner zero” is a safety conclusion. Account response revokes sessions, applications, and recovery paths; chain monitoring follows slots 5–7, zero-address issuance, approvals, swaps, and later LP changes.

3.1 Source verification failed, so the deployed object—not a guessed repository—became the reference

Blockscout reports is_verified: false, and Sourcify has neither a full nor partial match for this address on chain 4663. The chain preserves creation and runtime bytecode, calldata, storage, logs, and execution results. Developer file names, variable names, comments, tests, and Git history remain outside that record. Compiler metadata identifies Solidity 0.8.20 and an IPFS content identifier; the gateways checked during this review did not return the referenced source. Function labels below come from selector resolution, while state-variable labels are semantic names chosen for analysis.

This distinction prevents a common forensic error. An analyst can search the function selectors, find a public contract with similar names, and begin describing that source as though it were deployed here. Selector collisions, copied templates, compiler settings, and post-deployment changes make that unsafe. Without a verified match, source-like pseudocode is an explanatory model whose every branch must be anchored back to the immutable runtime and a successful or reverted transaction witness.

To make the exact deployed object reproducible without relying on an explorer screenshot, this review pins both code artifacts:

• The runtime returned by eth_getCode is 4,779 bytes; its SHA-256 is 7F13E3B7F75F8971A7213320A818A7DB97F1DE9D39E864218BC5BAD43EC0DCB3.
• The deployment transaction's creation input is 6,781 bytes; its SHA-256 is 7EA4C46E0EC8FC8BE34BD54DA0F10EF0F828F6617D6B5382B2B0AF2D624EFC25.
• Metadata identifies Solidity 0.8.20 and IPFS CID QmYzTHFH6H3fzmfhCBE7BeVLCzSRv8uyCLg1qBYgH2HqcM. The CID could not be retrieved during review, leaving the source-verification state unresolved.

The two hashes serve different purposes. The creation input includes constructor logic and arguments used only during deployment; the runtime is what later calls execute. A future explorer reindex, label change, or frontend outage cannot alter either byte sequence. Fetching the deployment input and eth_getCode at the same address, then hashing the raw bytes, is enough to confirm that the analysis concerns the identical object.

Compiler metadata narrows provenance without restoring source. Solidity 0.8.20 explains checked arithmetic and metadata structure, while the IPFS CID records a content reference embedded by the build. Because that CID is unavailable, original filenames, comments, developer intent, and a Git commit remain unknown. “Unverified” describes the missing source artifact; executable authorization can still be recovered from runtime behavior.

3.2 Storage turns a reassuring zero into a graph of reachable authority

The EVM dispatcher reads the first four bytes of calldata and jumps into a matching branch. Within each branch, SLOAD, SSTORE, KECCAK256 mapping keys, checked arithmetic, revert strings, and LOG3 events remain observable. SOSEC matched selector resolutions against successful transactions and recovered eight central slots: balances at slot 0, allowances at slot 1, total supply at slot 2, name and symbol at slots 3 and 4, the active admin at slot 5, a saved reclaiming admin at slot 6, and the cooldown deadline at slot 7.

Slots 0 and 1 are mappings, with keys derived from addresses, not flat address lists. A balance read derives the storage key from the padded account address and mapping slot; an allowance adds the spender under the owner-derived root. Slot 2 is a scalar supply value. Those relationships are recoverable because ordinary ERC-20 calls and observed transfers exercise them. The analysis does not need a source variable named balances to show that the branch changes the same mapping queried by balanceOf.

Slots 5, 6, and 7 form the authority state machine. Looking at slot 5 alone answers “who can call the admin-gated branch in the present state?” Looking at all three and the dispatcher answers the more important question: “which address can move the contract into a future state where that branch becomes callable?” The saved address and elapsed deadline made the zero value temporary and reversible.

At the latest reviewed state, both slots 5 and 6 resolved to 0xfEE50d4ce48F2D05f520CE04c875647e4870a8ba, while slot 7 still encoded 16:43:44 UTC on July 12. Slot 2 held 10,006,000,000,000 tokens. These direct reads agree with the historical calls and zero-address Transfer events, providing three independent views of current authority and supply.

3.3 Successful transactions convert selector guesses into witnessed behavior

The signatures are selector resolutions and the variable labels are semantic names chosen for readability. The evidence is the state access and execution. Expressed as Solidity-like pseudocode, the authority path is compact:

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]

The label rebalance sounds like portfolio management, but its branch has mint semantics. It requires the active administrator, increments total supply, increments an arbitrary recipient balance, and emits the standard zero-sender transfer log. No corresponding debit occurs. The 17:22:34 transaction supplied the main operator as recipient and 10 trillion as amount, so calldata, storage delta, and event amount all point to the same privileged issuance.

beginCooldown does not burn a key or set an unreachable address. It copies the active address before clearing it, then establishes a time condition. claimAdmin checks the saved address and deadline before restoring the active slot. Reading the three branches together explains why the later call succeeded without any new nomination transaction. The contract itself retained the path back.

The code implements a recoverable administrator. While the active-admin slot was empty, the same address remained in slot 6 and became eligible to return after five minutes. The actual claim occurred at 17:22:23, about 39 minutes after the first eligible time of 16:43:44. A market page that snapshots the current owner or admin would show zero during this window; a complete authority review reads the connected slots and evaluates reachable state.

A minimal independent reproduction does not require decompiling the whole contract. First, fetch the runtime and verify its 4,779-byte length and SHA-256. Second, fetch the cooldown, claim, and mint receipts at fixed block heights. Third, read slots 5–7 before and after each transaction. Fourth, decode the zero-address transfer emitted by the mint. Finally, replay read-only calls or trace the successful branch to confirm that the recipient balance and total supply increased by the same amount.

That workflow also exposes mistakes. If a selector database supplied the wrong signature, calldata lengths or decoded argument positions would conflict with state changes. If a storage label were wrong, the before-and-after read would not match the transaction's observable effect. If an explorer token page scaled decimals incorrectly, raw event amounts and slot arithmetic would still preserve the underlying integer. Reproduction is a set of cross-checks, not a screenshot of a decoded label.

Reverted selectors describe attempted control, not deployed capability. Two reverted calls settle that question. After reclaiming, the operator sent selector 0x5ed7ca5b and later 0x046f7da2. Selector databases commonly render them as halt() and resume(). The runtime dispatcher has no successful branch for either, and both transactions reverted. The deployed contract therefore provides no confirmed pause function under those selectors; the authority inventory follows successful branches, state access, and execution results.

The calls are still useful as behavioral evidence. They show that the main address attempted those calldata values after authority returned. They do not prove that the operator believed a pause function existed, copied an interface accurately, or controlled a different implementation. A failed attempt belongs in the chronology with its revert status attached; promoting it into a feature claim would confuse intention, tooling labels, and executable code.

The same discipline applies to absent functions. This report confirms mint authority and reclaimability because branches, state, and transactions witness them. It does not claim upgradeability, blacklist control, transfer taxes, or a working pause mechanism merely because such features are common in token contracts. Each additional capability must be demonstrated from runtime control flow or successful state transitions.

Reproduction must also pin byte-decoding rules and block heights. Remove the JSON-RPC 0x prefix, decode the bytes, and only then calculate length and SHA-256. Historical state should come from each transaction's parent and resulting blocks, or from a trace that preserves pre- and post-state. The main address's slot-0 balance, the router's slot-1 allowance, slot-2 supply, and zero-address Transfer must agree with balanceOf, allowance, and the receipt before words such as “cleared,” “restored,” and “minted” become measured state changes.

Selector names retain resolution confidence because one four-byte prefix can map to several candidates. Argument length, ABI offsets, revert behavior, branch access, and successful effects jointly select rebalance, beginCooldown, and claimAdmin here; a future source match may rename them without changing their execution. The 4,779-byte runtime and its hash define the code object analyzed in this report. If the same address later returns different code, investigators should first test for proxying, destruction and redeployment, network mismatch, or collection error before carrying these conclusions forward.

4 The first withdrawal receipt was burned; the key that made new inventory survived

4.1 Pool reserves, LP receipts, and token authority are three separate control surfaces

An automated market maker contains at least two different kinds of assets. SCATMAN and WETH are pool reserves. LP tokens are receipts representing a liquidity provider's position. Sending an LP receipt to an unusable address makes that position difficult to redeem through the ordinary path, but it does not alter the SCATMAN bytecode or storage. If a token administrator can still mint, it can manufacture inventory far beyond the existing reserve and sell it through the same router and pool.

The distinction can be expressed as three ledgers. The token contract records account balances, allowances, total supply, and administrator state. The pair records its two reserves and issues LP receipts representing proportional claims on them. The router orchestrates transfers and pair calls but does not erase token-level permissions. A reassuring event in one ledger cannot be assumed to constrain the other two.

When initial liquidity was added, the pair received one billion SCATMAN and the wrapped representation of 5 ETH. In return, it minted LP tokens, apart from any minimum quantity the pair permanently locks. The provider then sent almost all usable receipts to a dead address. That act made the provider's first proportional withdrawal claim inaccessible; it did not send the pool reserves themselves to the dead address and did not modify slot 5 or slot 6 in SCATMAN.

This is why “liquidity burned” is narrower than “market cannot be drained.” The phrase usually describes one path: presenting LP receipts to burn them and receive a proportional share of reserves. A privileged issuer has a different path: create token inventory outside the pair, grant a router allowance, and trade that inventory against the WETH reserve. In each principal sale here, the ordinary swap sent pair-held WETH to the router, which called withdraw and paid the seller native ETH in the same transaction; LP redemption was not involved.

4.2 The dead-address transfer constrained the old receipt, not the future supply

The LP-burn transaction occurred at 16:38:38, two minutes and 19 seconds after pool creation; six seconds later, slot 5 showed no active administrator. The runtime already contradicted any broad surrender claim: rebalance could increase supply when slot 5 was populated, and the cooldown path could restore slot 5 from slot 6. A complete pre-trade review therefore asks four separate questions—who can redeem this LP, who can change supply, whether an absent administrator can return, and whether new LP receipts can be issued. The supported dead-address finding is correspondingly narrow: almost all usable first-position receipts became normally inaccessible to the sender. Unknown keys or implementation-specific recovery would need more evidence, and the actual exit did not depend on either possibility because it used newly minted SCATMAN.

A later deposit proved why the claim must remain batch-specific. The second rebalance minted five billion tokens at 17:25:39; eleven seconds later, the main address paired approximately 1,843,391,573.398149076868715556 SCATMAN with 0.27 ETH, received a new LP receipt, and removed that position at 09:22:58 the next day. This was normal fungible LP accounting, not an exception to the first burn: an older receipt sent to a dead address neither prohibits a new deposit nor controls the destination of a new receipt. The second mint, deposit, issuance, and post-alert removal also extend the operator's market-management window beyond the principal sale.

5 Authority returned; 22 seconds later, pair WETH became seller ETH

5.1 Claim, mint, approval, and swap form one executable sentence

At 17:22:23, the saved administrator called claimAdmin() and restored itself to slot 5. Eleven seconds later, at 17:22:34, the same main address called rebalance with itself as recipient and an amount of exactly 10 trillion SCATMAN. The transaction increased both total supply and its balance and emitted a transfer from the zero address. The state machine had moved from latent authority to newly created inventory.

At 17:22:39, five seconds after minting, the main address approved the router to spend the new tokens. An ERC-20 approval does not move inventory into the pool; it writes an allowance under owner and spender. That intermediate step matters because it shows the swap did not rely on a hidden pair privilege. The operator used the standard token authorization expected by a router, but the inventory being authorized came from an administrator-only issuance branch.

At 17:22:45, six seconds after approval and eleven seconds after minting, the router path sold exactly 10 trillion SCATMAN. The pair sent 59.085639498469409057 WETH to the router; the router called WETH withdraw, burned that amount, and paid exactly 59.085639498469409057 native ETH to the seller within the same transaction. The amount minted, the amount authorized, and the amount sold align, while the seller's WETH balance delta is zero.

The entire privilege-to-proceeds chain took 22 seconds from claimAdmin() to swap, and 11 seconds from mint to swap. Both intervals are useful but answer different questions. Twenty-two seconds measures recovery through market exit; eleven seconds measures how quickly fresh supply became sale inventory. The summary states both intervals, while the body and timeline preserve the four transactions that connect them.

Nothing in those timestamps proves whether the transactions were manually clicked, scripted, bundled, or pre-composed. Their tight spacing is operational evidence of coordination, not evidence of a particular automation framework. A responder can safely conclude that detection based only on price or supply after the swap would have had almost no preventive window; preventive monitoring must watch authority restoration, zero-address issuance, and abnormal allowance changes.

5.2 The router did not create the exit mechanism; it carried privileged inventory to an ordinary pair

A V2-style constant-product pair holds two reserves and quotes trades subject to fees and invariant checks. The initial pool held one billion SCATMAN; the privileged sale supplied 10 trillion, ten thousand times that starting token quantity, making WETH the limiting reserve. Exact output depends on the immediate pre-swap reserves, intervening trades, fee, and integer arithmetic. The receipt and trace fix the result: 59.085639498469409057 WETH left the pair for the router, then exactly 59.085639498469409057 native ETH left the router for the seller in the same transaction.

The pair did not need to know whether SCATMAN came from an ordinary transfer, another market, or an administrator mint. Once the approved router transferred fungible ERC-20 inventory into the pair, the pair evaluated balances, reserves, output, and invariant conditions. The failure therefore lies in unbounded privileged issuance combined with market trust, not an unexplained pair-contract bypass.

WETH is the ERC-20 wrapper for the native asset and belongs in pair reserves; the router's same-transaction withdraw burned the pair output and produced native ETH for each seller. The two seller WETH deltas are zero, and neither principal path contains a later seller-side unwrap. Accounting must preserve both representations as two legs of one value flow—pair WETH outflow and equal native-ETH seller receipt—then treat later, differently sized collector transfers as linkage rather than additional principal-sale income.

5.3 Supply arithmetic closes independently across calls, events, balances, and storage

The contract began with one billion tokens. The first privileged call added 10 trillion. The second rebalance at 17:25:39 added five billion. Their sum is 10,006,000,000,000, which matches slot 2 at the review point. That equality is simple, but it is important: it shows that the observed privileged events account for the reviewed supply without relying on a market-cap page or a rounded token dashboard.

Each mint can be checked four ways. Decode the rebalance input to recover recipient and integer amount; inspect the zero-address Transfer log; compare the recipient balance before and after; and compare total supply before and after. When all four deltas agree, the conclusion does not depend on the selector's human-readable label. A discrepancy would signal a decoding, decimal, proxy, rebase, or event-assumption problem that needs resolution before publication.

Decimals affect display, not the underlying authorization transition. Explorers may render a raw integer with token decimals, and articles may use “billion” or “trillion” for readability. Investigators should retain raw values in their working record, identify the token's decimal convention, and document every scale conversion. This report's integer supply equation, exact pair-side WETH outputs, and matching router-paid native-ETH receipts remain the reproducible anchors.

The second five-billion mint served a different operational purpose from the first. The first issuance was sent through the router as principal sale inventory. Part of the second issuance—approximately 1,843,391,573.398149076868715556 SCATMAN—was combined with 0.27 ETH for a new liquidity position. Distinguishing the calls explains why total supply exceeds the sold 10 trillion and why a later LP receipt existed after the first one had been burned.

Keep the pair WETH outflow and router-paid seller ETH in separate asset columns but one economic-flow identifier. The later 59.30669483459594-ETH and 7.702168160337135-ETH collector transfers are different transactions and amounts; reconcile them against full balances, gas, retained value, and other activity instead of inventing a later unwrap. The detection sequence is equally compact: claimAdmin() restores issuance, rebalance creates inventory, approve delegates spending, and the swap changes reserves while the router realizes native ETH for the seller. A fresh allowance covering most of a giant mint is therefore an independently useful alert.

The evidence supports ordinary successful V2-style swaps, not a malfunctioning pair. Relationship-based detection can alert when a zero-address mint dwarfs prior supply, a restored admin mints inside a short window, a fresh allowance covers the inventory, or that balance enters a shallow pair. Block order proves claim, mint, approval, and swap execution order but not whether submission used manual clicks, automation, a private relay, or a direct sequencer path; monitoring should act on confirmed state progression without guessing the delivery stack.

6 The second wallet and main operator form one on-chain investigation cluster

6.1 The second wallet was present near market birth and exited before administrator recovery

0xDD9F…Ba89 entered with two purchases totaling 0.32145299431379584 ETH about three minutes after the first pool was created, well before the public account alerts. It sold an initial 955,000 tokens, then sold approximately 59.27687 million at 17:15:29. That principal sale moved exactly 14.729642457926006985 WETH from the pair to the router and, after same-transaction withdraw, exactly 14.729642457926006985 native ETH from the router to the seller. Its entry and both sales preceded the main address's administrative reclaim.

The two buys matter as separate observations, beyond their summed cost. They place the wallet in the first minutes of liquidity, when discovery of a new pair would otherwise depend on monitoring, coordination, or chance. The later principal sale shows that the wallet held a much larger token balance through that early phase and chose to exit before the 10-trillion issuance radically changed supply and price.

This sequence supports investigation priority, not omniscience. It does not reveal whether the wallet bought from the launch transaction, monitored the factory, received an off-chain signal, or was controlled by the contract deployer. It does show that classifying it as a member of the public audience would ignore unusually early timing, a favorable pre-mint exit, and later consolidation evidence.

6.2 A common collector, an intermediary return path, and close timing strengthen the cluster

The destination of funds adds weight. At 17:36:00 the main address sent 59.30669483459594 ETH to 0xf252b1CBDA23b3DCa3223D237a37171DAA9Ae5B8. Roughly 80 seconds later, the second wallet sent 7.702168160337135 ETH to the same collector. It also funded intermediary 0x87d13e0719d67567687a1DFa6Cc5bEaA9354213A, which later returned ETH to the main address. Shared consolidation, temporal proximity, and a return path place the wallets in one operating cluster. Real-world attribution requires exchange, bridge, custodian, and platform account records.

The result is a strong on-chain operating cluster, not a claim that every private key sat on one device. A team can divide wallets, an automation service can submit transactions, and a custodian can control keys on behalf of an account holder; if the shared destination proves to be a common service wallet, its identity weight falls further. “Common operation” means the behavior should be investigated as coordinated until service records explain it; it does not collapse key custody, beneficial ownership, and real-world identity into one concept.

The intermediary edge is reproducible in two transfers. At 17:39:43 on July 12, the second wallet sent 7.03837116 ETH to 0x87d13e0719d67567687a1DFa6Cc5bEaA9354213A in 0x5f6f2103acd01f6a19aea47b4629e8d99f79e24f13ef97ab13d34511809b2cf1. At 09:20:03 on July 13, that intermediary sent 0.00112335 ETH to the main address in 0x278f01430564526e7eb625457a3eaf7a72b5ab0be6ab0d7605609a34eca99472. The returned amount is economically small, but its direction establishes a relationship different from two wallets merely touching the same public contract. Full interpretation still requires complete wallet history and independently verified service records.

6.3 Pair output, seller receipts, net profit, and trader loss answer different questions

The two principal sales produced a reproducible total of 73.815281956395416042 on each side of the router conversion: 59.085639498469409057 plus 14.729642457926006985 WETH left the pair, and identical amounts of native ETH reached the two sellers in their respective transactions. The router was the WETH recipient and called withdraw; each seller's WETH balance delta was zero, with no later seller-side unwrap. The total is therefore pair WETH outflow and matching native-ETH seller receipts—not seller WETH proceeds, net operator profit, or victim loss.

Reproduction decodes the two pair-to-router WETH Transfer logs, retains the raw 18-decimal integers, verifies the matching WETH burns and router-to-seller native-value calls in each trace, and adds the integers only once. Net profit additionally needs the complete address set, opening and closing balances, deployment and bridge costs, initial 5 ETH liquidity, the linked wallet's 0.32145299431379584-ETH buys, later 0.27-ETH LP contribution and withdrawal, gas, remaining assets, services, and off-chain costs. The differently sized collector transfers are subsequent consolidation evidence, not a second count of either principal receipt.

Trader loss requires a separate wallet population, cutoff, cost basis, buys, sells, transfers, remaining holdings, recoveries, and valuation method. Pool reserves reflect the original LP plus trading at changing prices, so neither collapsed market capitalization nor operator-side asset flow equals users' realized loss. Public reports also used time-sensitive USD conversions; this report keeps exact on-chain amounts primary and treats fiat equivalents as dated context.

Facts, strong links, and unresolved hypotheses remain separate in the final record:

The hierarchy also governs “takeover” and brand impact. Unexpected authenticated-account behavior and contemporary warnings justify an account-compromise investigation, but BeInCrypto could not independently verify control and sought comment; X and enterprise evidence must establish the acquisition path. Rocket and satellite imagery conveys brand trust, not access to launch systems, spacecraft, satellite control, billing, terminals, or customer traffic. Later platform or provider records may close a named gap without changing the immutable chain sequence.

7 Respond to the account and the chain at the same time

7.1 Preserve the disappearing account evidence before containment changes it again

Deleting abnormal content stops continued exposure; it does not complete incident response. A mature response runs account, identity, endpoint, communications, and on-chain workstreams in parallel, recording the actor, time, object, and result for every containment step.

The first responder faces a real tension. Leaving an unauthorized repost visible can expose more users, but removing it changes the observable platform state. The practical answer is rapid preservation followed by containment: capture the URL, post or repost identifier, account, full UTC display, media, reply and quote context, visible engagement, notification mail, and the device clock used for the capture; then remove or hide the content according to platform and legal guidance.

Screenshots should be accompanied by machine-readable identifiers wherever possible. A cropped image can omit the account handle, timestamp, or surrounding thread, and pixels alone are difficult to correlate with platform logs. Record who captured each item, when, from which authenticated or public view, and calculate a file hash. If the platform later supplies an export, retain the original export and map it alongside the earlier evidence.

Communications must use a channel whose trust is independent of the possibly compromised session. A corporate website, status page, or separately controlled account can warn users not to interact with the token while the affected accounts are contained. The initial notice needs the exact contract address and time window; it does not need a speculative acquisition story. Fast precision is safer than fast certainty.

7.2 Containment must revoke every path that can still publish, recover, or delegate

1. Freeze publishing, then preserve the abnormal window. Pause automated publishing, ads, and third-party social tools. Preserve post IDs, URLs, first- and last-seen times, screenshots, notification emails, and visible engagement. If the organization must communicate immediately, use its independent website or another already-verified channel before repeatedly interacting through a session that may still be unsafe.
2. Revoke sessions and application grants, not only the password. From a controlled device, reset the password, sign out all sessions, and remove unrecognized authorized apps, API tokens, delegates, and recovery methods. Secure the attached mailbox. Before reopening, have two owners verify the login email, phone, hardware key or passkey roster, team roles, ad accounts, and API clients.
3. Trace forward from identity and mail evidence. Export at least 72 hours around the incident from IdP sign-ins, MFA, device registration, risk events, OAuth consent, mailbox access, forwarding rules, recovery changes, and admin audit logs. Join time, source IP, ASN, device or browser, session identifier, authentication method, challenge result, and resulting action. A search for failed logins alone is not sufficient.
4. Review operator endpoints and token custody. Preserve EDR timelines, browser extensions, downloads, processes, network connections, and credential-storage practices on workstations and mobile devices used for brand accounts. Rotate credentials in social schedulers, vaults, CI publishing jobs, and marketing automation. Old tokens must be invalidated server-side, not merely deleted from one device.
5. Give X a reproducible incident package. Provide the account names, abnormal post or repost IDs, UTC window, revoked sessions, known administrators, and a corporate-domain contact. Request preservation and whatever login, session, authorized-application, and setting-change records the platform can provide. Keep platform and enterprise timestamps in their original forms before normalization.
6. Publish a correction with exact addresses and evidence boundaries. Once control is restored, state the unauthorized-content window, the SCATMAN contract address, and that the brand did not endorse the token, using both the account and corporate website. Do not promise an unproven entry method or loss number. Update the same notice when additional facts mature.
7. Promote chain monitoring from price alerts to authority alerts. Track this contract, the main address, second wallet, common collector, and pair for zero-address Transfer events, slots 5/6/7, LP Mint/Burn, large Swap events, and WETH movement. Any token marketed as fixed-supply should receive a high-priority review when zero-address minting appears or a zero admin has a reachable reclaim path.
8. Exercise dual control for high-impact accounts. Prefer hardware-backed authentication, separate personal recovery from the enterprise identity, and require a second approver for high-risk reposts, pins, and ads. Test offboarding, lost devices, mailbox compromise, and third-party revocation quarterly. Acceptance evidence should include revocation time, remaining-session count, and time to publish through an independent channel.

7.3 Chain containment is observation, preservation, and service coordination—not transaction reversal

Public EVM transactions cannot be deleted like reposts, so chain containment preserves a complete graph, warns with the exact network and contract, monitors onward movement, and coordinates services. Track deployer, token, pair, router, both sellers, intermediary, collector, LP events, and bridge or exchange destinations as separate entities. Preserve fixed-block queries with provider, chain ID, block numbers, methods, raw JSON, and evidence-bundle hashes so core state remains reproducible without an explorer frontend.

Alerts should cover slots 5–7, claimAdmin(), future rebalance calls, zero-address mints, large approvals, pair swaps, WETH transfer to the router, same-transaction WETH withdraw and native-ETH seller payment, LP mint/burn, new pairs, and collector movement. The claim signal preceded the main sale by 22 seconds and the mint by 11 seconds. If funds reach a bridge, exchange, or custodian, send the exact source address, incoming hash, network, asset representation, amount, and block time, explain the cluster edge, and ask the service to confirm control and preserve lawful account records rather than treating a third-party label as ownership proof.

Recovery closes only after controls survive tests. The account owner verifies the approved session, application, recovery, role, and device roster; exercises every authorized publishing path; proves removed paths cannot post; watches replay attempts; and retains an independent channel. The chain package fixes contract artifacts, transactions and receipts, storage snapshots, time normalization, wallet graph, and fact/inference boundaries under a named watchlist owner and retention period. Market interfaces must replace isolated “LP burned” and “owner = 0x0” badges with source status, writable and recoverable authority, historical mints, and later LP creation.

8 Brief brand amplification left a durable on-chain record

8.1 The decisive clue was not one dramatic transaction but the order of ordinary ones

Brand-account amplification gave SCATMAN a short burst of exposure after its market was already live, while the first LP burn and zero-admin snapshot created the appearance of reduced control. The reposts later disappeared, but the exact promoted address opens an earlier chain history: bridge funding, deployment, pool creation, LP-receipt disposal, a saved reclaim administrator, and the linked wallet's early entry and pre-mint exit. Account evidence explains trust and exposure; bytecode, state, receipts, and traces explain executable authority and asset movement without claiming either record identifies the account-entry method.

The exit required no mysterious pair exploit. The administrator returned through slot 6, minted 10 trillion SCATMAN, and approved the router; the pair then output 59.085639498469409057 WETH to the router, which burned it through same-transaction withdraw and paid the main seller exactly that amount in native ETH. The linked sale followed the same route for 14.729642457926006985, leaving both sellers with zero WETH delta. Together, 73.815281956395416042 is pair WETH outflow and matching seller ETH receipts; later collector transfers establish consolidation links but are different amounts and transactions. A second mint, new LP receipt, and next-day removal show that the first burned receipt never constrained later inventory or liquidity.

8.2 The strongest conclusion keeps its unanswered edges visible

Public reports and retained screenshots support the account-side report that abnormal SCATMAN amplification involved @SpaceXAI and @Starlink; they do not establish who controlled either account or how any access occurred. Robinhood Chain records independently confirm reversible administrator recovery, privileged issuance, and sale, while the two-wallet operating cluster remains a strong inference from fund flow rather than a proven real-world identity. The evidence does not establish custody, affected-trader loss, or access to SpaceX internal or Starlink operational systems, and those conclusions remain open until platform, identity, endpoint, bridge, exchange, custodian, or transaction-level trader records close a specific edge.

The durable repair is temporal control review. Market interfaces should show verified-source status, reachable mint and admin-recovery paths, historical supply changes, and identified LP receipt batches instead of isolated green snapshots. Account responders preserve X sessions, OAuth grants, recovery and delegate changes, mail, identity, and endpoint records before revoking every publishing and recovery route; an independent correction names the accounts, observed window, Robinhood Chain, full contract address, non-endorsement, and update location. Chain responders preserve raw RPC data, code artifacts, receipts, traces, storage, and the wallet graph, and alert on slots 5–7, claimAdmin(), zero-address mints, large allowances, pair-to-router WETH, router withdraw/seller ETH, new LP receipts, removals, and onward collector movement.

Closure is evidence, not elapsed quiet time: the approved session, application, recovery, role, and device roster has been tested; the chain watchlist has an owner and retention period; providers have acknowledged exact network/address/hash/asset/time preservation pivots; the correction is live; and every open access, custody, and loss question has an owner and deadline. New platform records may establish authorization or entry, provider records may revise custody links, and a defined trader ledger may calculate loss; each changes only the conclusion it answers. Until then, the brief account observations and durable chain record support containment and tracing without pretending every actor or loss has been named.