2026-05-16 · Loss: 0 · Post-Incident On-Chain Message
This Ethereum transaction occurred on 2026-05-16 18:28:23 UTC and is not the exploit execution path for the Adshares Wrapper incident. The trace shows a single zero-value CALL from 0xcb6af4e5e29d66A14af1F516BaAF1D5F7d8F6b84 to 0x63e22ce9bde9bb8892a447258abfcaa4142f001b carrying plaintext calldata that repeats the whitehat return message from the alert. No internal calls, logs, token transfers, or ETH transfers occur, so the financial impact of this specific transaction is zero. The only supported conclusion from the collected artifacts is that this hash is a post-incident communication artifact referencing the separate Adshares Wrapper exploit.
The incident brief points to WrappedADS at 0xcfcEcFe2bD2FED07A9145222E8a7ad9Cf1Ccd22A as the suspected affected component. The contract is not a proxy according to manifest.json, and its source is verified in 0xcfcEcFe2bD2FED07A9145222E8a7ad9Cf1Ccd22A/0xcfcEcFe2bD2FED07A9145222E8a7ad9Cf1Ccd22A.sol. However, this transaction never calls that contract, so the exploit root cause cannot be attributed from this dataset alone.
No vulnerable Adshares Wrapper function is exercised in 0x7a823a891b7c5c02de50931f34cf50fc12cc600fe8b390b8f3dc29f2222c93b8. The only observed call targets 0x63e22ce9bde9bb8892a447258abfcaa4142f001b, and the calldata is free-form ASCII text rather than ABI-encoded function input.
The closest relevant wrapper entrypoints reviewed from source are the unwrap paths below, but none of them are invoked in this transaction and no line in this snippet can be identified as the exploit trigger from the available evidence.
function unwrap(uint256 amount, uint64 to) public whenNotPaused {
_unwrap(amount, to, 0);
}
function unwrapMessage(uint256 amount, uint64 to, uint128 message) public whenNotPaused {
_unwrap(amount, to, message);
}
function _unwrap(uint256 amount, uint64 to, uint128 message) internal {
_checksumCheck(to);
emit Unwrap(_msgSender(), to, amount, message);
_burn(_msgSender(), amount);
}
function unwrapFrom(address account, uint256 amount, uint64 to, uint128 message) public whenNotPaused {
_checksumCheck(to);
emit Unwrap(account, to, amount, message);
_burnFrom(account, amount);
}
Expected behavior for an exploit report is that the analyzed transaction reaches the vulnerable contract, executes a state-changing path, and moves assets in a way that can be tied back to a concrete missing check or flawed invariant. Actual behavior here is different: the trace contains only one top-level call to a separate message destination, with no nested execution into WrappedADS, no event emissions, and no transfers in funds_flow.json.
That matters because any attempt to name an Adshares Wrapper root cause from this transaction would be speculative and would violate the evidence hierarchy. The correct forensic conclusion for round 1 is narrower: this hash documents incident response messaging after the exploit, not the exploit mechanism itself. The exploit root cause remains unproven until the actual draining transaction is analyzed.
0x63e22ce9bde9bb8892a447258abfcaa4142f001b, not the Adshares Wrapper.0xcb6af4e5e29d66a14af1f516baaf1d5f7d8f6b84 -> 0x63e22ce9bde9bb8892a447258abfcaa4142f001b, CALL, value 00x4c617720 is unresolved in selectors.json and corresponds to the ASCII start of the plaintext payload ("Law"), not to an ABI-resolved function selector.trace_callTracer.json.funds_flow.json reports No attacker gains detected, with no ERC-20 transfers, approvals, or ETH transfers. The total loss attributable to this transaction is therefore 0 tokens and $0. No user, LP, or protocol treasury balance change is evidenced in the collected artifacts for this hash.
0x7a823a891b7c5c02de50931f34cf50fc12cc600fe8b390b8f3dc29f2222c93b8251095262026-05-16T18:28:23Z10xcb6af4e5e29d66A14af1F516BaAF1D5F7d8F6b840x63e22ce9bde9bb8892a447258abfcaa4142f001b0xcfcEcFe2bD2FED07A9145222E8a7ad9Cf1Ccd22A