tRPC Asset Taxonomy API

• 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

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}}'

curl --request POST \
  --url 'https://api.glider.fi/v1/trpc/assetTaxonomy.resolveSymbol' \
  --header 'content-type: application/json' \
  --data '{"json":{"symbol":"AAVE","availabilityFilter":"indexed"}}'

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"}}'

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.