Choose Snapshot Attributes

[moul]

Should we use the block at the end of the vote based on date 18010654? Or should we consider an alternative? Can someone double-check if I have selected the correct block?

Once we confirm the correct block, I can help create a snapshot with all the metadata. We can process this snapshot later when we finalize the rules.

[giunatale]

I think the right block is either 18010660 (where the tallying is completed, you can see it because of the delay with the previous block is over 2 minutes instead of the usual 6 seconds) or block 18010659 which is where the tallying is triggered. The proposal was scheduled to end at 21:00:28-ish UTC which funnily enough concides with the time of block 18010658, so that's why it happens one block later.

But, tbh I am advocating for checking also other proposals and not just prop 848 (e.g. prop 69, 82)

[giunatale]

So for proposal 82, if we also want to snapshot the data for that one, it would be either block 12842181 - where the tally is triggered - or 12842182 - when the tally is finalized, following the same reasoning.

Just wanted to leave this here in case needed / helpful.

[albttx]

I can manage to setup a node with a snapshots at this block :)

[discoverdefiteam]

@giunatale hi! seems the snapshot should refer to when the tally was triggered, if it is true that vote decisions couldn't have been altered from the time the tally was triggered to the time it was finalized, therefore block 18010659

This should also apply to prop 82 if decided to be included in gauging AtomOne genesis distribution, meaning block 12842181. I want to provide my suggestion to this point specifically, will direct that comment to the proper issue thread.

[giunatale]

Yeah you can see also that votes in both blocks that are for the respective proposal fail because "proposal is inactive", therefore I agree that those blocks are sufficient.

[moul]

@albttx, yes please 👍

[albttx]

Some validators and addresses decided to do a Weighted Vote

How should we count them ? Pro-rata of the no vote or slashed ?

[moul]

The snapshot should reflect the reality with raw data, so we can decide this later.

My current opinion:

• Initially, let's involve only those who are pure/true NOers (NO + NoWithVeto).
• Then, we can let this NOers community decide if they wish to invite completely, partially, or not at all the weighted opinions.

[tbruyelle]

Some validators and addresses decided to do a Weighted Vote

How should we count them ? Pro-rata of the no vote or slashed ?

I just posted this question here #12 (comment)

Also, I wanted to bring this up, and I assume you guys are aware of this; votes are removed from the store during the tally execution.
This means that we need to take the block just before the tally to be able to iterate over the votes. In that case, we might miss the votes that were broadcasted in the same block as the tally execution, but I don't think we can mitigate that.

[giunatale]

the blocks we decided to use are just before the tally, but after voting period has ended. If you see votes coming at that block fail as I have written before.

So blocks 18..59 and 12...81 as written above

[giunatale]

• Initially, let's involve only those who are pure/true NOers (NO + NoWithVeto).

I think weighted vote are to be considered "pure" on the percentage that is assigned to NO/NWV. Don't really understand this assertion.

If they vote 30% no and 10% NWV, the stake counted is 30% and 10% respectively of the total. I don't see this as a technical challenge tbh

[amritkumarj]

Hey guys, I wanted to contribute so wrote some go code that anyone can run to create and verify the snapshots!

Please check - https://github.com/blockdudes/atomone-vote-snapshots