From my understanding even in the case of exploits Astroport still has to wait at least 6 days (assuming you skip the ARC and Freeze). This is still a long time for having an exploit in production code. Now depending on the exploit it could be a minor problem or a major issue with the possibility to drain all the liquidity of Astroport.
We should have some way to skip/drastically reduced this voting period only for patching exploits.
It could be done with a super-majority of tokens voting on a proposal so it’s accelerated but maybe you have another idea?
I don’t have any solid theory or idea. But your idea of more votes = faster execution does seem nice and a solid first step.
The idea I came up with is to have a separate framework for expolit relegated proposals. Which can be voted on for a very short period of time like 24 hrs and rather than using quorum it’s just whichever option has majority. The idea behind having just majority is that it’s much quicker than having to reach a quorum.
The main drawback I see is how does someone judge whether a proposal should actually follow the exploit framework or just the normal technical framework? And since the voting period is much shorter it’s going to be more easier to exploit when compared to using the the standard framework.
My solution to this is that proposals in this expoit framework can only be posted by select members/addresses (they don’t need to have the minimum 30000 xASTRO either). These members could be Astro dev’s, TFL dev’s, auditors and other trusted members. These trusted members would be voted on by Astro Assembly and anyone can nominate themselves to become a trusted member.
I am not sure how easy it would be implement a whole new framework though. On a side note these members could also be used for the blacklisting of generators if we want to follow the method you proposed.
Not sure I agree with having a whitelist. I think anyone should be able to post a proposal but there should be some conditions so the proposal can be fast-tracked. For example, a minimum of X ASTRO has to vote and the quorum must be higher than the one on normal proposals. If any of the conditions fail, the proposal either fails or maybe it becomes a normal proposal executed in about a week.
Yep I don’t really agree with a whitelist either but that was the easiest way to solve the problem. The only other real way to disincentivize people from abusing this framework would be to have a slashing on their deposits.
I think your idea is pretty good though. Having a higher quorum amount of let’s say 30% would allow you to stop voting right there and upgrade the required contract.
Slashing deposits is an interesting idea, if I recall, Mars does this. Think a proposal will be needed for all this
Yep I will try to formulate a good method either with slashing or with a way to speed up governance for these edge cases and make an ARC.
@Archkiwi you raise a good point.
While it is hard to mitigate the risk of exploits and governance attacks, allowing certain permissions and variable voting periods within governance is very difficult.
Your idea needs merit and requires a bit more detail for execution.
One possibility is triggering a vote after it reaches a higher, less attainable quorum.
After thinking more about it I think having a totally new framework would just increase complexity and would also probably be harder to implement than just upgrading the current one (dev input on difficulty of upgrading vs adding a new framework would be nice).
Also Stefan’s idea seems like a much more elegant solution.
Here’s a rough draft on the new framework -
All the basic stuff is the same 4 days of on chain voting and 2 days for execution.
But here is how we can speed up a proposal -
If the proposal get’s 30% quorom for YES (this quorom number is upto further discussion) the voting ends instantly and rather than having to wait 2 days for execution it would be executed instantly. I thought about adding a 6 hours grace period for further voting so let’s say your on 24th hour when you reach 30% quorom only 6 more hours would be available (rather than 3 more days) but this just seems to add more complexity without a lot of upside.
Another thing to note is initially 51% could be set for speeding up the proposal rather than the 30% as at 51% the proposal would have to be executed. Then with further governance we could decide a lower number for speeding up governance. If the devs think this is a good solution I would like them to hear their opinions on the quorum number for speeding up governance.
Kudos for the ideation process you’ve started!
I like the ideas you’ve come to, but I believe that the instant resolution of a vote as long as it passes quorum opens up the protocol to flash-loan assisted governance attacks similar to that suffered by Beanstalk recently.
In that case, afaik, the attacker actually posted the polls a full day before the attack, too, so they could be resolved within the flash-loan’s transaction.
The 6hr delay seems to resolve this concern.
Let’s make sure the mechanism is as bulletproof as possible before we put it up for a vote.
@Sandro could you maybe start a conversation about this topic in the Discord someday? It’d be great to get some eyes on this topic, to ideate and poke holes into our propositions ^^
Hey not sure if it changes after vxASTRO launches but currently speaking if a proposal was made on (block x) then only those who have had xASTRO on (block x-1) and builders can vote. So that’s the reason I said the 6 hours is an option and not really a necessity. As at least currently it’s not possible to flash-loan attack the Astro Assembly (might change once vxASTRO launches).
But I agree we need to have a bulletproof system especially when it comes to topics such as speeding up Governance. That’s also the reason I suggested that 51% as only then are we fully sure to whether or not pass the proposal.
I had forgotten about this security mechanism, thanks for reminding me!
Not sure that’s enough to counter the hack I’m describing though: in that case, the proposals were put up for vote a full day before the attack, so the attacker would have been able to vote with the flash-loaned tokens.
Maybe the mechanism could be adapted though so that the maximum voting power of a user at block x is limited by the voting power he possessed at block x -1.
x -1. I vote on block x with my full available balance of 100 ASTRO. My voting power is equal to 100 ASTRO’s worth.x -1. I use a flashloan to acquire 1M ASTRO and vote on block x. My exercised voting power is still equal to 100 ASTRO’s worth, because I acquired the extra tokens on the same block I voted on.Hope I got this right and the mechanism isn’t redundant.
Hey sorry if a getting the flashloan wrong but shouldn’t it be done in the same transaction?
In this case an exploiter would have to buy ASTRO before the poll even goes live then stake it for xASTRO. But in that case this would no longer be a flashloan right?
My bad, I misunderstood your reply.
You’re right, the attack is prevented already ^^