Question in detail:

Let's explore movement of delegation on Cosmos.

When delegators un-stake from one validator and move to another, is there any pattern to where they re-stake? Are users more likely to re-delegate after their validator votes in a way they disagree with? Do they re-align their stake with validators whose values reflect their own?

How do validator votes change over the course of a proposal? Share any interesting voting statistics you find.

Examine any voting propositions here (example: Prop 82) as a use case to explore these questions.

Cosmos Hub:

Cosmos is a collection of parallel and independent blockchains that can communicate with each other. Cosmos was launched with the aim of increasing scalability and the ability to establish communication between different networks. Currently, the Cosmos ecosystem is a collection of 46 different blockchains that can communicate with each other using the communication protocol developed by this collection. Cosmos ecosystem is a collection of blockchains, which is Cosmos Hub, the first and so far the most important network of this collection, the native digital currency of this network is called Atom (ATOM). In the considered architecture of Cosmos, there are independent and parallel networks that are managed by Tendermint BFT resilient consensus algorithm. Each of these networks is called a zone. On the other hand, there are a number of connection points or hubs that can enable communication between these networks through a communication protocol called IBC. Also, blockchain technical development is easily possible by the innovative framework of this collection called Cosmos-SDK.

There is onchain a module for managing offers. Each offer has an opportunity at the beginning called the deposit period; During this period - which will last up to 14 days - the proposer or other supporters must prepare and deposit a total of 64 atoms. If this amount is deposited before 14 days, this period will be completed, otherwise, if this amount is not provided after 14 days, the provided amounts will be burned. Then we enter the voting period, which has been defined for 14 days. If more than one third of the voters choose the last option (not with the veto), the deposit of the bidders will be confiscated and burned. Also, if the voting does not reach the quorum (40% of all staked atoms), the 64-atom bond will still be burned.

If the voting reaches the quorum of 40%, more than 50% vote for the yes option and the number of "no with veto" voters is less than one third, the proposal will be approved. The voting weight depends on the amount of address stack at the end of the 14-day voting period and is calculated proportionally to the total amount of staked atoms.

Method and roadmap of this analysis:

The data provided by Flipside has been used to handle this analysis. To handle this investigation first of all identified the steps of analysis as below:

• Step 1: The voting performance on proposal no.82
  • Table→ from cosmos.core.fact_msg_attributes where MSG_TYPE ilike '%proposal_vote%'
  • Metrics→ Voter type (Validator or regular voters)
• Step 2: Find out the voters changed their voting option by various voter type (Validator or regular voters)
  • Metrics→ Switch vote pattern by voters, switching vote over time
  • Validator vote change pattern
• Step 3: Re-delegation activity
  • Metrics→ Count and volume of re-delegation by various voter types of proposal no.82
  • Determine the re-delegation path by (Source Validator→ Destination Validator)
• Step 4: By aggregating the outcomes of the steps and deep dive into the proposal, draw a conclusion about the re-delegation of users based on the re-delegation path and compare it with the vote change of validators to find out the relation between re-delegation pattern and voting performance of Validators.

The outcomes of each step have been drawn in the following part of this investigation.

First step:

The case study of proposal #82 has been selected to find out the re-delegation pattern on Validators by voters of this proposal. First of all estimate the voting performance by regular voters and Validators and the outcomes are:

• The Validators voted on proposal #82 are 205 unique Validators.
• The option NO WITH VETO has been captured the largest count of votes since November 6.
• The vote share for Validators and regular voters reveals that the Validators has voted on No With Veto option more than regular users.

Second step:

The second step has been used to identify the pattern of vote change by Validators and regular voters:

• As can be seen most of the voters change their vote option from YES to No With Veto option.
• The share of voters change their voting option for Validators is more than regular users.
• Most of the Validators changed their voting option from YES to No With Veto and lets find out the re-delegation pattern and see were these Validators obtain more or less share then others.

Final step:

Finally got the point and voting behavior of regular voters and Validators. Aa well as, the vote change pattern of Validators has been determined. Now lets see how users re-delegate to or from these Validators and draw a conclusion:

• From the result related to the most popular re-delegation path it can be seen that the most popular destination Validator is Imperator.co and lets find out the vote change pattern of this Validator.
• It can be be seen that the Imperator.co Validator has been changed its vote from YES to No With Veto option during voting period of Proposal #82 and according to this option change has been selected by users as a destination Validator of re-delegation.
• It can be concluded that the voters change their delegated ATOM from validators voted on YES to Validators voted on No With Veto or change their voting option to No With Veto.

Useful links:

• Cosmos Hub
• Cosmos governance
• Proposal no. 82

Author:

Credited by MZG

Discord handle: m.zamani#0361

Twitter handle: @GargariZamani