What parameters should be passed between the Round Contract and Voting Contract?

[nfrgosselin]

The initial structure of the protocol created a function called vote that would pass vote data from the round contract to the voting contract. @hmrtn suggested additional parameters that we are discussing here

[nfrgosselin]

Capturing a discussion from Discord:

@hmrtn:
Yes, I mentioned the "Strategy" Interface method signatures should be something like

function vote(bytes[] calldata _encodedVotes, address _voterAddress) external;
function tally() external returns(uint256[](?) memory);

and maybe
function reward(...)? external;

The parameters for these are still being worked on though
The voting strategy contract would implement this interface.
vote is for capturing and storing votes. The parameter _encodedVotes could be an an array of abi-encoded tuples of the grant identifier and the senders vote amount i.e. (bytes id, uint256 vote)[].

tally is for counting votes. I believe it should be a part of the interface because it offers flexibility for adding middleware (e.g. calculating a distribution, etc) from the raw votes. Acts as sort of an optional pre-processing step for the fund rewarding.

reward This one is sort of up in the air, I think, and largely depends on the Funding contract implementation and what contract should be responsible for what. Reward would accept a tally, or distribution of the votes, and then rewards calls the Funding.reward method.

@thelostone-mc:
So in my head tally as something that could be computed off chain via the events fired. Like for example in QF having tally within the contract wouldn't make much sense

reward is essentially sending out the funds. This i've not thought about if the voting contract should also perform the payment being sent out.
We'd need to prep the pros / cons on this to see if

• this should be same as voting / new contract
• should we involve a claim process etc etc

My question here is given we are making our voting super generic -> should the interface even define the tally / reward function ?
we could just let it up to the voting strategy implementation to choose if they want to implement it / not

(But i do see the benefit of what you're saying @hmrtn -> maybe we set the method and then strategy can choose not to implement it if it doesn't require it . Is that what you were thinking ? )

@nfrgosselin:
Talking through this, I do like the idea of tally as a way for the voting strategy contract to provide a "final result" that's recorded via an event on the round contract. So via the round contract you would be able to see:

1. all of the votes
2. the final result of the voting calculation
   ☝️ I think that idea of tally also makes the interface a bit more friendly to things like direct grant programs, as it allows them to record a final on-chain "decision" for how they allocated the funds.

Although I would like to find a more generic term for that — maybe something like finalResult?
re: reward —> I think we should keep the voting contract separate from the payout contract in the spirit of modularity. We want round operators to be able to make decision about how to pay out independently of how they want to allocate the funds

[hmrtn]

@thelostone-mc

So in my head tally as something that could be computed off chain via the events fired. Like for example in QF having tally within the contract wouldn't make much sense

(But i do see the benefit of what you're saying @hmrtn -> maybe we set the method and then strategy can choose not to implement it if it doesn't require it . Is that what you were thinking ? )

Depending on the flavor of quadratic voting, it may make sense. If the user does wish to have a voting strategy that is to calculate distributions, etc, on-chain, tally could prove very helpful! But yeah - I'd imagine some situations tally would not be useful for calculations, but the very least it can mark the end of voting!

[thelostone-mc]

@hmrtn Hmm i see what you are getting at !
But the end of voting is already controlled with the round where it has the start and end date. So that information is already present

I'm good with having tally for now and we evaluate reward and add it later!
Does that align with your thoughts here ?

[thelostone-mc]

TLDR: A tally function would be added to voting interface and it's upto the team adding the new voting strategy to implement it

[hmrtn]

As discussed on call, we've decided to opt for utilizing subgraph and voting events to keep a running tally of the votes as opposed to implementing a tally() method.
This effectively changes the distribution calculation to happen off-chain.