These addresses have the same active path

[opop369]

Related Safe Addresses

0x1f69aca06d3a74b55852a3a5d5220d9d68ec558e 0xd0538047787f449cb13788f4706da04e0f61fcb0 0x528da959d713352501d51aaff04a254427929754 0x64fe6c1f6531032036a6b5cc274240df9d036147 0x31e92b07d2d78cc385137b7c52e9b9c4c4dda37c 0xf2e16ff38cb39718eaedd822006aef6bd0931ea7 0x382afa7d6d4f57bf997fff740d599e87ad0bac43 0x937f9f494e24bb53f1cc3a5dd20247322ff9a9e4 0xfeab316b9a4c347c3aca32dd222a44f6d644884e 0xfe3518186eaaa9273b72a14e2ccb511d57529498 0xe011347618df9ada92cf3733bf24d549db4ba025 0x5443242f472f74d1403cb52876044e9e8a0d2ebd 0x1d1cb8ae052dca636c9b9ac078ef8c1e0ee80b4a 0x2fba07fccf6eec6e3322965efeb83002a6909f77 0xcfadc5c19de286589f1dd8e0d5180db636c7ba04 0x6e2e94646ff9b4f579944991fd6ef07f3e994b8e 0x6c2c602af6ff8513e2fa42571ac253767718dd76 0xaf3adb7a3e1f57f06d898ee0d6e20fb8e69c4536 0x3c767cd0cf692e0ff5ed72531bbb942523746556 0x70be85bbbaeadb7a1a707d8f005080a0b52cf1b3 0xbb4f0b2c2a5cafc8c1fe55aeae8082387190f6d7 0x87a772896db6163a0e270de414ca7fe59f20135d 0xc9552d437515bd48d6e638655321476eb03ebe8c 0x4039a52cc161d44b1489a03df2d152f1a754f164 0x94c7de9d0bc58b6fd85f85c35700fa3b4cb1169b 0xfe6203b62983e44dc52bf2985601662bb6c5f4d6 0x7e4c932860dc766616c190d0314b2a1a430048d4 0x426686fcb693f0be8e4381154e9f0e1ba1b29bec 0x099669d704f006a97a74d3832c35e98ea8fffec5 0x46f9470d6f2a114c94d8ed5c07af83693cf03794 0x04d58611dbdfa38b910c247f356018f457111615 0x975d1b7cdd1e47e0c05f350373109dc0fb03e2c9 0x4d17bff181e6444b7d3dac68563f1595c5a0c91d 0x68631588c462190269a3705a8eb645e7d51ac5f8 0x36da9454632b5ff83aa3df2ca5553239782cfdba 0x923766e32dfcc6d5e2225643cce8b3549b14ad66 0x952c8d39c7e5960a919e8719a67c06775b7d5a23 0x167da1673fb3d4a76e0cb8d996a0c9cad00bc49f 0xc1dd7edcf5027eefacda5541e9810d329c272c81 0x1e415173ea74bb2cc5c0ac063660540acb7d50fa 0xbfadd9b878834358e074a907a05a08b6e7310efa 0x38d9e655b8d79acd134a8383128f81a70ba4db10 0xd4d1c46bfe38b0900acc90c7a797144a0e49a088 0x03200ce2772b1644b9a4d7c2671fc1f9c31a6b75 0x46facc6006f27d5108feeb7062f689677fd13378 0xc633e6ed95ee62522b4ee80fcbdf5ac42a01b73b 0x605ddad3819dcf910a9d0ff55f997d67e41d43f5 0x21ddc7f6eba722d0aa3500105c5066d256533483 0x8e6c177b9c4d8e6348f35398dca55a46cc6e55ac 0x0caf90c527cdba003dc61cc0893662f6b3adaed6 0x88ae2737e4f64b4eb3feebce5346b52fbf565910 0x3e305d3ae7476a109d8a4a59f2448f2a48dc1734 0x9c9521dd1fb2e6878731117082f4e62acc396fa5 0x4e49d7496bafa44b9dc1f125a18d305aa319c78b 0xa231eebcfb9a49893a496a09315b63c49bebed94 0xedcdbaba2e1527e2609bf8f82edcf90f56540666 0xf0ad1415a72933a9c5c97bf91797b186ff2c8206 0x0b538258d5c75381076374d1987fa07b7282904b 0x9c612178a5136d21e384413274a9c9614f0f8878 0x8fc079af96945798498af219c7f7526d0588ae5b 0xfb52249094a4c1621d9f956e98f5c2d389a5feb5 0xbd0c2bc4cb7940a680537390653c6d5cfc0d7e2b 0x6f4f15cd1447c818d01d0d44abf4a641de3ddf9d 0x45a2f2e337050026a6303abd741b3ec82b8c2a4a

