# trustwallet/assets: The Token Metadata Repository That Feeds Trust Wallet > The trustwallet/assets repository holds logo files, blockchain data, dApp records, and trading pair information for thousands of crypto tokens. Contributing a new listing requires passing Go-backed CI validation and meeting non-minimal circulation requirements. **trustwallet/assets** — A comprehensive, up-to-date collection of information about several thousands (!) of crypto tokens. - Repository: https://github.com/trustwallet/assets - Website: https://developer.trustwallet.com/assets/new-asset - Stars: 5,393 · Forks: 27,500 - Language: Go - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/trustwallet-assets ## What trustwallet/assets Stores and Why Wallets Depend on It The repository is the single source of truth for token presentation in Trust Wallet. When the app displays a token logo or shows metadata for a dApp, the image and data come from here. The project covers several blockchains and for each supported chain the repository tracks token logos, optional extended info that cannot be stored on-chain, dApp records, and staking validator details. What gets stored is deliberately narrow. Each token entry contains a logo image and an optional info.json file with fields such as name, symbol, type, and description. There is no price feed, no real-time balance, and no ABI. The repository is a metadata layer only. Other projects besides Trust Wallet consume it, which is why consistency in naming and image sizing matters: a logo that renders cleanly at small sizes in one app is likely to display correctly in others. The practical consequence is that adding a token to Trust Wallet's display is the same operation as contributing to this repository. The code path Trust Wallet follows at runtime fetches the logo and metadata from this source, so a missing entry means a blank icon in the app. There is no separate asset pipeline that could supply a logo from somewhere else. The contribution path is the display path. ## Repository Layout: blockchains/, dapps/, and the knowledge/ Directory The top-level layout of the repository reflects its scope. The blockchains/ directory holds subdirectories organized by chain, each containing token entries at the appropriate address path. The dapps/ directory holds records for supported decentralized applications. The knowledge/ directory is present alongside the Go command source in cmd/ and the library code in internal/. The Go tooling lives in cmd/ and internal/, and the module is declared at github.com/trustwallet/assets with a minimum Go version of 1.19, as stated in go.mod. The tools depend on github.com/trustwallet/assets-go-libs, github.com/trustwallet/go-libs, and github.com/trustwallet/go-primitives. These libraries handle the actual validation logic for image formats, JSON structure, and naming conventions. The assets-go-libs package version pinned in go.mod is v0.3.9-0.20240905070109-9da7e7c4847a, meaning the library is versioned separately from this repository. The .github/ directory contains the assets.config.yaml configuration file, which controls which assets are force-included or force-excluded from validation checks. This config file is the place to override default validation behavior for specific edge cases without touching the Go source code. The Makefile targets are the primary interface for running the tools locally, and each target that runs the binary depends on building it first. ## Running Validation and Adding Tokens: The Makefile Workflow The repository ships a Makefile with commands for both day-to-day maintenance and for preparing a contribution. The first command any contributor should run is make check, which builds the binary at bin/assets and then runs it against the full repository tree: ```bash make check ``` This executes the same logic that runs in continuous integration, so a clean local pass is a reliable indicator that the pull request will not fail validation. The check covers image dimensions, color mode, file size limits, JSON schema conformance, and naming conventions. A failure message names the specific file and rule that was violated. Where the validator can correct a problem without human input, make fix applies automatic remediation: ```bash make fix ``` For maintainers pulling in external trading pair data, make update-auto fetches updates from Uniswap on Ethereum and PancakeSwap on Smartchain and writes the results to the relevant tokenlist.json files: ```bash make update-auto ``` When adding a new token entry rather than editing an existing one, a helper command creates a template info.json at the correct path. Replacing the placeholder asset_id with the actual chain-and-address identifier (in the format c60_tAddress) scaffolds the directory structure: ```bash make add-token asset_id=c60_t0x4Fabb145d64652a948d72533023f6E7A623C7C53 ``` Two more commands handle trading pair lists: ```bash make add-tokenlist asset_id=c60_t0x4Fabb145d64652a948d72533023f6E7A623C7C53 make add-tokenlist-extended asset_id=c60_t0x4Fabb145d64652a948d72533023f6E7A623C7C53 ``` The template these commands produce sets required fields to placeholder values that make check will then flag. The correct workflow is: scaffold, fill the actual data, run make check, resolve any reported problems, and then open a pull request. ## The Three Environments That Run Check Logic: CLI, Assets App, and merge-fee-bot Validation does not happen in one place. The repository documents three separate environments that run equivalent check logic, each suited to a different stage in the contribution process. The Go CLI (make check) runs the full check against the entire repository. It is intended for local development and for the CI build. Because it checks the whole tree, it catches problems that cross-file rules might miss if only changed files were examined. The assets-management app at assets.trustwallet.com runs a browser-based version of the same checks. It checks only the diff for a pull request or for a token being added through the web interface. This scope is intentional: the app is designed for contributors who are adding or modifying a single token, not for maintainers reviewing repository-wide state. It can be used directly from a browser without a local Go environment. The merge-fee-bot is a GitHub App that runs on pull requests and posts the check result as a PR comment. It executes in a non-browser environment and covers the diff, like the assets-management app, but its output appears on GitHub rather than in a local terminal. All three environments use the same underlying rules, but they differ in scope (whole repository versus diff) and in execution context (CLI versus browser versus GitHub App). A PR that passes the assets-management app check may still fail the CI run if it introduces a problem that only appears when the full repository is analyzed as a whole. This is worth understanding before spending time diagnosing a discrepancy between local results and CI results. ## Token Admission Policy: Circulation Requirements and What Gets Rejected The repository explicitly does not accept brand-new tokens. A project must have established circulation and must have publicly available information before a listing can be considered. The README states this directly: projects have to be sound, with information available, and have non-minimal circulation. The specific threshold values are documented at developer.trustwallet.com/listing-new-assets/requirements rather than in the README itself, so the exact minimums are not visible from the repository. The Trust Wallet team reviews submissions and rejects projects that appear fraudulent or that function as scams. The disclaimer section of the README states that a listing does not imply a partnership with the listed project, that the team reserves the right to change submission terms at any time due to changing market conditions or risk of fraud, and that tokens distributed as spam to random addresses will be flagged and potentially removed. These are operational policies, not technical constraints enforced by the Go tooling. The tooling validates format and structure; human review determines eligibility. For token projects that do meet the requirements, the preferred submission path is the Assets web app at assets.trustwallet.com. The GitHub repository contribution path is for cases the web app cannot handle. The developer site at developer.trustwallet.com/listing-new-assets/new-asset is the canonical reference for which path applies to a given token type. This admission policy has a direct consequence for anyone building tooling that reads from trustwallet/assets: the set of listed tokens is always a curated subset of all deployed tokens, and the curation is partly editorial. A token can be in wide circulation and still absent from the repository if it has not gone through the submission process, and a listed token can be removed if the team later determines it is fraudulent. Applications that treat this repository as a complete index of all valid tokens will encounter gaps. ## Trading Pairs, tokenlist.json, and the Config Override System Trading pair data is stored in tokenlist.json files within the repository. These files record which tokens are supported as trading pairs on integrated exchanges. The update process for Uniswap on Ethereum and for PancakeSwap on Smartchain is automated through make update-auto, which fetches the current pair data and writes the results into the repository. This is a maintainer operation, not something a contributor adding a new token runs directly. The minimum values for trading pair inclusion are set in .github/assets.config.yaml. This configuration file also contains force-include and force-exclude lists. A token that falls below the configured threshold can be included by listing it under force-include, and a token that meets the threshold can be excluded by listing it under force-exclude. This config-based override system means that trading pair eligibility rules are adjustable without code changes to the Go tooling. The extended trading pair list is separate from the default tokenlist.json. The make add-tokenlist-extended command adds an entry to tokenlist-extended.json. The README does not document the behavioral difference between the two lists, so the actual distinction requires reading the source of the Go tooling in internal/ or consulting the developer documentation on the Trust Wallet developer site. Any tool that scrapes tokenlist.json files for trading pair data should account for the fact that the make update-auto job runs on a schedule via GitHub Actions. The data reflects the state at the last automated run, not real-time exchange pair availability. ## MIT License Scope, Community Contribution, and Scale Constraints The scripts and documentation in this repository are released under the MIT License. The token logos themselves are not under the MIT License, as individual token projects hold the rights to their brand assets. The license covers the Go verification tooling and the repository infrastructure, not the content of the individual token directories. Operators who fork the repository and distribute it should be aware of this distinction. The repository is community-maintained in the sense that contributions come from token projects and developers across the ecosystem. The admission and removal decisions rest with the Trust Wallet team, not with the community at large. The last push was on 2026-09-26, two days before this writing, so the infrastructure side of the project is current. A practical constraint for any project that clones this repository and wants to maintain a synchronized mirror: the volume of token directories means that a full clone is large. Running make check against the full tree takes time proportional to the number of entries. Each new listing added increases CI build time. This is a property of the design, not a defect, but it matters for anyone considering a fork that intends to stay synchronized over time and run validation at the same frequency as the upstream project does. ## Conclusion Teams building wallets or token aggregators that need verified metadata can clone this repository and run make check to audit additions before any pull request is opened. Individual token projects that have established circulation can submit through the Assets web app at assets.trustwallet.com. Brand-new tokens are rejected, and the Trust Wallet team reserves the right to remove listings flagged as spam or fraud, so any submission depends on meeting the circulation and legitimacy requirements documented at developer.trustwallet.com/listing-new-assets/requirements. ## FAQ ### Does listing a token in trustwallet/assets make it appear in Trust Wallet automatically? A merged pull request that passes all validation checks will be picked up by Trust Wallet once the app refreshes its data from the repository. The README does not document a specific propagation delay. The assets-management app at assets.trustwallet.com is the preferred submission path for most token additions. ### Can a newly deployed token be submitted to trustwallet/assets? No. The README states that brand-new tokens are not accepted. Projects must have sound information publicly available and non-minimal circulation before a submission will be considered. The specific thresholds are documented at developer.trustwallet.com/listing-new-assets/requirements. ### What does make check actually verify in this repository? It builds the Go binary at bin/assets and runs it against the entire repository tree. The check covers image dimensions, color mode, file size, JSON schema conformance for info.json files, and naming conventions. The same logic runs in CI, so passing locally means the PR is unlikely to fail the automated build. ## Sources - [Issues](https://github.com/trustwallet/assets/issues) - [License: MIT](https://github.com/trustwallet/assets/blob/master/LICENSE) - [Project website](https://developer.trustwallet.com/assets/new-asset) - [README](https://github.com/trustwallet/assets/blob/master/README.md) - [trustwallet/assets on GitHub](https://github.com/trustwallet/assets) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/trustwallet-assets