Thank you for the quick response and for taking the time to review our case. We understand your point, but unfortunately, the third tiebreaker method you chose seems unfair, considering that the first comment on the [RFC] Uniswap Delegate Reward Initiative - Cycle 2 post was ours, in which we mentioned this:
We also think that doesn’t make sense to encourage behavior to rush in and create an account without setting the proper structure.
We understand and agree with your point; however, the proposal as approved did not specify this, and the tiebreaker method used was not outlined, whereas the method our team is referring to was clearly specified. We believe it sets a concerning precedent for Uniswap governance to adopt a tiebreaker method that hasn’t been officially approved, as it might appear tailored to influence the outcome as you knew the candidates in advance (though we’re not suggesting that happened here). Similarly, as you reviewed some elements for inclusion in Cycle 3, it’s crucial to avoid setting a poor precedent. To maintain transparency and uphold the legitimacy of the proposal, we suggest that this clarification be added to Cycle 3, and for this cycle, the method that the DAO voted on should be respected. We also agree to consider this a tie and share the rewards 50% - 50% with the other candidate.