After some internal and talks with our community of users, we quickly realized that DeFi Saver users are for the most part in a similar boat as Dharma users.
As mentioned earlier, the architecture that transactions made via DeFi Saver follow in terms of Uniswap interactions is: Tx Sender -> User’s DSProxy -> DFS UniswapWrapper <> Uniswap. However, due to our Automation services the Tx Sender can be either the User’s actual account, or an Automation bot account.
We believe the fairest approach in terms of DeFi Saver users would be for Users’ DSProxy accounts to be included, instead of Tx Sender accounts, since many DeFi Saver users exclusively use our Automation services for their leveraging and de-leveraging trades on their MakerDAO and Compound positions, in which case the Tx Sender is not User’s Account, but rather one of our Automation bot accounts (very similar to Dharma where they sign and send transactions for their users, if I understand correctly). For example, 71% of DeFi Saver transactions that include token swaps in August have been initiated by Automation bots.
This approach would make sure that the receipients of the UNI aidrop are the actual accounts whose funds were being swapped and not our team owned Automation bot accounts (of which we have at least 10 currently active and many more that were previously used) that were merely signing and sending these transactions, on behalf of actual user accounts. As all DeFi Saver features revolve around the DSProxy architecture, all funds involved in all trades made via Uniswap were indeed originating from Users’ DSProxies, which hold either their MakerDAO CDPs/Vaults or their Compound portfolios.
Additionally, we would like to highlight that we already have an interface available for User accounts to withdraw any tokens (e.g. UNI in this case) from their User DSProxies, meaning this approach would not be creating an issue for anyone.
We are open on feedback and discussion on this, of course.