Skip to content
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 EPIC] Phase 1: Develop and implement a tool for indexing the Hedera network to detect ERC-20 and ERC-721 contracts. #1066

Closed
8 tasks done
Tracked by #1028
quiet-node opened this issue Dec 9, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request Epic Collections of tasks
Milestone

Comments

@quiet-node
Copy link
Member

quiet-node commented Dec 9, 2024

Problem

The ERC Registry is an initiative aimed at creating a comprehensive registry of contracts that are widely recognized and believed to be standard ERC token contracts with a high degree of confidence. At this early phase of the project, it requires a design document to highlight and outline the approach.

Solution

As a first pass to accelerate improved UX we can produce a registry of contracts that are beleived with high confidence to be ERC's. The Mirror node explorer and other apps can take this list as a starting point to build out their UX for users.

Simple approach is to

  • create a self contained runnable npm project erc-repository-indexer under tools.
  • Index the networks contracts and verify they are ERC20 or ERC721 by matching the presence of interface function bytes. Utilize current POC on 1st pass if applicable and then sevm soon after. Ensure the tool support the specification of env, mirrorNodeUrlandstartingContractId` to allow for flexibility.
  • Create an ERC20s_.json and an ERC721s_.json file each with the appropriate but minimal details. Files should be placed under tools/erc-repository-indexer/registry. Entries should be sorted in ascending order of contractId
  • For additional confidence one may simulate an eth_call on the functions also. Consider pros and cons based on accuracy to this point
  • Make the tool runnable in CI with the output being a new PR with the file updates for approval and merge

A starting schema for an ERC20 may be

{
    "address": "0x....",  // Address of the ERC20 contract/token
    "contractId": "0.0.x",  // contract id of the ERC20 contract/token
  }

A starting schema for an ERC721 may be

{
    "address": "0x....",  // Address of the ERC20 contract/token
    "contractId": "0.0.x",  // contract id of the ERC20 contract/token
  }

Alternatives

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Epic Collections of tasks
Projects
Status: Done
Development

No branches or pull requests

1 participant