$ARB Sybil Analysis

This analysis looks into possible sybil addresses gaming the recent $ARB airdrop. Before we get into it, I just wanted to point out that it's obviously easier to do this post-airdrop analysis than beforehand, though I do think some of these users could definitely have been detected. Sources used for the analysis are Dune and Arbiscan.

Tracking $ARB Transfers

So how can we detect possible sybil addresses after the airdrop? One way is to look at the first $ARB transfers out of addresses that received the $ARB airdrop. Basically checking where the received airdrop is ‘collected‘. By summarizing these results you could potentially find addresses that received $ARB from many other addresses (clusters). Few assumptions I made when analyzing this:

• Exclude contract addresses; we rule these out by looking at the ‘arbitrum.traces’ table where type = ‘create’, indicating the creation of a contract.

• Only look at direct $ARB transfers to other wallets; we can do this by looking at the transfer method: ‘0xa9059cbb‘

• Include the $ARB transfers that happen within a short period after the claim; 7 days.

When applying these rules we get the great visualization below, clearly showing many clusters and hence addresses that have been send the $ARB airdrop from many other addresses. To keep this analysis manageable i limited it to addresses receiving at least 100 transfers, but many other small clusters could also be found. You can directly visit the visualization below here.

The image above clearly shows that the $ARB airdrop was gamed to some extent. As stated we will only look at the top receivers (>100 transfers), which include a total of 86 clusters. These clusters received the $ARB token from 23,068 addresses.

Below we can find a table of the top 10 clusters (by transfers in). The top cluster received the airdrop from over 1500 addresses with a value (at current price $1,40) of almost $3 million. In total these 86 clusters received 34.2M $ARB with a current value of almost $48 million.

So, could these clusters have been detected?

Yes, well at least some of them could in my opinion. Let’s look at some of these clusters and their onchain data to find out if they could have been connected before the airdrop.

Wallet funding
An important way to detect connections between addresses is looking at the way the addresses were initially funded, basically checking where did the first incoming value transaction came from. The top cluster address: 0xe1e271.. (and also other top clusters) did this by sending a small portion of ETH from an exchange to all these different addresses (fairly the same amount) in a close period of time. I won’t dive in this type of funding as it is more difficult to completely ‘confirm‘ on chain, more on this you can find in this great article by X-explore.

Disperse funding
One well known way to fund addresses, is through Disperse, which allows you to send ETH to multiple addresses in one transaction. The source sender and the addresses funded are easily viewable on chain. So if we take the addresses belonging to the 86 clusters we can cross check with the Disperse contract on Arbitrum. We can do this by looking at the ‘arbitrum.traces‘ table where the source is Disperse (0x692..) and join this result with our clusters/addresses list.

The result: 8292 addresses were funded through disperse transactions, which are part of 31 unique clusters. The funds came from a total of 209 different sources. So for more than 1/3 of the addresses in this analysis, it could already be proven they share a similar funding source and therefore are likely owned by the same user. So in essence 8292 addresses can be brought back to only 31. And it gets worse.

I noticed some overlap between funding sources, so I dug a little deeper. I aggregated the disperse addresses by ‘funding source’ and ‘cluster‘, to find out that different clusters had the same funding source(s). Below we can see the visualization, in short: 15 clusters can be brought back to 3 unique clusters which have overlapping funding addresses, making it highly likely these addresses are also connected.

The end result, these 3 groups eventually account for 5567 airdrop receivers. In total these groups received over 5.7 million $ARB ($8M), which in my opinion could have and probably should have been prevented.

There are of course other ways to look into connections between wallets; for example bridging transactions, behavior on other EVM chains, similar transactions patterns but also for example (big) value transfers between wallets. If we look at the value transfers between the addresses in this analysis, we can also find some patterns. This is of course easier in hindsight. When filtering for relative large value transfers, we can find patterns like below, where a fairly large transfer happens to a wallet, some action is performed (a swap for example) and almost the same amount is transferred on to the next address, creating a “chain” of addresses highly likely to be connected. In my opinion these patterns could also be detected in advance.

In conclusion, it looks like the $ARB airdrop was gamed to some extend. Big clusters can be found by looking at where the $ARB airdrops are gathered. Over 23K addresses could be reduced to 86, and even these clusters showed connections by looking at the funding source, reducing 15 of these clusters to 3 unique groups. By looking at the Disperse transactions we could easily identify over 8K connected addresses prior to the airdrop. Also other methods like value transfers, could be used to identify suspicious behaviour between wallets.

In my opinion, when distributing these amounts of value to users, more attention/analysis is needed to detect connections between wallets. Some connections can quite easily be surfaced, making it possible to prevent unfair distribution of tokens across communities.