Use MiniMe token instead of ERC20 token #170

Closed
opened 2019-08-26 16:12:31 +00:00 by haythem96 · 4 comments
haythem96 commented 2019-08-26 16:12:31 +00:00 (Migrated from github.com)

The MiniMe token is a cloneable ERC20 token, It is designed to easily spawn tokens that have the same balance distribution as the parent token at any given block number. This gives any developer the ability to give extra functionality to token holders while leaving the original token unaffected.

More details: https://medium.com/giveth/the-minime-token-open-sourced-by-giveth-2710c0210787

The MiniMe token is a cloneable ERC20 token, It is designed to easily spawn tokens that have the same balance distribution as the parent token at any given block number. This gives any developer the ability to give extra functionality to token holders while leaving the original token unaffected. More details: https://medium.com/giveth/the-minime-token-open-sourced-by-giveth-2710c0210787
bumi commented 2020-01-16 17:47:07 +00:00 (Migrated from github.com)

Can you document some of the advantage here on which we then can decide if/how/when to do this.

Can you document some of the advantage here on which we then can decide if/how/when to do this.
haythem96 commented 2020-01-18 14:45:14 +00:00 (Migrated from github.com)

The MiniMe Token is created by the Giveth team that maintains a history of balances and is easily cloned to create independent tokens with unique functionality.

Advantages:

MiniMe is an ERC20 compatible token implementation, that allows querying token balances of holders at any block height (as the vanilla ERC20 specification only provides the current balance). MiniMe tokens allow for a fairly simple solution to the double voting problem, a problem which can be exploited by an account voting with their tokens, then transferring them to another account and then voting again with this different account. If using a MiniMe token, when a vote is created, a past block number is selected as the snapshot block for the vote. When someone votes, their balance is checked at the snapshot block number, and because the same token can't be in two accounts at the same time at the end of a block, the double voting problem is prevented.

Downsides:

MiniMe transfers are costly (transfers are at least 50k gas more expensive): every transfer needs to add a checkpoint to both accounts involved in the transfer. This results in at least one fresh SSTORE (for a non-zero slot) and modifying the checkpoints array length (1 SSTORE with a 15k refund if it is not the first transfer) per account. Balance checks are also more expensive, the best case (checking the current balance) resulting in at least two additional SLOAD.

[The MiniMe Token](https://github.com/Giveth/minime) is created by the Giveth team that maintains a history of balances and is easily cloned to create independent tokens with unique functionality. **Advantages:** MiniMe is an ERC20 compatible token implementation, that allows querying token balances of holders at any block height (as the vanilla ERC20 specification only provides the current balance). MiniMe tokens allow for a fairly simple solution to the double voting problem, a problem which can be exploited by an account voting with their tokens, then transferring them to another account and then voting again with this different account. If using a MiniMe token, when a vote is created, a past block number is selected as the snapshot block for the vote. When someone votes, their balance is checked at the snapshot block number, and because the same token can't be in two accounts at the same time at the end of a block, the double voting problem is prevented. **Downsides:** MiniMe transfers are costly (transfers are at least 50k gas more expensive): every transfer needs to add a checkpoint to both accounts involved in the transfer. This results in at least one fresh SSTORE (for a non-zero slot) and modifying the checkpoints array length (1 SSTORE with a 15k refund if it is not the first transfer) per account. Balance checks are also more expensive, the best case (checking the current balance) resulting in at least two additional SLOAD.
raucao commented 2020-01-20 16:01:22 +00:00 (Migrated from github.com)

Interesting solution!

However, we do not plan on voting using the ERC20 tokens, but only the ERC271 tokens, which cannot be transferred between accounts. Our contribution tokens are always tied to a contributor profile.

So it would seem to me that the costly transfers are not worth the benefit in this case.

Interesting solution! However, we do not plan on voting using the ERC20 tokens, but only the ERC271 tokens, which cannot be transferred between accounts. Our contribution tokens are always tied to a contributor profile. So it would seem to me that the costly transfers are not worth the benefit in this case.
raucao commented 2020-05-29 08:08:57 +00:00 (Migrated from github.com)

Closing due to inactivity. Feel free to re-open.

Closing due to inactivity. Feel free to re-open.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kredits/contracts#170