-
Notifications
You must be signed in to change notification settings - Fork 5.3k
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
ERC: registry for token symbol? #740
Comments
Tokens already have a verifiable unique identity based on the contract address, so the need to implement an official token registry seems redundant. Unofficial ones could be very useful though. |
@jojeyh agreed but unregulated token symbol means you could have 100 OMG under 100 different contract addresses. How do you proof the authenticity of the token easily by merely looking at the address? How do you know the googled token website is indeed the real website containing the real address of the token? |
Why not use ENS for this? You can use any subdomain you want to establish your own registry; everyone can choose which registry they want to listen to. |
I think the gist of this is the protection of the brand. ENS is just an alias for an address and should not be confused with the rightful owner of the brand. Put this in real world analogy, if we have no control over the symbol, we are allowing anyone to operate under the name IBM from any parts of the world. As the original IBM becomes more popular, 1000 more IBM springs up from nowhere profiting from the brand and faking its identity, praying on suspecting victims. |
@bernardpeh I think nick means you can get a .eth domain and make your own registry, call it Then |
hi @shrugs thanks for the clarification. Who manage tns.eth then? how do we know that tns.eth is official and the standard? |
@bernardpeh you do! (or rather, someone does). The only want to ensure "brand ownership" (instead of, like, contract address ownership) is to either "get humans involved" to solve the squatting issue or let the community collectively decide who owns what brand (TCR). Not sure there's any other option. And there's no way to make a standard; people would have to adopt it. But if you say "here are 10 public figures in the community and they're the 10 people with the keys to this MultiSig that is the only contract that can change the registry" that's probably enough justification for people to consider it the One True Registry™. Or you could think up some sort of TCR to incentivize people to vote on who owns what brand. I think this could be valuable, especially in the case of contention around token symbols (see the recent AIR debacle, with AirSwap switching to AST); the most support a project has, the more of a claim it has to the brand. Lot of issues with this approach as well (51% attacks, need to start a flywheel, etc). Basically, the tech has been figured out by ENS; there's no reason to do any foundational development since the generic concept of "ethereum-based human readable string pointer to something else" has been solved. The real development would be the registrar you build to manage your .ens token registry domain. |
I also realised etherscan had an unofficial reputation rating against each token. cudos to them for doing a great job. perhaps that could be a quick and simple alternative for now. |
<p>This PR was automatically created by Snyk using the credentials of a real user.</p><br /><h3>Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.</h3> #### Changes included in this PR - Changes to the following files to upgrade the vulnerable dependencies to a fixed version: - assets/eip-4675/package.json #### Vulnerabilities that will be fixed ##### With an upgrade: Severity | Issue | Breaking Change | Exploit Maturity :-------------------------:|:-------------------------|:-------------------------|:------------------------- ![medium severity](https://res.cloudinary.com/snyk/image/upload/w_20,h_20/v1561977819/icon/m.png "medium severity") | Open Redirect <br/>[SNYK-JS-GOT-2932019](https://snyk.io/vuln/SNYK-JS-GOT-2932019) | No | No Known Exploit <details> <summary><b>Commit messages</b></summary> </br> <details> <summary>Package name: <b>solidity-coverage</b></summary> The new version differs by 41 commits.</br> <ul> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/0a33e13b166651bf8ce94d425d0abf590fed784c">0a33e13</a> 0.8.0</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/4c63612f83f6b230810f5728f4c1315cfe28cef2">4c63612</a> Add hardhat to peerDependencies (ethereum#722)</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/9ce20ff4bbc3c7e015ac0a5574cc1ab61cfc216b">9ce20ff</a> Typo / Grammar fix. (ethereum#738)</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/204a5ebaa4be69fd420f9d3851dd518d9072ece9">204a5eb</a> Added a section for the report location. (ethereum#739)</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/ed3d5041764e1b6a2270d0b910a3bfaf1a9d3c01">ed3d504</a> Fix README for v0.8 release</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/05ab320fbccb7bc607d9e5ada4a3261c46a273e8">05ab320</a> Fixes for Hardhat 2.11.0 (ethereum#740)</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/bc7d07623ec4bd71a2ce4c8ecb4a872af613c8ef">bc7d076</a> 0.8.0 Additional Coverage Measurements & Restructure (Merge)</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/a7db2fedc447f318da0424a162e58a2475072dc1">a7db2fe</a> More README changes</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/16367d15389ade4f8cc5d9c17ccac2cfd0962e14">16367d1</a> Remove truffle files from project</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/26898c1ad9f81ae089953fa0a824ab01b7caef08">26898c1</a> Remove Builder-E2E test</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/8ea8ec93d923a9722a3549e5788d5aaa81b3a41a">8ea8ec9</a> Fix true/false scoped method definition function visibilities</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/21ca46e2de3e1fe27d120b38fe7383a0a90792b1">21ca46e</a> Temporarily skip truffle integration tests</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/22992e1c19825d27de665762ffb8798a6b3195fe">22992e1</a> Fix constructor test</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/cf126ea7311145214fde7f7538bf4428e168b834">cf126ea</a> Fix assert tests</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/0ba3f11701097693674dab8cf831fac9af113fb0">0ba3f11</a> Remove more buildler things</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/d57a1315ec73ee0f0a26a2e64212a6055d51c3ab">d57a131</a> Remove buidler</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/3bcec941ecbeac2fd385c3e17886e7e02c66c2ad">3bcec94</a> Fix rebase errors & regenerate yarn.lock</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/88c1d0039033cfbb38311c6430ebdc41d5480c03">88c1d00</a> Fix loops, modifiers, options and statements tests</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/0deb0013cbf9e552a133c18d46e4b6536700982f">0deb001</a> Fix if/else tests</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/29c0fdda7fcc438861bcbb4ad1c0cb26ffbd08fb">29c0fdd</a> Fix constructor keyword test</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/d4e8536aa3087f40853f2b4c168dfa2b4e9c6e7a">d4e8536</a> Update tests for adjusted statement coverage</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/3edfd2537180e0f78ba769b077664a3159ba0b2a">3edfd25</a> Stop injecting statement coverage into conditionals</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/7eb94a93f3b2a2c68535051758c688470de9a1e2">7eb94a9</a> Update @ solidity-parser/parser to 0.14.1</li> <li><a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/commit/e9133d719ca3969b63ffa777a13a3424f886fbc8">e9133d7</a> Generate mocha JSON output with --matrix (ethereum#601)</li> </ul> <a href="https://snyk.io/redirect/github/sc-forks/solidity-coverage/compare/0e17f18e80e46c598097ab89e32379cb6ffd7e33...0a33e13b166651bf8ce94d425d0abf590fed784c">See the full diff</a> </details> </details> Check the changes in this PR to ensure they won't cause issues with your project. ------------ **Note:** *You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.* For more information: <img src="https://api.segment.io/v1/pixel/track?data=eyJ3cml0ZUtleSI6InJyWmxZcEdHY2RyTHZsb0lYd0dUcVg4WkFRTnNCOUEwIiwiYW5vbnltb3VzSWQiOiI5MjU1NWU1OC1iZGQ2LTQ5MjctOWVlMy1hZDlkMTE1NDFmNWIiLCJldmVudCI6IlBSIHZpZXdlZCIsInByb3BlcnRpZXMiOnsicHJJZCI6IjkyNTU1ZTU4LWJkZDYtNDkyNy05ZWUzLWFkOWQxMTU0MWY1YiJ9fQ==" width="0" height="0"/> 🧐 [View latest project report](https://app.snyk.io/org/woodpile37/project/f0dcf1c9-ecf1-445b-bc07-e8f73c595f54?utm_source=github&utm_medium=referral&page=fix-pr) 🛠 [Adjust project settings](https://app.snyk.io/org/woodpile37/project/f0dcf1c9-ecf1-445b-bc07-e8f73c595f54?utm_source=github&utm_medium=referral&page=fix-pr/settings) 📚 [Read more about Snyk's upgrade and patch logic](https://support.snyk.io/hc/en-us/articles/360003891078-Snyk-patches-to-fix-vulnerabilities) [//]: # (snyk:metadata:{"prId":"92555e58-bdd6-4927-9ee3-ad9d11541f5b","prPublicId":"92555e58-bdd6-4927-9ee3-ad9d11541f5b","dependencies":[{"name":"solidity-coverage","from":"0.7.22","to":"0.8.0"}],"packageManager":"npm","projectPublicId":"f0dcf1c9-ecf1-445b-bc07-e8f73c595f54","projectUrl":"https://app.snyk.io/org/woodpile37/project/f0dcf1c9-ecf1-445b-bc07-e8f73c595f54?utm_source=github&utm_medium=referral&page=fix-pr","type":"auto","patch":[],"vulns":["SNYK-JS-GOT-2932019"],"upgrade":["SNYK-JS-GOT-2932019"],"isBreakingChange":false,"env":"prod","prType":"fix","templateVariants":["updated-fix-title"],"priorityScoreList":[null],"remediationStrategy":"vuln"}) --- **Learn how to fix vulnerabilities with free interactive lessons:** 🦉 [Open Redirect](https://learn.snyk.io/lesson/open-redirect/?loc=fix-pr)
People always want to have sexy token symbol when launching ico. There is nothing stopping anyone from using a name that has been used before. Parity has a token registry standard - https://github.com/paritytech/parity/wiki/Token-Registry but its still not widely accepted.
I can think of 2 issues for not having central governance of token symbols.
We are relying on people to check https://etherscan.io/tokens when registering a new token and create a new one that has not been used. There is nothing stopping anyone from spamming 100 new erc20 tokens with OMG symbol for example. It is also possible to create dummy erc20 tokens and park all sexy 3 letters and 4 letters symbols, just like how people park domain names during the .com boom.
Hackers might create new contracts using existing token symbol and create fake advertisements asking people to buy the token. Victims follow the instructions to add the token address in MEW and see that the token name is indeed correct, not realising the address is incorrect. This hack has been done in ico before.
Solution: Following the footpath of dns and ens, why not create a token named service (tns) managed by ethereum foundation? Then teach people to always use this service as the source of truth.
The text was updated successfully, but these errors were encountered: