dimensions.tokens contains one row per token: one contract on one chain. It covers every token our price feed covers, and every other table about tokens joins to it.
Columns
| Column | Type | Description |
|---|---|---|
token_id | STRING | Token identifier: {token_address}-{chain_id}. |
asset_id | STRING | The curated asset this token is a deployment of. Empty where no one has matched it. |
chain_id | STRING | Chain the contract is deployed on. |
token_address | STRING | Contract address, lowercase. |
symbol | STRING | Symbol read from the contract, unverified. |
name | STRING | Name read from the contract, unverified. |
decimals | INT64 | How many decimal places to move to turn a raw amount into a token amount. |
created_at | TIMESTAMP | When the token launched onchain. |
bridged | BOOL | Whether the deployment is a bridged wrapper. Empty where the token has not been matched to an asset. |
Sample queries
- By address
- By asset
Look up a token by its address. The address identifies the token.
symbol and name are read from the contract without verification.Notes
symbol and name are text read straight off the contract, and nobody has checked them. Any contract can call itself USDC, and thousands do. Work out what a token is from token_address, or from asset_id where somebody has already made that judgment.
token_id is the key every other token table joins on. A source row with no address would produce an empty key that matches nothing, so those rows are dropped before they get here. Every row carries a real address.
asset_id and bridged come from the curated asset registry, and are empty for the long tail. A token that has been matched also appears as a deployment row in dimensions.asset_tokens, which says more about it, including bridged_status. Assets โธ Registry covers that layer.