Status-react: [EPIC] Custom ERC-20 tokens

[goranjovic]

Problem

Currently Status only supports a limited fixed list which is manually maintained by core contributors.
If a user own some tokens which are not on that list, they would not appear in any of the Wallet screens.

The issue is particularly irritating when the user buys unsupported tokens on one of the exchange dapps listed in Status but then never sees them appear under assets.

Implementation

Screen designs in figma - https://www.figma.com/file/XUehMnhyD1FGcWzvGz6SXqvh/Wallet_Source-of-Truth?node-id=160%3A3954

Minimal path

• new screens for custom token entry by address and token details (see designs)
• validation that checks if the address corresponds to an ERC-20 token contract
• validation that checks if the address is already in the token list
• validation that checks that contract defines name, symbol and decimals fields (see MVP for constraints)
• validation that checks if name or symbol of the added token isn't a duplicate of another already added token (see MVP for constraints)
• new database operations to store, retrieve and delete custom tokens. Store address and all values retrieved from the contract (name, symbol, decimals).
• addition of custom tokens loaded from database to all-tokens in app-db upon login
• use the same logo icon for all custom tokens, in this iteration the default icon is fine

So, to summarize, the flow that allows the user to add a new custom token and then be able to send and receive them, both directly in wallet and in chat (subject to initial constrants).

Constraints (i.e. what's being left out from the minimal path):

• Strictly speaking, fields name, symbol and decimals are optional in ERC-20 and having our wallet rely on them being present in the contract is a departure from the standard. Still, in the first iteration, we can reduce the complexity of the UI by requiring the added tokens to define them, which reduces the UI to a single field with an address.
• Strictly speaking, token name and symbol are not guaranteed to be unique. Furthermore they are even subject to change over time as tokens get rebranded. Still, for the first iteration we can simplify things by assuming that they are and restrict any duplicates. The ideal solution would be to allow users to override or somehow tag namesake tokens, e.g. "My WETH" as opposed to "Other WETH" but that is outside the scope of this issue.

Acceptance Criteria

User can add new tokens by address (subject to some constraints). After the addition, user can see the current balance of new tokens (if any) and send/receive them in wallet and chat.

[Swader]

One suggestion on how to approach this problem: https://discuss.status.im/t/listing-custom-assets-and-tcring-their-verification/918/2

Status.im

Listing custom assets and TCRing their verification

Agreed it’s a huge pain point. — here’s an Issue about the first part with designs and such. (Adding a custom ERC20)

[kayuzee]

How is there not more voices on this, it's a integral issue to allow adoption of Status, espdicslly with the ease of access for the dexes through the browser.

Like any normal app, it should follow the metamask approach to add a token by address (and auto read decimals and symbol from chain) to add the custom token. Happy to provide more details and examples for how others use it, but standard best practice

This is going to become incredibly important as the user base grows - as to my knowledge you cannot export your private key from Status - so those that have sent tokens thinking it was open are now stuck.

https://github.com/status-im/status-react/issues/6542
https://github.com/status-im/status-react/issues/4614

[Swader]

Keep spreading the word and asking others to +1 this, let's show the demand.

[dioro]

+1

[oskarth]

@goranjovic is there a reason this isn’t bountied up yet?

[guylouis]

@goranjovic can this be a bounty or you do not recommend it ?

[oskarth]

Ping @goranjovic

[goranjovic]

@guylouis I don't recommend bountying this - it's too large in scope for a bounty. It's pretty large even as a non-bounty issue.

[oskarth]

If it is too large in scope it should probably be broken down into manageable chunks, and then bountied.

[oskarth]

@mandrigin @guylouis Can Core or Keycard/Wallet help break this task done a bit into parts that can be bountied out? Some kind of dependency tree or so. E.g. visual screens can easily be done in separation with mocking and flag, and API call for get/post can be done and tested separately, as well as any dependency for this (LES / Infura blockers etc, should point to this specific issue / upstream then).

[mandrigin]

I bet core knows very little about how the tokens are stored...
I know to display a token we should store it's address, number of decimals and some artworks.
Is there anything else we need to support to make it happen? Assuming that the UI to add it already exists and assuming that we don't assist user that much with solving errors.

[guylouis]

@goranjovic can definitely help here

[goranjovic]

We already merged the supporting changes some time ago - previously we had hardcoded tokens, now they are subscription driven, which means that now their info can be stored in the database.
I'll put together an itemized list of things to do here. It should give us a clue what can be removed from the minimal PR scope.

[mandrigin]

@goranjovic thanks!

[oskarth]

so...what's happening with this @goranjovic?

[goranjovic]

Apologies for the delays everyone, had my hand full elsewhere.

I expanded the work description to include the itemized scope and removed some high complexity items from it. We can address those in a different issue/bounty when this one is done.

Added:

---

Minimal path

• new screens for custom token entry by address and token details (see designs)
• validation that checks if the address corresponds to an ERC-20 token contract
• validation that checks if the address is already in the token list
• validation that checks that contract defines name, symbol and decimals fields (see MVP for constraints)
• validation that checks if name or symbol of the added token isn't a duplicate of another already added token (see MVP for constraints)
• new database operations to store, retrieve and delete custom tokens. Store address and all values retrieved from the contract (name, symbol, decimals).
• addition of custom tokens loaded from database to all-tokens in app-db upon login
• use the same logo icon for all custom tokens, in this iteration the default icon is fine

So, to summarize, the flow that allows the user to add a new custom token and then be able to send and receive them, both directly in wallet and in chat (subject to initial constrants).

Constraints (i.e. what's being left out from the minimal path):

• Strictly speaking, fields name, symbol and decimals are optional in ERC-20 and having our wallet rely on them being present in the contract is a departure from the standard. Still, in the first iteration, we can reduce the complexity of the UI by requiring the added tokens to define them, which reduces the UI to a single field with an address.
• Strictly speaking, token name and symbol are not guaranteed to be unique. Furthermore they are even subject to change over time as tokens get rebranded. Still, for the first iteration we can simplify things by assuming that they are and restrict any duplicates. The ideal solution would be to allow users to override or somehow tag namesake tokens, e.g. "My WETH" as opposed to "Other WETH" but that is outside the scope of this issue.

[oskarth]

Thanks @goranjovic, can we please pull those apart into separate issues, where relevant, and create bounties of them? Unless this work is going to start this week.

Strictly speaking, fields name, symbol and decimals are optional in ERC-20 and having our wallet rely on them being present in the contract is a departure from the standard. Still, in the first iteration, we can reduce the complexity of the UI by requiring the added tokens to define them, which reduces the UI to a single field with an address.

That's fine

Strictly speaking, token name and symbol are not guaranteed to be unique. Furthermore they are even subject to change over time as tokens get rebranded. Still, for the first iteration we can simplify things by assuming that they are and restrict any duplicates. The ideal solution would be to allow users to override or somehow tag namesake tokens, e.g. "My WETH" as opposed to "Other WETH" but that is outside the scope of this issue.

That's fine, you can also inspect actual contract address, optionally add link to etherscan which has basic ad hoc reputation system

[goranjovic]

@oskarth

can we please pull those apart into separate issues, where relevant, and create bounties of them?

Are we ok with having this hidden behind a flag until at least minimum path bounties been fully merged?

[oskarth]

Are we ok with having this hidden behind a flag until at least minimum path bounties been fully merged?

Yes.

[cammellos]

this has been implemented I believe