Excel file for USDC transactions where I’ve marked duplicates and our attention is on blocks between 28643736 and 28643797;
A txt file with all addresses with exactly 11 transactions within the above block range;
A txt file with addresses in the same block range, but with transactions ranging from 4 to 8 per address or addresses that aren’t in the Tester’s List.
A txt file with 10 random addresses from 2) which I tested to see if there was the same Diesel DAI transaction around 2021-12-06 1:35 ±seconds UTC+2 (if Etherscan shows the correct timezone).
Yes, the scenario is the same, I just wanted to point out the timing of the Diesel DAI transaction as proof of botting for all of them, because it paints the picture clearly and simply.
I think if you tell two people to come up with a sequence of 10-11 actions, the probability that both will use the same order of actions is extremely small…
Have you checked for the other abnormally frequent patterns for 10txs+?
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:
0xCBc442546281A663834acf25e3874aa91Cf0a77a
0x9f436624c4f05bfdee86ea1311899ccdcf17eb1d
0xbc6a1532b1957ad71b963fe919e7e744c26bf59a
0xc701f3cad9f2d5cc7a62633fb00b2d0b57a60fb1
0x9ae30865fbc37630c61724359ad28a77a4757743
0x41bd414546d577080b5fdf3adf6b57d4127649ed
0xd7277eef51e23c74d0fd66a5c0ede90827e1bb25
0x231384fb4f4c3566458692bca017b92ab224fe6f
I think the full/final list will be longer.
Update:
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:
