No disagreement! Right now in the protocol there is no reason that a governance proposal would need to be passed within X days. And as a general principle I hope there never is such a reason.

1 month is kind of long, but could easily see 1 week (and then one week for voting).

No disagreement! Right now in the protocol there is no reason that a governance proposal would need to be passed within X days. And as a general principle I hope there never is such a reason.

1 month is kind of long, but could easily see 1 week (and then one week for voting).

very good question :) tricky. my answer is that they are too numerous to count in a purely decentralized model.

a decentralized governance group has little recourse should this happen - it's simply too slow

we all know of the 51% attack concept - here the bar is lower and there is nothing preventing someone from pulling off a 4% attack anonymously

however, there are several critical steps in governance that could mitigate the concern. each relies on some form of centralization.

1. Delegates have the ability to move a proposal to a formal vote. The community can recommend proposals, but it's no longer an autonomous function. Just make the trigger multi-sig. Here's the trade-off. Pros -No single person can shove a deleterious proposal through on volume of UNI alone Cons -No longer a decentralized function either.- Prone to internal politics, and can easily be utilized to stall efforts to progress the platform

2. Do none of the above, but let's continue with the idea of an 'approved delegate'. Here is the post-hoc solution. If an attack is imminent, then give them a multi-sig ability to 'cancel' a vote. Pros -No single person can pull off an attack Cons -not decentralized when you give a small group 'veto' power -may also expose a critical weakness of multi-sig, because it assumes all delegates are paying attention and 'able' to vote

3. Extend the power of a governor. This 'governor' address (presumably uniswap employee) already has the override power to 'cancel' a vote. A classic fail-safe mechanism that is built into the code, unless i'm reading it incorrectly. There should be an 'appeal' process that allows us to ask the Governor to 'cancel' a vote. Pros -Nothing in the code needs changing -No single bad agent can get away with an attack Cons -can be misused in a trustless system

this is a matter for a different post altogether, but we are at the stage where the foundational assumptions behind 'decentralized social groups' should be challenged.

• there is no historical precedence for this social entity working effectively.
• social anthropology says 'no' - do not try to equate this to hunter/gatherers - different scale - different problem
• behavioural economics says 'no' - human social progress is not a formative, rational, or ethical system - it is darwinian - it doesn't give a gnats' ass about which form of social organization we take. besides, modern capitalism is on the verge of collapse. there are many reasons for this, but my favourite is the critical assumption that Adam Smith got wrong in 'wealth of nations'. he assumed, incorrectly, that given an economic choice, every human being would make a choice that improved the state of the social group. kahneman eloquently dismantled that argument on his way towards getting a nobel prize.

so, maybe a 'hybrid' model that mixes decentralized with centralized structures. the purists will cry foul because they prefer to see the universe as a convenient, non-quantum, arrangement of 1s and 0s. fair enough, the clockmakers among us may be right in the end, but i have my doubts. the point of innovation is to 'temporarily suspend your disbelief', because it's the only way to trigger the novelty center of the brain. if we remain stuck in our beliefs, and hold them as sacrosanct pillars, we may as well let go of any claim to critical thought.

otherwise, a purist approach to decentralization will succeed, or not, on the assumption that humans can align on matters of mutual benefit. find precedence and i may be convinced. this is why satoshi was brilliant - he turned it into an economic challenge, and deferred the question of 'trust' to one of economic viability. here's the irony. in order for a truly 'decentralized' system to work, we would have to abandon selfish needs and privilege the group over the self. in that system we no longer rely on PoW or PoS to achieve consensus on anything. :) i fear we are mixing decentralized wealth, identity, ownership of data (SELF) with decentralized governance (SOCIAL). the fact that it works so well with one, does not automagically confer the same outcome for the other.

Can you give an example of one? Specifically, I'm interested in attacks where there is a time delay on governance proposals between creation and delegation snapshot, and someone executes a governance attack that can then be mitigated by governance, but only if the delay is short.

very good question :) tricky. my answer is that they are too numerous to count in a purely decentralized model.

a decentralized governance group has little recourse should this happen - it's simply too slow

we all know of the 51% attack concept - here the bar is lower and there is nothing preventing someone from pulling off a 4% attack anonymously

however, there are several critical steps in governance that could mitigate the concern. each relies on some form of centralization.

1. Delegates have the ability to move a proposal to a formal vote. The community can recommend proposals, but it's no longer an autonomous function. Just make the trigger multi-sig. Here's the trade-off. Pros -No single person can shove a deleterious proposal through on volume of UNI alone Cons -No longer a decentralized function either.- Prone to internal politics, and can easily be utilized to stall efforts to progress the platform

2. Do none of the above, but let's continue with the idea of an 'approved delegate'. Here is the post-hoc solution. If an attack is imminent, then give them a multi-sig ability to 'cancel' a vote. Pros -No single person can pull off an attack Cons -not decentralized when you give a small group 'veto' power -may also expose a critical weakness of multi-sig, because it assumes all delegates are paying attention and 'able' to vote

3. Extend the power of a governor. This 'governor' address (presumably uniswap employee) already has the override power to 'cancel' a vote. A classic fail-safe mechanism that is built into the code, unless i'm reading it incorrectly. There should be an 'appeal' process that allows us to ask the Governor to 'cancel' a vote. Pros -Nothing in the code needs changing -No single bad agent can get away with an attack Cons -can be misused in a trustless system

this is a matter for a different post altogether, but we are at the stage where the foundational assumptions behind 'decentralized social groups' should be challenged.

• there is no historical precedence for this social entity working effectively.
• social anthropology says 'no' - do not try to equate this to hunter/gatherers - different scale - different problem
• behavioural economics says 'no' - human social progress is not a formative, rational, or ethical system - it is darwinian - it doesn't give a gnats' ass about which form of social organization we take. besides, modern capitalism is on the verge of collapse. there are many reasons for this, but my favourite is the critical assumption that Adam Smith got wrong in 'wealth of nations'. he assumed, incorrectly, that given an economic choice, every human being would make a choice that improved the state of the social group. kahneman eloquently dismantled that argument on his way towards getting a nobel prize.

so, maybe a 'hybrid' model that mixes decentralized with centralized structures. the purists will cry foul because they prefer to see the universe as a convenient, non-quantum, arrangement of 1s and 0s. fair enough, the clockmakers among us may be right in the end, but i have my doubts. the point of innovation is to 'temporarily suspend your disbelief', because it's the only way to trigger the novelty center of the brain. if we remain stuck in our beliefs, and hold them as sacrosanct pillars, we may as well let go of any claim to critical thought.

otherwise, a purist approach to decentralization will succeed, or not, on the assumption that humans can align on matters of mutual benefit. find precedence and i may be convinced. this is why satoshi was brilliant - he turned it into an economic challenge, and deferred the question of 'trust' to one of economic viability. here's the irony. in order for a truly 'decentralized' system to work, we would have to abandon selfish needs and privilege the group over the self. in that system we no longer rely on PoW or PoS to achieve consensus on anything. :) i fear we are mixing decentralized wealth, identity, ownership of data (SELF) with decentralized governance (SOCIAL). the fact that it works so well with one, does not automagically confer the same outcome for the other.

Can you give an example of one? Specifically, I'm interested in attacks where there is a time delay on governance proposals between creation and delegation snapshot, and someone executes a governance attack that can then be mitigated by governance, but only if the delay is short.

That's fair but in that case should there not be two types of proposals?

1. Urgent proposal - Should be a rare occurrence (:crossed_fingers:) to handle emergency situations with a shorter period of time to both vote on & delegate votes for

2. Normal proposal - Longer period of time to vote on & delegate votes for

So, just to flesh out this conversation further:

Consider: say you delegate to one group before an initial proposal, but don't agree with your delegate's opinion and signalled intent to vote on a second proposal put forward after voting began but before it concluded for the first?

To preserve voter autonomy, we need to be able to delegate and undelegate if multiple issues are up for a vote at any given time.

If multiple issues can not be put up for a vote simultaneously, we should be considering the risks of miring ourselves into a somewhat plodding governance structure.

There's a happy medium in here somewhere, I'm just throwing out some knock-on effects of both sides of this. I very much appreciate an eye towards mitigating governance attacks by unfaithful actors--however we move forward with this, that should be at the forefront.

nothing

however, you must consider that the greater the financial stake, the more this 'actor' will be incentivized to 'improve' the uniswap marketcap

practically, it'll require 40M*3.20 = 128 Million USD to make it a cinch without the political 'delegate to me' campaign, and there isn't enough liquidity on the order books to do this

the only possibility i can think of is

1. wait for a drop in price
2. all the steps you propose while fear is high
3. launch some sort of campaign to temporarily pump price
4. unload

that's a pretty elaborate scheme that is difficult and risky to pull off. most whales i know calculate R:R like surgeons. that's to say it is highly unlikely but possible.

1 token = 1 vote is very very problematic because it tips the balance in favour of those with short-term financial interests

Chris, you have to change the votepage.tsx implementation

github page

The code is here to see. This modifies the user behaviour on the page.

// only count available votes as of the proposal start block const availableVotes: TokenAmount | undefined = useUserVotesAsOfBlock(proposalData?.startBlock ?? undefined)

