CCIP - On-chain Stacked Token Vote
Closed this issue · 1 comments
In light of the proposed changes in #3, we discussed having this governance
repository as the official off-chain resource to track protocol changes, and also want to implement an on-chain vote that correlates to the changes being described in the related CCIPs.
The structure below is inspired by SIP-012, used by the Stacks Blockchain to vote on the release of stacks-node 2.0.5
.
https://sip012.xyz/
https://github.com/stacksgov/sips/blob/main/sips/sip-012/sip-012-cost-limits-network-upgrade.md
The voting contract should include:
- store basic data about the proposal(s)
- store the relevant git commit hash for proposal(s)
- the starting Stacks block height for a vote
- the duration of the vote in Stacks blocks
- a map of addresses and their vote data
- address, vote, total MIA, total NYC, total vote
- a map of aggregated vote data
- number of votes yes/no, total MIA yes/no, total NYC yes/no, total votes yes/no
- read-only functions to return all data
The voting contract should enforce:
- any address with stacked MIA/NYC in the selected cycles can vote
- MIA will be counted from cycles 12 and 13
- NYC will be counted from cycles 6 and 7
- any address cannot withdraw their vote, but can reverse it
- any address cannot vote more than once
The voting contract should calculate:
At the time of writing this issue, the total supply of MIA is 4,365,050,000
and the total supply of NYC is 3,065,650,000
. Given the difference in supply, there would be a larger number of MIA votes available compared to NYC votes.
In order to normalize the difference here and make it closer to 1 MIA vote = 1 NYC vote a scaling factor should be applied to MIA.
The proposed formula for calculating the votes is below using the average amount stacked by an address across two cycles, with a scaling factor applied to MIA based on the total supply of NYC/MIA.
MIA Vote:
((MIA Cycle 12 + MIA Cycle 13) / 2) * (Total Supply NYC / Total Supply MIA)
NYC Vote:
(NYC Cycle 6 + NYC Cycle 7) / 2
Total Vote: MIA Vote + NYC Vote
Hi! I'm currently writing a Clarity smart contract for voting. The plan is for it to be simple, like Snapshot w/ only "Single Choice Voting."
With that said, I am investing in a nice UI, and I'm very open minded to it being extensible. I'm also building off of Marvin's Executor DAO.
If that sounds at all interesting, I'd be happy to chat more. Maybe there's the possibility we could collaborate, or that I could invest in designing a system that could also work for CityCoins.