Skip to content

Latest commit

 

History

History
98 lines (69 loc) · 5.86 KB

eip-0021.md

File metadata and controls

98 lines (69 loc) · 5.86 KB

Genuine tokens verification

  • Author: @MrStahlfelge
  • Status: Proposed
  • Created: 31-Aug-2021
  • License: CC0
  • Forking: not needed

Description

This EIP defines a way for wallet applications, dApps and users to verify tokens. The EIP is meant to be updated regularly when new tokens of value or verification services are added.

Motivation

Ergo tokens can hold a certain value, best-known examples are the SigUSD and SigRSV tokens in use by the SigmaUSD stablecoin protocol. Tokens can be minted by every user, with a name and description free to choose. This means everyone can mint new tokens named "SigUSD", which bears a problem for end-users to decide if a token they received is genuine or not.

Ergo tokens background

See EIP-4: Ergo supports custom tokens as first-class citizens. A transaction can create out-of-thin-air tokens in its outputs if the token identifier is equal to the identifier of the first input box of the transaction. As the box identifier is cryptographically unique, there's no chance to have the second token with the same identifier while the hash function being used is collision-resistant.

In order to verify the authenticity of a token, the unique identifier of a token and its name is needed to check.

Token authenticity verification algorithm

The verification algorithm relies on a list of blocked tokens and a list of genuine tokens that can have a unique name. The token to test is checked as follows:

  • Is the token id listed in verified tokens? If yes, the token is verified.
  • Is the token id listed in blocked tokens? If yes, the token is blocked.
  • Is the token id not listed, but its name is the name of a verified token with unique name? If yes, the token is suspicious.
  • If nothing applies, the token authenticity is unknown.

Recommended approach for applications showing tokens to end-users

Verified tokens

Applications should add a verification sign next to a token which is listed in the following genuine tokens list.

Proposed verification sign: Material icons verified

Suspicious tokens

In order to protect end-users for confusion, it is decided for some tokens in the genuine tokens list that the verbose name should be unique and should not be used by other tokens. This is not enforced by Ergo protocol, so applications should check if a token uses a unique name from the list and add a warning sign when needed.

Proposed warning sign: Material icons report

Blocked tokens

Applications should show a warning sign next to tokens identified to be harmful or impersonating other tokens.

Proposed warning sign: Material icons dangerous

REST API services and OpenAPI specification

The algorithm outlined before can be implemented in dApps/wallet applications, but this needs constant maintenance and slow updates to the users, so REST API services are preferable to be used. Since verifying and blocking tokens means responsibility and providers of such services are free to add tokens to their lists as they wish, users should have the choice which service they want to use and what provider they trust the most. To give users a choice to switch and providers the ability to set up own services, an OpenAPI specification for a token verification service is attached to this EIP. API service providers must implement it completely.

A reference implementation can be found here: https://github.com/MrStahlfelge/eip21-backend-reference

Token lists

Process to add tokens to this list

As outlined before, this list should only hold tokens of value. This means that mainly tokens of financial value can be added. Before opening a PR to add your token to this list, ask yourself if your token is interesting for scammers. When the answer is no, the token should probably not added to this list. On rare occasions, tokens of a certain intrinsic value to the community could be added as well when there was a community vote with significant community participation. Applications and REST API service providers can add own tokens to their list, but should be open about it. As Ergo is neutral, the list defined here should be compact and the smallest common denominator.

Genuine tokens

Verbose name Token id Unique name Issuer
SigUSD 03faf2cb329f2e90d6d23b58d91bbb6c046aa143261cc21f52fbe2824bfcbf04 yes sigmausd.io
SigRSV 003bd19d0187117f130b62e1bcab0939929ff5c7709f843c5c4dd158949285d0 yes sigmausd.io
NETA 472c3d4ecaa08fb7392ff041ee2e6af75f4a558810a74b28600549d5392810e8 yes anetabtc.io
Erdoge 36aba4b4a97b65be491cf9f5ca57b5408b0da8d0194f30ec8330d1e8946161c1 yes community
LunaDog 5a34d53ca483924b9a6aa0c771f11888881b516a8d1a9cdc535d063fe26d065e yes community
Kushti fbbaac7337d051c10fc3da0ccb864f4d32d40027551e1c3ea3ce361f39b91e40 yes community

Suspiscious Tokens

Verbose name Token id Reasoning
ADA 944f72c571f7e894fe75fe5b351cdc67ea2fa6daa538321d72f759d551b1d147 May be misrepresented as genuine ADA tokens

Blocked tokens

Token id