// only show voting if user has > 0 votes at proposal start block and proposal is active, const showVotingButtons = availableVotes && JSBI.greaterThan(availableVotes.raw, JSBI.BigInt(0)) && proposalData && proposalData.status === 'active'

the logic continues in hooks.ts which checks to see if you have valid votes that were activated before the proposal datetime startblock

// fetch available votes as of block (usually proposal start block) export function useUserVotesAsOfBlock(block: number | undefined): TokenAmount | undefined { const { account, chainId } = useActiveWeb3React() const uniContract = useUniContract()

// check for available votes const uni = chainId ? UNI[chainId] : undefined const votes = useSingleCallResult(uniContract, 'getPriorVotes', [account ?? undefined, block ?? undefined]) ?.result?.[0] return votes && uni ? new TokenAmount(uni, votes) : undefined }

That's fair but in that case should there not be two types of proposals?

1. Urgent proposal - Should be a rare occurrence (:crossed_fingers:) to handle emergency situations with a shorter period of time to both vote on & delegate votes for

2. Normal proposal - Longer period of time to vote on & delegate votes for

So, just to flesh out this conversation further:

Consider: say you delegate to one group before an initial proposal, but don't agree with your delegate's opinion and signalled intent to vote on a second proposal put forward after voting began but before it concluded for the first?

To preserve voter autonomy, we need to be able to delegate and undelegate if multiple issues are up for a vote at any given time.

If multiple issues can not be put up for a vote simultaneously, we should be considering the risks of miring ourselves into a somewhat plodding governance structure.

There's a happy medium in here somewhere, I'm just throwing out some knock-on effects of both sides of this. I very much appreciate an eye towards mitigating governance attacks by unfaithful actors--however we move forward with this, that should be at the forefront.

nothing

however, you must consider that the greater the financial stake, the more this 'actor' will be incentivized to 'improve' the uniswap marketcap

practically, it'll require 40M*3.20 = 128 Million USD to make it a cinch without the political 'delegate to me' campaign, and there isn't enough liquidity on the order books to do this

the only possibility i can think of is

1. wait for a drop in price
2. all the steps you propose while fear is high
3. launch some sort of campaign to temporarily pump price
4. unload

that's a pretty elaborate scheme that is difficult and risky to pull off. most whales i know calculate R:R like surgeons. that's to say it is highly unlikely but possible.

1 token = 1 vote is very very problematic because it tips the balance in favour of those with short-term financial interests

Chris, you have to change the votepage.tsx implementation

github page

The code is here to see. This modifies the user behaviour on the page.

// only count available votes as of the proposal start block const availableVotes: TokenAmount | undefined = useUserVotesAsOfBlock(proposalData?.startBlock ?? undefined)

// only show voting if user has > 0 votes at proposal start block and proposal is active, const showVotingButtons = availableVotes && JSBI.greaterThan(availableVotes.raw, JSBI.BigInt(0)) && proposalData && proposalData.status === 'active'

the logic continues in hooks.ts which checks to see if you have valid votes that were activated before the proposal datetime startblock

// fetch available votes as of block (usually proposal start block) export function useUserVotesAsOfBlock(block: number | undefined): TokenAmount | undefined { const { account, chainId } = useActiveWeb3React() const uniContract = useUniContract()

// check for available votes const uni = chainId ? UNI[chainId] : undefined const votes = useSingleCallResult(uniContract, 'getPriorVotes', [account ?? undefined, block ?? undefined]) ?.result?.[0] return votes && uni ? new TokenAmount(uni, votes) : undefined }

I believe this change is a good one and is by far the easiest to implement, I called it the preparation period. It provides the necessary safety check for the system and allows for voter mobilization. It also, albeit not perfectly, allows the UNI/ETH LP tokens to participate in the governance matters if they're perceived as critical.

I also support the concern that 48 hours might not be enough - but it shouldn't be more than a week. I don't think that the preparation period should be shorter than the voting period. If anything, it takes more time to review, audit, and discuss than to vote.

I could see a 6-day preparation - 4-day voting sequence working fine, as an example.

I believe this change is a good one and is by far the easiest to implement, I called it the preparation period. It provides the necessary safety check for the system and allows for voter mobilization. It also, albeit not perfectly, allows the UNI/ETH LP tokens to participate in the governance matters if they're perceived as critical.

I also support the concern that 48 hours might not be enough - but it shouldn't be more than a week. I don't think that the preparation period should be shorter than the voting period. If anything, it takes more time to review, audit, and discuss than to vote.

I could see a 6-day preparation - 4-day voting sequence working fine, as an example.