Reasoning

These Safes have only 1 tx in its entire lifetime, and that is like the following:

https://etherscan.io/tx/0x934eab25eb98b64106fa3f26030cef71ef7973b769c57c6414b8acfc7696dce1#eventlog

https://etherscan.io/tx/0xb67f18efc13c0ae420a5e7356a45886a1f6b1c857ae49e5c4f91dde914fe21b2#eventlog

From the event logs we can see, 0xDf21b894A490Cbdf49d9De7B9D780b79f7CB0AC7 sent a tx to remove owner 0x66a0ff664f8509370c5d718a0f69ac1dc01f5c3d, and assigns a new owner. This is the only tx that these Safes have.

These Safes were created by 0x5769770f5efe8fb017fb09b6de3b2d096668377d. This is an address that creates Safe proxies in batch. For example: https://etherscan.io/tx/0x5bf24dd77e6aa807f2db992de7e5993ade0255ad0a1e74fa415513d472af65f6#eventlog In this tx more than 30 Safes were created.

Following the same arguments as in https://github.com/safe-global/safe-user-allocation-reports/issues/237, I believe the creator of these Safes is a relayer. It created Safes for users in batch. After creation, 0xDf21b894A490Cbdf49d9De7B9D780b79f7CB0AC7 who used to be an owner of the Safe, and then renounced ownership and transferred ownership to users.

Generally, this indicates a valid use case where the protocol configures Safes on user's behalf. However, if such an owner configuration tx is the only tx that the Safe has, should it be qualified for the airdrop? I don't think these are airdrop farmers, but neither do I think they should be qualified. I'll leave it to the team to decide.

The tenet of the airdrop is to incentivize / reward organic usage of Safe but not to send free money to whoever just happened to create a Safe without actually using it. That's why those Safes without any tx history are ineligible. Having 1 tx in Safe's tx history doesn't necessarily mean the user has ever used it for real transaction. Instead, the user may have never heard of Gnosis Safe, but just happened to create one via third-party apps.

Methodology

Algorithm:

I identified 0xDf21b894A490Cbdf49d9De7B9D780b79f7CB0AC7 (let's call it the "manager") interacted with multiple Safes that have only 1 tx in the history, and those interaction times are close. There were 9995 interacted addresses in total. Retrieve the manager's tx history from etherscan API For each tx initiated from the manager, I filter those txs calling "execTransaction" method, and record the callee addresses. These callees are the Safes. For each Safe obtained from last step, I filter those safes with only 1 record in the tx history. 5693 addresses are obtained. Lastly, I manually checked a handful of safes to validate that the creators belonged to 0x5769770f5efe8fb017fb09b6de3b2d096668377d Finally, these Safes are the ones that users didn't actually interact with, but instead the manager configured the owner as the only tx in their lifetime shows. The Safes were inactive ever since then.

Safe Address

0xe0E84EE75F74e9d2f291b96366601D083952627a

[PulsarNetwork]

You copied my report! https://github.com/safe-global/safe-user-allocation-reports/issues/301

[tschubotz]

That's a copy of #301