0x281ec184…7243sent to0x6f3e6272…223d·#20,019,654·view on Etherscan
The more I think about this the more I agree with what wiz has said in other forums. With the structure of these incentives the most popular clients will be the ones that send rewards back to the user performing the actions. The only tool we have to fight this is client id permissioning. Do we ban clients that return funds to users?
Assuming clients return rewards to the users:
Auction rewards act as a rebate on Nouns won at auction. Not a big deal.
Voting rewards incentivize users to vote on every eligible proposal. I'm ok with this. More vote volume. Not necessarily an increase in thoughtful votes, but still more eyeballs paying attention to Nouns. Perhaps there is also an incentive to discourage others from voting, to increase a users proportional share of votes.
Proposal rewards I'm less certain about. It incentivizes users to submit more proposals that reach a minimum # of FOR votes, currently 10% or 57 Nouns. Perhaps we see an increase in simple proposals like config changes, large proposals split into multiple smaller ones. This could also incentivize users to put more proposals onchain on behalf of others and keep the rewards. However, individuals and coordinated groups are already able to meet the 10% threshold specified. We could see voting blocks pass each others minor but legit proposals to drain the rewards. Worst case we see absolute spam from a voting block that controls the minimum amount of FOR votes. The other challenge here is that a growing proposal volume increases the risk that a malicious proposal will go unnoticed, as well, Nouns will be covering the bill to refund gas costs on all of the extra proposal voting happening.
In the future I would like to fund third party analysis of protocol changes like this.