@exodus/assets-base

Exodus Assets Base

[![npm][npm-image]][npm-url] [npm-image]: https://img.shields.io/npm/v/@exodus/assets-base.svg?style=flat-square [npm-url]: https://www.npmjs.com/package/@exodus/assets-base

This package is intended to be for reusable asset names and basic asset properties across Exodus projects.

It's currently used in desktop, mobile, and pricing server. It will be backported to Exotrack.

Scripts

Install

yarn add @exodus/assets-base

Get Token Metadata

ct

yarn ct --network:<network> tokenAddress1 tokenAddress2 ....

Where <network> one of solana, ethereum, bsc, matic... It will print out the token metadata that should become part of assets-base tokens definitions file as well as the info that should go into asset-info.

batch-token-generator

• Have a CMC API KEY set as env variable CMC_PRO_API_KEY
• Define input.yml (see asset-lis.yml example) and

yarn batch-token-generator <path-to-input.yml>

In addition to data to paste in @exodus/assets-base, it will print out data to paste in other static files like clients' scss files.

Usage

import assets from '@exodus/assets-base'

for (const [key, val] of Object.entries(assets)) {
  console.log(`${key}: ${val.properName}`) // bitcoin: Bitcoin
}

"Base" asset vs "Tokens"

From a technical point of view, a "token" is an asset:

• such that asset.name !== asset.baseAsset.name: it is a "non-primary" asset of the chain
• that has a specific assetType property: ETHEREUM_ERC20, BINANCE_TOKEN, SOLANA_TOKEN, OTHER (ontologygas).

In some cases a token can be a "gas" token(feeAsset): the asset used to pay for fees on the given network (e.g ontologygas, vethor, tfuel).

At UX level:

• tokens that are not "gas" tokens are displayed using a chain badge (ERC20s, BEP20, tron tokens, solana tokens)
• tokens that are "gas" tokens (gas for neo chain, ontologygas for ontology chain, vethor for vechain...) don't use a chain badge.

Note that the lower level implementation of tokens (accountState, nomenclature of variables, imports...) isn't standardized yet but it is planned to unify it in the future.

Asset Attributes Documentation

The assets-base/src/<asset>.js files are where we define our supported assets. These files consists of a list of objects that more/less follow this object definition:

{
  name: 'aeron',
  baseAssetName: 'ethereum',
  feeAssetName: 'ethereum',
  assetType: 'ETHEREUM_ERC20',
  properName: 'Aeron (old)',
  decimals: 8,
  ticker: 'ARN',
  tickerAlias: 'ARNv1',
  tickerAliases: ['ARNv1'],
  units: [ base: 0, [ticker]: 18 ]
  properTicker: 'ARN',
  displayNetworkName: 'Ethereum',
  displayNetworkTicker: 'ETH',
  addresses: {
    current: '0xBA5F11b16B155792Cf3B2E6880E8706859A8AEB6',
  },
  old: true, // deprecated
}

These attributes are defined as follows:

Attribute	Definition	Desktop Usage	Mobile Usage	Pricing Server/Exchange Usage
name	The unique identifier of the asset which is used by code in both wallets to reference specific assets. Nuances are documented here.	:point_left:	:point_left:	name is notably, not used when making requests to the pricing and exchange servers; in those cases, ticker is used. See the ticker section below for details.
properName	The name of the asset, as displayed to the user in our wallets.	:point_left:	:point_left:	n/a
decimals	Many assets support fractional values. They accomplish this by using a scaling factor denoted by the value of decimals. This value indicates how many zeroes there are to the right of the decimal point the fixed-point representation of a token.	:point_left:	:point_left:	n/a
baseAssetName (optional)	The base asset name. This field only applies to tokens. The base asset of tokens is the primary asset of a blockchain. If this field is not defined it MUST fall back to name. This makes primary assets on chains without tokens their own base asset. E.g. the baseAssetName of ERC20 tokens on the Ethereum network is ethereum. E.g. the baseAssetName of bitcoin is bitcoin.	This field is mapped into an asset object to be accessed as asset.baseAsset	This field is mapped into an asset object to be accessed as asset.baseAsset	n/a
feeAssetName (optional)	The fee asset name. This is intended to be set by assets where the fee asset is not the primary network asset. If not defined, this MUST fall back to baseAssetName. E.g. the feeAssetName on the Vechain network is vethor. is	This field is mapped into an asset object to be accessed as asset.feeAsset	This field is mapped into an asset object to be accessed as asset.feeAsset	n/a
assetType	A type parameter so assets can be grouped. Used for grouping tokens of the same base asset. E.g. all Ethereum ERC20 tokens have a type value ETHEREUM_ERC20	:point_left:	:point_left:	n/a
ticker	A secondary unique identifier for assets. It is used for anything that requires the asset's symbol (eg: Bitcoin -> BTC).	On desktop it is not required to be unique in the code, however we should treat it as unique because of mobile and exchange usage.	In mobile, this attribute is used as a unique identifier to reference an asset.	In both cases, this attribute is used as an idenfiifer to reference a specific asset when interfacing with the exchange and pricing servers. Note that it is possible for two assets to have the same ticker - in these cases, the old attribute is used to differentiate between the two.
properTicker (optional)	The ticker we display to the user. This field MUST fall back to the value of ticker if not defined. It MAY only be used for display purposes.	:point_left:	:point_left:	n/a
tickerAlias (optional)	This property is specific to Ethereum-like tokens (but may be ported to others). It updates the Unit object to recognize tickerAlias as the same unit as ticker.	:point_left:	:point_left:	n/a
tickerAliases (optional)	This property is specific to Ethereum-like tokens (but may be ported to others). It behaves the same as tickerAlias except that it is an array of aliases.	:point_left:	:point_left:	n/a
units	An array used to build the UnitType for this asset/token. The keys are the unit names and the values are the number of decimals. Thus the base value (integer) has zero (0) decimals. The number of keys and their names in the array are arbitrary but the ordering is not. The keys need to be ordered by the decimals number starting with zero and encreasing. By convention the last key should be the same as the ticker. Example for an asset with 8 decimals: [ base: 0, micro: 2, [ticker]: 8 ]	:point_left:	:point_left:	n/a
displayNetworkName (optional)	The name of the network/blockchain of this asset. If not defined it MUST fall-back to the properName of the asset's baseAsset. It MAY only be used for display purposes.	:point_left:	:point_left:	n/a
displayNetworkTicker (optional)	The short name of the network/blockchain of this asset. If not defined it MUST fall back to properTicker of the asset's baseAsset. It MAY only be used for display purposes.	:point_left:	:point_left:	n/a
addresses	These are the contract addresses. They are used to detect transactions/balances/send. Without them then you wouldn't know how to look up which token this is on the ETH blockchain.	:point_left:	:point_left:	n/a
old (optional) (deprecated)	This flag exists to handle cases in which an asset has upgraded to it's own mainnet or the underlying contract has been upgraded. In these cases, there would be two assets with similar tickers and this flag would be used to imply the differentiation between the two. Details on how this works can be found here.	:point_left:	:point_left:	:point_left:

Some notes on the above from @faris:

name is required to be unique. No two assets can have the same name. This is how assets are referenced.

ticker is required to be unique on mobile. Desktop does not have that requirement but since it is on mobile, we must treat it as such on desktop too. The requests to the pricing server and the exchange use ticker (updated by @feri).

For the exchange specifically, if two assets have the same ticker, the wrong asset could activate on the exchange screen in the wallet. This would happen with mainnet swaps. For instance, the old EOS would activate instead of the new EOS.

To solve this, we added a hack which introduced the old property. The old property was meant to imply that there is an identifical ticker for a newer asset. So for the exchange, we skip over the old assets and activate the ones without the old property.