Skip to main content
The catalogue is uatu’s view of what is swappable where. It is populated by the seeding CLI and read back through the /blockchains endpoints.

The four objects

A network uatu supports. Carries name, slug, chainId, symbol, nativeToken, blockExplorer, rpcUrl, ecosystem and blockChainLogo, plus the tokens array embedded within it.The chain object does not carry its DEXes. Use GET /blockchains/dex for those.ecosystem says which virtual machine the chain runs: evm, tvm for TRON or svm for Solana. It is what tells you how to read the chain’s addresses.rpcUrl comes back empty from the hosted API. The endpoint a deployment prices against is its own configuration, not public data.
An ERC-20 or native asset: address, symbol, name, slug, decimals, logo and the blockchainId it belongs to. decimals is what converts between the integer and display amounts on a quote.
A protocol deployment on one chain. Beyond name, slug and version, it holds the contract addresses uatu prices and encodes against: v2FactoryAddress, v2RouterAddress, v3FactoryAddress, v3RouterAddress, v3QuoterAddress, universalRouterAddress, permit2Address and settlementAddress.
A discovered liquidity pool: pairAddress, poolType, poolFee, tickSpacing, the baseToken / quoteToken pair with their balances, liquidity and liquidityInUsd breakdowns, marketCap and isActivePool.

Reading the catalogue

GET /blockchains filters by chainId, by slug, or by both, and omitting both lists every chain. Either one identifies a single chain on its own. GET /blockchains/dex takes the same two filters, but there you want both: a slug identifies a DEX only within a single chain, so uniswap on Ethereum and uniswap on Base are different deployments with different addresses. The result is always an array, and a protocol appears once per version, so chainId=1&slug=uniswap returns two entries: Uniswap v2 and v3.

The response envelope

Every endpoint wraps its payload in the same shape:
message is always present and describes what was fetched, such as Tokens fetched successfully or Pools fetched successfully. data holds the result, an object or an array depending on the endpoint, and is absent on errors, where message carries the reason and code mirrors the HTTP status.

How pools get there

Chains, tokens and DEXes are declared in JSON definitions embedded into the binary at build time. Pools are not: the seed command walks each chain’s token list, queries the v2 and v3 factories over RPC to find pools that actually exist, and persists what it finds. That means the catalogue reflects the last seed run, so what you can quote is what the seeder found on-chain at that point.