Reveal the “Message’’ Replay Attacks on EthereumPoW

3 min readSep 18, 2022

By BlockSec

On September 16th, 2022, we detected that some attackers successfully harvested lots of ETHW by replaying the message (i.e., the calldata) of the PoS chain on EthereumPoW (aka the PoW chain). The root cause of the exploitation is that the Omni bridge on the PoW chain uses the old chainId and doesn’t correctly verify the actual chainId of the cross-chain message.

We immediately contacted the official team of EthereumPoW. The team was actively willing to take actions, and they also tried to communicate with the Omni Bridge.

However, as more and more attacks were observed in the wild, we believed that the risk should be notified to the public, and we published the alert on September 18th, 2022.

As there still exists some misunderstanding about these attacks, i.e., replaying the transaction rather than the message. In this report, we’d like to provide a detailed analysis to clarify it.

Attack Analysis

Here is an example of exploitation transactions:

Note that, these two transactions are different, however, the calldata (or input data) of these two transactions are exactly the same:


It is just the input data of invoking of the safeExecuteSignaturesWithAutoGasLimit function.

Obviously, the attacker (0x82fae) first transferred 200 WETH through the omni bridge of the Gnosis chain, and then replayed the same message on the PoW chain and got extra 200 ETHW. By doing so, the balance of the bridge contract deployed on the PoW chain could be drained.

Vulnerability Analysis

After anaylzing the source code of the Omni bridge, we find that there DOES exist the logic to verify the chainId.

function _isDestinationChainIdValid(uint256 _chainId) internal returns (bool res) {
return _chainId == sourceChainId();

Unfortunately, the verfied chainId used in this contract comes from the value stored in the storage named unitStorage:

* Internal function for retrieving chain id for the source network
* @return chain id for the current network
function sourceChainId() public view returns (uint256) {
return uintStorage[SOURCE_CHAIN_ID];

It is NOT the actual chainId fetched through the CHAINID opcode, which was proposed in EIP-1344. This is probably due to the fact that the code is quite old (using Solidity 0.4.24). The code works fine all the time until the fork of the PoW chain.

In short, the root cause of the exploitation is that the Omni bridge on the PoW chain uses the old chainId and doesn’t correctly verify the actual chainId of the cross-chain message. Besides, the similar issues may exist in other protocols.

The Impact

The straightfoward impact is that the attacker(s) could harvest lots of ETHW (and also other tokens owned by the bridge on the PoW chain) and traded them in some marketplaces (e.g., some CEXs). By doing so, the price of ETHW might be affected due to the increase of the liquidity. Hence users/investors should be cautious about the trade of these tokens on the PoW chain.


Solidity developers should pay special attention when dealing with the chainId that is designed to be maintained by the contract itself.

About BlockSec

The BlockSec is dedicated to building blockchain security infrastructure. The team is founded by top-notch security researchers and experienced experts from both academia and industry. We have published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, and successfully protected digital assets that are worth more than 5 million dollars by blocking multiple attacks.




The BlockSec Team focuses on the security of the blockchain ecosystem and the research of crypto hack monitoring and blocking, smart contract auditing.