BGD. Aave Governance V3

Hello folks! @bgdlabs in reading the proposal again and following up on my earlier comment, I think there might be a critical flaw in the design that effectively kills delegation.

In this design, ERC20 snapshotting is removed to save costs on L1 tokens transactions. This also removes delegation, as delegation uses the snapshotting to track the total voting power of a Delegatee by tracking how much voting power is being delegated each time a token is transferred.

This becomes a problem when using storage proofs to verify voting power on a different chain, because now we need to proofs for:

A) Voters token balance

But also two additional storage proofs for each address delegating to that voter:

B) Delegators token balance
c) Proof Delegator is delegating to Voter

This problem becomes unbounded because you now need two storage proofs for every delegator, and the number of delegators is unlimited.

While most voters in the AAVE ecosystem don’t have as many delegators as in other ecosystems, even at current delegation amounts it can easily make voting on l2 more expensive than on l1 because the amount of calldata necessary for each proof multiplied by each delegator.

Additionally this is vector for a severe griefing attack, whereby and attacker can could prevent a voter from ever being able to vote by simply delegating to them so many times that it becomes impractical for the user to submit the required storage proofs.

You could get around this problem by not requiring a user to submit all their delegated voting power, but since a voter can only vote once, you get into a weird state by which someone for economic reasons might only be voting with portions of their voting power which could lead to other problems.

Socially, delegation is important for the scalability and long term success of hyperscale public infrastructure like AAVE. Removing it all together would, IMHO be a net negative for the protocol.

Am I wrong in my assessment that this design is not compatible with Delegations?