We do not have a reliable USD price for the recorded assets yet.
0x4f3a120e72c76c22ae802d129f599bfdbc31cb81OptimismOn Optimism, assets were sent to 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81 before the intended Safe was deployed there. An unprivileged adversary then recreated the Gnosis ProxyFactory deployment path, occupied that same address first, and used the resulting attacker-controlled proxy to transfer out OP. The observable loss was two successful withdrawals of 1,000,000 OP each, both sent to 0x60b28637879b5a09d21b68040020ffbf7dba5107, for a total of 2,000,000 OP.
The root cause was not a private-key compromise or privileged access failure. The failure was operational and architectural: the victim treated a future CREATE-derived address as if it were reserved, even though that address was reproducible by anyone who could recreate the deployer address and nonce schedule before the legitimate deployment occurred.
The incident sits at the intersection of three Ethereum mechanics.
First, a CREATE deployment address is derived only from the deployer address and the deployer's nonce. It does not commit to constructor arguments, future owners, or the business intent associated with that address. If two environments can recreate the same deployer and nonce progression, they can recreate the same destination address.
Second, the Gnosis ProxyFactory pattern used here deploys a proxy with a plain new Proxy(masterCopy) flow. That means the proxy address depends on the factory address and factory nonce progression. It does not bind the eventual proxy address to a specific legitimate owner set.
Third, ERC20 tokens can be transferred to an address that has no code. The assets remain at that address until some contract code is deployed there and can move them. If the address was only "intended" for a future deployment, the first party to actually occupy it controls whatever logic ends up there.
0x230e17117986f0dc7259db824de1d00c6cf455c925c0c8c6b89bf0b6756a7b7e0x50257bd3b13510ccf7b1ba712811486fba585f5e987fcb0cce8ce5a08afb2098This incident is an ATTACK-category ACT opportunity. The exploit condition was a pre-funded, undeployed address whose future occupancy was assumed to be exclusive to the intended Safe deployment. That assumption was false because the address was derivable from public information and because the deployment path did not cryptographically bind future code or owners to the pre-funded address.
The security invariant should have been: assets staged for a future Safe must remain withdrawable only by the intended Safe owners after deployment. That invariant was already broken operationally when OP was sent to 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81 before any code existed there. The exploit became realizable because ProxyFactory.createProxy(address masterCopy, bytes memory data) uses CREATE-based nonce-derived addressing, allowing an attacker to recreate the same progression and deploy into the target address first. Once that happened, the attacker-controlled owner of the occupied proxy could directly command the address to transfer tokens out.
The earliest critical condition was the victim-side pre-funding step. Before block 10607736, the target address 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81 already held OP while still having no code. Independent state inspection confirms that immediately before the occupation transaction, the address had empty code and a positive OP balance:
cast code 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81 --block 10607735
=> 0x
cast call 0x4200000000000000000000000000000000000042 \
'balanceOf(address)(uint256)' \
0x4f3a120e72c76c22ae802d129f599bfdbc31cb81 \
--block 10607735
=> 20000001000000000000000000
That state created an exploitable prize at a known address. The attacker then recreated the deployer path needed to reach it. Seed transaction 0x75a42f240d229518979199f56cd7c82e4fc1f1a20ad9a4864c635354b4a34261 created 0x76E2cFc1F5Fa8F6a5b3fC4c8F4788F0116861F9B, the Gnosis ProxyFactory instance referenced throughout the analysis. This restored the deployer address whose nonce progression could later reproduce the victim address.
The next critical step was transaction 0x00a3da68f0f6a69cb067f09c3f7e741a01636cbc27a84c603b468f65271d415b, sent from 0x60b28637879b5a09d21b68040020ffbf7dba5107 to helper contract 0xe7145dd6287ae53326347f3a6694fcf2954bcd8a. That transaction consumed essentially the full block gas limit and emitted a long series of ProxyCreation logs from 0x76E2..., which is consistent with repeated proxy deployments to walk the factory nonce forward until the desired address was hit. Among those logs is the exact target address:
tx: 0x00a3da68f0f6a69cb067f09c3f7e741a01636cbc27a84c603b468f65271d415b
emitter: 0x76e2cfc1f5fa8f6a5b3fc4c8f4788f0116861f9b
logIndex: 0x87
ProxyCreation(proxy): 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81
The attacker-controlled helper was not incidental. Current chain state confirms owner() on 0xe7145dd6287ae53326347f3a6694fcf2954bcd8a returns 0x8BcFe4f1358E50A1db10025D731C8b3b17f04DBB, the same EOA that later issued the withdrawal transactions. That ties the occupation step and extraction step to the same adversary cluster.
After occupation, the target address no longer behaved like an empty future Safe slot. It behaved like an attacker-controlled proxy. Current code is present at 0x4f3a..., and owner() on that address resolves to 0x8BcFe4f1358E50A1db10025D731C8b3b17f04DBB, showing the target ended up under attacker control rather than under the intended Safe owner set.
The extraction transactions then become straightforward consequences of that control. Transaction 0x230e17117986f0dc7259db824de1d00c6cf455c925c0c8c6b89bf0b6756a7b7e was sent from 0x8BcFe4f... to 0x4f3a... with calldata that wraps ERC20 transfer(address,uint256) for OP and directs the transfer to 0x60b28637.... Its receipt contains a successful OP Transfer log from the target address to the attacker recipient for 1000000000000000000000000 wei units, or 1,000,000 OP:
from: 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81
to: 0x60b28637879b5a09d21b68040020ffbf7dba5107
token: OP (0x4200000000000000000000000000000000000042)
amount: 1000000000000000000000000
tx: 0x230e17117986f0dc7259db824de1d00c6cf455c925c0c8c6b89bf0b6756a7b7e
Transaction 0x50257bd3b13510ccf7b1ba712811486fba585f5e987fcb0cce8ce5a08afb2098 repeated the same mechanism later and produced an identical second 1,000,000 OP transfer to the same recipient. Together, those withdrawals confirm the ACT success predicate: an unprivileged adversary used public deployment mechanics to occupy a pre-funded address first and realize direct profit from it.
The adversary execution flow is a four-stage single-chain attack on Optimism.
Stage one was Factory Recreation. EOA 0x1aa7451dd11b8cb16ac089ed7fe05efa00100a6a, which the analysis ties to the attacker cluster through funding, deployed the recreated ProxyFactory in transaction 0x75a42f.... This restored the specific deployer address needed for nonce-based address reproduction.
Stage two was Victim Address Occupation. EOA 0x60b28637879b5a09d21b68040020ffbf7dba5107 called attacker helper 0xe7145dd6287ae53326347f3a6694fcf2954bcd8a in transaction 0x00a3.... That helper repeatedly invoked the recreated factory until one proxy creation landed exactly on 0x4f3a120e72c76c22ae802d129f599bfdbc31cb81. At that moment, the attacker became the first party to deploy code at the pre-funded target.
Stage three was Control Confirmation. The attacker-controlled owner EOA 0x8BcFe4f1358E50A1db10025D731C8b3b17f04DBB became the operative authority over the occupied proxy. This control relationship is visible through the helper ownership and through the fact that the later drain transactions were directly sent by 0x8BcFe4f... to the occupied address.
Stage four was Token Extraction. In transactions 0x230e... and 0x50257..., 0x8BcFe4f... instructed 0x4f3a... to transfer OP to 0x60b28637.... The target address was no longer a benign future Safe slot. It had become an attacker-operated contract endpoint capable of moving the staged assets.
The adversary-related cluster identified in the analysis is internally consistent:
0x60b28637879b5a09d21b68040020ffbf7dba5107: funds the sequence, triggers the occupation loop, and receives the stolen OP.0x1aa7451dd11b8cb16ac089ed7fe05efa00100a6a: deploys the recreated ProxyFactory.0x8BcFe4f1358E50A1db10025D731C8b3b17f04DBB: owns the helper/mastercopy control surface and sends the drain transactions.0xe7145dd6287ae53326347f3a6694fcf2954bcd8a: helper/mastercopy used to advance the factory nonce schedule and expose the execution surface needed after occupation.The confirmed measurable loss is 2,000,000 OP, represented on-chain as 2000000000000000000000000 raw units with 18 decimals. The loss occurred in two successful withdrawals of 1,000,000 OP each from the occupied target address to the attacker's recipient address.
The broader impact is that the address-reservation assumption behind the intended Safe deployment failed entirely. Any operational workflow that funds a future CREATE-derived address before deployment, without binding code and ownership first, is vulnerable to the same class of takeover if an adversary can recreate the deployer path early enough.
0x75a42f240d229518979199f56cd7c82e4fc1f1a20ad9a4864c635354b4a342610x00a3da68f0f6a69cb067f09c3f7e741a01636cbc27a84c603b468f65271d415b0x230e17117986f0dc7259db824de1d00c6cf455c925c0c8c6b89bf0b6756a7b7e0x50257bd3b13510ccf7b1ba712811486fba585f5e987fcb0cce8ce5a08afb2098ProxyFactory: 0x76E2cFc1F5Fa8F6a5b3fC4c8F4788F0116861F9B0xe7145dd6287ae53326347f3a6694fcf2954bcd8a0x4f3a120e72c76c22ae802d129f599bfdbc31cb810x4200000000000000000000000000000000000042