How to solve the rounding error issue in the cart & donation history page in MACI

[bhargavaparoksham]

Current Implementation:

Current Steps:

1. User donates 0.1 ETH. This will give them ( 0.1 * 10^5 ) 10,000 voice credits. Note that voice credits currently are not shown to user.
2. User allocates % of their donation to different projects.
3. So if a project A gets 30% allocation => they get 3000 voice credits (VCs).
4. This then is converted to Votes or voteWeights which is sqrt(VC) because of QF.
5. Votes for project A is sqrt(3000) = 54.7722557505. But because contracts only handle BigInts this gets rounded to 54.
6. This vote is then encrypted & posted to the maci polling contract.
7. When we pull this message again & decrypt it in the frontend. We have 54 Votes => 2,916 VCs => 29% allocation.
8. This is how 30% is becoming 29% and so on in the current implementation which can cause confusion both for the user and then also affect the calc if the user wants to update their allocation.

Solution:

We completely reverse how we do things so that user gets more control.

1. Instead of percentages give user the option to directly allocate Votes (V) i.e Vote Weights
2. To allocate 1 Vote (V) the user need to spend V^2 of their allocated voice credits i.e VCs spent = V^2
3. In the cart page show the total Voice Credits (VCs) & VCs balance.

In this implementation the flow will be:

1. User chooses to donate 0.1 ETH
2. They get 10000 VCs which they can use, which is clearly show in the cart page.
3. If user assigns

• 50 Votes to Project A
• 80 Votes to Project B

4. Then total VCs spent = 50 * 50 + 80 * 80 = 8900.
5. VCs balance of the user = 10000 - 8900 = 1100
6. Now as the user can clearly see they still have 1100 VCs left, they can allocate it to other projects to utilise full credits.
7. If the user allocates 30 more Votes to Project C, 10 Votes to Project D & 10 Votes to Project E. All their VCs are used. This way we won't have any rounding error because VCs for each project is a perfect square of Votes.
8. If the user doesn't allocate all the VCs then we can easily communicate that only part of their allocation goes to projects & the rest goes to matching pool.
9. If the user tries to allocate more than 100 Votes in the above case it should error out showing, not enough VCs, because eg: 110 Votes require 12100 voice credits.
10. If the user allocates 0.12 ETH then they'll get 12000 VCs. In this case the max votes they can allocate will be a non integer as sqrt(12000) = 109.54. We might need to round it off to the nearest lower integer, so the Votes the user can allocate will be 109.

The main advantage to this solution is rather than VCs getting wasted in rounding, the user gets full control of how they want to allocate it to projects. This also incentivises users to allocate to more projects.

References:

1. https://maci.pse.dev/docs/core-concepts/poll-types

[codenamejason]

@nijoe1 this is what we talked about the other day and how we did it in Impact Stream app here => https://github.com/0xPrimordia/impact-stream-app

We displayed the VC's to the user and for each vote they would deplete based on the QF calculation.

Here is the app https://app.impact.stream/

[nijoe1]

@codenamejason

That workflow was tricky to grasp at first because it used a reverse logic.

Now I can see!