arno/trezor-firmware
1
0
Fork 0
mirror of https://github.com/trezor/trezor-firmware.git synced 2024-11-18 05:28:40 +00:00
Code Issues Releases Wiki Activity
2b7b4b13bd
trezor-firmware/common/defs
History
Szymon Lesisz 60fe007ed2 chore(common): update DOGE fees 
https://github.com/dogecoin/dogecoin/blob/master/doc/fee-recommendation.md#dust-limits

- default fee 1000 (0.01) DOGE
- min fee 100 (0.001) DOGE
- dust limit 1000 (0.01) DOGE
2021-11-29 14:59:47 +01:00
..
bitcoin chore(common): update DOGE fees 2021-11-29 14:59:47 +01:00
ethereum chore(common): update chains and tokens 2021-11-01 16:43:02 +01:00
fido chore(common/defs/fido): add coinbase u2f 2021-11-08 15:55:01 +01:00
misc chore(common): update coins support status 2021-11-01 13:58:48 +01:00
nem MONOREPO MERGE trezor-common 2019-04-15 19:14:45 +02:00
blockchain_link.json fix(common): cardano blockfrost definitions (#1879) 2021-11-01 14:21:07 +01:00
coins_details.json chore(common): bring back eth:xDAI 2021-11-02 15:05:14 +01:00
coins_details.override.json feat(common): update XDC wallet 2021-10-05 12:21:51 +02:00
duplicity_overrides.json chore(common): update chains and tokens 2021-11-01 13:58:48 +01:00
README.md feat(common): remove "soon" as support status 2021-09-20 15:49:11 +02:00
support.json chore(common): update suite support 2021-11-29 14:59:47 +01:00
wallets.json fix(common): remove Wanchain from misc (it is now eth:WAN) 2021-08-24 13:14:06 +02:00

README.md

Coin and FIDO Definitions

This directory hosts JSON definitions of recognized coins, tokens, and FIDO/U2F apps.

FIDO

The fido/ subdirectory contains definitons of apps whose logos and names are shown on Trezor T screen for FIDO/U2F authentication.

Each app must have a single JSON file in the fido/ subdirectory. Every app must have its label set to the user-recognizable application name. The u2f field is a list of U2F origin hashes, and the webauthn field is a list of FIDO2/WebAuthn hostnames for the app. At least one must be present.

Each app can have an icon. If present, it must be a 128x128 pixels RGBA PNG of the same name as the corresponding JSON name. If the app does not have an icon, it must instead have a field no_icon set to true in the JSON.

Coins

We currently recognize five categories of coins.

bitcoin

The bitcoin/ subdirectory contains definitions for Bitcoin and altcoins based on Bitcoin code.

Each Bitcoin-like coin must have a single JSON file in the bitcoin/ subdirectory, and a corresponding PNG image with the same name. The PNG must be 96x96 pixels and the picture must be a circle suitable for displaying on Trezor T.

Testnet is considered a separate coin, so it must have its own JSON and icon.

We will not support coins that have address_type 0, i.e., same as Bitcoin.

eth

The file ethereum/networks.json has a list of descriptions of Ethereum networks. Each network must also have a PNG icon in ethereum/<chain>.png file.

erc20

ethereum/tokens is a submodule linking to Ethereum Lists project with descriptions of ERC20 tokens. If you want to add or update a token definition in Trezor, you need to get your change to the tokens repository first.

Trezor will only support tokens that have a unique symbol.

nem

The file nem/nem_mosaics.json describes NEM mosaics.

misc

Supported coins that are not derived from Bitcoin, Ethereum or NEM are currently grouped and listed in separate file misc/misc.json. Each coin must also have an icon in misc/<short>.png, where short is lowercased shortcut field from the JSON.

Keys

Throughout the system, coins are identified by a key - a colon-separated string generated from the coin's type and shortcut:

  • for Bitcoin-likes, key is bitcoin:XYZ
  • for Ethereum networks, key is eth:XYZ
  • for ERC20 tokens, key is erc20:<chain>:XYZ
  • for NEM mosaic, key is nem:XYZ
  • for others, key is misc:XYZ

If a token shortcut has a suffix, such as CAT (BlockCat), the whole thing is part of the key (so the key is erc20:eth:CAT (BlockCat)).

Sometimes coins end up with duplicate symbols, which in case of ERC20 tokens leads to key collisions. We do not allow duplicate symbols in the data, so this doesn't affect everyday use (see below). However, for validation purposes, it is sometimes useful to work with unfiltered data that includes the duplicates. In such cases, keys are deduplicated by adding a counter at end, e.g.: erc20:eth:SMT:0, erc20:eth:SMT:1. Note that the suffix is not stable, so these coins can't be reliably uniquely identified.

Duplicate Detection

Duplicate symbols are not allowed in our data. Tokens that have symbol collisions are removed from the data set before processing. The duplicate status is mentioned in support.json (see below), but it is impossible to override from there.

Duplicate detection works as follows:

  1. a symbol is split off from the shortcut string. E.g., for CAT (BlockCat), symbol is just CAT. It is compared, case-insensitive, with other coins (so WIC and WiC are considered the same symbol), and identical symbols are put into a bucket.
  2. if all coins in the bucket also have a suffix (CAT (BlockCat) and CAT (BitClave)), they are not considered duplicate.
  3. if any coin in the bucket does not have a suffix (MIT and MIT (Mychatcoin)), all coins in the bucket are considered duplicate.
  4. Duplicate tokens (coins from the erc20 group) are automatically removed from data. Duplicate non-tokens are marked but not removed. For instance, bitcoin:FTC (Feathercoin) and erc20:eth:FTC (FTC) are duplicate, and erc20:eth:FTC is removed.
  5. If two non-tokens collide with each other, it is an error that fails the CI build.

The file duplicity_overrides.json can override detection results: keys set to true are considered duplicate (in a separate bucket), keys set to false are considered non-duplicate even if auto-detected. This is useful for whitelisting a supported token explicitly, or blacklisting things that the detection can't match (for instance "Battle" and "Bitlle" have suffixes, but they are too similar).

External contributors should not make changes to duplicity_overrides.json, unless asked to.

You can use ./tools/cointool.py check -d all to inspect duplicate detection in detail.

Coins Details

The file coins_details.json is a list of all known coins with support status, market cap information and relevant links. This is the source file for https://trezor.io/coins.

You should never make changes to coins_details.json directly. Use ./tools/coins_details.py to regenerate it from known data.

If you need to change information in this file, modify the source information instead - one of the JSON files in the groups listed above, support info in support.json, or make a pull request to the tokens repository.

If you want to add a wallet link, modify the file wallets.json.

If this is not viable for some reason, or if there is no source information , you can also edit coins_details.override.json. External contributors should not touch this file unless asked to.

Support Information

We keep track of support status of each coin over our devices. That is trezor1 for Trezor One, trezor2 for Trezor T, connect for Connect and suite for Trezor Suite. In further description, the word "device" applies to Connect and Suite as well.

This information is stored in support.json. External contributors should not touch this file unless asked to.

Each coin on each device can be in one of four support states:

  • supported explicitly: coin's key is listed in the device's supported dictionary. If it's a Trezor device, it contains the firmware version from which it is supported. For connect and suite, the value is simply true.
  • unsupported explicitly: coin's key is listed in the device's unsupported dictionary. The value is a string with reason for not supporting. For connect and suite, if the key is not listed at all, it is also considered unsupported. ERC20 tokens detected as duplicates are also considered unsupported.
  • unknown: coin's key is not listed at all.

Supported coins are used in code generation (i.e., included in built firmware). Unsupported and unknown coins are excluded from code generation.

You can edit support.json manually, but it is usually better to use the support.py tool. See tools docs for details.