Chris-Hibbert
commented
3 years ago @JimLarson added a write-up of the cosmos level design, which reminds me that I only talked about how vote counters should be isolated, and not about the Javascript layer that communicates to cosmos.
Currently this is provided by the Attestation contract, but that contract assumes that the share weights are static, and can be locked down for the duration of voting. Since that won't be the case going forward, we'll want to replace Attestation (for voting, line of credit can continue to use the same attestations) with something that gives the vote counters a persistent representation of their staking authority which another layer (the registrar) would be in a position to dynamically translate into voting weight at the time the vote counting should take place
dckc
To drive the discussion and design for representing how token ownership impacts voting,
We're planning a change to the API for communicating token holdings between the cosmos/Go layer and Javascript. The previous approached had a static representation of voting power in the Attestation contract. The representation needs to be more dynamic to represent cosmos delegation and validation. (because redelegation, slashing, and undelegation muddle the state of who voted for what if we try to base it on a single snapshot.)
Some scenarios we want to handle:
The current somewhat vague theory is that vote counters will continue to know how to count ballots with arbitrary weights for binary or multi-outcome questions, with varying weights by voter or one ballot-one vote, for plurality rules, or parliamentary votes, or instant runoff, or single-transferable vote.
In order to make this orthogonal to the representation of the weight of each ballot, and allow the weight to change up to the time of counting, the vote counters need to make an explicit call to the registrar/electorate to get the weights. In some of the cases above, this can be returned immediately by the registrar, but other cases require e.g. an expensive call to cosmos to compute.
The API from vote counter to registrar should be clarified, and necessary helpers provided, rather than building it as each case comes up for a particular application.