Yes, users will need to do something to receive tokens. Because at the end of the day, they will pay maintenance for the space these tokens take. It would be wrong to allow anyone to burden you with such maintenance without your consent. On the other hand, it makes the fat finger problem less likely. Useless airdrops will not be possible. Tokens organised in such way will have better legal standing (this is my speculation)
EDIT: on the legal standing - in real world, you normally have an option to refuse unwanted gifts. And sometimes, it protects you from liability
That's where I disagree. I think the token contract creator should pay for maintaining all token balances of his contract.. If it's a valuable token people will come together and crowdfund the maintainance of the token contract. To prevent extreme splitting/dust attacks.. well.. give the token less decimals or just implement a min-value you have to send.
What I see in this document is a clear case of over-engeneering IMO. Keep it simple/clean.
Thanks for the comment! I shall explore this more in the next version of the document. It actually mentions what you are suggesting, on the page 23 under "alternative point of view". Obviously, the greater is the min-value, the smaller is griefing factor. But the greater is the min-value, the smaller is number of owners who can potentially hold the token. Will try to put some numbers behind this - to make is more visible why I think it is a genuine problem and cannot be waived away by saying "less decimal points and min-value".
Regarding the crowd-sourcing the rent, this is another unknown. As I described in the document, the problem here is free riding. The smaller holder won't contribute, because they will hope that the larger holders would. And larger holders might find it expensive, unless they hold supermajority of tokens.
Non-Fungible tokens and similar assets also need special treatment - though they are taken care of in the document by the cross-contract storage.
Therefore, I disagree about the over-engineering - it solves lots of problems with one new primitive. I would say - make it as simple as possible, but not simpler.
How about the following dynamic (all solvable on contract level [best practices will emerge]):
Token contracts can migrate to new contracts with more digits or smaller min values once they become popular and increase in value. More users & more value means more interest from more parties in keeping the token contract alive. So the contract can afford a higher rent. Before seeing their tokens value disappear a substancial amount of token whales will always either vote the min-values up or pay for the rent from their own money (better lose some than all). I think it's ok for small holders to free-ride a bit here.
Also a best practice that could emerge is that using these tokens will force holders to pay a certain fee (either by inflation or a portion of their holdings "melts away"). This fee is used in an auction contract to buy ETH on the market which gets automatically sent to pay for the token contracts rent.
There are many scenarios possible.. My argument would be that it should be handled on the contract/application level.
> Regarding the crowd-sourcing the rent, this is another unknown. As I described in the document, the problem here is free riding. The smaller holder won't contribute, because they will hope that the larger holders would. And larger holders might find it expensive, unless they hold supermajority of tokens.
In this example the contract dies.. and that's ok.. the contracts that handle it better will stay and over a long time only well managed contracts will survive.
Another point: Storage cost should be low enough (especially with state sharding) that a simple token contract with millions of balances shouldn't cost more than a couple $/year. So yes.. whales will say "so what" and just pay the bill and that's ok.
> There are many scenarios possible.. My argument would be that it should be handled on the contract/application level.
That is great! If someone is prepared to work this out - it would be great. At the moment my position is that these scenarios only work in limited circumstances, and the EVM architecture is lacking primitives to write efficient contract under the rent conditions. I alone cannot explore all the scenarios one can think of, so I invite other people to contribute by making alternative proposals.