The user must send a minimal amount of BTC from their PoX reward address to one of the following Bitcoin addresses...
However, more than 2/3 of the solo votes were sent from addresses that were not a pox reward address.
There are two likely reasons;
users were not solo stacking, did not understand the process and sent bitcoin transactions anyway.
users were solo stacking but misunderstood that they needed to send the transaction from the actual reward address.
Since different addresses within the same wallet cannot be cryptographically linked together the above options look almost identical to anyone counting the votes.
Pool stackers
For pool voting 2/3s of all vote transactions did not correlate to stacking data. In this case the addresses don't appear to be involved in stacking.
It's possible these issues were in play in the 2.1 SIP upgrade vote but have only been uncovered here because the voting and counting processes have changed.
Project management
A major improvement will be to assign a point person from within the Foundation team, with responsibilities that include;
overall delivery
raising and chasing issues
representing issues to the wider team
engaging external consultants (eg Ortege) in good time
organising reviews and testing
Communication
The project communications moved between different dm groups across discord and signal. Going forward, most communication should take place in the open on a public stacks Discord server channel with internal team communications in single Signal channel.
Planning
The project was stop start for a couple of months - the initial suggestion was to prepare the platform for voting starting December '23. The start date was moved three times and a decision taken to rebrand / redesign the platform was taken during this process, leading to some confusion and stress.
Two important factors for planning the sBTC SIP vote;
dealing with the methodology questions
determining if voting will be over pox-4 or pox-3 stacking cycles.
Results
Several factors led to a difficult counting process for solo and pool stacker votes.
complexity of the pox-3 data
the zero vote problem
unavailability of core devs (due to delivery of Nakamoto)
The zero vote problem was known early on in the voting phase but we waited till after voting had closed to engage an external partner with whom the votes could be verified. Time zone differences were also a factor here. A plan for verifying the count needs to be in place in advance of the start of voting.
Budget
The project needs a small budget to cover;
design/ui/ux
server and contract deployment (~$800)
overtime
Design was covered by small grants. This was extremely helpful/vital but had the downside that it was difficult to plan as it introduces time delays during the grant approval process and uncertainty later in the project around whether anything more could be asked.
Other costs like overtime and fixed infrastructure have been covered as part of development but need to be discussed before the next vote takes place.
Nakamoto SIP Voting
Two key areas for improvement; methodology and project management.
Methodology
Following issues need to be resolved before future votes take place.
Solo Stackers
Some difficulties have been unearthed in the underlying methodology.
According to SIP 21;
However, more than 2/3 of the solo votes were sent from addresses that were not a pox reward address.
There are two likely reasons;
Since different addresses within the same wallet cannot be cryptographically linked together the above options look almost identical to anyone counting the votes.
Pool stackers
For pool voting 2/3s of all vote transactions did not correlate to stacking data. In this case the addresses don't appear to be involved in stacking.
It's possible these issues were in play in the 2.1 SIP upgrade vote but have only been uncovered here because the voting and counting processes have changed.
Project management
A major improvement will be to assign a point person from within the Foundation team, with responsibilities that include;
Communication
The project communications moved between different dm groups across discord and signal. Going forward, most communication should take place in the open on a public stacks Discord server channel with internal team communications in single Signal channel.
Planning
The project was stop start for a couple of months - the initial suggestion was to prepare the platform for voting starting December '23. The start date was moved three times and a decision taken to rebrand / redesign the platform was taken during this process, leading to some confusion and stress.
Two important factors for planning the sBTC SIP vote;
Results
Several factors led to a difficult counting process for solo and pool stacker votes.
The zero vote problem was known early on in the voting phase but we waited till after voting had closed to engage an external partner with whom the votes could be verified. Time zone differences were also a factor here. A plan for verifying the count needs to be in place in advance of the start of voting.
Budget
The project needs a small budget to cover;
Design was covered by small grants. This was extremely helpful/vital but had the downside that it was difficult to plan as it introduces time delays during the grant approval process and uncertainty later in the project around whether anything more could be asked.
Other costs like overtime and fixed infrastructure have been covered as part of development but need to be discussed before the next vote takes place.