What I was essentially looking at was the total activity for all the addresses that are receiving dripped POOL, and tallying up all of the activity those addresses were doing. I did not cover transfers of POOL out from those addresses, because any interaction with a contract (e.g. trading, depositing in pPOOL) also looks like a transfer and there would be double counting there.
Here’s an example from the report:
For example, imagine a user with 1000 existing POOL who then claims a further 300 POOL, sells 200 POOL, and then puts 200 POOL into the POOL pool (hereafter, pPOOL). Since the Working Group cannot attribute the claimed POOL directly into selling and pPOOL activity, respectively, what we can say is, at a maximum, that user sold 200 of their 300 claimed POOL, and, at a maximum, they put 200 of their 300 claimed POOL into the pPOOL. By definition this user could not have done both, but what this heuristic defines is the maximum amount of POOL they could either sell or move into the pPOOL.
What this emphatically does not cover is activity where the selling address is different from the claiming address. So if Yearn claims POOL into address X, and transfers to address Y before selling from address Y, then that would not show up in my analysis. I assumed that most addresses are straightforward about where they do their activity from and don’t route their claimed POOL to various place. But so long as Yearn is claiming into address X and then selling or pulling into pPOOL from address X, this analysis will catch that.
Since this particular part of the analysis was only a fringe part of the overall report, I limited my scope of the analysis to defensible simplifying assumptions around the entire claiming userbase. I didn’t want to get into a really detailed chain analysis rabbit hole around tracking down exactly what Yearn is doing with their claimed POOL- but if y’all think that’s important we can structure another proposal centered around doing this sort of detective work.