You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 1, 2026. It is now read-only.
It is possible to imagine that some use cases of PLCRVoting need access to the number of tokens associated with the losing option. For example, a TCR implementation may have an entity that is able to overturn the result of a challenge (we do this at Civil in our TCR implementation: https://github.com/joincivil/Civil/blob/master/packages/contracts/contracts/tcr/CivilTCR.sol). In order to properly dispense tokens to voters, the TCR contract needs access to both the total number of tokens associated with the losing option, and the number of tokens for a voter of the losing option.
It is possible to imagine that some use cases of PLCRVoting need access to the number of tokens associated with the losing option. For example, a TCR implementation may have an entity that is able to overturn the result of a challenge (we do this at Civil in our TCR implementation: https://github.com/joincivil/Civil/blob/master/packages/contracts/contracts/tcr/CivilTCR.sol). In order to properly dispense tokens to voters, the TCR contract needs access to both the total number of tokens associated with the losing option, and the number of tokens for a voter of the losing option.
I propose to add the following two functions:
and