What's Going On With Gnosis?
There’s been some unusual activity with Gnosis as pointed out by our community. Time to figure out exactly what’s going on.
Outline
In this report, we are taking a look at a suspicious event that occurred on Gnosis network. In the beginning of October 2022, the Gnosis network experienced a high number of transactions and the unique users performing those transactions. We want to know what happened, so analyze the number of users, the successful and failed transactions, the types of transactions (and abnormal ones), the recipients of transactions and the xDAI transfers.
Analysis of Active Users
First, lets take a look at the number of active users in Gnosis. The definition of active users can be subjective. But for the purpose of this report, intentionally, we took any address with at least one transaction and more than one transaction per day as an active address.
Our observations:
- We can see that since the beginning of September 2022, the total number of users with at least one transaction peaked three times compared to the number of users who has more than one transaction.
- We define the events on September 28 and October 5 for the addresses with at least one transactions as anomal events.
- The plot shows that the users that caused the spikes, only performed a single transactions.
Analysis of Number of Transactions
The figure on the right shows the number of transactions that occurred since the beginning of September 2022.
Our observations:
- We can see that the number of transactions peaked at September 20, and October 5 to 7. The difference, though, is that the number of transactions peak at September 20 with a gentle slope, while in October the slope was significantly steeper.
- Also, we saw that the number of active users peaked at October 5, but the number of transactions peaked for 3 days while the number of active users were not as high.
- There was a high number of failed transactions in this period, which we will analyze in the next section.
Analysis of Failed Transactions
Now, lets check what percentage of transaction on the Gnosis network was successful, which is shown in the figure on the right.
Our observations:
- We can see that the ratio of failed transactions to succeeded ones where almost consistent since the beginning of September (~5%), except for two periods, September 19-20 and October 4-8. These statistics matches the numbers we had for the total number of transactions.
Now, we know that most of the transactions did not went through on anomal days. We think that this is the result of a DDoS attack, where the attacker tries to halt or slow down the transaction processing procedure.
Analysis of Types of Transactions
We are also curious about the types of transactions that took place since the beginning of September.
Note that we only chose those events that had at least 2000 occurrence each day.
Our observations:
- The main function call, during this period, was
massUpdate
, which was consistent till our final datapoint. - The raise we saw during mid-September was the result of a burst of
claim
functions. - At the end of the mid-September peak, we saw the rise of
executeAffirmation
function calls. It began to increase its function call share, until October 4, where it suddenly experience a massive jump. On October 5, there was close to no call of this function.
What is executeAffirmation
?
By searching the keyword “executeAffirmation” on Google, the first results we encountered were the contract address details of Gnosis contracts called “EternalStorageProxy” and “AMB Rinkeby Bridge“. Interestingly, these are the contracts responsible for the almost all of the failed executeAffirmation calls. Based on the source code of the OmniBridge, this function:
> Executes a message affirmation for some Foreign side event. Can be called only by a current bridge validator.
So, this function is responsible for an affirmation check from the foreign side of the bridge.
> Foreign Network: Can be any EVM chain, generally it refers to Ethereum - hackermd.io.
We think that this massive function call was in order to block the transaction processing power of the network, which according to the hackermd reference, mentioned above, was the case for many users.
Analysis of the Recipients of Transactions
The question has to be asked, who where the target of these transactions?
The figure on the right shows the top recipients of transactions from October 1 to October 10. Note that we only considered those addresses that received more than 2000 transactions per day.
Our observations:
- We can see that the address
0xc38d…
, along with other top contract addresses, received the most number of transactions. These contracts belongs to AMB Rinkeby Bridge. Almost all of the transactions headed to AMB Bridge were failed during this period. - An interesting fact is that on October 5, the address
0x37ef…
received a large number of transactions each with a small volume of xDAI, totaling 538 xDAI. Almost all of the transactions headed towards this address was successful. This can a be the result of a DDoS and extort attack.
Analysis of xDAI Transfers
Finally, lets take a look at the xDAI transfers. As shown in the figure on the right, the number of xDAI transfers were almost consistent through time, but peaked at October 5 and the recipient was the address 0x37ef…
. As far as we know the pure transfer of xDAI was barely effected by the attack and the executeAffirmation
function call was the main functions that failed the most (which we think was a part of the attack), which could in turn affect the xDAI transactions’ performance.
Conclusions
- Based on what we collected, we think the most possible scenario was a DDoS or Sybil attack. Because a huge number of accounts performed a single operation during that time, and the result was a massive down of service.
- The main target of attacked were bridges. Specifically, the AMB bridge.
- Though we could not find any relation between the attacks and the xDAI transfers to account
0x37ef…
, the coincident seems suspicious. Also, the total xDAI amount transferred to this address was 538 xDAI, which equals to 538 USD. A every small value an incentive for such a large-scaled attack!

