A mapping of checksummed Ethereum contract addresses to metadata, like names, and images of their logos.
All address keys follow the EIP 55 address checksum format.
This repository is effectively frozen. We recommend that developers of new tokens use EIP 747 to ask the user's permission to display your tokens in their wallet. This reduces the dangers of airdrop-based phishing, and reduces administrative overhead from managing this list.
You can install from npm with npm install @metamask/contract-metadata
and use it in your code like this:
import contractMap from '@metamask/contract-metadata'
import ethJSUtil from 'ethereumjs-util'
const { toChecksumAddress } = ethJSUtil
function imageElFor (address) {
const metadata = contractMap[toChecksumAddress(address)]
if (metadata?.logo) {
const fileName = metadata.logo
const path = `${__dirname}/images/contract/${fileName}`
const img = document.createElement('img')
img.src = path
img.style.width = '100%'
return img
}
}
imageElFor ("0x06012c8cf97BEaD5deAe237070F9587f8E7A266d")
Maintaining this list is a considerable chore, and it is not our highest priority. We do not guarantee inclusion in this list on any urgent timeline. We are actively looking for fair and safe ways to maintain a list like this in a decentralized way, because maintaining it is a large and security-delicate task.
images
folder.contract-map.json
file with the specified address as the key, and the image file's name as the value.Criteria:
A sample submission:
{
"0x6090A6e47849629b7245Dfa1Ca21D94cd15878Ef": {
"name": "ENS Registrar",
"logo": "ens.svg"
}
}
Tokens should include a field "erc20": true
, and can include additional fields:
A full list of permitted fields can be found in the permitted-fields.json file.
The project follows the same release process as the other libraries in the MetaMask organization. The GitHub Actions action-create-release-pr
and action-publish-release
are used to automate the release process; see those repositories for more information about how they work.
Choose a release version.
If this release is backporting changes onto a previous release, then ensure there is a major version branch for that version (e.g. 1.x
for a v1
backport release).
v1.0.2
release, you'd want to ensure there was a 1.x
branch that was set to the v1.0.1
tag.Trigger the workflow_dispatch
event manually for the Create Release Pull Request
action to create the release PR.
action-create-release-pr
workflow to create the release PR.Update the changelog to move each change entry into the appropriate change category (See here for the full list of change categories, and the correct ordering), and edit them to be more easily understood by users of the package.
yarn auto-changelog validate --rc
to check that the changelog is correctly formatted.Review and QA the release.
Squash & Merge the release.
action-publish-release
workflow to tag the final release commit and publish the release on GitHub.Publish the release on npm.
publish-release
GitHub Action workflow to finish. This should trigger a second job (publish-npm
), which will wait for a run approval by the npm publishers
team.publish-npm
job (or ask somebody on the npm publishers team to approve it for you).publish-npm
job has finished, check npm to verify that it has been published.