Adding A New Pool Via Governance Voting

[anilhelvaci]

Think

test-lendingPoolElectorate

• What test cases should there be?
• Should I write tests for voting and redeeming? In commitee.js only tests for addQuestion exist.

  lendingPoolElectionManager

• Should I test the voting and redeeming here?

• I will probably have to use offerTo helper method because methods in the electorateFacet can be invoked via offers. Is this too costly?

  The reason why methods in electorateFacet can only be invoked via Zoe offers is because Electorate needs some assets to be escrowed in order the perform appropriate actions.

quorumTreshold

• I want to use binaryVoteCounter.js contract for counting votes. However, we're required to do a token weighted voting. The current implementation of binaryVoteCounter contract expects a quorumTreshold to enforce the quorumRule. The problem is, in our case we don't know how many shares(tokens) will be used in voting. So if we wanted to do a MAJORITY voting we would need to know how many tokens are locked for the question to calculate required quorumTreshold for that particular question.

  Solution

  One possible solution would be to pass a promise in voteCounter terms as the quorumTreshold instead of a bigint and a reference to a method that lives under the ElectionManager called resolveTreshold. The body of this method;

   const resolveTreshold = async (questionHandle) => {
        const { questionSeat, tresholdPromiseKit } = getQuestion(questionHandle);
        const amountEscrowed = questionSeat.getAmountAllocated('GOV');
        const valueEscrowed = AmountMath.getValue(govBrand, amountEscrowed);
        tresholdPromiseKit.resolve(valueEscrowed);
   }

  We wrap the makeBinaryVoteCounter inside our own contract and implement a very similar scheduleClose method where it invokes above resolveTreshold before invoking closeVoting and quorumQounter awaits this promise to resolve before starting to count quorum.

[Chris-Hibbert]

using a Promise to convey the quorumThreshold violates the legibility requirements. Anyone who can see the questionDetails would be able to see the Promise, but they wouldn't be able to tell what it will resolve to. I thought #41 had a proposal to update the quorumThreshold dynamically in a way that would lead to legibility.

The rest of your sketch seems like the right direction.

[anilhelvaci]

I thought https://github.com/anilhelvaci/dapp-pool-lending-protocol/issues/41 had a proposal to update the quorumThreshold dynamically in a way that would lead to legibility.

I think you're talking about updateTotalSupply.

using a Promise to convey the quorumThreshold violates the legibility requirements. Anyone who can see the questionDetails would be able to see the Promise, but they wouldn't be able to tell what it will resolve to.

I see where you're coming from, this makes sense. Using a promiseKit to update the quorumThreshold was just a brain storm I did back when I first encountered this problem. The current design uses updateTotalSupply.