TFT based GEP voting with optional stash account

[LeeSmet]

In a current GEP, we will ask for agreement to move to TFT based voting on future GEP's. Essentially, everyone who has TFT on tfchain will be able to vote, and 1 TFT equals 1 vote. There will no longer be a threshold, and votes are decided based on simple majority.

To protect users funds, we also want to introduce the concept of a "stash" account which is essentially a cold wallet with some funds, and a controller account which will cast a vote, which then uses the combined value of the controller and associated stash when calculating the voting power.

The simplest way to accomplish this would probably be adding an extrinsic where the author of the extrinsic designates an optional controller account. If the value is not set, the controller is removed. If a value is set, the account is added to a mapping
of accounts which maps the controller to a list of stash accounts.

To avoid double voting, the voting power should be resolved when the vote closes.

[sameh-farouk]

There will no longer be a threshold, and votes are decided based on simple majority.

Are you certain about removing the threshold?
If one user votes 'yes' with say 1 TFT and no one else votes, would that mean GEP passes?

[sameh-farouk]

The simplest way to accomplish this would probably be adding an extrinsic where the author of the extrinsic designates an optional controller account. If the value is not set, the controller is removed. If a value is set, the account is added to a mapping
of accounts which maps the controller to a list of stash accounts.

We already support bonding a stash account, with bond_twin_account call within TGGridModule.
Is it a strict requirement to support more than one stash account per twin at this stage or we can use what we have already?

[renauter]

In a current GEP, we will ask for agreement to move to TFT based voting on future GEP's. Essentially, everyone who has TFT on tfchain will be able to vote, and 1 TFT equals 1 vote. There will no longer be a threshold, and votes are decided based on simple majority.

I am a bit confused since by including this token-based voting we give voting power to grid users and remove it from farmers:

• TFT are minted on Stellar and there is no "specific" interest for farmers to bridge them to TFChain
• who owns TFT on TFChain are usually users wanting to deploy on TFGrid

[renauter]

We already support bonding a stash account, with bond_twin_account call within TGGridModule.

Btw (a bit off topic but...) I just had a look to implementation of bond_twin_account and, if you have twin A and tin B, nothing prevents to bound account from twin A to twin B and also account from twin B to twin A. Not sure it is an expected case and should also be considered in this new feature to avoid double-voting.

[sameh-farouk]

Btw (a bit off topic but...) I just had a look to implementation of bond_twin_account and, if you have twin A and tin B, nothing prevents to bound account from twin A to twin B and also account from twin B to twin A. Not sure it is an expected case and should also be considered in this new feature to avoid double-voting.

Yes, this is a valid point, but can be easily approached by adding a check to verify whether any of the twin and its stash account have already voted. Additionally, we can prevent this within the bond call itself where it makes sense more.

[sameh-farouk]

TFT are minted on Stellar

I believe this is no longer relevant. Farmers now rewarded on tfchain based on utilization (on devnet) and I assume minting will be stopped on stellar as soon as this release reaches main net.

[renauter]

TFT are minted on Stellar

I believe this is no longer relevant. Farmers now rewarded on tfchain based on utilization (on devnet) and I assume minting will be stopped on stellar as soon as this release reaches main net.

Yes, aware of the farmer reward even if it will continue representing a small amount compared to already minted amount on stellar.
Was not aware of the minting on tfchain and with this information it now makes more sense to make this voting changes.

[renauter]

Yes, this is a valid point, but can be easily approached by adding a check to verify whether any of the twin and its stash account have already voted. Additionally, we can prevent this within the bond call itself where it makes sense more.

Of course, just wanted to leave a trace of this observation in the issue.

[LeeSmet]

There will no longer be a threshold, and votes are decided based on simple majority.

Are you certain about removing the threshold? If one user votes 'yes' with say 1 TFT and no one else votes, would that mean GEP passes?

Yes, I forgot to mention this but the GEP introduces a minimum time for votes of 5 days. This feels like sufficient time to ensure multiple people can take a look at it. In the future the tooling surrounding this should also improve, e.g. the app will allow voting and could potentially send a push notification if a new vote is added (push notification is just an idea, not a concrete thing that will happen atm).

For reference, the GEP: https://forum.threefold.io/t/tfchain-dao-gep-voting-process-update/4409

[LeeSmet]

The simplest way to accomplish this would probably be adding an extrinsic where the author of the extrinsic designates an optional controller account. If the value is not set, the controller is removed. If a value is set, the account is added to a mapping
of accounts which maps the controller to a list of stash accounts.

We already support bonding a stash account, with bond_twin_account call within TGGridModule. Is it a strict requirement to support more than one stash account per twin at this stage or we can use what we have already?

While supporting more than 1 account is somewhat of a niche case, one thing which should be considered is that in a 1 to 1 mapping, a rogue actor could create new (almost) empty accounts and bind those those to existing twins, thereby preventing those twins from adding their stash account or using their stash account. I'm not opposed to having a 1 to 1 mapping, but then there needs to be more security to ensure the twin actually wants the stash account as no other stash account can be controlled. In that sense, having a 1 to many mapping also would allow for some kind of "delegated" voting where a user can set up an account , add it as stash of another users twin, so he effectively delegates his voting power to said user.