I have not found other frequent patterns. The only reason I found this pattern is because of the 9+ transaction block range that caught my attention.
There is no such block range in November (for USDC transactions at least), only in December.
To me, this totally makes sense. There is 0 justification to send $$$ to each other since faucet has malfunctioned only once or twice (for short periods of time). And if it were even friends sharing ETH with each other, it wouldn’t have the same action patters. I’d vote to have this list excluded, agree.
Not necessarily related to botting, but I have a primitive script that just counts transactions from one GEAR receiving address to other GEAR receiving addresses. It gives lot’s of hit’s and there’s probably still some bugs in the script so the results are far from perfect, but I’ve manually checked and confirmed few of the alerts and below is an example:
At the moment not sure how many of these case’s there are in the whole data, but I’d say at least +20 addresses that transfered to +7 addresses. If decided that this is useful data to dig further into, I can refine the script at better time and provide more detailed proof. But all that said, the above example could well be a group of friends testing together!
0x6cfcbb7bab66b8749628d81c4ab1f03120835350 sends eth to new one at 28612456
this applies to subsequent transactions as well. so it looks like it was one person who did the same actions with different addresses.
I think if friends are sitting together, they will take the test more or less simultaneously, and not sequentially and if friends are not sitting together, then the testing time for them will differ for long time intervals
Imo, “friends” could well claim testing tokens from the faucet, there was hardly any need to send the tokens back and forth. And even the best partnering “friends” would hardly perform exactly the same actions, sequentially and in short time.
In any case, the issue looks very suspicious to me.
Maybe we can ask the owners of the addresses to explain what magic they used? LOL
@spadefish I also want to share details on how faucet works if you don’t mind. Hope it can be useful to filter malicious accounts.
The basic faucet address is 0xF41c132Eb225376feAa7dbe:5dAc69118ca051C.
List of resolvers is here **
** how to get the list of resolvers: resolvers received 0.5 eth from basic faucet
Testers received ETH either from the basic faucet address or from resolver address (0.1 ether). Resolvers or basic faucet called contract 0x5a3EfECD039d23cCD55fE71Ce5f4b48751Dd5Bd9 to send testers tokens USDC/WBTC/DAI.
If user gets eth/tokens not from pp. 3 - it’s the reason to consider these addresses carefully…
Also I think it would be interesting to see the list of airdrop addresses that sent eth and/or tokens to each other. What I would pay attention to:
test start time
time of the end of testing
time when address gets eth/tokens
time when address sends eth/tokens to other tester
I think using these data we can divide bots from group of friends.
This address 0x2c8eb399eb6f8ad6cf33a09a0b5d5cccac4a05ed [leymo.eth] sent 1 (one) 1INCH token to 100 addresses using Multisender.app (hash 0xe69cb47e17a0a0ff9da285946f999dcebb67b0831924b61f6c76ab32aaf2e010)
As I see most of these 100 addresses were whitelisted.
some of them are:
I think the full/final list will be longer.
Address 0x2c8eb399eb6f8ad6cf33a09a0b5d5cccac4a05ed that sent 1INCH tokens to 100 other addresses was also whitelisted.
I now think there has been some serious botting. Parsed all the txs from TESTER LIST address to another TESTER LIST address. My script collecting the data just finished and need to look into it carefully later, but I did draw a quick network graph: