EIP-21 Genuine tokens verification
@morphic @MrStahlfelge
Sorry for jumping into the conversation.
I think all tokens should have the freedom to belong to Ergo. What one considers garbage to another may be the illusion of a lifetime.
37 Replies
yes, they can, the protocol is open. But this standard is for ecosystem devs to obey.
So only selected tokens can be there IMO
If some dApps follow the standard and others are not, then it is not a standard at all.
So the acceptance rules should be conservative. But the Ergo protocol is very open.
So I think before including or rejecting some tokens the standard should be well defined.
@MrStahlfelge I think you can do a reference implementation of this standard in the wallet. If necessary the EIP can be changed.
yeah I will do. want to point out, the EIP is only about showing a special flag next to the token: genuine, malicious, or suspicious. All other tokens default to no special flag which is open in my opinion, but we should keep the number of tokens flagged as genuine low.
thinking about it, the EIP lags in declaring that the default is showing no flag.
Maybe if a token has a website, is the first to use a name, had a real team, then all they have to do to be flagged genuine is provide evidence of the token ID they're using for the tokens. Then anyone who copies it after will not be genuine and all will be well. Being gatekeepers of what tokens are considered good and what are bad is contrary to the manifesto, and crypto as a whole
How many tokens should be visible in the wallet, all of them or a subset?
What if there is 1000 tokens in the wallet to be shown?
We don't have this problem ATM, but we also don't have wide adoption.
I can easily write a bot which will attack any PK address by sending a 0.001 ERGs with 1000 garbage tokens.
Do we want any support from the wallet software to filter out garbage from genuine tokens?
Also, any wallet should not accidentally burn tokens. To handle this, the tokens need to move from box to box (as part of change output of transaction).
If anyone can pollute the network with tokens, and there is no self-cleanup mechanism, the whole user experience will awful.
So, some tokens are better be burned.
One possible option is to let the user decide which tokens he/she wants to burn by flagging it in UI.
yes, we will have these problems as well in the future, the question how to burn tokens is raised regularly the last weeks.
I've added a PR with some clarification what tokens to add to the list, please review: https://github.com/ergoplatform/eips/pull/47
I think this suggestion faces the "policeman" concern (tokens can be added by community vote) while emphasizing that the list is mainly to prevent people getting scammed.
since we had a vivid discussion before, I suspect the silence now after a proposed change means no one have seen it. 🙂 Pinging @Community Developer and @Contributors to help that.
It doesn't appear to address the question of who controls the approval process, and what is the specific criteria for an approved token
Is it voted on by the community?
tokens of a certain intrinsic value to the community could be added as well when there was a community vote with significant community participation.
Just making sure, the only criteria to be added is this part?
As outlined before, this list should only hold tokens of value.the criteria is
mainly tokens of financial value can be addedor
tokens of a certain intrinsic value to the community could be added as wellThis is a quote of the change. Open to adjustments of these sentences if they are not clear enough. I think who exactly checks and approves if this applies is not that important, technically it is anyone with write access to the GitHub repo
added is what is highlighted in green:
Seems fair? Maybe everyone left it because they're ok with how it turned out
I was expecting a more specific criteria but I don't see a problem with how you have it..looks good. If it needs to become more specific, no reason not to add that later
might be. we have now two approvals but let's wait for some more opinions. opinion of @LADOPIXΣL would be interesting to hear.
I didn't see the updates actually
Will review later, workin day job right now :'(
Sorry!! I had read it the other day but it was not clear to me, I thought that after Curia's response this whole topic was on pause.
Although I don't like this topic of value tokens at all, I have some doubts.
If I create a token and sell it to a certain wallet this token already has value. It is not the first time that a record company buys 100 million copies to become a gold record or has overbid their NFT to gain value.
Here is a concrete example for you to give me your opinion: Some time ago I minted a token 640,000 units. Of these 640,000 I have managed to sell 100. Is this value? Because for the person who bought it and for me, it has value the price he paid for them.
ask yourself, is the token you minted interesting for scammers? I think it is obvious that the answer is no. same for the one NFT I paid for, no need to add it to the list.
That is, this filter system bases the value of a token on the answer to a question that someone invented. It doesn't seem very serious to me.
the question was not invented out of the blue but is the question related to the problem the eip tries to help with
I'm not saying it was made up out of thin air, I'm saying that basing a decision on this question seems to me to be somewhat ambiguous and a joke.
do you have a constructive alternative suggestion?
I think more clarification might be needed, but the idea is very promising. For genuine tokens, how will the community vote for 'valueless' tokens be held? And what conditions will a 'blocked' token need?
Not at the moment, sorry. Only give my opinion, if something occurs to me I will let you know for here.
I also want you to know that I really appreciate the effort you are making. I don't want you to think otherwise because i disagree with the measurements.
Not sure about the blocked token myself. I hope we will never need it, it is more meant that we can already prepare it in our apps.
I think how the vote is held can be left open. It is not really necessary to specify it because the community is on TG, Twitter and Reddit or elsewhere. All these channels should be accepted as long as their is significant interest expressed.
I think we should block tokens which has the same name (and other parameters) as any of the genuine tokens. So once the token becomes "genuine", all the others with the same name should be marked as "suspicious". From this perspective, genuine tokens list is kind of naming conflict resolution mechanism.
at the current state, these tokens are not "blocked" but "suspicious", recommended sign is an exclamation mark. so I guess it is exactly as you propose? Blocked is a bit more, proposed sign is a cross
from a user perspective, I think morphic's suggestion works better than having to pre-approve suspicious tokens... The first user to get scammed with a fake token wouldn't have any indication its fake except the lack of 'genuine' marker
If that's their first token, they could easily go ahead and buy more without realising its fake, and not seeing any indications for that...
I have added the hardcoded SigUSD and SigRSV ids to my token burner to prevent to burn them, waiting for a list.
In my point of view, for a good transparency, the criteria to integrate the list should be measurable and if a vote is implied, the condition of the vote should be described.
I tend to agree with Morphic that the only blocked/flagged tokens should be tokens which would easily be confused with an intended/actual token, and help users delineate between the correct token they mean to use and a suspicious one
Outside of that, I don’t think it is the protocol’s place to distinguish between tokens of value, community tokens, etc
There could be a network effect kind of... Or a user vote. If a token has a website, several users express they own it, then it gets the genuine tick. Any tokens that come after that copy the name are likely a scam, in this case.
If a project goes dead for a certain length of time, perhaps it loses that approved mark and makes the name available to others. Could be tracked based on dex activity and user base?
It's just a community helper, like we're saying this is the official one, to protect others from getting scammed. Nothing more, correct?
What if a token was reissued by a legitimate party?
I'd propose to add optional "issuer PK" field to EIP4,. If it's empty - then the token can't be re-issued and all duplicates should be handled as "suspicious", otherwise we can expect the issuer to spend a box locked by "issuer PK" in order to re-issue his token. This can be automatically checked (fetch_box(token_id).address == P2PKAddress("issuer PK")) and such duplicates should be handled as legitimate.
This won't apply to SigUSD/SigRSV. As far as I remember they were re-issued and early versions were deprecated.
isn't this solvable by just changing the token id in the list? If someone sends you SigUSD v1, it is probably not what you expect to get
But then the list should always be maintained manually
And the above approach allows to resolve everything automatically
I think EIP21 is created to facilitate some unification of token names. And it is better to avoid duplicated names to avoid confusion. If someone is willing to issue a new token with "issuer PK" as a means to redefine the token in future (or create a new version of it) then it is better to come up with some naming scheme in a first place (like MyToken1, MyToken2 etc.).
Having unique names for "genuine" tokens is a simple way to guarantee, that, over time, the name of each token represents the same actual token id, so users can use "genuine" token names instead of ids. Otherwise it will not be possible.
Unification is a good thing, and EIP21 will be really helpful to handle scam assets (not only duplicates, also shitcoins etc). But I'd avoid relying on this framework entirely as it isn't generic enough to cover all potential cases (I mean the assumption that TokenName is always unique).
eip21 hasn't such an assumption, it is a flag that is set for the two list entries but it can be set to "no".
As with most standards there may be MUST and SHOULD clauses in EIP21 (as well as in any other EIP). Then any "compliant" app need to follow them.
For example EIP21 may require (i.e. using MUST clause) that any listed token MUST be marked and any duplicate token MUST be also marked.
Over time the community may decide to evolve the standard so that marking duplicates is no longer the MUST, but instead it SHOULD (i.e. recommended).
Currently I think all the EIP21 requirements are SHOULD, and the community may end up deciding to make some of them MUST. We'll see how it goes.