-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support/logic for supporting ETH + ERC20 tokens #9
Comments
Why is |
You can do it this way. You need the ticker as well for display, but you can have token = {ticker, address} |
You can get the ticker from the token contract. |
Not always. It is an optional field so I think it is better to have it passed. We also we need to be careful because you can't use any token -- it needs to be ERC20. So if someone uses the widget with a different token the buyers payment will be stuck in the contract. This was my original thinking when I planned to integrate the T2CR. |
Ahh, ok.
How is that related to the ticker thing? |
It's related because its part of the decision to not use the T2CR. One option that I was planning on going with is to have them just pass the ticker and look up the contract address in the T2CR (and throw an error if a ticker passed doesn't have the ERC20 badge). The other option we have discussed here is to have the integrator pass the ticker and address |
Can't multiple tokens have the same ticker? |
The component takes
currency
as an input but there is no logic to route it to the ERC20 contract instead of the normal arbitrable contract. Will need to get address from T2CR and throw an error if a token ticker is used that is not in the list. Alternatively you can have seller pass a contract address in addition to the ticker and bypass using the T2CRThe text was updated successfully, but these errors were encountered: