On August 31, 2026, Injective stopped at block 181,027,000.
This was not an unplanned outage caused by validators failing to produce blocks. Validators intentionally halted the network while an attack was still in progress.
The Injective Foundation told validators that a potential attack vector had been identified and asked them to configure a halt-height at block 181,027,000. It later distributed a new binary, v1.20.3-safeharbor.1.
But by the time the chain stopped, a significant amount of value had already left Injective.
Should a decentralized blockchain remain unstoppable even during an active exploit?
Roughly $4.8M is believed to have been extracted through a Binary Options vulnerability
As of September 1, 2026, Injective has not yet published an official post-mortem, so the exact exploit path has not been fully confirmed.
According to currently available on-chain analysis, the attacker appears to have started with roughly $55K in capital and repeatedly exploited Injective’s Binary Options markets.
The leading analysis suggests that the attacker generated realized PnL through trades between accounts they controlled, then took advantage of the refund and settlement path for markets where no oracle price was provided.
The result appears to have been a double credit: previously realized profit remained reflected in the account while the margin associated with unsettled positions was also refunded.
This pattern is believed to have been repeated across roughly 299 markets, resulting in approximately $4.8M being extracted.
Injective’s safeharbor patch disabled Binary Options functionality on Mainnet.
The patch also introduced additional checks requiring the quote denom of a derivative market to match the deposit denom of the corresponding insurance fund.
It is not yet clear whether the insurance fund changes address the direct root cause of this exploit or were added as additional hardening.
Emergency release:
https://github.com/InjectiveFoundation/injective-core/releases/tag/v1.20.3-safeharbor.1-1788190988
The attacker moved USDC from Injective to Ethereum through Circle CCTP
The address believed to be associated with the attacker is:
0x792c6bf8ee604edee807327168af89fbf863c027
Injective Explorer:
https://blockscout.injective.network/address/0x792C6Bf8Ee604edeE807327168Af89Fbf863C027
Ethereum:
https://etherscan.io/address/0x792C6Bf8Ee604edeE807327168Af89Fbf863C027
The attacker used Circle CCTP to move funds from Injective to Ethereum.
44,094 USDC was burned on Injective
At Injective block 181,025,018, the attacker burned 44,094.293341 USDC through Circle CCTP’s depositForBurn() function.
The call specifies destinationDomain = 0, which corresponds to Ethereum in Circle CCTP, and the recipient is the attacker’s own EVM address.
Roughly 20 seconds later, the same 44,094 USDC was minted on Ethereum
About 20 seconds later, Circle CCTP’s receiveMessage() function was executed on Ethereum.
https://etherscan.io/tx/0xa876e6a57af4f64f78b8f44ef4fd3ef638124241697a3ecf94730d914e312497
Exactly 44,094.293341 USDC was minted to the same attacker address.
The event log contains:
sourceDomain = 29mintRecipient = 0x792c6bf8...amount = 44,094.293341 USDC
In Circle CCTP, domain 29 corresponds to Injective.
The two transactions therefore represent both sides of the same CCTP transfer.
Injective USDC burn → Ethereum USDC mint
The USDC was swapped into ETH on Ethereum
The attacker then swapped the USDC received on Ethereum into WETH through Uniswap.
https://etherscan.io/tx/0xbcf17493454be53daee100adae30cd3a9f00ea3a41b96dc95a2b3d65e08f8200
The transaction swaps:
44,094.293341 USDC → 17.879993994158254918 WETH
The observable fund flow was:
Binary Options exploitInjective USDCCircle CCTPEthereum USDCUniswapETH
Roughly 1,980 ETH was consolidated into a separate Ethereum address
The converted ETH was moved into the following address:
0x5A18C382eD5bb01814296ee03026dbf5b32A69EA
https://etherscan.io/address/0x5A18C382eD5bb01814296ee03026dbf5b32A69EA
The major transfers we can verify include:
1,650 ETH
https://etherscan.io/tx/0xda74518b78483c101890c4cb0e233d7b7698f0a9e96d79caea74612e0fab8c4b
211.107589 ETH
https://etherscan.io/tx/0x93a1de874fc6ec4bd61834971ea13bb1a8f26974a1752dc1bbe9e88d2b8c12a2
118.7 ETH
https://etherscan.io/tx/0x01be6e131ae4ce5f61541f360539402db83973f182937d6bfb8231dafd106004
Together, these amount to approximately:
1,979.807589 ETH
At the time, that was worth roughly $4.9M, close to the approximately $4.8M exploit size estimated in public analysis.
Injective halted the chain to stop further exploitation, not to recover already stolen funds
A significant portion of the large on-chain transfers we can verify had already left Injective before the halt.
The 1,650 ETH transfer occurred on August 31, 2026 at 03:50 UTC.
https://etherscan.io/tx/0xda74518b78483c101890c4cb0e233d7b7698f0a9e96d79caea74612e0fab8c4b
The 211.107589 ETH transfer occurred at 05:21 UTC on the same day.
https://etherscan.io/tx/0x93a1de874fc6ec4bd61834971ea13bb1a8f26974a1752dc1bbe9e88d2b8c12a2
Both happened before the Injective Foundation asked validators to halt the chain.
Withdrawals also continued after the halt request but before the network actually reached the configured halt height.
The 44,094.293341 USDC CCTP transaction above was executed at block 181,025,018.
The target halt height was 181,027,000.
The halt therefore was not a mechanism to reverse or contain funds that had already been stolen.
Its purpose was to stop the attacker from repeatedly exploiting the same vulnerability while validators deployed the patch.
The attacker’s existing transactions were not rolled back, and account balances were not directly rewritten.
The network’s state transition was simply stopped until the patched software could be deployed.
A bounty negotiation message was sent to the address holding the stolen funds
The consolidation address 0x5A18... later received the following Ethereum transaction:
https://etherscan.io/tx/0xe2d56a88696ed1b72f6421875eb6bb1278373fbab589fef67e477b430f7eda24
Its input data contains the message:
Hi. We would like to chat and offer you a bounty. Please get in touch.
The transaction was sent from:
0x91e4f2e8770Cad99Bf3F1905c0336EbF8B964640
The on-chain flow we can verify is therefore:
ExploitInjective USDC obtainedTransferred to Ethereum through CCTPConverted into ETH through UniswapRoughly 1,980 ETH consolidated into another addressA bounty negotiation message sent to that address
During the KelpDAO exploit, Arbitrum kept the chain running and directly moved 30,766 ETH held by the attacker
A useful comparison is the KelpDAO rsETH exploit from April 2026.
It is often described as a “LayerZero hack,” but it is more accurate to say that the incident involved KelpDAO’s bridge configuration and the RPC infrastructure used by a LayerZero Labs DVN, rather than a vulnerability in the LayerZero protocol itself.
A forged cross-chain message was accepted as valid, resulting in approximately 116,500 rsETH, worth around $292M at the time, being stolen.
LayerZero incident report:
https://layerzero.network/blog/layerzero-labs-kelpdao-incident-report
The attacker later held 30,765.67 ETH on Arbitrum One.
The Arbitrum Security Council responded with an emergency action.
https://forum.arbitrum.foundation/t/security-council-emergency-action-21-04-2026/30803
The Security Council temporarily upgraded the Arbitrum Inbox contract and added functionality that allowed a transaction to be executed on behalf of the attacker address.
It then moved approximately 30,766 ETH to a recovery address and restored the Inbox implementation to its original state.
The chain remained operational throughout the process, but the Security Council directly intervened in the state associated with a specific attacker account.
Injective halted the chain, while Arbitrum directly changed specific state
The two responses were fundamentally different.
Injective used validator coordination to halt the entire network.
The objective was to stop further exploitation, and the protocol did not directly move funds that had already been stolen.
Arbitrum, by contrast, kept the network running while the Security Council directly intervened in the state of a specific attacker account.
Approximately 30,766 ETH held by the attacker was moved to a recovery address to prevent further movement.
In short:
Injective stopped the entire chain to prevent additional exploitation.
Arbitrum kept the chain running and intervened directly in specific attacker-controlled assets.
Decentralization may be less about preventing intervention and more about constraining intervention power
Blockchain decentralization is often described as the property that no one can stop or reverse transactions.
But if a critical vulnerability is actively being exploited and no one is able to stop the system, losses can continue indefinitely.
At the same time, if a small group can arbitrarily move assets or rewrite state, it becomes difficult to describe the system as immutable.
Whether intervention is possible may therefore be the wrong question.
More important questions are:
Who has the authority to intervene, and under what conditions?
How broad is that authority?
How many independent parties must agree?
Can the intervention and its outcome be publicly verified?
On Injective, emergency power was exercised through validator coordination and a network halt.
On Arbitrum, it was exercised through the Security Council’s emergency upgrade authority and direct intervention in specific state.
Both incidents show that emergency power exists in real blockchain systems.
The difference lies in who holds that power, how broad it is, and what process governs its use.
When evaluating decentralization, it may be more useful to ask not whether intervention is impossible, but whether the power to intervene is sufficiently constrained, distributed, and transparent.