Skip to main content

Get vault data across providers

GET 
/v1/data/vaults

Returns public vault data across the supported ERC-4626-style providers on a single chain. By default this is served from the recorder origin — a DB-backed, USD-priced, paginated listing — and the response is a flat { start, count, items[] } envelope (one entry per vault, see Response shape below).

Pagination — start is the row offset and limit the page size; the origin returns up to one page per call. To walk a chain, request start=0, then start=limit, start=2*limit, … until fewer than limit items come back. This is intentional: large chains return hundreds of vaults and are paged rather than returned in one payload.

Legacy live mode — pass source=live to bypass the origin and compute the data live on-chain via multicall. This returns the older provider-keyed VaultPublicDataAll shape (one key per provider, not items[]) and ignores start/limit. It is also the automatic fallback when no origin is configured (e.g. local dev) or the origin is unreachable.

Supported providers

keysource
fluidFluid fTokens (ERC-4626 yield tokens) and vaults (NFT-position margin markets)
gearboxGearbox V3 passive PoolV3 (ERC-4626 Diesel shares)
morphoMorpho Blue MetaMorpho vaults
listaLista DAO earn vaults (Moolah-fork of MetaMorpho, BNB chain; fetched on-chain)
siloSilo V2 + V3 isolated lending vaults (GraphQL-backed)
euler-earnEuler V2 Earn vaults (ERC-4626)
lstProtocol-issued liquid-staking share tokens (Lido wstETH, Rocket Pool rETH, EtherFi weETH, Renzo ezETH, Kelp rsETH, Swell rswETH/swETH, Puffer pufETH, YieldNest ynETH, StakeWise osETH, Stader ETHx, Mantle mETH, Coinbase cbETH). Ethereum only in this drop.
savingsERC-4626 yield-bearing-stablecoin wrappers (Ethena sUSDe, Sky sUSDS/stUSDS, Maker sDAI, Reservoir wsrUSD, YieldFi yUSD, Resolv wstUSR, Angle stUSD/stEUR, Falcon sUSDf, InfiniFi siUSD, Maple syrupUSDC/syrupUSDT). Plus Avant savUSD on Avalanche and YO yoETH on Base.
yearnYearn V3 vaults (VaultV3 + TokenizedStrategy ERC-4626) on Ethereum, Polygon, Base, Arbitrum, Gnosis, Sonic, Katana. Discovered + priced via the yDaemon API.

Response shape

Default (origin) mode: { start, count, items[] } where each item is a normalized, USD-priced vault record: { chainId, provider, vaultAddress, underlying, symbol, name, displayName, curatorName, decimals, assetDecimals, dataTs, updatedAt, rates: { depositRate, rewardsRate, totalRate, fee }, tvl: { totalAssets, totalSupply, totalAssetsFormatted, totalAssetsUsd }, liquidity: { liquidity, liquidityFormatted, liquidityUsd }, underlyingInfo, vaultInfo, curatorEntity, providerMeta, … }. totalAssetsUsd / liquidityUsd are computed by the recorder from its own price store (see margin-fetcher DATABASE_INTEGRATION.md).

Three metadata bundles travel with every item (mirroring lending's underlyingInfo + lenderInfo):

  • underlyingInfo — the underlying token: { asset: { chainId, address, symbol, name, decimals, logoURI, assetGroup, currencyId, props }, prices: { priceUsd, priceTs } }.
  • vaultInfo — the vault's own identity: { address, symbol, name, logoURI, assetGroup, yieldProfile, denomination }. logoURI is resolved from the share token's token-list entry, falling back to the underlying asset's logo. name uses the branded share-token name for lst/savings (e.g. etherFi weETH) and the curated label elsewhere (e.g. Steakhouse USDC).
  • curatorEntity — the curator's { name, logoUri } from the curator registry, or null.

Legacy live mode (source=live): the top-level object is keyed by provider name. Each provider's value is a free-form payload from @1delta/margin-fetcher's getVaultPublicDataAll — schemas diverge per provider (see the package's types for exact field shapes). Common fields across most providers: vault/share token address, underlying asset, supply rate, total assets / supply, and provider-specific metadata (e.g. Fluid vaultId, Silo siloAddress).

LST deposit metadata (providerMeta on lst items)

lst records carry the data needed to build a deposit without reading SDK source:

  • isMintable — false ⇒ no permissionless on-chain mint (e.g. cbETH); skip the action endpoint.
  • mintContract — the mint target.
  • exchangeRate / convertToShares — to compute expected output and a minOut.
  • isRebasing — output-balance semantics (stETH/eETH rebase; wstETH/weETH don't).
  • mintInputAsset — the primary pay asset (native or an ERC-20 address).
  • acceptedInputs[] — the full accept-set, each { asset: "native"|"0x…", symbol?, mode: "direct"|"wrap"|"submit-wrap", needs?: string[] }. asset is what to pass as payAsset; needs lists the option query params that path requires. This is the machine-readable answer to "what can I pay with"; drive the deposit request off it. See GET /v1/actions/vaults/lst for the build flow.
  • delegation — present only when the deposit requires/allows picking a validator/group/node/pool: { required, kind, optionKey, default, source }. Absent ⇒ pooled (no picker needed). When present and source: "endpoint", fetch the selectable set from /v1/data/vaults/validators and send the chosen id back to the deposit as the param named by delegation.optionKey. This is the flag that tells the UI whether a validator fetch is needed. Attached by the worker in both origin and source=live modes.

Related action endpoints

  • GET /v1/actions/vaults/deposit — ERC-4626 deposit via the 1delta Composer, with optional Fluid native-deposit path.
  • GET /v1/actions/vaults/withdraw — ERC-4626 withdraw via the 1delta Composer, with native-unwrap support.
  • GET /v1/actions/vaults/lst — LST/LRT mint · withdraw-request · claim · cancel, driven by the acceptedInputs above.

For Fluid margin vaults (the NFT-position kind, not fTokens), the lending action endpoints (/v1/actions/lending/{deposit,withdraw,borrow,repay}) are the right surface — they understand the per-vault FLUID_<chainId>_<vaultId> lender keys and Fluid's NFT ownership model (including the pre-flight ownerOf validation for deposit-to-existing-NFT with a custom receiver).

Request​

Responses​

Origin mode: { start, count, items[] } paginated, USD-priced vault records. Legacy live mode (source=live): provider-keyed vault data, with failed providers omitted (the worker logs a warning but does not propagate per-provider errors).