Ecosystem DAO and Community Voting on Stacks 2.1 Upgrade

Community
#1

Proposal

We’d like to propose using the Ecosystem DAO as a platform to conduct a vote on activation of the upcoming Stacks 2.1 Upgrade.

There are a few issues and decisions to make in putting this forward which we’d like to resolve with help from the community.

Stacking Based Voting

Previous votes (e.g. the 2.05 upgrade) were carried out based on the average amount of STX that a user had stacked over the 2 previous POX reward cycles at the the time of voting. The motivations for this as a voting mechanism are;

  1. Stackers clearly have a stake in the Stacks Network
  2. Decreases the degree by which whales and exchanges could influence voting - because they require STX liquidity - and its not clear their vested interests align with those of the network.
  3. The mechanism for counting votes was tightly coupled to the Stacking protocol itself.

The voting took place through sending dust bitcoin transactions to one of two addresses - one representing a yes vote and the other a no vote. Voting power was proportional to the amount stacked. Voting required a degree of technical knowledge to be able to take part.

Ecosystem DAO Voting

The main motivation for wanting to switch voting mechanism to Ecosystem DAO is to increase the participation and turnout for the proposal by simplifying the voting mechanism. Ecosystem DAO will achieve this by enabling users to vote using their Web Wallet via a simple client application.

However there are a few considerations. Two voting mechanisms Ecosystem DAO can readily support are;

A: Snapshot STX Voting

Votes are broadcast using the web wallet to a contract via the Ecosystem DAO user interface. The user enters the voting power they wish to vote with - up to the balance of the account they are using at the time the proposal was submitted.

B. Snapshot Stacked STX Voting

The only difference with the above is that the amount is the amount of STX the user has stacked in the current reward cycle (as opposed to their STX balance). With this voting method we run into the problem of desktop wallets.

Many people stack with a desktop wallet. At time of writing, Stacks desktop wallets cannot make contract calls / broadcast transactions. This is a problem for Ecosystem DAO, or any voting mechanism based on voting via smart contract. To get around this problem we could encourage voters to start stacking from web wallet account (at least one of the stacking pools supports this with a minimum stake of 200 STX). However, this feels like an artificial solution to the problem.

We also consider the ability to connect a Ledger wallet to the Hiro Web Wallet as a favourable condition for choosing a stacking based voting mechanism. But in the absence of evidence to support use of ledger wallets in stacking and combined with the additional technical barrier this introduces, remain inclined to favour plain STX snapshot voting.

Snapshot vs Stacked Voting

Some ways to strengthen regular snapshot voting and guard against disproportionate voting power of whales and exchanges;

  1. Upper cap on voting power per address
  2. Using voter balance over longer time periods

People can of course set up multiple accounts and distribute STX to those account but an upper cap on voting power would introduce drag and cost time both in scripting a workaround and maintaining their fragmented balance. We can also use balance at-block height to make this impossible in the context of the 2.1 vote.

Other mechanisms e.g. which flatten voting power - e.g. taking the Log (base 2) of the voting amount don’t work as they worsen the same attack. People spreading their voting capacity over a number of accounts actually increase their voting power.

Desktop Wallet Support - another suggestion would be to add support, in the Desktop Wallet, for voting either as a one off, specifically on the 2.1 upgrade, or generic support for signing SIP-018 messages. Ecosystem DAO is able to support off-chain voting via signed structured messages and this technique could be used with either plain STX snapshot or stacking based voting.

Recommendations

The desktop wallet problem makes it hard to see that many stackers won’t be actually excluded from voting simply because they don’t want to / haven’t been stacking with a web wallet and this feels unjustifiable.

For this reason, and assuming we are not able to come up with a fix for the desktop wallet problem, then we recommend A: Snapshot STX Voting (assuming the community decides to use Ecosystem DAO). That is a voting mechanism based on the voters STX balance at some block height. Whether or not the voting power should be capped and the block height set to some point in the past to avoid the account splitting problem is an open question.

We’d love hear feedback, alternative suggestions and any other views on this topic. You can also contact us in the #ClarityLab channel on Stacks Server.

3 Likes
#2

Hey Mike, thanks for writing this up! Just had a couple questions:

I’d love to hear more about this, because the SIP-012 voting procedure was designed to meet users where they were. If you were a Stacker and were able to send BTC in any way, shape, or form from your PoX address, then you were able to vote via any BTC wallet you wanted. They didn’t have to use one of the wallets Hiro or Xverse designed; they could even use an exchange account if that’s what they used for PoX. Are there users out there who met these criteria, but who didn’t feel like they knew how to send BTC to one of two designated addresses? Asking because we were planning for this option to be available as one of a few ways of voting for in SIP-015.

People can of course set up multiple accounts and distribute STX to those account but an upper cap on voting power would introduce drag and cost time both in scripting a workaround and maintaining their fragmented balance. We can also use balance at-block height to make this impossible in the context of the 2.1 vote.

Right; if we took this approach, we’d want to use a block height that occurred before this proposal went live. It’s not very hard, nor very expensive to spread your STX around, especially with something like send-many. We should assume that for someone who’s interested in screwing this up, it will be trivial for them to do so.

2 Likes
#3

This was based on anecdotal evidence - some conversations and on the turnout for SIP-012. Enabling users to vote on SIP-015 via the web wallet could make it easier to engage. If so, the question is whether snapshot voting based on STX balance at some block height is fairest way to go?

1 Like
#4

Update: Following some discussion on using EcosystemDAO (stx.eco) for voting on sip activation criteria we’re adding the ability to handle super majority voting.

The DAO currently runs votes as permissioned majority where anything over 50% of the votes being for carries the proposal. With this change we’ll be able to set the majority required when the proposal is submitted to the DAO. This’ll be an optional parameter with no value falling back to current behaviour and anything over 50% will be the the threshold required for the vote to pass.

The Clarity code for this is in the EcosystemDAO Github on branch feat/dynamic-majority

1 Like
#5

Definitely support this additional functionality!
As a Bitcoiner, seeing high bar for consensus gives more assurance about this blockchain system vs others.

1 Like
#6

Is it possible to have tiered thresholds? Some small changes can be appropriate to only have 50%, but i feel like other proposals that have wider impacts should potentially have 66% or more thresholds to ensure broad consensus vs a scenario that may encourage a divided community.

Since ledger support in the web wallet is available now this seems like a great idea overall.

1 Like
#7

Hi thanks - yes this is something we are working on. A proposal which requires high level of support can have the threshold set higher than 50% - say 66% (so the vote is carried if more than 66% of the votes are for) whereas another proposal could leave the threshold at 50%.

2 Likes