Length of Voting Procedure

Hey Everyone,

Our friends in the Cafe have been discussing the length and number of voting periods.

We certainly respect the need to ensure a diverse range of voices and options are heard and the spirit and governance of the process is upheld.

In the situation of the Smart Treasury my view is that it is Crystal clear that the entire community is ready and waiting and it’s unanimous.

The multiple layers of voting, and the timelock seems unnecessarily bureaucratic.

Is it possible to consider a vote on an accelerator or more streamlined process that can be activated in situations to create a more agile process that creates faster innovation whilst also ensuring adequate engagement and due diligence opportunities.

Would love to hear everyone’s thoughts on this.

And let’s get this Treasury live!!!


While it’s clear what IIP-3 will be, do we already have IIP-4, 5 and 6 ready in the pipeline and blocked, waiting on previous voting to complete?

The (perceived) delay with Smart Treasury deployment is more due to actions-per-IIP limit than anything. Nothing stops governance from defining next IIP while 2 and 3 are going through the motions.


Thanks @Coinballers for posting this.

Right now the current state of the art of the voting journey is:

  • Off-chain discussions and polls;
  • On-chain proposals.

What can we improve here? How can we speed up this process?

On-chain Voting Phase

The current approach requires 5 days (3 days for voting and 2 days as timelock) for an on-chain proposal to pass through the voting phase. This is an industry-standard already adopted by protocols like Compound and changing this can impact the security of the protocol.

The timelock might seem useless, but it allows people to exit the protocol if they don’t agree with the approved proposal. While some proposals are only related to Governance Ecosystem funds or minor fixes, others might affect users’ interests (eg changes in governance tokens distribution or protocol’s fees). This grace period gives members who voted No or didn’t vote the opportunity to redeem their assets before the execution of the proposal if they’re willing to do so.

It would be quite interesting to set up a framework to classify proposals’ impact on the protocol (simply, high/low impact). In this way, minor changes might have a faster consensus approach (e.g. 2 days for voting and 1 day as timelock) and the most important ones would continue with the current approach. This differentiation can even be applied to the minimum threshold and quorum for proposals.

What do you think? Any additional input on this would definitely help further discussions.

Off-chain Discussion and Consensus Formation

The governance process we’ve set up takes into account that a proposal often comes without any “ready-to-prod” code attached. If we look at the Smart Treasury, it took 6 Temperature Checks (Snapshot votes) to define community consensus on the proposal, pools’ weights, trading fees, grant applications, security review, and final Consensus Check (in approximately 2 months, considering holiday season and other development that were coming along at the same time). This is mainly due to the fact that this initiative’s parameters needed to be discussed with the community and it came without any code, so we had to go through the grant selection process, building phase, and security review.

As first improvement to this process, we have recently proposed to bypass the Consensus Check if the proposal has been widely discussed and accepted.

Furthermore, I think that the Pilot League (treasury committee) would be an initial way to speed up this process. As @idal said, multiple IIPs can be processed at the same time and having a PM that organizes discussions/grants/applications should quicken the implementation of a new proposal.

This Leagues structure can be improved further down the line with more departments that take care of a specific area of expertise (eg Development League, Treasury League, Communications League, …) effectively creating a more agile process that allows faster innovation and adequate due diligence process. We recognize that the majority of $IDLE participants might tend towards passivity over time and the Idle Governance architecture should allow for such reality as protocol improvements should be directed by a sufficiently decentralized community of competent professionals, but not necessarily all participants.

That said, DeFi governance space is still highly experimental, and the approach we’re taking is iterative. I think this discussion helps us to nail down where the bottlenecks are, and your feedback is definitely useful!

Where do you specifically see slowdowns in the “Off-chain Discussion and Consensus Formation” phase? Where do you guys feel it is unnecessarily bureaucratic (other than the final Consensus Check)?


Hi Matteo,

Thanks for the response and agree that the Treasury Committee / league will help to accelerate things.

Understand the logic on the time lock, and I guess this applies mostly where the voting is close (or not unanimously passed)

Perhaps a streamlined voting / time lock where the proposed action is unanimously passed or only minor amendments are proposed would be worthy of consideration.

I certainly agree that this shouldn’t be about rushing through change, more to streamline those decisions where it is a clear and unanimous decision or minor changes as you suggest.

Happy to hear other community voices on this.



I think time lock is needed even for unanimous votes, it’s common for holders to disagree by not voting rather than voting “nay”.

I can see how frequent small changes, like protocol parameter adjustments for current market conditions, can become annoying. Maker, for example, batches many of these into a single on-chain vote. Does not change latency, but improves throughput. Though I’d say let’s cross that bridge when we get to it.