Flawed AZ phase voting

The AZ funding process consists of 2 main subflows:

1. Creating a project
2. Creating a phase

  1. Creating a project

I wouldn’t change anything here since no funds are being released as a result.


  1. Creating a phase

Problem: The phase votes are counted too early, pillars don’t have time for opposition.

With 86 pillars, the quorum is now 30 votes, which is calculated as the total amount of yes + no + abstain.

For a phase to be funded, it needs to pass the following checks:

A. YES votes > NO votes
B. sum of YES + NO + ABSTAIN > quorum

This means that once a phase has 16 pillars supporting it, meaning 16 YES votes, there’s no real way for others to stop it.

If other pillars decide they don’t want to fund this phase, intuitively they’d vote NO or ABSTAIN, but not enough NO votes could be casted (17 NO votes) to surpass the 16 YES votes before the quorum (31 votes) is reached.

Therefore once the pillars opposing this phase start voting NO or ABSTAIN, once they reach 15 NO votes, the quorum is reached and the phase gets funded automatically, at which point the voting stops.


Solution: Count votes # days after phase is created

The best solution here is enforce a window of time before any phase can get funded regardless of the outcome, this way pillars have the change to oppose a phase by casting NO votes.

To sum it up, add condition C. to the ones above:

A. YES votes > NO votes
B. sum of YES + NO + ABSTAIN > quorum
C. phase created at least # days ago

The number of days should be enough for pillars to vote, but not so much that it would discourage spontaneity.

For simplicity, considering that the projects have a maximum of 2 weeks before they are considered expired if they don’t get enough votes, phases could get a minimum of 2 weeks before the votes are counted.

6 Likes

this is a good idea.

Maybe instead of having an expiration date, we can have a 1 week window after the quorum is reached so other pillars can vote/change their votes instead of instantly paying out.

Projects already have an expiration date.

The issue is with phases, which don’t have an expiration date and the proposed solution doesn’t add an expiration date, but rather a minimum time before the votes are counted.


Imagine that during a political election, the votes would be counted after each vote is casted and the same moment vote number 1 million is casted, whoever has more votes, wins.

That wouldn’t work, the votes are only counted at the end of the election.


That’s happening with phases right now, the votes are counted after each vote is casted by a pillar and once the 31st vote (quorum) is reached, the voting ends.

There should be a dedicated window for casting votes and the votes should only be counted after the voting window ends.

I was referring to the phases in my comment, having a 1-2 weeks window after the quorum is reached is better than a 2 weeks expiration date starting from the submission date, that way pillars and community will have enough time to discuss the delivered project without having a deadline. There was some projects where they had to resubmit because of the expiration date and start all over again.

Agreed.
Also how do we prevent pillars from voting yes just because others did ?

Technically this would more complex to implement compared to the proposed solution.

And the community would still have the chance to discuss during the 2 weeks. Pillars could also change their vote during that time.

The solution you’re proposing sounds like adding another voting window after the voting ends.

That accomplishes the same: giving pillars time to oppose a phase, but with extra steps.

Do we have a TG channel that shows every project and phase once proposed? If not it might be a good idea to set 1 up so all the Pillar owners can subscribe and vote pretty quickly. Or an email, just need a notification really.
I think this could really help our voting behavior be more efficient.

I support the new model you are suggesting here :+1:

The only way would be a secret vote.

1 Like

I’m not sure. But good idea, new projects/phases should be advertised on all main communication channels: TG, Discord, Twitter, Forum.

Adding a voting window after the quorum is reached, not after the voting ends. It doesn’t accomplish the same as what you proposed, maybe I didn’t explain it well, but having a 2 weeks window to vote (not reaching the quorum during this time means they need to resubmit and pillars need to vote again) is not the same as having the current implementation where there is no voting window but once quorum is reached we start the 1-2 weeks voting window ( that way we can be sure the proposal will get through and we don’t have to resubmit because of the lack of voting from lazy pillars).

We already have an A Z tracker on both tg and discord.

Tg : Telegram: Contact @az_tracker
Discord : Discord

1 Like

Ok, now I’m starting to understand.

That’s the way projects work: they get 2 weeks to pass + reach quorum, otherwise the project expires and they need to submit a new one.

After the project passes, they can submit phases.

So you’re saying the projects should have a minimum of 2 weeks instead of a maximum of 2 weeks?

Btw, @ZNNAYIID if you haven’t done so yet, it might be a good idea to get some tZNN from the testnet faucet and see how AZ works.

These need better exposure throughout the community.

1 Like

Very nice must have missed that.
I think a lot of the lazy pillars could benefit from being in this channel. :grin:

If we give a 1 week window after the quorum is reached it will be a minimum of 1 week, instead of having 2 weeks maximum, the reason for that again is what you said in your post, and also not making the pillars vote again if it doesn’t reach the quorum during the 2 weeks window you suggested because of 1 missing votes ( this already happened before).
No need for that I already know how A Z currently works.

Could you rephrase it in this format, please? It would make it easier for me to understand what changes you’re proposing.

For a phase to be funded, it needs to pass the following checks:
A. YES votes > NO votes
B. sum of YES + NO + ABSTAIN > quorum

To sum it up, add condition C. to the ones above:
C. phase created at least # days ago

Also, are you also proposing changes to the Project flow or just the Phase flow?

Awesome!

1 Like

A. YES votes > NO votes
B. sum of YES + NO + ABSTAIN > quorum
C. Phase reached quorum x days ago

Thanks, now I understand exactly what you mean.
It does sound like a great idea.

Let me think about what it would take to implement this.

1 Like

Topic moved to ╰ Funding | Staging