> ## Documentation Index > Fetch the complete documentation index at: https://docs.glider.fi/llms.txt > Use this file to discover all available pages before exploring further. # tRPC Asset Taxonomy API > Canonical asset lookup for asset products, derivative markets, and onchain routes. The `assetTaxonomy.*` namespace resolves a user-facing query such as `TSLA`, `NVDA`, or `AAVE` to a canonical asset, then returns products or issuances, derivative markets, and explicit onchain token representations linked to that asset. * Base endpoint: `POST /v1/trpc` * Namespace: `assetTaxonomy.*` * Auth: public * Primary model: canonical asset first, products/issuances or explicit crypto token representations and derivative markets second, exact onchain routes third * Compatibility: `searchIssuedAssets`, `listIssuedAssets`, and `getIssuedAssetsForUnderlying` remain available as legacy aliases while consumers migrate to the generic asset-universe procedure names. ## Procedures * `assetTaxonomy.resolveSymbol` * Purpose: resolve a human-facing `/symbol/:symbol` alias to one canonical underlying without asking the client to race multiple searches * Input: * required `symbol`, 1-128 characters * optional `assetClass`, for example `tradfi`, `equity`, `fund`, or `crypto`; when omitted the resolver checks TradFi first, then crypto * optional `availabilityFilter`, `indexed` or `glider_supported`, default `indexed` * Resolution order: 1. exact TradFi canonical/identifier/product symbol 2. exact crypto canonical/identifier/product/token symbol * Response: * `status`: `resolved`, `not_found`, or `invalid_symbol` * `selected`: the resolved canonical-underlying group, or `null` * `selectedReason`: why the selected canonical won, such as `tradfi_exact_symbol` or `crypto_exact_symbol` * `candidates`: scored exact-match candidates considered by the resolver * `cache`: process-local decision-cache metadata, including TTL and whether the response was served from cache * `strategy`: current resolver strategy metadata. Today this is exact-match only with TradFi priority and no manual override table. * `assetTaxonomy.resolveSymbols` * Purpose: batch `resolveSymbol` for collection hydration and other clients that already know the exact symbols they need. This avoids sending one tRPC request per symbol while preserving the same exact-match resolver, cache metadata, and candidate scoring. * Input: * required `symbols`, 1-50 strings, each 1-128 characters * optional `assetClass`, for example `tradfi`, `equity`, `fund`, or `crypto` * optional `availabilityFilter`, `indexed` or `glider_supported`, default `indexed` * Response: * `results`: ordered `resolveSymbol` responses for the normalized, deduplicated symbol list. Invalid or duplicate symbols are not returned. * `assetTaxonomy.searchAssetUniverse` * Purpose: search canonical assets by symbol, provider identifier, product symbol, product name, or canonical asset name * Input: * required `query`, 1-128 characters * optional `limit`, 1-25, default `10` * optional `assetClass`, for example `equity` or `crypto` * optional `availabilityFilter`, `indexed` or `glider_supported` * Response: * `items[].underlying`: canonical symbol, name, asset class, instrument type, country, currency, exchange, product count, onchain route count, supported product count, supported route count, token representation count, derivative market counts, SIC description, and optional `sectorClassification` * `items[].underlying.sectorClassification`: current Glider-owned display sector for the canonical asset when available. The object includes `taxonomy`, `displaySector`, `source`, `confidence`, source key fields, original provider industry fields, SIC audit fields, resolver version, and resolution timestamp. Tokenized products inherit this through their canonical underlying; product rows do not carry a separate sector. * `items[].marketDataIdentifiers`: provider mappings such as Massive symbols * `items[].issuedProducts`: product or issuance rows such as Circle USDC, Aave aUSDC, Ondo, or xStocks. Each product includes `relationshipType` so direct issuer representations, wrapped tokens, staking derivatives, receipt tokens, and synthetic products can be separated in UX and policy. * `items[].issuedProducts[].assets`: chain-scoped CAIP assets/contracts * `items[].derivativeMarkets`: perpetual/futures-style markets such as Hyperliquid or Ondo Perps markets for the same canonical asset * `items[].tokenRepresentations`: explicit chain-scoped crypto token representations such as native assets, primary tokens, bridged tokens, wrapped tokens, or issuer representations. Each row includes `gliderSupported` so clients can distinguish indexed routes from routes available in supported Glider flows; this flag is backed by `core.asset_token_subject_links.is_glider_supported`, not inferred from the presence of an indexed token link. * `assetTaxonomy.listAssetUniverse` * Purpose: page through canonical asset groups with the same grouped response shape as `searchAssetUniverse` * Input: * optional `cursor`, default `0` * optional `limit`, 1-100, default `48` * optional `includeTotalCount`, default `true` * optional `assetClass`, category, and `availabilityFilter` * `assetTaxonomy.getAssetUniverseForCanonicalAsset` * Purpose: load the same grouped asset-universe surface for one canonical asset id * Input: * required `assetCanonicalId`, UUID * Response: * `item`, or `null` when the canonical asset is not found ## Example Calls Search for Tesla asset-universe products: ```bash theme={null} curl --request POST \ --url 'https://api.glider.fi/v1/trpc/assetTaxonomy.searchAssetUniverse' \ --header 'content-type: application/json' \ --data '{"json":{"query":"TSLA","assetClass":"equity","limit":5}}' ``` Resolve a symbol route alias: ```bash theme={null} curl --request POST \ --url 'https://api.glider.fi/v1/trpc/assetTaxonomy.resolveSymbol' \ --header 'content-type: application/json' \ --data '{"json":{"symbol":"AAVE","availabilityFilter":"indexed"}}' ``` Resolve several stock route aliases in one request: ```bash theme={null} curl --request POST \ --url 'https://api.glider.fi/v1/trpc/assetTaxonomy.resolveSymbols' \ --header 'content-type: application/json' \ --data '{"json":{"symbols":["AAPL","MSFT","NVDA"],"assetClass":"tradfi","availabilityFilter":"glider_supported"}}' ``` Load one canonical asset: ```bash theme={null} curl --request POST \ --url 'https://api.glider.fi/v1/trpc/assetTaxonomy.getAssetUniverseForCanonicalAsset' \ --header 'content-type: application/json' \ --data '{"json":{"assetCanonicalId":"11111111-1111-4111-8111-111111111111"}}' ``` ## Runtime Notes * The response is intentionally grouped for asset-first UX. A UI should render one `TSLA` result, then show Ondo, xStocks, and future products under that asset. For crypto, a UI should render one canonical symbol such as `USDC` or `AAVE`, then show direct tokens, wrapped tokens, staked tokens, and yield-bearing receipt products under it. * Yield-bearing receipt tokens such as Aave `aUSDC` or Compound `cUSDC` should stay under the supplied canonical asset (`USDC`) with `relationshipType = receipt_token`. They are not cash-like default routes and should be selected only when the user asks for yield/receipt exposure, already holds that exact token, or provides an exact token/contract preference. * Tokenized equities should stay grouped as: canonical stock underlying -> issuer product -> chain-scoped token assets. For example, `NVDA` may have Ondo and xStocks products under the same underlying, and the Ondo `NVDAon` product may link to multiple EVM/SVM assets. Do not seed tokenized stock contracts directly as flat canonical token representations when an issuer product is known. * Equity sector filters prefer the current `internal_display_sector_v1` classification on the canonical asset. They fall back to legacy SIC-description matching only while a canonical classification row is missing during rebuild/backfill. `sicDescription` remains available for audit and backcompat during the migration. * Derivative markets are separate from both products and token representations. A canonical asset such as `NVDA` can have spot issuer products and perpetual/futures markets side by side. A Hyperliquid `NVDA-PERP` market is a market instrument, not an onchain token asset. * Ondo Global Markets rows are backfilled into the new model by the migration so existing tokenized equity data can resolve through the canonical layer. * Market-data integrations should use `marketDataIdentifiers` instead of deriving provider symbols from issuer-specific product data. * `/symbol/:symbol` should use `assetTaxonomy.resolveSymbol`, not a broad search. Batch hydration paths should use `assetTaxonomy.resolveSymbols`. The resolver is intentionally exact-match and cached. It gives TradFi aliases priority over crypto aliases so a crypto token claiming a stock ticker does not displace the stock page. * Crypto identity is not inferred from symbol at request time. Concrete tokens appear under canonical crypto symbols only when an explicit `core.asset_token_subject_links` relationship exists. * Canonical `glider_supported` filtering includes both supported products and explicitly supported direct token representations. This lets native or primary crypto routes make a canonical asset selectable even when there is no issuer product wrapper, without treating every indexed token link as executable. * Curated crypto seeds can attach `coingecko` identifiers to canonical assets. CoinGecko-style aggregate market data should live at the canonical crypto subject level, while trade actions continue to resolve to exact chain assets. * The crypto seed can optionally fetch CoinGecko `/coins/{id}` platform contracts and link only already-known Postgres `assets` rows by explicit chain/address matches. It does not create executable assets from CoinGecko data because decimals and trade metadata must remain authoritative in Postgres. * Platform-link relationship types are curated by Glider. Provider platform metadata identifies candidate chain/address matches, while the seed controls whether those matches are primary, bridged, wrapped, native, or issuer representations.