# MCP Server: Onchain Yield Tools for Claude, Cursor, and Any MCP Client
Source: https://docs.vaults.fyi/ai-agents/mcp-server
Connect Claude Desktop, Claude Code, Cursor, and any streamable-HTTP MCP client to the full Vaults.fyi data and transaction surface — discovery, history, recommendations, position tracking, and onchain transaction building.
The Vaults.fyi MCP server connects MCP-compatible clients to the full Vaults.fyi data and transaction surface. Discovery, history, recommendations, position tracking, and transaction building are all callable as tools — your client decides which to use and how to chain them.
Hosted at `https://mcp.vaults.fyi/mcp` over streamable HTTP. 38 tools. Bearer-token auth. No server-side private keys: every transaction tool returns calldata for your client to sign.
## What people use it for
A few prompts that exercise meaningful tool chains:
> "Find me the best USDC yields right now with TVL over \$10M and no active warnings."
> "What yields beat the USDC benchmark by more than 200 bps over the last 30 days?"
> "Show me Steakhouse and Gauntlet curated Morpho vaults across all stablecoins."
> "Which Aave v3 markets have the highest USDC supply APY across networks?"
> "I'd consider sUSDe and sUSDS — find vaults with composite APY above 8% accounting for the underlying asset rate."
> "Plot Fluid USD Vault APY against the USDC benchmark for the last 90 days."
> "Audit positions for 0xabc… — total deposited, current value, unclaimed rewards, and any flagged exposure."
> "Build a deposit of 10,000 USDC into the highest-rated Morpho vault on Base and return the calldata."
## Quickstart
You'll need a Vaults.fyi API key. Request one at [portal.vaults.fyi](https://portal.vaults.fyi/).
### Recommended setup
Configure Vaults.fyi across supported MCP clients with one command:
```bash theme={null}
npx @vaultsfyi/scripts init-mcp --api-key YOUR_VAULTS_API_KEY
```
To configure one client:
```bash theme={null}
npx @vaultsfyi/scripts init-mcp --api-key YOUR_VAULTS_API_KEY --client cursor
```
The installer creates or updates your local MCP config and adds the `vaults-fyi` server entry without removing existing servers.
Supported clients: Claude Desktop, Cursor, Claude Code, Windsurf, VS Code, Zed, Amazon Q, and GitHub Copilot CLI.
Restart your client after installation. The 38 Vaults.fyi tools should appear in the client's MCP tools list.
Without `--api-key`, the installer prompts interactively. In CI and other non-interactive environments, pass `--api-key`.
### Manual setup
Claude Desktop may require a local bridge for remote MCP servers. Add Vaults.fyi through [`mcp-remote`](https://www.npmjs.com/package/mcp-remote) in your Claude Desktop config (`~/Library/Application Support/Claude/claude_desktop_config.json` on macOS, `%APPDATA%\Claude\claude_desktop_config.json` on Windows):
```json claude_desktop_config.json theme={null}
{
"mcpServers": {
"vaults-fyi": {
"command": "npx",
"args": [
"-y",
"mcp-remote@latest",
"https://mcp.vaults.fyi/mcp",
"--header",
"Authorization:${VAULTS_AUTH_HEADER}",
"--transport",
"http-only"
],
"env": {
"VAULTS_AUTH_HEADER": "Bearer YOUR_VAULTS_API_KEY"
}
}
}
}
```
Restart Claude Desktop. The 38 Vaults.fyi tools will appear in the tools menu.
Add the server with one command:
```bash theme={null}
claude mcp add --transport http vaults-fyi https://mcp.vaults.fyi/mcp \
--header "Authorization: Bearer YOUR_VAULTS_API_KEY"
```
Verify with `claude mcp list`.
Any client that supports streamable-HTTP MCP works. Point it at `https://mcp.vaults.fyi/mcp` and pass `Authorization: Bearer YOUR_VAULTS_API_KEY` as a header.
Health check:
```bash theme={null}
curl -i https://mcp.vaults.fyi/health
```
## What you can do
Six capability surfaces, each backed by several tools:
Search across networks, protocols, assets, curators, and tags. Filter by TVL, APY, score, and active warnings in a single structured query.
Reputation Scores and inline flags (bad debt exposure, qualified-investor gates, depegs, recent incidents) ship with the data. No separate lookup.
APY, TVL, share-price, and total-return time series for any vault. Asset-price history and benchmark APY for relative performance.
Deposit, withdraw, claim rewards, and approve. Tools return decoded calldata and signing instructions; your client signs and submits.
Aggregate positions and rewards across networks for any address. Drill into per-position cost basis and event history.
Approve, transfer, wrap, and unwrap as primitives — useful when an agent is composing multi-step flows.
## Tool inventory
38 tools, grouped by purpose. Each returns structured JSON optimized for agent consumption.
| Tool | Purpose |
| - | - |
| `vaults_search` | Filtered search across vaults (TVL, APY, score, curator, tags, warnings) |
| `vaults_list` | Paginated full vault list |
| `networks` | Supported chains |
| `protocols` | Supported protocols |
| `assets` | Supported assets |
| `curators` | Named curators (79+) |
| `tags` | Vault tags (e.g., `top-curator`, `lst`, `rwa`) |
| Tool | Purpose |
| - | - |
| `vault_details` | Full vault metadata, including flags and Reputation Score |
| `vault_apy` | Current APY (headline, base, rewards, composite) |
| `vault_tvl` | Current TVL |
| Tool | Purpose |
| - | - |
| `vault_apy_history` | APY time series |
| `vault_tvl_history` | TVL time series |
| `vault_share_price_history` | Share-price time series |
| `vault_history` | Combined APY/TVL/share-price |
| `vault_returns` | Realized total returns |
| `asset_price_history` | Underlying asset price |
| `benchmark_apy` | Asset-level benchmark APY |
| `benchmark_apy_history` | Benchmark APY time series |
| Tool | Purpose |
| - | - |
| `best_vault` | Single best-fit vault for a given asset/criteria |
| `best_deposit_options` | Ranked deposit options |
| Tool | Purpose |
| - | - |
| `positions` | All positions for an address |
| `position_details` | Per-position cost basis, current value, P\&L |
| `wallet_balances` | Token balances across networks |
| `token_balance` | Single token balance |
| `user_events` | Deposit/withdraw/claim history |
| `rewards` | Outstanding reward entitlements |
| Tool | Purpose |
| - | - |
| `transaction_context` | Pre-flight context (allowance, balances, gas) |
| `build_vault_tx` | Deposit/withdraw calldata with decoded steps |
| `build_claim_rewards` | Claim calldata for a single vault |
| `claim_all_rewards` | Multi-vault claim calldata |
| `withdraw_all_positions` | Multi-vault withdraw calldata |
| `submit_tx_hash` | Register a submitted hash for status tracking |
| `get_transaction_status` | Status of a tracked transaction |
| Tool | Purpose |
| - | - |
| `approve_erc20` | ERC-20 approval calldata |
| `transfer_erc20` | ERC-20 transfer calldata |
| `transfer_native` | Native transfer calldata |
| `wrap_native` | Wrap native to wrapped equivalent |
| `unwrap_native` | Unwrap |
## Authentication
Every request requires a bearer token:
```
Authorization: Bearer YOUR_VAULTS_API_KEY
```
The API key is forwarded only to Vaults.fyi API calls and is never placed in signing URLs or transaction payloads.
Request a key at [portal.vaults.fyi](https://portal.vaults.fyi/). For keyless pay-per-request access via USDC on Base, see [x402](/ai-agents/x402).
## Signing model
Transaction tools (`build_vault_tx`, `build_claim_rewards`, `approve_erc20`, etc.) return structured calldata, not signed transactions. The server holds no private keys.
Each response includes:
* `stepDecodings` — human-readable description of each call
* `signingInstructions` — step-by-step guidance for the signer
* `signingPaths` — supported signing surfaces (e.g., wallet, [OWS](https://docs.openwallet.sh/))
* `submitTool` — the tool to call after signing (`submit_tx_hash`)
* `statusTool` — the tool to call for status (`get_transaction_status`)
This keeps key custody with the client. Agents that integrate with [OpenWallet Standard](https://docs.openwallet.sh/) can sign and submit without leaving the conversation.
## Going further
The full surface area for agents: MCP, x402, and the LLM-optimized API reference.
Pay-per-request access on Base, no API key required.
Full reference at `llms.txt` and `llms-full.txt`.
Underlying REST API the MCP wraps.
# AI Agents & LLMs: Onchain Yield with Vaults.fyi
Source: https://docs.vaults.fyi/ai-agents/overview
Use the Vaults.fyi API to build AI agents that discover, evaluate, execute, and manage DeFi yield strategies — no protocol-specific logic required.
Vaults.fyi gives AI agents and LLMs a single, structured interface to the onchain yield market. Instead of writing protocol-specific integrations for each of the 80+ supported protocols, including Solana protocols available through the Beta SVM API, you call one API that handles discovery, evaluation, transaction preparation, and portfolio management — and returns data in a consistent format your agent can reason over directly.
The full API reference optimized for LLM consumption is available at [llms.txt](https://api.vaults.fyi/llms.txt). This file contains endpoint specifications, SDK usage, and best practices for credit-efficient development.
## What your agent can do
* **Discover yield opportunities** — Query vaults filtered by network, asset, protocol, APY range, or TVL. Every result includes standardized market data sourced hourly from onchain contracts.
* **Evaluate risk** — Use the Reputation Score and benchmark rates to compare vaults against money-market baselines and assess protocol risk without custom logic.
* **Execute transactions** — Receive ready-to-sign deposit, redeem, and reward-claim payloads. No intermediary contracts, fully non-custodial.
* **Handle advanced protocols** — The API abstracts deferred deposits, delayed withdrawals, and multi-step flows so your agent doesn't need to model each protocol's behavior.
* **Claim rewards** — Merkl reward claiming is supported via `/v2/transactions/rewards/claim/{userAddress}`.
* **Manage portfolios** — Track user positions, detect idle assets, and surface personalized opportunities matched to wallet holdings via portfolio endpoints.
## Key advantages
**Single API, no protocol-specific logic.** One integration covers 1,000+ vaults across 80+ protocols, including Solana/SVM vault coverage in Beta. You don't need to maintain separate adapters or ABIs per protocol.
**Ready-to-sign transaction payloads.** Deposit and redeem endpoints return fully formed, signable transaction objects. Your agent submits them directly — no transaction construction required.
**Reputation scores and benchmarks for risk assessment.** Every vault exposes a reputation score and is benchmarked against reference rates. Your agent can filter by risk tier without custom scoring logic.
**Advanced protocol handling is abstracted.** Deferred deposits, delayed withdrawals, and queued redemptions are handled by the API layer. Your agent sees a consistent interface regardless of the underlying protocol's mechanics.
**Reward claiming via Merkl.** The API integrates Merkl reward data and generates ready-to-submit claim transactions, so agents can manage the full yield lifecycle including harvesting.
**Portfolio management endpoints.** Endpoints like `/v2/portfolio/positions/{userAddress}`, `/v2/portfolio/idle-assets/{userAddress}`, and `/v2/portfolio/best-vault/{userAddress}` give agents the full context they need to make allocation decisions for a given wallet.
## Integration options
Choose the integration method that fits your workflow:
Connect Claude Desktop, Claude Code, Cursor, or any streamable-HTTP MCP client to the full Vaults.fyi tool surface. 38 tools for discovery, history, recommendations, position tracking, and onchain transaction building.
Access the API without an API key using the x402 payment protocol. Your agent pays per request in USDC on Base — ideal for autonomous systems with their own onchain wallets.
# Keyless API Access with x402 Pay-Per-Request
Source: https://docs.vaults.fyi/ai-agents/x402
Use the x402 protocol to access the Vaults.fyi API without an API key — pay per request in USDC on Base from your agent's onchain wallet.
The Vaults.fyi API supports the [x402 payment protocol](https://www.x402.org/) for keyless, pay-per-request access using USDC on Base. Instead of managing API keys, your agent pays for each request directly from its onchain wallet. This makes x402 ideal for autonomous agents and systems that already hold assets onchain.
## How it works
1. Send a request with the `x-402-auth: true` header — no API key needed.
2. Receive a `402 Payment Required` response containing payment details, including the current `maxAmountRequired`.
3. Sign a USDC payment on Base using your agent's wallet.
4. Resend the original request with the `X-Payment` proof header attached.
5. Receive a `200` response with the requested data.
The [`x402`](https://www.npmjs.com/package/x402) JavaScript and Python libraries handle this payment flow automatically, so you don't need to implement the handshake manually.
## Quick start
Install the x402 client library and make your first request:
```javascript javascript theme={null}
import { wrapAxios } from "x402/axios";
import axios from "axios";
import { createWalletClient, http } from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { base } from "viem/chains";
const account = privateKeyToAccount(process.env.PRIVATE_KEY);
const walletClient = createWalletClient({
account,
chain: base,
transport: http(),
});
const client = wrapAxios(axios, walletClient);
const response = await client.get("https://api.vaults.fyi/v2/vaults", {
headers: { "x-402-auth": "true" },
});
```
```python python theme={null}
from x402.client import Client
client = Client(private_key=PRIVATE_KEY, chain="base")
response = client.get(
"https://api.vaults.fyi/v2/vaults",
headers={"x-402-auth": "true"},
)
```
For a complete working example, see the [Agentic DeFi repo](https://github.com/WallfacerLabs/agentic_defi).
## Pricing
All prices are in USDC on Base, charged per request. Payment is in USDC raw units (6 decimals) — for example, `5000` = \$0.005 USDC. The `402` response always contains the current `maxAmountRequired`. Prices are subject to change.
| Price | Endpoints |
| - | - |
| \$0.005 | `/v2/networks`, `/v2/vaults`, `/v2/tags`, `/v2/assets`, `/v2/curators` |
| \$0.01 | `/v2/detailed-vaults/{network}/{vaultId}/apy`, `/v2/detailed-vaults/{network}/{vaultId}/tvl` |
| \$0.02 | `/v2/detailed-vaults/{network}/{vaultId}`, `/v2/portfolio/positions/{userAddress}` |
| \$0.025 | `/v2/portfolio/best-deposit-options/{userAddress}`, `/v2/portfolio/idle-assets/{userAddress}`, `/v2/portfolio/best-vault/{userAddress}` |
| \$0.05 | `/v2/transactions/*`, `/v2/transactions/rewards/claim/{userAddress}` |
| \$0.75 | `/v2/detailed-vaults` (paginated list of all vaults) |
| Free | `/v2/health` |
`/v2/historical/*` endpoints are not available via x402 and require an API key. [Sign up](https://portal.vaults.fyi/signup) to get a key and access historical data endpoints.
# Get advanced vault analytics
Source: https://docs.vaults.fyi/api-reference/advanced-analytics/get-advanced-vault-analytics
https://api.vaults.fyi/beta/documentation/json post /beta/advanced-analytics/{network}/{vaultId}
Returns advanced analytics for a single vault. Use the POST body `select` to opt into analytics sections — max drawdown, withdrawal pause ratio, composition, utilization rate and/or the full v2 `detailedVault` payload.
# List advanced vault analytics
Source: https://docs.vaults.fyi/api-reference/advanced-analytics/list-advanced-vault-analytics
https://api.vaults.fyi/beta/documentation/json post /beta/advanced-analytics
Returns a paginated list of vaults with advanced analytics. Filtering/pagination is passed via querystring (mirrors the v2 detailed-vaults list endpoint). Use the POST body `select` to opt into per-item analytics sections — max drawdown, withdrawal pause ratio, utilization rate and/or the full v2 `detailedVault` payload. Pricing has a 1 credit request base and scales per returned item: each item costs 2 if `maxDrawdown` is included + 3 if `detailedVault` is included + 2 if `withdrawalPauseRatio` is included + 3 if `composition` is included + 3 if `utilizationRate` is included.
# Alpha
Source: https://docs.vaults.fyi/api-reference/alpha
Early access features. These endpoints may change without notice and are not covered by stability guarantees.
Alpha endpoints are experimental and subject to breaking changes at any time. They are not included in the standard API changelog. Use them to explore upcoming features, not in production flows that require stability.
Alpha features are accessible using your existing API key. The endpoints below cover upcoming product areas that are still in active development.
Where an endpoint supports `allowedProtocols` or `disallowedProtocols`, each value may be either a broad protocol name or a full [protocol ID](/concepts/supported-protocols#protocol-names-and-ids) for one product and version.
## Cross-chain intents
Quote, execute, and track intent-based cross-chain position changes. This is the higher-level cross-chain transaction flow for products that want to move users into vault positions without building every bridge and execution step themselves.
| Capability | How to call | Required inputs |
| - | - | - |
| Create a transaction intent quote | `POST /alpha/transactions/intent/getQuote` | JSON body: `userAddress`, `inputPosition`, `outputPosition`, `feeToken`, `provider` |
| Execute a transaction intent | `POST /alpha/transactions/intent/execute` | JSON body: `payloadSignature`, `provider`. Optional body: `originalQuote` |
| Check transaction intent status | `GET /alpha/transactions/intent/status` | Query: `crosschainTransactionId`, `provider` |
## CCTP bridge
Build USDC bridge flows with transaction context, calldata generation, in-transit tracking, and bridge status checks.
| Capability | How to call | Required inputs |
| - | - | - |
| Check CCTP balances and bridge context | `GET /alpha/transactions/cctp/context/{userAddress}/{srcNetwork}/{dstNetwork}/{assetAddress}` | Path: `userAddress`, `srcNetwork`, `dstNetwork`, `assetAddress` |
| Build a CCTP bridge transaction | `GET /alpha/transactions/cctp/transactions/{action}/{userAddress}/{srcNetwork}/{dstNetwork}` | Path: `action`, `userAddress`, `srcNetwork`, `dstNetwork`. Optional query includes `assetAddress`, `amount`, `recipientAddress`, `transferType`, `useForwarding`, `message`, and `attestation` depending on the bridge step |
| List CCTP transfers in transit | `GET /alpha/transactions/cctp/money-in-transit/{userAddress}` | Path: `userAddress` |
| Check CCTP transfer status | `GET /alpha/transactions/cctp/status` | Query: `burnTxHash`, `srcNetwork` |
## Historical flows
Inspect daily vault inflows and outflows for flow analytics, dashboards, and monitoring.
| Capability | How to call | Required inputs |
| - | - | - |
| Fetch historical daily vault inflows and outflows | `GET /alpha/historical/{network}/{vaultId}/daily-flows` | Path: `network`, `vaultId`. Query: `fromDate`, `toDate`. Optional query: `page`, `perPage` |
## Historical positions
Fetch a wallet's historical vault positions for account history, retention analytics, and portfolio timeline views.
| Capability | How to call | Required inputs |
| - | - | - |
| List historical positions for a wallet | `GET /alpha/historical-positions/{userAddress}` | Path: `userAddress`. Optional query: `fromTimestamp`, `toTimestamp` |
## Historical balances
Reconstruct a wallet's vault balances at a specific point in time. This is useful for historical account snapshots, period reporting, retention analysis, and backtesting portfolio views against previous user exposure.
| Capability | How to call | Required inputs |
| - | - | - |
| Fetch historical balances for a wallet | `GET /alpha/historical-balances/{userAddress}/{timestamp}` | Path: `userAddress`, `timestamp`. Optional query filters include `allowedNetworks`, `disallowedNetworks`, `allowedAssets`, `disallowedAssets`, `allowedProtocols`, `disallowedProtocols`, `minTvl`, `maxTvl`, `minApy`, `maxApy`, `minVaultScore`, `tags`, `curators`, `onlyTransactional`, `onlyAppFeatured`, `allowCorrupted`, `allowVaultsWithWarnings`, `minUsdAssetValueThreshold`, `apyInterval`, `sortBy`, and `sortOrder` |
## Holders
Analyze vault holders and LP-token balances for concentration, ownership, and distribution views.
| Capability | How to call | Required inputs |
| - | - | - |
| List vault holders and LP-token balances | `GET /alpha/{network}/{vaultId}/holders` | Path: `network`, `vaultId`. Optional query: `page`, `perPage` |
If you're interested in any of these areas, [sign up](https://portal.vaults.fyi/signup) to get an API key and start using Alpha endpoints. Existing customers can reach the team via [Telegram](https://t.me/vaultsfyisupport) or [email](mailto:support@wallfacer.io) to share feedback.
# Benchmarks
Source: https://docs.vaults.fyi/api-reference/benchmarks
DeFi benchmark APY rates for USD and ETH strategies, including historical time-series.
Reference rates representing baseline DeFi yield for USD and ETH strategies. Use these to compare vault performance against the broader market.
| Capability | How to call | Required inputs |
| - | - | - |
| Fetch the current benchmark rate for a network | [`GET /v2/benchmarks/{network}`](/api-reference/benchmarks/get-benchmark-rate) | Path: `network`. Query: `code` |
| Fetch historical benchmark rates for a network | [`GET /v2/historical-benchmarks/{network}`](/api-reference/benchmarks/get-historical-benchmarks) | Path: `network`. Query: `code`. Optional query: `fromTimestamp`, `toTimestamp`, `page`, `perPage` |
# Get benchmark rate
Source: https://docs.vaults.fyi/api-reference/benchmarks/get-benchmark-rate
https://api.vaults.fyi/v2/documentation/json get /v2/benchmarks/{network}
Retrieves benchmark APY data for the specified network and benchmark code.
# Get historical benchmarks
Source: https://docs.vaults.fyi/api-reference/benchmarks/get-historical-benchmarks
https://api.vaults.fyi/v2/documentation/json get /v2/historical-benchmarks/{network}
Retrieves historical benchmark APY data for the specified network and benchmark code with pagination.
# Beta
Source: https://docs.vaults.fyi/api-reference/beta
Features in testing. More stable than Alpha, but may still change before general availability.
Beta endpoints are functional and tested but not yet part of the stable API. Interfaces may change before general availability. Not recommended for production use without monitoring.
Beta features are accessible using your existing API key. The endpoints below cover product areas that are being validated before general availability.
Where an endpoint supports `allowedProtocols` or `disallowedProtocols`, each value may be either a broad protocol name or a full [protocol ID](/concepts/supported-protocols#protocol-names-and-ids) for one product and version.
## Solana vaults
Build Solana/SVM vault integrations alongside the EVM vault API surface. These endpoints cover Solana vault discovery, detailed vault data, wallet positions and events, idle assets, and ready-to-sign transaction construction.
Detailed vault responses can include an optional `lpToken` object with `address` (the LP-token mint), `tokenCaip` (its CAIP-19 identifier), `name`, `symbol`, and `decimals`. The object is omitted when the required metadata is unavailable.
Idle-asset responses include token `name` and `symbol`, plus `assetLogo` where available, alongside the address, decimals, and balance. For single-asset lookups, unavailable names and symbols can be empty strings.
| Capability | How to call | Required inputs |
| - | - | - |
| List SVM vault identifiers | `GET /beta/svm/vaults` | None |
| List SVM detailed vaults | `GET /beta/svm/detailed-vaults` | None. Optional query filters include `page`, `perPage`, `assetSymbol`, `allowedAssets`, `disallowedAssets`, `allowedProtocols`, `disallowedProtocols`, `allowedAssetMints`, `disallowedAssetMints`, `minTvl`, `maxTvl`, `minApy`, `maxApy`, `sortBy`, and `sortOrder` |
| Fetch one SVM detailed vault | `GET /beta/svm/detailed-vaults/{vaultAddress}` | Path: `vaultAddress` |
| List SVM positions for a wallet | `GET /beta/svm/portfolio/positions/{userAddress}` | Path: `userAddress`. Optional query: `apyInterval`, `minUsdAssetValueThreshold` |
| List SVM portfolio events for a wallet | `GET /beta/svm/portfolio/events/{userAddress}` | Path: `userAddress` |
| List SVM portfolio events for one vault | `GET /beta/svm/portfolio/events/{userAddress}/{vaultAddress}` | Path: `userAddress`, `vaultAddress` |
| List idle SVM assets for a wallet | `GET /beta/svm/portfolio/idle-assets/{userAddress}` | Path: `userAddress`. Optional query: `allowedAssets`, `disallowedAssets` |
| Fetch one idle SVM asset | `GET /beta/svm/portfolio/idle-assets/{userAddress}/{assetAddress}` | Path: `userAddress`, `assetAddress` |
| Check balances and limits before building an SVM transaction | `GET /beta/svm/transactions/context/{userAddress}/{vaultAddress}` | Path: `userAddress`, `vaultAddress` |
| Build a ready-to-sign SVM transaction | `GET /beta/svm/transactions/{action}/{userAddress}/{vaultAddress}` | Path: `action`, `userAddress`, `vaultAddress`. Query: `assetAddress`, plus `amount` when the action requires an amount. Optional query: `simulate` |
### Reading SVM position values
`GET /beta/svm/portfolio/positions/{userAddress}` returns positions in `data`. Each position's `asset` object includes:
| Field | Meaning |
| - | - |
| `balanceNative` | Current position value in underlying-asset base units, as an integer string |
| `positionValueInAsset` | Optional explicit position-value field, currently equal to `balanceNative` |
| `balanceUsd` | Current position value in USD, as a string |
| `unclaimedNative` | Pending-redemption amount in underlying-asset base units, separate from the current position value |
| `unclaimedUsd` | Pending-redemption value in USD, as a string |
| `decimals` | Underlying-asset precision used to convert base units to display units |
For example, a `positionValueInAsset` of `"1250000"` with `decimals: 6` represents 1.25 underlying tokens. Do not add `positionValueInAsset` to `balanceNative`: they describe the same balance. If the optional field is absent, use `balanceNative`. These are underlying-asset amounts, not LP-token share amounts.
### Building SVM transactions
SVM transaction responses return one or more actions with a Solana transaction object at `actions[].tx.transaction`. The value is a base64-encoded serialized Solana transaction ready for wallet signing. Passing `simulate=true` can add a `simulation` object with status plus token amounts expected to be spent or received.
## Borrow markets
Build borrow dashboards and account-health views against one borrow market model instead of wiring separate protocol-specific routes. Use these endpoints for market discovery, historical rates, user positions, user events, and ready-to-sign borrow transaction payloads.
Supported Aave V4 Standard Spoke markets on Ethereum use this same normalized surface for market data, wallet positions, and supply, withdraw, borrow, and repay transaction payloads.
| Capability | How to call | Required inputs |
| - | - | - |
| List all borrow markets | `GET /beta/borrow/markets/` | None. Optional query filters include `page`, `perPage`, `allowedNetworks`, `disallowedNetworks`, `allowedCollateralAssets`, `disallowedCollateralAssets`, `allowedBorrowAssets`, `disallowedBorrowAssets`, `allowedProtocols`, `disallowedProtocols`, `minTvl`, and `maxTvl` |
| List borrow markets on one network | `GET /beta/borrow/markets/{network}` | Path: `network`. Optional query filters include `page`, `perPage`, `allowedCollateralAssets`, `disallowedCollateralAssets`, `allowedBorrowAssets`, `disallowedBorrowAssets`, `allowedProtocols`, `disallowedProtocols`, `minTvl`, and `maxTvl` |
| Fetch one borrow market | `GET /beta/borrow/markets/{network}/{marketId}` | Path: `network`, `marketId` |
| Fetch near-real-time borrow market asset data | `GET /beta/borrow/markets/nrt/{network}/{marketId}/{assetId}` | Path: `network`, `marketId`, `assetId` |
| Fetch historical borrow market data | `GET /beta/borrow/markets/historical/{network}/{marketId}/{assetId}` | Path: `network`, `marketId`, `assetId` |
| List borrow positions for a wallet | `GET /beta/borrow/portfolio/positions/{userAddress}` | Path: `userAddress`. Optional query: `allowedNetworks`, `disallowedNetworks`, `allowedAssets`, `disallowedAssets`, `minUsdAssetValueThreshold`, `sortBy`, `sortOrder` |
| Fetch one borrow market position | `GET /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}` | Path: `userAddress`, `network`, `marketId` |
| Fetch one asset-level borrow market position | `GET /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}/{assetId}` | Path: `userAddress`, `network`, `marketId`, `assetId` |
| List borrow market events | `GET /beta/borrow/portfolio/events/{userAddress}/{network}/{marketId}/{assetId}` | Path: `userAddress`, `network`, `marketId`, `assetId` |
| Check balances and limits before building a borrow transaction | `GET /beta/borrow/markets/transactions/context/{userAddress}/{network}/{marketId}/{assetId}` | Path: `userAddress`, `network`, `marketId`, `assetId` |
| Build a ready-to-sign borrow market transaction | `GET /beta/borrow/markets/transactions/{action}/{userAddress}/{network}/{marketId}/{assetId}` | Path: `action`, `userAddress`, `network`, `marketId`, `assetId`. Query: `amount` or `all=true` when the action requires an amount |
### Reading borrow positions
`GET /beta/borrow/portfolio/positions/{userAddress}` lists markets with outstanding debt, not every supply-only or collateral-only position. A market must retain an asset with nonzero `borrowedNative` after asset and USD-value filtering to appear in the list. Filtering out the debt asset can therefore remove the entire market, including its collateral.
Use the single-market or asset-level position endpoints when inspecting a known position, including one without debt. When aggregating balances across markets, use `assets[].positionId` to avoid counting the same underlying position more than once.
### Building borrow transactions
Fetch transaction context first and use the returned `supplySteps`, `withdrawSteps`, `borrowSteps`, or `repaySteps`. Their action lists depend on the protocol and collateral configuration, and may include `enableCollateral` or `enableController` alongside approval and supply/withdraw/borrow/repay actions. Do not hard-code a universal approval-and-supply sequence.
Borrow market responses expose `assetsData[].marketAssetId`. Pass that value as `{assetId}` when chaining from market discovery into historical data, portfolio events, asset-level positions, or transaction endpoints.
Risk-parameter objects can include `borrowRateMultiplier`, the collateral risk multiplier applied to the base borrow rate. The field is optional because it is only returned when the underlying protocol supplies this parameter.
## Advanced analytics
Request heavier per-vault analytics only when your product needs them. Selectable analytics sections include max drawdown, withdrawal pause ratio, composition, utilization rate, and the full V2 detailed-vault payload where supported.
| Capability | How to call | Required inputs |
| - | - | - |
| List advanced vault analytics using selected analytics sections | `POST /beta/advanced-analytics` | JSON body: `select`. Optional query filters include detailed-vault-style filters such as `allowedNetworks`, `disallowedNetworks`, `allowedAssets`, `disallowedAssets`, `allowedProtocols`, `disallowedProtocols`, `minTvl`, `maxTvl`, `minApy`, `maxApy`, `minVaultScore`, `tags`, `curators`, `onlyTransactional`, `onlyAppFeatured`, `allowCorrupted`, `allowVaultsWithWarnings`, `sortBy`, `sortOrder`, `page`, and `perPage` |
| Fetch advanced analytics for one vault | `POST /beta/advanced-analytics/{network}/{vaultId}` | Path: `network`, `vaultId`. JSON body: `select` |
Each request costs 1 base credit. The remaining cost scales with the number of items returned and the fields included for each item:
| Selected field | Credits per returned item |
| - | -: |
| `maxDrawdown` | 2 |
| `detailedVault` | 3 |
| `withdrawalPauseRatio` | 2 |
| `composition` | 3 |
| `utilizationRate` | 3 |
The per-item costs are cumulative. For example, a request that returns 10 items with `maxDrawdown` and `composition` costs `1 + (10 × (2 + 3)) = 51` credits.
## The Deep
Build AMM-style vault integrations for Deep liquidity positions. These endpoints cover vault discovery, wallet positions, and ready-to-sign deposit or withdrawal transactions.
| Capability | How to call | Required inputs |
| - | - | - |
| List Deep detailed vaults | `GET /beta/amm/deep/detailed-vaults` | None. Optional query: `page`, `perPage` |
| Fetch one Deep position | `GET /beta/amm/deep/positions/{userAddress}/{network}/{vaultId}` | Path: `userAddress`, `network`, `vaultId` |
| Build a Deep deposit transaction | `GET /beta/amm/deep/deposit/{userAddress}/{network}/{vaultId}` | Path: `userAddress`, `network`, `vaultId`. Query: `assetAddress0`, `amount0`. Optional query: `assetAddress1`, `amount1` |
| Build a Deep withdrawal transaction | `GET /beta/amm/deep/withdraw/{userAddress}/{network}/{vaultId}` | Path: `userAddress`, `network`, `vaultId`. Query: `amount` or `all=true` |
## Fixed Term (Pendle)
Add fixed-term yield market support for Pendle-backed opportunities. Use these endpoints to discover and compare active markets, retrieve detailed market data, preview transaction context, and generate swap-in or swap-out transactions.
| Capability | How to call | Required inputs |
| - | - | - |
| List fixed-term markets | `GET /beta/fixed-term/` | None. Optional query filters include `page`, `perPage`, `allowedAssets`, `disallowedAssets`, `allowedProtocols`, `disallowedProtocols`, `allowedNetworks`, `disallowedNetworks`, `minTvl`, `search`, `sortBy`, and `sortOrder` |
| Fetch fixed-term detailed vault data | `GET /beta/fixed-term/detailed/{network}/{vaultId}` | Path: `network`, `vaultId` |
| Preview balances and limits before building a fixed-term transaction | `GET /beta/fixed-term/context/{userAddress}/{network}/{vaultId}` | Path: `userAddress`, `network`, `vaultId` |
| Build a fixed-term transaction | `GET /beta/fixed-term/transactions/{action}/{userAddress}/{network}/{vaultId}` | Path: `action`, `userAddress`, `network`, `vaultId`. Query: `assetAddress`, `amount`. Optional query: `simulate` |
Fixed-term market discovery costs 1 base credit plus 3 credits per returned market. For example, 10 returned markets cost 31 credits.
## Portfolio
Measure user returns over a selected time window instead of only showing lifetime returns. This supports performance reporting, account history views, and user-specific analytics.
| Capability | How to call | Required inputs |
| - | - | - |
| Measure user returns over a selected time window | `GET /beta/portfolio/partial-returns/{userAddress}/{network}/{vaultId}` | Path: `userAddress`, `network`, `vaultId`. Query: `fromTimestamp`. Optional query: `toTimestamp` |
Beta endpoints require an API key. [Sign up](https://portal.vaults.fyi/signup) to get started, then watch the [changelog](/resources/changelog) for changes before general availability.
# Create borrow market transaction
Source: https://docs.vaults.fyi/api-reference/borrow-markets/create-borrow-market-transaction
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/transactions/{action}/{userAddress}/{network}/{marketId}/{assetId}
Generates payloads for borrow market supply, withdraw, borrow, or repay transactions.
# Get borrow market
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/{network}/{marketId}
Retrieves detailed discovery data for one borrow market on one network.
# Get borrow market asset NRT data
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market-asset-nrt-data
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/nrt/{network}/{marketId}/{assetId}
Retrieves near-real-time data for one asset within one borrow market.
# Get borrow market asset position
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market-asset-position
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}/{assetId}
Provides the user position for one asset within one borrow market.
# Get borrow market historical data
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market-historical-data
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/historical/{network}/{marketId}/{assetId}
Retrieves paginated historical data for one borrow market asset on one network.
# Get borrow market position
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market-position
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}
Provides the user position for one borrow market.
# Get borrow market transaction context
Source: https://docs.vaults.fyi/api-reference/borrow-markets/get-borrow-market-transaction-context
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/transactions/context/{userAddress}/{network}/{marketId}/{assetId}
Retrieves context for borrow market supply, withdraw, borrow, and repay transactions.
# List borrow market events
Source: https://docs.vaults.fyi/api-reference/borrow-markets/list-borrow-market-events
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/portfolio/events/{userAddress}/{network}/{marketId}/{assetId}
Retrieves paginated borrow market events for one user, market, and asset on one network.
# List borrow markets
Source: https://docs.vaults.fyi/api-reference/borrow-markets/list-borrow-markets
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/
Retrieves a paginated list of supported borrow markets across all supported networks.
# List borrow markets by network
Source: https://docs.vaults.fyi/api-reference/borrow-markets/list-borrow-markets-by-network
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/markets/{network}
Retrieves a paginated list of supported borrow markets for one network using the canonical network slug.
# List borrow positions
Source: https://docs.vaults.fyi/api-reference/borrow-markets/list-borrow-positions
https://api.vaults.fyi/beta/documentation/json get /beta/borrow/portfolio/positions/{userAddress}
Provides all borrow market positions for the user, with optional filters.
# Create CCTP transaction
Source: https://docs.vaults.fyi/api-reference/cctp-bridge/create-cctp-transaction
https://api.vaults.fyi/alpha/documentation/json get /alpha/transactions/cctp/transactions/{action}/{userAddress}/{srcNetwork}/{dstNetwork}
Retrieves executable transaction payloads for CCTP bridge actions (bridge or claim)
# Get CCTP transaction context
Source: https://docs.vaults.fyi/api-reference/cctp-bridge/get-cctp-transaction-context
https://api.vaults.fyi/alpha/documentation/json get /alpha/transactions/cctp/context/{userAddress}/{srcNetwork}/{dstNetwork}/{assetAddress}
Retrieves context for a CCTP cross-chain bridge operation, including asset balance, allowance, and fees
# Get CCTP transaction status
Source: https://docs.vaults.fyi/api-reference/cctp-bridge/get-cctp-transaction-status
https://api.vaults.fyi/alpha/documentation/json get /alpha/transactions/cctp/status
Checks the status of a CCTP bridge transaction via Circle Iris API
# List CCTP money in transit
Source: https://docs.vaults.fyi/api-reference/cctp-bridge/list-cctp-money-in-transit
https://api.vaults.fyi/alpha/documentation/json get /alpha/transactions/cctp/money-in-transit/{userAddress}
Returns CCTP money-in-transit transfers for all supported source/destination chain pairs
# Create transaction intent quote
Source: https://docs.vaults.fyi/api-reference/cross-chain/create-transaction-intent-quote
https://api.vaults.fyi/alpha/documentation/json post /alpha/transactions/intent/getQuote
Get transaction intent quote for cross-chain or same-chain position changes. Returns EIP-712 payload for signing and fee breakdown.
# Execute transaction intent
Source: https://docs.vaults.fyi/api-reference/cross-chain/execute-transaction-intent
https://api.vaults.fyi/alpha/documentation/json post /alpha/transactions/intent/execute
Execute a transaction intent with a signed payload. Returns the supertransaction hash for tracking.
# Get transaction intent status
Source: https://docs.vaults.fyi/api-reference/cross-chain/get-transaction-intent-status
https://api.vaults.fyi/alpha/documentation/json get /alpha/transactions/intent/status
Get the status of a crosschain transaction intent.
# Detailed Vaults
Source: https://docs.vaults.fyi/api-reference/detailed-vaults
Comprehensive vault data including APY, TVL, the Reputation Score, fees, holder data, and protocol details.
Full vault objects with performance metrics, the Reputation Score, fee structures, holder data, and protocol info. Use these endpoints to build vault comparison views, detail pages, or yield aggregators.
APY fields in detailed-vault responses are net of performance and management fees. Use the `fees` object to display the fee breakdown alongside yield; do not subtract it from APY again. See [How Vaults.fyi Calculates APY](/methodology/calculating-apy) for the full methodology.
| Capability | How to call | Required inputs |
| - | - | - |
| List and filter vaults with full analytics | [`GET /v2/detailed-vaults`](/api-reference/detailed-vaults/list-detailed-vaults) | None. Optional query filters include `allowedNetworks`, `allowedAssets`, `allowedProtocols`, `minTvl`, `maxApy`, `onlyTransactional`, `onlyAppFeatured`, `page`, `perPage`, `sortBy`, and `sortOrder`. Protocol filters accept either a broad protocol name or a full [protocol ID](/concepts/supported-protocols#protocol-names-and-ids) |
| Get one vault's full detail object | [`GET /v2/detailed-vaults/{network}/{vaultId}`](/api-reference/detailed-vaults/get-vault-details) | Path: `network`, `vaultId` |
| Get one vault's APY breakdown | [`GET /v2/detailed-vaults/{network}/{vaultId}/apy`](/api-reference/detailed-vaults/get-vault-apy) | Path: `network`, `vaultId` |
| Get one vault's TVL data | [`GET /v2/detailed-vaults/{network}/{vaultId}/tvl`](/api-reference/detailed-vaults/get-vault-tvl) | Path: `network`, `vaultId` |
## Related Alpha and Beta endpoints
Use these endpoints when you need newer vault-like data surfaces that are still in Alpha or Beta.
| Capability | How to call | Status |
| - | - | - |
| List Solana/SVM detailed vaults | [`GET /beta/svm/detailed-vaults`](/api-reference/beta#solana-vaults) | Beta |
| Fetch one Solana/SVM detailed vault | [`GET /beta/svm/detailed-vaults/{vaultAddress}`](/api-reference/beta#solana-vaults) | Beta |
| Fetch fixed-term detailed vault data | [`GET /beta/fixed-term/detailed/{network}/{vaultId}`](/api-reference/beta#fixed-term-pendle) | Beta |
| List Deep detailed vaults | [`GET /beta/amm/deep/detailed-vaults`](/api-reference/beta#the-deep) | Beta |
| List borrow markets and market metadata | [`GET /beta/borrow/markets/`](/api-reference/beta#borrow-markets) | Beta |
| Fetch advanced analytics for one vault | [`POST /beta/advanced-analytics/{network}/{vaultId}`](/api-reference/beta#advanced-analytics) | Beta |
| List vault holders and LP-token balances | [`GET /alpha/{network}/{vaultId}/holders`](/api-reference/alpha#holders) | Alpha |
# Get vault APY
Source: https://docs.vaults.fyi/api-reference/detailed-vaults/get-vault-apy
https://api.vaults.fyi/v2/documentation/json get /v2/detailed-vaults/{network}/{vaultId}/apy
Retrieves vault APY breakdown.
# Get vault details
Source: https://docs.vaults.fyi/api-reference/detailed-vaults/get-vault-details
https://api.vaults.fyi/v2/documentation/json get /v2/detailed-vaults/{network}/{vaultId}
Retrieves a detailed performance metrics of single vault including APY, TVL, rewards, risk scores, and protocol information based on specified filters.
# Get vault TVL
Source: https://docs.vaults.fyi/api-reference/detailed-vaults/get-vault-tvl
https://api.vaults.fyi/v2/documentation/json get /v2/detailed-vaults/{network}/{vaultId}/tvl
Retrieves vault Tvl breakdown.
# List detailed vaults
Source: https://docs.vaults.fyi/api-reference/detailed-vaults/list-detailed-vaults
https://api.vaults.fyi/v2/documentation/json get /v2/detailed-vaults
Retrieves a comprehensive list of vaults with detailed performance metrics including APY, TVL, rewards, risk scores, and protocol information based on specified filters.
# Create fixed-term transaction
Source: https://docs.vaults.fyi/api-reference/fixed-term-pendle/create-fixed-term-transaction
https://api.vaults.fyi/beta/documentation/json get /beta/fixed-term/transactions/{action}/{userAddress}/{network}/{vaultId}
Get Pendle fixed-term transaction data via Pendle API. Actions: swap-in (asset→PT), swap-out (PT→asset). API handles SY wrapping internally.
# Get fixed-term market
Source: https://docs.vaults.fyi/api-reference/fixed-term-pendle/get-fixed-term-market
https://api.vaults.fyi/beta/documentation/json get /beta/fixed-term/detailed/{network}/{vaultId}
Retrieves a Pendle fixed-term market including APY, TVL, and expiry
# Get fixed-term transaction context
Source: https://docs.vaults.fyi/api-reference/fixed-term-pendle/get-fixed-term-transaction-context
https://api.vaults.fyi/beta/documentation/json get /beta/fixed-term/context/{userAddress}/{network}/{vaultId}
Retrieves transaction context for a Pendle fixed-term market, including user balances for PT token and underlying asset
# List fixed-term Pendle markets
Source: https://docs.vaults.fyi/api-reference/fixed-term-pendle/list-fixed-term-pendle-markets
https://api.vaults.fyi/beta/documentation/json get /beta/fixed-term/
Returns eligible active Pendle PT markets with current Fixed APY, expiry, TVL, and liquidity.
# General
Source: https://docs.vaults.fyi/api-reference/general
Core endpoints for vault discovery, assets, networks, protocols, and curators.
Core reference data endpoints — use these to browse available vaults, resolve asset and network metadata, and populate filter dropdowns.
| Capability | How to call | Required inputs |
| - | - | - |
| List supported vault identifiers | [`GET /v2/vaults`](/api-reference/general/list-vaults) | None. Optional query filters include `network`, `assetSymbol`, `onlyTransactional`, `onlyAppFeatured`, `page`, and `perPage` |
| List supported assets and tokens | [`GET /v2/assets`](/api-reference/general/list-assets) | None. Optional query filters include `network`, `page`, and `perPage` |
| List supported networks | [`GET /v2/networks`](/api-reference/general/list-networks) | None |
| List vault tags | [`GET /v2/tags`](/api-reference/general/list-tags) | None. See [Vault Tags](/concepts/vault-discovery#vault-tags) for taxonomy definitions |
| List vault curators | [`GET /v2/curators`](/api-reference/general/list-curators) | None |
| List supported protocols and their filterable protocol IDs | [`GET /v2/protocols`](/api-reference/general/list-protocols) | None. See [Protocol names and IDs](/concepts/supported-protocols#protocol-names-and-ids) for filtering examples |
| Check API availability | [`GET /v2/health`](/api-reference/health/health-check) | None |
`GET /v2/curators` returns each curator's canonical `name` and an optional `displayName`. Use `name` for filtering and stable matching; use `displayName` for presentation, falling back to `name` when it is absent. The same fields appear in the optional `curator` object returned by both detailed-vault endpoints.
# List assets
Source: https://docs.vaults.fyi/api-reference/general/list-assets
https://api.vaults.fyi/v2/documentation/json get /v2/assets
Retrieves a filtered list of supported assets with their metadata including address, symbol, name, decimals, and network information.
# List curators
Source: https://docs.vaults.fyi/api-reference/general/list-curators
https://api.vaults.fyi/v2/documentation/json get /v2/curators
Retrieves a complete list of available vault curators that can be used for filtering and organizing vault data
# List networks
Source: https://docs.vaults.fyi/api-reference/general/list-networks
https://api.vaults.fyi/v2/documentation/json get /v2/networks
Retrieves a complete list of supported blockchain networks with their identifiers including network name, chain ID, and CAIP format identifier.
# List protocols
Source: https://docs.vaults.fyi/api-reference/general/list-protocols
https://api.vaults.fyi/v2/documentation/json get /v2/protocols
Retrieves a complete list of available protocols that can be used for filtering and organizing vault data
# List tags
Source: https://docs.vaults.fyi/api-reference/general/list-tags
https://api.vaults.fyi/v2/documentation/json get /v2/tags
Retrieves a complete list of available vault categorization tags that can be used for filtering and organizing vault data
# List vaults
Source: https://docs.vaults.fyi/api-reference/general/list-vaults
https://api.vaults.fyi/v2/documentation/json get /v2/vaults
Retrieves a filtered list of vaults with their basic information including address, network, associated asset details, and transactional support status.
# Health
Source: https://docs.vaults.fyi/api-reference/health
Service health endpoint for monitoring API availability.
Use the health endpoint for uptime checks and lightweight service monitoring.
| Capability | How to call | Required inputs |
| - | - | - |
| Check API availability | [`GET /v2/health`](/api-reference/health/health-check) | None |
# Health check
Source: https://docs.vaults.fyi/api-reference/health/health-check
https://api.vaults.fyi/v2/documentation/json get /v2/health
Checks the health status of the API and its dependencies including database connections and cache availability.
# Historical
Source: https://docs.vaults.fyi/api-reference/historical
Time-series APY, TVL, share price, and asset price data for any vault.
Time-series data for any vault over configurable date ranges and granularity. Use these endpoints to build performance charts, run backtests, or track share price over time.
Historical APY values are net of performance and management fees, matching the current APY fields returned by detailed-vault responses.
| Capability | How to call | Required inputs |
| - | - | - |
| Fetch combined APY, TVL, and share-price history | [`GET /v2/historical/{network}/{vaultId}`](/api-reference/historical/get-vault-historical-data) | Path: `network`, `vaultId`. Optional query: `fromTimestamp`, `toTimestamp`, `granularity`, `apyInterval`, `page`, `perPage` |
| Fetch APY history only | [`GET /v2/historical/{network}/{vaultId}/apy`](/api-reference/historical/get-historical-apy) | Path: `network`, `vaultId`. Optional query: `fromTimestamp`, `toTimestamp`, `granularity`, `apyInterval`, `page`, `perPage` |
| Fetch TVL history only | [`GET /v2/historical/{network}/{vaultId}/tvl`](/api-reference/historical/get-historical-tvl) | Path: `network`, `vaultId`. Optional query: `fromTimestamp`, `toTimestamp`, `granularity`, `page`, `perPage` |
| Fetch share-price history only | [`GET /v2/historical/{network}/{vaultId}/sharePrice`](/api-reference/historical/get-historical-share-price) | Path: `network`, `vaultId`. Optional query: `fromTimestamp`, `toTimestamp`, `granularity`, `apyInterval`, `page`, `perPage` |
| Fetch historical underlying asset prices | [`GET /v2/historical/asset-prices/{network}/{assetAddress}`](/api-reference/historical/get-historical-asset-prices) | Path: `network`, `assetAddress`. Optional query: `fromTimestamp`, `toTimestamp`, `granularity`, `page`, `perPage` |
## Related Alpha and Beta endpoints
Use these endpoints for historical data that is still being validated outside the stable V2 surface.
| Capability | How to call | Status |
| - | - | - |
| Fetch historical borrow market rates and liquidity | [`GET /beta/borrow/markets/historical/{network}/{marketId}/{assetId}`](/api-reference/beta#borrow-markets) | Beta |
| Fetch historical daily vault inflows and outflows | [`GET /alpha/historical/{network}/{vaultId}/daily-flows`](/api-reference/alpha#historical-flows) | Alpha |
| List historical positions for a wallet | [`GET /alpha/historical-positions/{userAddress}`](/api-reference/alpha#historical-positions) | Alpha |
| Reconstruct wallet balances at a point in time | [`GET /alpha/historical-balances/{userAddress}/{timestamp}`](/api-reference/alpha#historical-balances) | Alpha |
# List user historical balances
Source: https://docs.vaults.fyi/api-reference/historical-positions/list-user-historical-balances
https://api.vaults.fyi/alpha/documentation/json get /alpha/historical-balances/{userAddress}/{timestamp}
Returns the user vault positions and balances at a specific historical timestamp.
# List user historical positions
Source: https://docs.vaults.fyi/api-reference/historical-positions/list-user-historical-positions
https://api.vaults.fyi/alpha/documentation/json get /alpha/historical-positions/{userAddress}
Returns vaults the user held a position in (had a non-zero balance at the start of the window or deposited during the window). Both timestamps are optional.
# Get historical APY
Source: https://docs.vaults.fyi/api-reference/historical/get-historical-apy
https://api.vaults.fyi/v2/documentation/json get /v2/historical/{network}/{vaultId}/apy
Retrieves time-series historical APY data for a specific vault, including base yield and rewards components over a customizable time range
# Get historical asset prices
Source: https://docs.vaults.fyi/api-reference/historical/get-historical-asset-prices
https://api.vaults.fyi/v2/documentation/json get /v2/historical/asset-prices/{network}/{assetAddress}
Retrieves historical USD prices for a specific asset on a given network.
# Get historical daily vault flows
Source: https://docs.vaults.fyi/api-reference/historical/get-historical-daily-vault-flows
https://api.vaults.fyi/alpha/documentation/json get /alpha/historical/{network}/{vaultId}/daily-flows
Retrieves daily UTC vault deposit and redemption totals for a specific vault over an exclusive date range.
# Get historical share price
Source: https://docs.vaults.fyi/api-reference/historical/get-historical-share-price
https://api.vaults.fyi/v2/documentation/json get /v2/historical/{network}/{vaultId}/sharePrice
Retrieves time-series historical TVL data for a specific vault, including base yield and rewards components over a customizable time range
# Get historical TVL
Source: https://docs.vaults.fyi/api-reference/historical/get-historical-tvl
https://api.vaults.fyi/v2/documentation/json get /v2/historical/{network}/{vaultId}/tvl
Retrieves time-series historical TVL data for a specific vault, including base yield and rewards components over a customizable time range
# Get vault historical data
Source: https://docs.vaults.fyi/api-reference/historical/get-vault-historical-data
https://api.vaults.fyi/v2/documentation/json get /v2/historical/{network}/{vaultId}
Retrieves historical APY and TVL for a specific vault, based on the provided query parameters.
# List vault holders
Source: https://docs.vaults.fyi/api-reference/holders/list-vault-holders
https://api.vaults.fyi/alpha/documentation/json get /alpha/{network}/{vaultId}/holders
Retrieves current holders for a specific vault with their balances (converted to LP token amounts for rebasing vaults)
# Near Real-Time
Source: https://docs.vaults.fyi/api-reference/nrt
Sub-second vault metrics: share price, total assets, total supply, and underlying asset price.
Near real-time vault metrics sourced directly from onchain state — updated far more frequently than the standard indexed data. Use these endpoints when your product needs the most current share price or TVL figures, such as deposit previews, live dashboards, or liquidation monitoring.
| Capability | How to call | Required inputs |
| - | - | - |
| Fetch all current vault metrics in one response | [`GET /v2/nrt/vault/{network}/{vaultId}`](/api-reference/nrt/get-vault-nrt-data) | Path: `network`, `vaultId` |
| Fetch the current share price | [`GET /v2/nrt/vault/{network}/{vaultId}/sharePrice`](/api-reference/nrt/get-vault-nrt-share-price) | Path: `network`, `vaultId` |
| Fetch the current total supply | [`GET /v2/nrt/vault/{network}/{vaultId}/totalSupply`](/api-reference/nrt/get-vault-nrt-total-supply) | Path: `network`, `vaultId` |
| Fetch the current total assets | [`GET /v2/nrt/vault/{network}/{vaultId}/totalAssets`](/api-reference/nrt/get-vault-nrt-total-assets) | Path: `network`, `vaultId` |
| Fetch the current underlying asset price | [`GET /v2/nrt/vault/{network}/{vaultId}/underlyingAssetPrice`](/api-reference/nrt/get-vault-nrt-underlying-asset-price) | Path: `network`, `vaultId` |
## Related Beta endpoints
Borrow market live data is currently exposed through the Beta borrow market surface.
| Capability | How to call | Status |
| - | - | - |
| Fetch near-real-time borrow market asset data | [`GET /beta/borrow/markets/nrt/{network}/{marketId}/{assetId}`](/api-reference/beta#borrow-markets) | Beta |
# Get vault NRT data
Source: https://docs.vaults.fyi/api-reference/nrt/get-vault-nrt-data
https://api.vaults.fyi/v2/documentation/json get /v2/nrt/vault/{network}/{vaultId}
Retrieves nrt data for vault (underlyingAssetPrice, sharePrice, totalAssets, totalSupply)
# Get vault NRT share price
Source: https://docs.vaults.fyi/api-reference/nrt/get-vault-nrt-share-price
https://api.vaults.fyi/v2/documentation/json get /v2/nrt/vault/{network}/{vaultId}/sharePrice
Retrieves NRT share price for vault
# Get vault NRT total assets
Source: https://docs.vaults.fyi/api-reference/nrt/get-vault-nrt-total-assets
https://api.vaults.fyi/v2/documentation/json get /v2/nrt/vault/{network}/{vaultId}/totalAssets
Retrieves total assets for vault
# Get vault NRT total supply
Source: https://docs.vaults.fyi/api-reference/nrt/get-vault-nrt-total-supply
https://api.vaults.fyi/v2/documentation/json get /v2/nrt/vault/{network}/{vaultId}/totalSupply
Retrieves total supply for vault
# Get vault NRT underlying asset price
Source: https://docs.vaults.fyi/api-reference/nrt/get-vault-nrt-underlying-asset-price
https://api.vaults.fyi/v2/documentation/json get /v2/nrt/vault/{network}/{vaultId}/underlyingAssetPrice
Retrieves underlying asset price for vault
# Vaults.fyi API Overview
Source: https://docs.vaults.fyi/api-reference/overview
The vaults.fyi V2 API — comprehensive DeFi vault data and transaction execution across 20+ EVM networks, with Solana/SVM endpoints in Beta.
## Base URL
```
https://api.vaults.fyi/v2
```
## Authentication
Every request must include your API key as a header:
```bash theme={null}
x-api-key: YOUR_API_KEY
```
All API keys have access to all endpoints. Rate limits depend on your plan — see [Plans & Pricing](/plans/overview), or contact support to increase your limit.
## Networks
The V2 API tracks vaults across 20+ EVM-compatible networks. Networks can be identified by name or CAIP-2 identifier:
| Name | Chain ID | CAIP-2 |
| - | - | - |
| `arbitrum` | 42161 | `eip155:42161` |
| `avalanche` | 43114 | `eip155:43114` |
| `base` | 8453 | `eip155:8453` |
| `berachain` | 80094 | `eip155:80094` |
| `bsc` | 56 | `eip155:56` |
| `celo` | 42220 | `eip155:42220` |
| `etherlink` | 42793 | `eip155:42793` |
| `gnosis` | 100 | `eip155:100` |
| `hyperliquid` | 999 | `eip155:999` |
| `ink` | 57073 | `eip155:57073` |
| `katana` | 747474 | `eip155:747474` |
| `linea` | 59144 | `eip155:59144` |
| `mainnet` | 1 | `eip155:1` |
| `mega-eth` | 4326 | `eip155:4326` |
| `monad` | 143 | `eip155:143` |
| `optimism` | 10 | `eip155:10` |
| `plasma` | 9745 | `eip155:9745` |
| `polygon` | 137 | `eip155:137` |
| `robinhood` | 4663 | `eip155:4663` |
| `swellchain` | 1923 | `eip155:1923` |
| `unichain` | 130 | `eip155:130` |
| `worldchain` | 480 | `eip155:480` |
Use `GET /v2/networks` for the complete current list of V2 EVM networks. Solana/SVM vault discovery, portfolio, idle-asset, and transaction endpoints are available separately in [Beta](/api-reference/beta#solana-vaults).
## APY values
All APY fields are **raw decimals**. Multiply by 100 to display as a percentage:
```js theme={null}
// API returns: 0.0543
// Display as: 5.43%
const displayApy = (rawApy * 100).toFixed(2) + '%';
```
APY values are net of performance and management fees. The detailed-vault `fees` object is for display and should not be subtracted from APY again.
## Pagination
All list endpoints use offset pagination with `page` (zero-indexed) and `perPage`:
```bash theme={null}
GET /v2/detailed-vaults?page=0&perPage=50 # first page
GET /v2/detailed-vaults?page=1&perPage=50 # second page
```
The response includes `nextPage` — it is `null` when you are on the last page.
## Error responses
| Status | Meaning |
| - | - |
| `400` | Invalid parameters |
| `401` | Missing or invalid API key |
| `403` | API key has exhausted available credits |
| `404` | Resource not found |
| `429` | Rate limit exceeded |
| `500` | Internal server error |
| `503` | Service temporarily unavailable |
Error bodies follow this shape:
```json theme={null}
{
"statusCode": 400,
"error": "Bad Request",
"message": "Descriptive error message"
}
```
Some authentication errors omit `statusCode`; always key your handling off the HTTP status code first.
## Quick start
Fetch the top 5 USDC vaults by 7-day APY on Ethereum mainnet:
```bash theme={null}
curl -H "x-api-key: YOUR_API_KEY" \
"https://api.vaults.fyi/v2/detailed-vaults\
?allowedAssets=USDC\
&allowedNetworks=mainnet\
&minTvl=1000000\
&sortBy=apy7day\
&sortOrder=desc\
&perPage=5"
```
Check a user's idle assets and suggest vaults to deposit into:
```bash theme={null}
# Step 1 — find idle assets
curl -H "x-api-key: YOUR_API_KEY" \
"https://api.vaults.fyi/v2/portfolio/idle-assets/0xYourWallet"
# Step 2 — get ranked deposit suggestions
curl -H "x-api-key: YOUR_API_KEY" \
"https://api.vaults.fyi/v2/portfolio/best-deposit-options/0xYourWallet\
?onlyTransactional=true&maxVaultsPerAsset=3"
```
# Portfolio
Source: https://docs.vaults.fyi/api-reference/portfolio
User positions, idle assets, deposit recommendations, transaction history, and returns.
Wallet-aware endpoints that return a user's vault positions, uninvested balances, personalized deposit suggestions, total returns, and transaction history.
Protocol filters accept either a broad protocol name or a full [protocol ID](/concepts/supported-protocols#protocol-names-and-ids) for one product and version.
| Capability | How to call | Required inputs |
| - | - | - |
| List all vault positions for a wallet | [`GET /v2/portfolio/positions/{userAddress}`](/api-reference/portfolio/list-portfolio-positions) | Path: `userAddress`. Optional query filters include `allowedNetworks`, `allowedAssets`, `allowedProtocols`, `minTvl`, `minVaultScore`, `onlyTransactional`, `onlyAppFeatured`, `apyInterval`, and `minUsdAssetValueThreshold` |
| Fetch one vault position for a wallet | [`GET /v2/portfolio/positions/{userAddress}/{network}/{vaultId}`](/api-reference/portfolio/get-portfolio-position) | Path: `userAddress`, `network`, `vaultId`. Optional query: `apyInterval` |
| List uninvested token balances | [`GET /v2/portfolio/idle-assets/{userAddress}`](/api-reference/portfolio/list-idle-assets) | Path: `userAddress`. Optional query filters include `allowedNetworks`, `allowedAssets`, `minUsdAssetValueThreshold`, `sortBy`, and `sortDirection` |
| Rank deposit opportunities matching wallet holdings | [`GET /v2/portfolio/best-deposit-options/{userAddress}`](/api-reference/portfolio/get-best-deposit-options) | Path: `userAddress`. Optional query filters include `allowedNetworks`, `allowedAssets`, `allowedProtocols`, `minTvl`, `minVaultScore`, `minApy`, `apyInterval`, `alwaysReturnAssets`, and `maxVaultsPerAsset` |
| Fetch the single best-fit vault for a wallet | [`GET /v2/portfolio/best-vault/{userAddress}`](/api-reference/portfolio/get-best-vault) | Path: `userAddress`. Optional query filters include `allowedNetworks`, `allowedAssets`, `allowedProtocols`, `minTvl`, `minVaultScore`, `minApy`, and `apyInterval` |
| Calculate earned yield for one position | [`GET /v2/portfolio/total-returns/{userAddress}/{network}/{vaultId}`](/api-reference/portfolio/get-total-returns) | Path: `userAddress`, `network`, `vaultId` |
| List deposit, redeem, and claim history for one position | [`GET /v2/portfolio/events/{userAddress}/{network}/{vaultId}`](/api-reference/portfolio/list-position-events) | Path: `userAddress`, `network`, `vaultId` |
## Related Alpha and Beta endpoints
Some newer portfolio surfaces are available in Alpha or Beta before they move into the stable V2 API. Use these when you need the capability now and can tolerate interface changes.
| Capability | How to call | Status |
| - | - | - |
| Measure user returns over a selected time window | [`GET /beta/portfolio/partial-returns/{userAddress}/{network}/{vaultId}`](/api-reference/beta#portfolio) | Beta |
| List Solana/SVM vault positions for a wallet | [`GET /beta/svm/portfolio/positions/{userAddress}`](/api-reference/beta#solana-vaults) | Beta |
| List Solana/SVM portfolio events for a wallet or vault | [`GET /beta/svm/portfolio/events/{userAddress}`](/api-reference/beta#solana-vaults) | Beta |
| List Solana/SVM idle assets for a wallet | [`GET /beta/svm/portfolio/idle-assets/{userAddress}`](/api-reference/beta#solana-vaults) | Beta |
| List borrow positions for a wallet | [`GET /beta/borrow/portfolio/positions/{userAddress}`](/api-reference/beta#borrow-markets) | Beta |
| List borrow market events for a wallet | [`GET /beta/borrow/portfolio/events/{userAddress}/{network}/{marketId}/{assetId}`](/api-reference/beta#borrow-markets) | Beta |
| List historical vault positions for a wallet | [`GET /alpha/historical-positions/{userAddress}`](/api-reference/alpha#historical-positions) | Alpha |
| Reconstruct wallet balances at a point in time | [`GET /alpha/historical-balances/{userAddress}/{timestamp}`](/api-reference/alpha#historical-balances) | Alpha |
# Get best deposit options
Source: https://docs.vaults.fyi/api-reference/portfolio/get-best-deposit-options
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/best-deposit-options/{userAddress}
Analyzes a user's existing wallet balances and recommends optimal vault deposit opportunities based on yield performance, risk parameters, and user-defined criteria.
# Get best vault
Source: https://docs.vaults.fyi/api-reference/portfolio/get-best-vault
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/best-vault/{userAddress}
Returns the single best vault opportunity for the user, based on balance and yield analysis.
# Get partial returns
Source: https://docs.vaults.fyi/api-reference/portfolio/get-partial-returns
https://api.vaults.fyi/beta/documentation/json get /beta/portfolio/partial-returns/{userAddress}/{network}/{vaultId}
Retrieves the returns for a user's position in a specific vault, calculated only for the requested time window. Returns the same asset metadata as total-returns plus the resolved period boundaries.
# Get portfolio position
Source: https://docs.vaults.fyi/api-reference/portfolio/get-portfolio-position
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/positions/{userAddress}/{network}/{vaultId}
Gives a detailed view of one specific vault position on a given network.
# Get total returns
Source: https://docs.vaults.fyi/api-reference/portfolio/get-total-returns
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/total-returns/{userAddress}/{network}/{vaultId}
Retrieves the total returns for a user's position in a specific vault, including asset details and native returns amount.
# List idle assets
Source: https://docs.vaults.fyi/api-reference/portfolio/list-idle-assets
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/idle-assets/{userAddress}
Get balances of idle assets for a specific user address.
# List portfolio positions
Source: https://docs.vaults.fyi/api-reference/portfolio/list-portfolio-positions
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/positions/{userAddress}
Provides all vault positions for the user, with optional filters.
# List position events
Source: https://docs.vaults.fyi/api-reference/portfolio/list-position-events
https://api.vaults.fyi/v2/documentation/json get /v2/portfolio/events/{userAddress}/{network}/{vaultId}
Retrieves all transactions (deposits and withdrawals) for a user's position in a specific vault, including transaction details and metadata.
# Create SVM transaction
Source: https://docs.vaults.fyi/api-reference/svm/create-svm-transaction
https://api.vaults.fyi/beta/documentation/json get /beta/svm/transactions/{action}/{userAddress}/{vaultAddress}
Get Solana transaction data for vault actions (deposit, request-redeem, confirm-redeem, complete-redeem). Returns a base64-encoded serialized transaction ready for wallet signing. Three-step redemption process: request-redeem creates stake account, confirm-redeem deactivates it, complete-redeem withdraws SOL after epoch boundary.
# Get SVM detailed vault
Source: https://docs.vaults.fyi/api-reference/svm/get-svm-detailed-vault
https://api.vaults.fyi/beta/documentation/json get /beta/svm/detailed-vaults/{vaultAddress}
Retrieves detailed information for a specific SVM vault including address (vault account public key), name, protocol, curator, TVL, and APY details.
# Get SVM idle asset
Source: https://docs.vaults.fyi/api-reference/svm/get-svm-idle-asset
https://api.vaults.fyi/beta/documentation/json get /beta/svm/portfolio/idle-assets/{userAddress}/{assetAddress}
Retrieves idle asset balance for a specific user and token on Solana.
# Get SVM transaction context
Source: https://docs.vaults.fyi/api-reference/svm/get-svm-transaction-context
https://api.vaults.fyi/beta/documentation/json get /beta/svm/transactions/context/{userAddress}/{vaultAddress}
Retrieves the complete transactional context for a user interaction with a Solana vault, including current balances and unclaimed assets.
# List SVM detailed vaults
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-detailed-vaults
https://api.vaults.fyi/beta/documentation/json get /beta/svm/detailed-vaults
Retrieves a filtered list of SVM vaults with detailed information including address (vault account public key), name, protocol, curator, TVL, and APY details. APY filter inputs and response values use v2 decimal semantics.
# List SVM idle assets
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-idle-assets
https://api.vaults.fyi/beta/documentation/json get /beta/svm/portfolio/idle-assets/{userAddress}
Get balances of idle assets for a specific user address on Solana.
# List SVM portfolio events across supported vaults
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-portfolio-events-across-supported-vaults
https://api.vaults.fyi/beta/documentation/json get /beta/svm/portfolio/events/{userAddress}
Retrieves deposits and withdrawals for a user's activity across supported SVM vaults by resolving protocol flow accounts and parsing vault-asset movements from Helius transactions.
# List SVM position events
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-position-events
https://api.vaults.fyi/beta/documentation/json get /beta/svm/portfolio/events/{userAddress}/{vaultAddress}
Retrieves deposits and withdrawals for a user's position in a specific SVM vault by resolving protocol flow accounts and parsing vault-asset movements from Helius transactions.
# List SVM positions
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-positions
https://api.vaults.fyi/beta/documentation/json get /beta/svm/portfolio/positions/{userAddress}
Provides all vault positions for a user on Solana.
# List SVM vaults
Source: https://docs.vaults.fyi/api-reference/svm/list-svm-vaults
https://api.vaults.fyi/beta/documentation/json get /beta/svm/vaults
Retrieves a filtered list of SVM vaults with their basic information including address (vault account public key) and associated asset details.
# Create Deep deposit transaction
Source: https://docs.vaults.fyi/api-reference/the-deep/create-deep-deposit-transaction
https://api.vaults.fyi/beta/documentation/json get /beta/amm/deep/deposit/{userAddress}/{network}/{vaultId}
Creates deposit transaction payloads for Deep AMM protocol for a specific user and network.
# Create Deep withdrawal transaction
Source: https://docs.vaults.fyi/api-reference/the-deep/create-deep-withdrawal-transaction
https://api.vaults.fyi/beta/documentation/json get /beta/amm/deep/withdraw/{userAddress}/{network}/{vaultId}
Creates redeem transaction payloads for Deep AMM protocol for a specific user and network.
# Get Deep position
Source: https://docs.vaults.fyi/api-reference/the-deep/get-deep-position
https://api.vaults.fyi/beta/documentation/json get /beta/amm/deep/positions/{userAddress}/{network}/{vaultId}
Gives a detailed view of one specific vault position on a given network.
# List Deep detailed vaults
Source: https://docs.vaults.fyi/api-reference/the-deep/list-deep-detailed-vaults
https://api.vaults.fyi/beta/documentation/json get /beta/amm/deep/detailed-vaults
Retrieves a filtered list of Deep vaults with detailed information including chain ID, address, display name, APY (7d and 30d), and TVL in USD.
# Transactions
Source: https://docs.vaults.fyi/api-reference/transactions
Ready-to-sign transaction payloads for deposits, redemptions, and reward claims.
Generates ready-to-sign transaction calldata for any supported vault action. Pass the output directly to your wallet provider — no ABI encoding required.
## Typical flow
1. **Check what the user can do**
Call `GET /v2/transactions/context/{userAddress}/{network}/{vaultId}` to fetch the user's balances, limits, supported actions, required steps, and rewards context for that vault.
2. **Build the transaction payload**
Call `GET /v2/transactions/{action}/{userAddress}/{network}/{vaultId}` with the action you want to prepare. Include `assetAddress` and either `amount` for a specific amount or `all=true` for a full redeem-style action.
3. **Send the returned transaction with the user's wallet**
The response includes the target address, calldata, and value. You do not need to encode the vault contract call yourself.
```bash theme={null}
curl "https://api.vaults.fyi/v2/transactions/deposit/0xUSER/base/0xVAULT?assetAddress=0xASSET&amount=1000000" \
-H "x-api-key: $VAULTS_FYI_API_KEY"
```
| Capability | How to call | Required inputs |
| - | - | - |
| Check available vault actions | [`GET /v2/transactions/context/{userAddress}/{network}/{vaultId}`](/api-reference/transactions/get-transaction-context) | Path: `userAddress`, `network`, `vaultId` |
| Build deposit, redeem, request, or claim calldata | [`GET /v2/transactions/{action}/{userAddress}/{network}/{vaultId}`](/api-reference/transactions/get-transaction-payload) | Path: `action`, `userAddress`, `network`, `vaultId`. Query: `assetAddress`, plus `amount` or `all=true` when the action requires an amount |
| Check claimable rewards | [`GET /v2/transactions/rewards/context/{userAddress}`](/api-reference/transactions/get-rewards-context) | Path: `userAddress` |
| Build rewards claim calldata | [`GET /v2/transactions/rewards/claim/{userAddress}`](/api-reference/transactions/claim-rewards) | Path: `userAddress`. Query: `claimIds` |
| Add transaction attribution | [`GET /v2/transactions/suffix/{userAddress}/{vaultId}`](/api-reference/transactions/get-transaction-suffix) | Path: `userAddress`, `vaultId` |
## Related Alpha and Beta endpoints
Alpha and Beta transaction endpoints extend the same wallet-action pattern to newer surfaces. Use them when your product needs these flows before they are promoted to stable V2.
| Capability | How to call | Status |
| - | - | - |
| Build a ready-to-sign Solana/SVM transaction | [`GET /beta/svm/transactions/{action}/{userAddress}/{vaultAddress}`](/api-reference/beta#solana-vaults) | Beta |
| Check Solana/SVM balances and limits before building a transaction | [`GET /beta/svm/transactions/context/{userAddress}/{vaultAddress}`](/api-reference/beta#solana-vaults) | Beta |
| Build a ready-to-sign borrow market transaction | [`GET /beta/borrow/markets/transactions/{action}/{userAddress}/{network}/{marketId}/{assetId}`](/api-reference/beta#borrow-markets) | Beta |
| Check borrow balances and limits before building a transaction | [`GET /beta/borrow/markets/transactions/context/{userAddress}/{network}/{marketId}/{assetId}`](/api-reference/beta#borrow-markets) | Beta |
| Build a Deep deposit or withdrawal transaction | [`GET /beta/amm/deep/deposit/{userAddress}/{network}/{vaultId}`](/api-reference/beta#the-deep) | Beta |
| Check balances and limits before building a fixed-term transaction | [`GET /beta/fixed-term/context/{userAddress}/{network}/{vaultId}`](/api-reference/beta#fixed-term-pendle) | Beta |
| Build a fixed-term transaction | [`GET /beta/fixed-term/transactions/{action}/{userAddress}/{network}/{vaultId}`](/api-reference/beta#fixed-term-pendle) | Beta |
| Quote, execute, and track cross-chain transaction intents | [`POST /alpha/transactions/intent/getQuote`](/api-reference/alpha#cross-chain-intents) | Alpha |
| Build and track CCTP bridge transactions | [`GET /alpha/transactions/cctp/transactions/{action}/{userAddress}/{srcNetwork}/{dstNetwork}`](/api-reference/alpha#cctp-bridge) | Alpha |
# Claim rewards
Source: https://docs.vaults.fyi/api-reference/transactions/claim-rewards
https://api.vaults.fyi/v2/documentation/json get /v2/transactions/rewards/claim/{userAddress}
Generates a claim rewards transaction for a user, returning transaction payloads needed to claim rewards from protocols.
# Get rewards context
Source: https://docs.vaults.fyi/api-reference/transactions/get-rewards-context
https://api.vaults.fyi/v2/documentation/json get /v2/transactions/rewards/context/{userAddress}
Retrieves claimable rewards context for a user across all networks and vaults, including reward details and claim URLs.
# Get transaction context
Source: https://docs.vaults.fyi/api-reference/transactions/get-transaction-context
https://api.vaults.fyi/v2/documentation/json get /v2/transactions/context/{userAddress}/{network}/{vaultId}
Retrieves the complete transactional context for a user's interaction with a specific vault, including available deposit/redeem steps, current balances, and claimable rewards.
# Get transaction payload
Source: https://docs.vaults.fyi/api-reference/transactions/get-transaction-payload
https://api.vaults.fyi/v2/documentation/json get /v2/transactions/{action}/{userAddress}/{network}/{vaultId}
Retrieves executable transaction payloads for specific actions (deposit, redeem, claim) for a user interacting with a vault, including ready-to-sign transaction data and optional simulation results.
# Get transaction suffix
Source: https://docs.vaults.fyi/api-reference/transactions/get-transaction-suffix
https://api.vaults.fyi/v2/documentation/json get /v2/transactions/suffix/{userAddress}/{vaultId}
Generates the transaction suffix for the current API key, user address, and vault. Append the returned raw hex suffix to calldata without a 0x prefix.
# Borrowing
Source: https://docs.vaults.fyi/concepts/borrowing
Add borrow market discovery, user position tracking, and ready-to-sign supply, withdraw, borrow, and repay flows to your app.
The Vaults.fyi borrowing API gives wallets and apps one integration for borrow market data, user-level lending and borrowing positions, market history, and ready-to-sign transaction payloads.
Instead of building separate integrations for each lending protocol, you can use a normalized borrow market model across supported networks and protocols. This lets you show users what they have supplied, what they have borrowed, their risk metrics, and which actions are available before you build a transaction.
Borrowing is currently a Beta API surface. The endpoints are functional and tested, but may still change before general availability. Check the [Beta](/api-reference/beta#borrow-markets) API Reference section before integrating.
## What you can build
List supported borrow markets, filter by network, and inspect supplied assets, borrowed assets, rates, utilization, and collateral configuration.
Show a wallet's supplied and borrowed balances across supported markets, including position value and market-specific asset balances.
Surface LTV, liquidation thresholds, health factor, and collateral data so users understand the state of their borrow positions.
Generate ready-to-sign supply, withdraw, borrow, and repay payloads after checking balances, limits, and available actions.
## Integration flow
List supported borrow markets, optionally scoped to one network. Use market details to render assets, rates, utilization, and collateral parameters in your product.
Retrieve the wallet's borrow portfolio to show supplied assets, borrowed assets, position value, and risk metrics across markets.
Before rendering action buttons, fetch transaction context for the user, market, and asset. The response tells you which actions are available and which inputs are required.
Build a ready-to-sign payload for the selected action: `supply`, `withdraw`, `borrow`, or `repay`. Pass the payload to the user's wallet for signing.
## Borrow market data
Borrow markets expose the normalized data needed to build market screens and position pages:
* Market identity: network, market ID, protocol, and supported assets
* Rates and utilization
* Supplied and borrowed asset data
* Collateral and liquidation parameters
* An optional `borrowRateMultiplier` where the protocol applies a collateral risk multiplier to the base borrow rate
* Historical market data where available
Use this data for borrow dashboards, market comparison views, and account-specific borrow screens.
Aave V4 Standard Spoke markets on Ethereum use this normalized model for discovery, positions, and transaction construction alongside the other supported lending protocols.
## Positions and events
Borrow portfolio endpoints let you inspect a user's current positions and market-level history:
* Supplied assets and balances
* Borrowed assets and balances
* LTV, health factor, and other risk metrics where available
* Asset-level position views for a specific market
* User events for a market and asset
The wallet-wide borrow position list includes only markets with outstanding debt. Supply-only and collateral-only markets are omitted. Asset filters and the USD-value threshold can also exclude a market if no borrowed asset remains in the response. Use the single-market or asset-level position endpoint to inspect a known position without debt.
When combining results across markets, deduplicate balances by `assets[].positionId`. The same economic position can appear in more than one market.
## Transaction support
Borrow transaction endpoints follow the same pattern as vault transaction flows:
1. Fetch context for the user, market, asset, and network.
2. Confirm which action is available.
3. Generate the action payload with `amount` or `all=true` where required.
4. Pass the returned transaction to the user's wallet.
Supported actions depend on the market and user state, but the model covers supply, withdraw, borrow, and repay flows. Read the action lists from transaction context: some protocols also require `enableCollateral` or `enableController`. Do not assume every supply flow consists only of approval and supply.
Always fetch transaction context before generating a borrow transaction. Borrow actions depend on collateral, balances, market limits, and protocol-specific constraints.
## API reference
See the current endpoint guide in [Beta](/api-reference/beta#borrow-markets).
# Portfolio Tracking
Source: https://docs.vaults.fyi/concepts/portfolio-tracking
Track user positions across protocols, detect idle assets, surface personalized deposit options, and report PnL — all from one API.
The Vaults.fyi portfolio API gives you a unified view of a user's DeFi yield activity across all supported protocols and networks. Instead of querying each protocol separately and normalizing the results yourself, you get aggregated position data, transaction history, and deposit options for any wallet address in a single integration.
If you want a packaged position view instead of building the UI yourself, the [embeddable widget](/use-cases/embeddable-widget) can combine discovery, user positions, and transaction-ready flows in a branded Earn surface.
## Position tracking
Call `GET /v2/portfolio/positions/{userAddress}` to retrieve a complete picture of a user's onchain yield activity.
The response includes:
* **Balances.** Current token balances across all supported networks, including idle assets not currently earning yield.
* **Active positions.** Each vault position with its current balance in native token and USD, unclaimed rewards, and estimated returns since deposit.
* **Transaction history.** A chronological record of past deposit, redeem, and claim transactions for the address.
One integration covers positions across hundreds of vaults. You don't need to write per-protocol logic to aggregate this data.
## Idle asset detection
The portfolio endpoint surfaces tokens sitting in a user's wallet that are not currently earning yield. You can use this signal to prompt users with relevant deposit opportunities — for example, showing a banner when a user holds USDC on Base with no active position.
This is the same data that powers the personalized deposit options described below.
## Personalized deposit options
`GET /v2/portfolio/best-deposit-options/{userAddress}` returns ranked yield opportunities that match the user's idle token holdings. Filter by network, minimum TVL, and preferred protocols.
`GET /v2/portfolio/best-vault/{userAddress}` returns the single best-fit vault for the user's current parameters — useful for a one-tap "earn" action.
Deposit options are computed from the user's actual wallet holdings, so you surface only relevant opportunities. A user holding WETH on Arbitrum won't see USDC vaults on mainnet.
Use filters such as `minTvl` and `allowedProtocols` on the best-deposit-options endpoint to enforce your own quality bar before showing deposit options to users.
## PnL and returns tracking
Active position data includes estimated returns since the user entered the vault. You can use this to display:
* **Yield earned to date** — show how much a user has earned in USD or native token terms.
* **Current vs. entry APY** — highlight whether the vault's rate has changed since deposit.
* **Unclaimed rewards** — surface pending reward balances so users know when to claim.
## Example use cases
Display a user's full DeFi yield portfolio in one view — positions across Aave, Morpho, Spark, and more — without building separate integrations for each protocol.
Detect idle assets in a user's wallet and recommend the best single vault for each token. Kraken Wallet uses this pattern to surface yield opportunities directly in the app.
Pull transaction history and returns data to generate a monthly yield report for a user, showing deposits made, yield earned, and current position value.
Periodically check unclaimed reward balances across a user's positions and trigger a notification when rewards exceed a threshold worth claiming.
## API reference
See the full endpoint reference at [/api/portfolio](/api-reference/portfolio), or explore the live spec at `https://api.vaults.fyi/v2/documentation/`.
# Supported DeFi Protocols and Networks on Vaults.fyi
Source: https://docs.vaults.fyi/concepts/supported-protocols
Vaults.fyi covers 80+ DeFi protocols on 20+ EVM networks plus Solana/SVM Beta coverage, including Aave, Morpho, Kamino, Drift, Jupiter, Jito, Lido, and Yearn.
Vaults.fyi covers over 80 DeFi protocols across more than 20 EVM networks, plus Solana/SVM vault coverage in Beta. For each supported protocol, you get standardized market data — APY, TVL, fees, and the Reputation Score — through one API surface, regardless of how each protocol is implemented under the hood.
## Analytics vs. transactional support
Not all protocols have the same level of integration. Coverage falls into two tiers:
Market data is available: APY, TVL, fees, historical rates, and the Reputation Score. You can query and display vault data but cannot prepare transaction payloads.
Full integration: market data plus ready-to-sign deposit, redeem, and claim transaction payloads. Users can interact with the vault directly through your app.
To check whether a specific vault supports transactions, call `GET /v2/transactions/context/` for that vault. If transactional actions are unavailable, the response will indicate which steps are supported.
## Key protocols
The following protocols are among the most widely used on Vaults.fyi:
* **Aave** — the largest decentralized lending protocol, available across multiple networks
* **Morpho** — modular lending built on top of Aave and Compound
* **Euler** — permissionless lending vaults with flexible risk parameters
* **Spark** — MakerDAO's lending and savings layer
* **Lido** — liquid staking for ETH with broad DeFi integrations
* **Compound** — one of the original onchain money markets
* **Yearn** — automated yield aggregation with multi-strategy vaults
* **Kamino, Drift, Jupiter, and Jito** — Solana/SVM vault coverage available through the Beta API
These protocols represent a cross-section of the 80+ covered. For the authoritative V2 EVM protocol list, query `GET /v2/protocols` directly. For Solana/SVM coverage, use the Beta SVM endpoints.
## Protocol names and IDs
Each protocol object includes a lowercase `protocolId` built from its name and, when available, its product and version. Use `GET /v2/protocols` to retrieve the current values rather than constructing them in your integration.
Protocol filters such as `allowedProtocols` and `disallowedProtocols` accept either:
* A protocol `name`, such as `aave`, to match every supported Aave product and version
* A full `protocolId`, such as `aave-standard spoke-v4`, to match only Aave V4 Standard Spoke opportunities
```bash theme={null}
# Match all Aave opportunities
curl --get 'https://api.vaults.fyi/v2/detailed-vaults' \
--header 'x-api-key: YOUR_API_KEY' \
--data-urlencode 'allowedProtocols=aave'
# Match only the Aave V4 Standard Spoke product
curl --get 'https://api.vaults.fyi/v2/detailed-vaults' \
--header 'x-api-key: YOUR_API_KEY' \
--data-urlencode 'allowedProtocols=aave-standard spoke-v4'
```
The same name-or-ID behavior applies anywhere these filters are exposed across V2, Alpha, and Beta. If both allow and deny filters are supplied, `allowedProtocols` takes precedence.
## Full protocol list
The following protocols are supported as of July 2026:
40acres, Aave, Aera, Ajna, Angle, Ankr, APYx, Arcadia, Avantis, Avon, Backed, Beefy, Cap, Centrifuge, Coinbase cbETH, Compound, Concrete, Convex, Dolomite, Drift, Ember, Ethena, Ether.Fi, Ethx, Euler, Extrafi, Fluid, Frax, Gearbox, Harvest Finance, Hop, Hyperbeat, Hyperlend, Infinifi, Inverse Finance, IPOR, Jito, Jupiter, Kamino, Kelp, Lagoon, Level, Lido, ListaDAO, Maker, Matrixdock, Mellow, Midas, Moonwell, Morpho, Mountain, Nashpoint, Notional, Ondo, Open Eden, OpenCover, Origin, Overnight Finance, Reservoir, Resolv, Revert.Finance, Rocket Pool, Seamless, Silo, Sky, Spark, Stader Ethx, Stakewise, Stargate, Summer.Fi, Superform, Swell, Syrup, Term, Tokemak, Tydro, Ultrayield, Upshift Finance, Veda, Venus, Wildcat, Yearn, Yearn yEth, Yo
## Supported networks
Vaults.fyi currently supports the following networks:
Ethereum Mainnet
Arbitrum
Base
Optimism
Polygon
Avalanche
Berachain
Binance Smart Chain (BSC)
Celo
Etherlink
Gnosis
Hyperliquid
Ink
Katana
Linea
Mega-ETH
Monad
Plasma
Robinhood
Solana (SVM, Beta)
Swellchain
Unichain
Worldchain
Query `GET /v2/networks` to get the live list of V2 EVM networks with their chain IDs. Solana/SVM endpoints are available in [Beta](/api-reference/beta#solana-vaults).
## How coverage expands
Vaults.fyi continuously adds new protocols and networks. When a new protocol launches or reaches meaningful TVL, it goes through a review and integration process before appearing in the API.
To check the current state of any protocol or network programmatically, use the reference endpoints:
* `GET /v2/protocols` — returns protocol names, products, and versions for the V2 EVM API
* `GET /v2/networks` — returns supported V2 EVM networks with chain IDs
* `GET /beta/svm/detailed-vaults` — returns Solana/SVM vault coverage in Beta
These endpoints always reflect the live state of the API, so they are more reliable than any static list.
# Transaction Flows
Source: https://docs.vaults.fyi/concepts/transaction-flows
Generate ready-to-sign deposit, redeem, and claim payloads for hundreds of vaults without intermediary contracts or custodial risk.
The Vaults.fyi transaction API lets you integrate vault interactions — deposits, redemptions, and reward claims — across hundreds of protocols without writing any protocol-specific contract logic. You get back ready-to-sign transaction payloads that users submit directly to the protocol. No intermediary smart contracts sit between your users and their funds.
If you want a packaged Earn UI instead of building transaction screens yourself, the [embeddable widget](/use-cases/embeddable-widget) can combine curated discovery, positions, and transaction-ready flows in a branded interface.
## Supported actions
The API supports the following vault interaction types:
| Action | Description |
| - | - |
| `deposit` | Move tokens into a vault to start earning yield |
| `redeem` | Withdraw tokens from a vault in a single step (for instant-redeem vaults) |
| `request-redeem` | Submit a withdrawal request for vaults with a queue or delay |
| `claim-redeem` | Claim tokens after a withdrawal request has been fulfilled |
| `claim-rewards` | Collect accrued reward tokens from a vault or across multiple vaults |
Not all vaults support every action. Use the transaction context endpoint to check which actions are available for a specific vault and user before rendering UI controls.
## How transaction preparation works
Call `GET /v2/transactions/context/` with the vault address, network, and user wallet address. The response tells you which actions are available, the user's current position and balances, and any claimable rewards.
Call `GET /v2/transactions/{action}/` with the action you want to prepare (e.g., `deposit`), the vault, the amount, and the user address. The API returns a fully formed transaction payload — including calldata, to-address, and value — ready to be signed.
Pass the payload to your wallet integration (e.g., `eth_sendTransaction` for EOA wallets, or a UserOperation for ERC-4337 smart wallets). The user signs and submits directly to the protocol.
After the transaction is confirmed onchain, re-fetch the transaction context or portfolio endpoints to reflect the updated position in your UI.
## EOA and smart wallet support
The API works with both externally owned accounts (EOA) and ERC-4337 compatible smart contract wallets.
For standard wallets (e.g., MetaMask, Coinbase Wallet), the API returns a single transaction object. Pass it directly to your wallet library and prompt the user to sign.
The user's transaction goes straight to the protocol contract — no proxy or intermediary contract is involved.
For ERC-4337 wallets, the API returns a payload formatted as a UserOperation. Submit it to your bundler of choice.
As with EOA wallets, the operation targets the protocol contract directly. No additional contract layers are introduced.
## Key properties
Users transact directly with protocol smart contracts. Vaults.fyi never holds or controls user funds.
The API prepares calldata for the protocol's own contracts. No proxy or aggregator contracts are inserted.
The rewards endpoint discovers claimable rewards across all supported vaults for an address and generates batched claim payloads.
Transactions generated by Vaults.fyi include attribution metadata so integrations can track TVL flows and support fee rebate programs where available.
## TVL tracking and fee rebates
Transactions created with the Vaults.fyi Transactions API include attribution metadata automatically. This lets your integration track deposits, withdrawals, and current attributed TVL in [portal.vaults.fyi](https://portal.vaults.fyi).
The same attribution layer can also support monetization through fee rebate programs where they are available. In those cases, the transaction metadata identifies the integration that originated the flow, making it possible to connect vault activity back to the partner that drove it.
If you use the Transactions API, no extra work is required — the returned payload already includes the tracking suffix.
If you build transactions yourself, use the free attribution suffix endpoint and append the returned suffix to your calldata. See [TVL Attribution](/concepts/tvl-attribution#generating-attribution-suffixes-for-existing-transaction-flows) for the full setup guide.
Always call the transaction context endpoint before generating a payload. Attempting to prepare a transaction for an unsupported action or insufficient balance will return an error.
## API reference
See the full endpoint reference at [/api/transactions](/api-reference/transactions), or explore the live spec at `https://api.vaults.fyi/v2/documentation/`.
# TVL Attribution
Source: https://docs.vaults.fyi/concepts/tvl-attribution
Track the deposits, withdrawals, and current TVL your app, wallet, or frontend drives into DeFi vaults.
TVL tracking lets wallets, apps, protocol frontends, and other transaction builders measure the vault flows they generate.
By adding a Vaults.fyi tracking suffix to vault transactions, your integration can see which deposits and withdrawals came from your product, how much attributed TVL remains in each vault, and how that traffic changes over time in [portal.vaults.fyi](https://portal.vaults.fyi). The same attribution layer can also support monetization through fee rebate programs where available.
The tracking layer does not change the user's transaction path. Users still interact directly with the target vault or protocol contract. Vaults.fyi only adds attribution metadata to the calldata so confirmed onchain activity can be connected back to your integration.
If you want attribution, discovery, positions, and transaction-ready flows packaged into one branded surface, see the [embeddable widget](/use-cases/embeddable-widget).
## What you can track
Once your transactions are tagged, portal.vaults.fyi gives you a live view of the traffic and TVL your integration drives.
You can track:
* Deposits, withdrawals, redeems, claims, and other supported vault actions created by your integration.
* Current attributed TVL by vault, protocol, curator, and network.
* Daily TVL changes over time.
* User-level balances and transaction history for tracked vault interactions.
* Which flows are sticky and how much value remains in vaults after users enter.
* Which attributed flows may be eligible for fee rebate programs where available.
## Why integrators use it
Show the vault TVL your wallet, app, or frontend is driving instead of relying on off-chain estimates or partner-side reporting.
Measure not only transaction volume, but how much value remains in vaults over time after users deposit.
Use the free suffix endpoint to track attributed TVL for free in portal.vaults.fyi and support fee rebate programs where available.
## Integration paths
There are two ways to enable TVL tracking.
### Option 1: Use the Vaults.fyi Transactions API
Every transaction created with the Vaults.fyi Transactions API automatically has TVL tracking enabled.
If you use Vaults.fyi to generate deposit, redeem, claim, or other supported vault transaction payloads, no additional integration work is required. The returned transaction data already includes the tracking suffix, so deposits and withdrawals can be attributed and reported in portal.vaults.fyi.
For apps and wallets that want Vaults.fyi to prepare the full vault transaction, this is the simplest path: request the transaction payload, pass it to the user's wallet, and tracking is included automatically.
### Option 2: Use your own transaction builder with the free suffix endpoint
If you already build vault transactions yourself, use the free suffix endpoint. It returns a short calldata suffix that you append to your existing transaction data.
This is the recommended path for wallets, apps, and protocol frontends that already build vault transactions themselves but want to track their deposits and withdrawals so they can analyze the flows and see their traffic.
## Generating attribution suffixes for existing transaction flows
This section is designed for integrators who already have their own transaction-building flow.
### What you need
* A free Vaults.fyi account. Accounts are currently invite-only.
* An API key created from that account.
* Access to [portal.vaults.fyi](https://portal.vaults.fyi), **where attributed TVL can be tracked for free**.
* The user wallet address and vault ID for each transaction being tagged.
### Endpoint
```http theme={null}
GET https://api.vaults.fyi/v2/transactions/suffix/{userAddress}/{vaultId}
x-api-key: YOUR_API_KEY
```
**The endpoint is free to use.** The returned suffix identifies your integration for TVL attribution.
The suffix is generated from both the user wallet address and the vault ID. Vaults.fyi uses these values to correctly attribute transactions even when the submitted transaction path is more complex than a simple EOA-to-vault call, including account abstraction, smart wallets, relayers, and other flows where the transaction sender may not be the same as the end user whose vault position should be tracked.
Example response:
```json theme={null}
{
"suffix": "d9d16d34ffb15ba3263708f3dcff6ee7535a2a0fffc69deb"
}
```
### Append the suffix to calldata
Append the returned suffix to your existing calldata without adding another `0x` prefix:
```ts theme={null}
const tx = buildVaultTransaction(...)
const { suffix } = await fetch(
`https://api.vaults.fyi/v2/transactions/suffix/${userAddress}/${vaultId}`,
{
headers: {
"x-api-key": process.env.VAULTS_FYI_API_KEY,
},
}
).then((response) => response.json())
const trackedTransaction = {
...tx,
data: `${tx.data}${suffix}`,
}
```
Append the suffix to every vault transaction you want attributed, including deposits, withdrawals, redeems, claims, and any other supported vault action. Attribution is transaction-level: if a transaction is sent without the suffix, Vaults.fyi cannot attribute that flow to your integration.
Send `trackedTransaction` through your normal wallet or transaction pipeline. Once confirmed onchain, the transaction can be attributed and analyzed for free in [portal.vaults.fyi](https://portal.vaults.fyi).
The transaction recipient, value, chain, and function arguments do not change. Only the calldata string is extended with the tracking suffix.
## What you see in the portal
Portal views are organized as a drill-down from your aggregate attributed TVL to individual user-vault activity.
### 1. Overview: total attributed TVL
Start with the overview to see total attributed value, asset allocation, and daily TVL over time.
### 2. Breakdown: protocol or curator source
Drill into attributed TVL by protocol or curator to understand where your tracked flows are landing and how those balances change over time.
### 3. Vaults: attributed TVL by vault
Open a source to see the vaults receiving tracked flows, including network, APY, average value outstanding, and net TVL.
### 4. Vault detail: users in a specific vault
Select a vault to inspect its daily attributed TVL and the users contributing to that balance.
### 5. User detail: transaction-level history
Open a user to review the attributed balance and transaction history for that user-vault relationship.
## For curators and protocols
Curators and protocols can use this page as an integration guide for wallets, apps, and other distribution partners.
Send integrators the [attribution suffix guide](#generating-attribution-suffixes-for-existing-transaction-flows) so they can create an API key, append the suffix to their existing vault transactions, and make their flows visible in portal.vaults.fyi.
Once integrators tag transactions, curators and protocols can use the portal to understand which partners are routing users into their vaults and how much TVL remains attributable to those flows.
## API reference
See the full endpoint reference at [/api-reference/transactions](/api-reference/transactions), or explore the live OpenAPI spec at `https://api.vaults.fyi/v2/documentation/json`.
# Vault Discovery
Source: https://docs.vaults.fyi/concepts/vault-discovery
Find, filter, and understand DeFi vaults using normalized identity, performance, TVL, fee, risk, holder, and transaction support data.
## Everything You Can Know About a Vault
The Vaults.fyi API surfaces more data about a DeFi vault than most applications ever need. Use it to discover opportunities, build vault detail pages, power filters, and decide which vaults are suitable for your users. This page documents what you can retrieve — what each field means, which endpoint it comes from, and what you would use it for.
The primary source for static vault data is [`GET /v2/detailed-vaults/{network}/{vaultId}`](/api-reference/detailed-vaults/get-vault-details). Additional endpoints extend that with advanced analytics, time-series history, near real-time state, and per-user position data.
The auto-generated [API Reference endpoint pages](/api-reference/detailed-vaults) are the authoritative source for exact field names, types, and required/optional status — they update automatically from the OpenAPI spec on every release. This page is the narrative layer: what each field means and when to use it. If you spot a discrepancy, the endpoint page is correct.
***
## Identity
Every vault has a stable identity and a set of descriptive fields.
| Field | Description |
| - | - |
| `vaultId` | Stable identifier used in all API calls and deep links. Persists across vault upgrades. |
| `address` | Vault contract address (EIP-55 checksummed). |
| `name` | Human-readable vault name. |
| `description` | Free-text description of the vault strategy, if provided by the protocol. |
| `network.name` | Network slug: `mainnet`, `base`, `arbitrum`, `optimism`, `polygon`, and others. |
| `network.chainId` | EVM chain ID. |
| `network.networkCaip` | CAIP-2 network identifier (e.g. `eip155:1`). |
| `tags` | Array of category tags (e.g. `Lending`, `Liquid Staking`, `RWA`). Useful for filtering. See [Vault Tags](#vault-tags). |
| `isAppFeatured` | Whether the vault is featured on app.vaults.fyi. |
| `lastUpdateTimestamp` | Unix timestamp of the most recent onchain data index. |
***
## Vault Tags
Vault tags describe the economic mechanism, product type, or structural exposure behind a vault. They are useful for filtering vaults, building category views, and explaining why a vault belongs in a given yield segment.
Tags are not mutually exclusive: a vault can have more than one tag when multiple classifications apply. Some tags are broad parent categories, while others are more precise subclasses. For example, `Lending` is the broad parent category for lending-driven yield, while tags like `Curated Lending`, `Direct Protocol Lending`, `Isolated Market`, and `Shared Lending Pool` provide more specific filtering.
Use [`GET /v2/tags`](/api-reference/general/list-tags) to retrieve the live list of supported tags.
| Tag | Definition |
| - | - |
| `Basis Trading` | Products where yield is primarily generated from futures, perps, or spot/derivatives basis and funding-rate strategies. |
| `Bridging` | Products related to moving assets or liquidity across networks. |
| `CDP` | Products where yield is sourced from collateralized debt position (CDP) systems where users mint or borrow against deposited collateral. |
| `Credit` | Products with default/underwriting/counterparty risk, including private credit, structured credit, or other off-chain sources of yield. |
| `Curated Lending` | Lending exposure where a curator, risk manager, or allocator selects eligible markets, collateral, caps, or allocations. |
| `DEX-Integrated Lending` | Lending products where supplied capital directly shares a unified liquidity layer that simultaneously supports lending and DEX or trading activity. |
| `Direct Protocol Lending` | Direct supply into a protocol lending pool or market, where yield is primarily generated by borrower interest rather than a curator vault, managed strategy, credit product, or protocol savings rate. |
| `Isolated Market` | Lending market where risk is sandboxed and scoped to a specific market contract, vault, or collateral configuration rather than shared across a broad pooled lending system. |
| `Lending` | Broad parent tag for products where yield primarily comes from lending activity. Use subclass tags for more precise filtering. |
| `Liquid Staking` | Products that provide exposure to staking yield through a liquid receipt token or staking vault. |
| `Market Making` | Products where yield is generated from providing liquidity, market making, or trader flow rather than borrower interest. |
| `Protocol Savings Rate` | Yield-bearing product where the return is primarily determined by a policy-driven or governance-managed savings/rate mechanism rather than direct lending market utilization. Excludes assets that actively underwrite protocol deficits or act as first-loss capital. |
| `Risk Cover` | Products that are protected in part by cover for smart contract, protocol, slashing, custody, depeg, or other onchain risks. |
| `RWA` | Products with exposure to real-world assets or offchain financial instruments, such as tokenized treasuries, private credit, or other offchain yield sources. |
| `Safety Module` | Products where deposited assets backstop protocol risk and may be used to absorb shortfalls, underwrite liquidations, or participate in protocol protection mechanisms. |
| `Shared Lending Pool` | Lending products where supplied liquidity is pooled across multiple collateral types, exposing depositors to global or protocol-wide risk parameters rather than an isolated market configuration. |
| `Synthetic` | Products with synthetic asset construction, derivative-like backing, or engineered exposure that does not represent a simple claim on the underlying asset. |
| `Yield Aggregator` | Broad category for products that route, allocate, or compound deposits across one or more external yield sources or strategies. |
***
## Protocol and Curator
Vaults belong to a protocol. Some are additionally managed by a named curator (e.g. a risk manager or strategy team).
| Field | Description |
| - | - |
| `protocol.name` | Protocol name (e.g. `Morpho`, `Aave`, `Compound`). |
| `protocol.product` | Product line within the protocol, if applicable. |
| `protocol.version` | Protocol version. |
| `protocol.protocolUrl` | Protocol website. |
| `protocol.description` | Short protocol description. |
| `protocol.protocolLogo` | URL to the protocol logo image. |
| `curator.name` | Canonical curator identifier, if one is assigned. Use this value for filtering and stable matching. |
| `curator.displayName` | Optional presentation-ready curator name. Fall back to `curator.name` when absent. |
| `curator.description` | Description of the curator. |
| `curator.websiteUrl` | Curator website. |
| `protocolVaultUrl` | Direct URL to this vault on the protocol's own interface. |
| `lendUrl` | URL to lend the vault's asset directly. |
***
## The Asset
The underlying asset is what users deposit and withdraw. All balances and TVL figures reference this token.
| Field | Description |
| - | - |
| `asset.symbol` | Token symbol (e.g. `USDC`, `WETH`). |
| `asset.name` | Full token name. |
| `asset.address` | Token contract address. |
| `asset.assetCaip` | CAIP-19 asset identifier. |
| `asset.decimals` | Token precision. |
| `asset.assetPriceInUsd` | Current USD price. |
| `asset.assetGroup` | High-level category: `USD`, `ETH`, `BTC`, `EURO`, or `OTHER`. |
| `asset.assetLogo` | URL to the token logo image. |
| `additionalAssets` | For multi-asset vaults: the same asset fields for each additional accepted asset. |
***
## The LP Token
When a user deposits into a vault, they receive LP tokens representing their share. These are the tokens held in a wallet.
| Field | Description |
| - | - |
| `lpToken.symbol` | LP token symbol. |
| `lpToken.name` | LP token name. |
| `lpToken.address` | LP token contract address. |
| `lpToken.tokenCaip` | CAIP-19 identifier for the LP token. |
| `lpToken.decimals` | LP token precision. |
| `sharePrice` | LP token share price. |
***
## APY
APY data is normalized across all protocols using a consistent methodology. See [Calculating APY](/methodology/calculating-apy) for details.
All APY values are net of performance and management fees. Use `fees` to show fee details alongside yield, not to adjust the returned APY.
Each vault returns APY across four time windows, each broken into three components:
| Field | Description |
| - | - |
| `apy.1hour.base` | Base yield earned from lending or strategy, annualized over the last hour. |
| `apy.1hour.reward` | Token reward APY (e.g. incentive programs), annualized over the last hour. |
| `apy.1hour.total` | Sum of base and reward. |
| `apy.1day` | Same breakdown averaged over 24 hours. |
| `apy.7day` | Same breakdown averaged over 7 days. |
| `apy.30day` | Same breakdown averaged over 30 days. |
Use `apy.7day.total` or `apy.30day.total` for user-facing yield displays. The 1-hour and 1-day figures are noisier and better suited for dashboards or anomaly detection.
### Composite APY (nested vaults)
When a vault's underlying asset is itself another vault's LP token (e.g. a vault that deposits into another yield vault), an additional `apyComposite` object is present. It compounds both layers of yield into a single figure.
| Field | Description |
| - | - |
| `apyComposite.totalApy` | Compounded APY combining this vault and the underlying vault (same 1h/1d/7d/30d windows). |
| `apyComposite.intrinsicApy` | The underlying vault's own APY, before compounding. |
| `apyComposite.vault.vaultId` | ID of the underlying vault. |
| `apyComposite.asset` | Asset details of the underlying vault. |
***
## TVL
| Field | Description |
| - | - |
| `tvl.usd` | Total value locked, denominated in USD. |
| `tvl.native` | Total value locked, denominated in the vault's native asset. |
***
## Advanced Analytics
For deeper vault discovery and diligence workflows, use the Beta Advanced Analytics endpoints:
| Endpoint | Use case |
| - | - |
| `POST /beta/advanced-analytics` | Screen a filtered list of vaults with selected analytics fields. |
| `POST /beta/advanced-analytics/{network}/{vaultId}` | Fetch selected analytics fields for one known vault. |
Advanced Analytics uses a `select` request body so applications only request the sections they need:
```json theme={null}
{
"select": {
"maxDrawdown": true,
"withdrawalPauseRatio": true,
"composition": true,
"utilizationRate": true,
"detailedVault": true
}
}
```
Each request costs 1 base credit. Add the following costs for each returned item based on the fields included in `select`:
| Selected field | Credits per returned item |
| - | -: |
| `maxDrawdown` | 2 |
| `detailedVault` | 3 |
| `withdrawalPauseRatio` | 2 |
| `composition` | 3 |
| `utilizationRate` | 3 |
The selected field costs are cumulative. For `n` returned items, calculate the total as `1 + n × (sum of selected field costs)`.
| Field | Description |
| - | - |
| `maxDrawdown.mdd30days` | Maximum drawdown (MDD): the largest observed peak-to-trough drop in vault price per share over the last 30 days, reported as a decimal. |
| `maxDrawdown.mdd90days` | Maximum drawdown (MDD) over the last 90 days. |
| `maxDrawdown.mdd365days` | Maximum drawdown (MDD) over the last 365 days. |
| `withdrawalPauseRatio` | Ratio from `0` to `1` representing how much time withdrawals were paused over the last two years. Returns `null` when the protocol does not expose a supported pause-event source or the event history has not been backfilled. |
| `composition[]` | Vault allocation or investment composition where available. Useful for showing what a vault is allocated into, especially allocator-style products. |
| `composition[].id` | Identifier for the investment or market. |
| `composition[].supplyAssets` | Amount of underlying assets supplied to that investment. |
| `composition[].allocation` | Share of the vault allocated to that investment, as a decimal. |
| `composition[].name` | Human-readable name for the investment or market. |
| `utilizationRate` | Share of vault assets currently utilized, as a decimal. For Morpho allocator vaults, this represents the invested share of vault assets. For Aave and Spark aToken vaults, it represents the underlying lending reserve utilization. Returns `null` when unavailable. |
| `detailedVault` | Full V2 detailed vault payload embedded alongside the selected analytics fields. Useful when building one combined discovery response. |
Advanced Analytics is currently in Beta. Field availability depends on protocol support and data coverage. Build integrations so nullable fields can be hidden or explained instead of treated as failures.
See [Beta API Reference](/api-reference/beta#advanced-analytics) for filters, request shape, and endpoint details.
***
## Additional Rewards
Many vaults distribute bonus reward tokens on top of base yield. Each entry in the `rewards` array represents one reward token.
| Field | Description |
| - | - |
| `rewards[].asset.symbol` | Reward token symbol. |
| `rewards[].asset.assetPriceInUsd` | Current USD price of the reward token. |
| `rewards[].apy.1hour` | Reward APY over 1 hour. |
| `rewards[].apy.1day` | Reward APY over 1 day. |
| `rewards[].apy.7day` | Reward APY over 7 days. |
| `rewards[].apy.30day` | Reward APY over 30 days. |
Reward APYs are already included in the top-level `apy.*.reward` field. The `rewards` array lets you attribute yield to specific tokens and display individual reward rates.
***
## Reputation Score
Vaults.fyi computes a composite reputation score for each vault based on several risk signals. Higher is better. See [Reputation Score](/methodology/reputation-score) for methodology.
| Field | Description |
| - | - |
| `score.vaultScore` | Composite Reputation Score combining all component scores, after any flag penalties are applied. |
| `score.vaultTvlScore` | Score component based on this vault's TVL. |
| `score.protocolTvlScore` | Score component based on the protocol's total TVL. |
| `score.holderScore` | Score component based on holder count and distribution. |
| `score.networkScore` | Deprecated network score. It is returned for backwards compatibility and diagnostics, but is not included in the current Reputation Score. |
| `score.assetScore` | Score component based on the underlying asset type and liquidity. |
| `score.totalScorePenalty` | Current point deduction applied to `score.vaultScore` because of flag penalties. |
| `score.penaltyComponents` | Active or decaying flag penalties applied to the composite score, with severity and resolution details for each. |
| `score.penaltyComponents[].type` | Penalty source. Flag penalties use `flag`. |
| `score.penaltyComponents[].value` | Current point deduction from this penalty component. For resolved flags, this may be partially reduced. |
| `score.penaltyComponents[].content` | Flag message text for flag-derived penalties. |
| `score.penaltyComponents[].severity` | Flag severity: `info`, `warning`, or `critical`. |
| `score.penaltyComponents[].endDate` | Unix timestamp when the flag expires. |
| `score.penaltyComponents[].resolution` | Optional resolution note explaining how the flagged issue was addressed. Omitted for unresolved flags. |
***
## Holders
| Field | Description |
| - | - |
| `holdersData.totalCount` | Total number of unique vault holders. |
| `holdersData.totalBalance` | Combined LP token balance across all holders. |
| `holdersData.topHolders[].address` | Address of a top holder. |
| `holdersData.topHolders[].lpTokenBalance` | LP token balance of that holder. |
***
## Capacity
| Field | Description |
| - | - |
| `maxCapacity` | Maximum total deposit capacity enforced by the vault, in asset units. Omitted if uncapped. |
| `remainingCapacity` | How much more can be deposited before the cap is reached. |
***
## Fee Structure
| Field | Description |
| - | - |
| `fees.performanceFee` | Percentage of yield taken by the protocol (as a decimal, e.g. `0.10` for 10%). |
| `fees.managementFee` | Annual fee on AUM (as a decimal). |
| `fees.withdrawalFee` | Fee charged on withdrawals (as a decimal). |
| `fees.depositFee` | Fee charged on deposits (as a decimal). |
All fee fields are optional and omitted when not applicable to a given vault. Performance and management fees are already reflected in returned APY values.
***
## Flags and Warnings
| Field | Description |
| - | - |
| `warnings` | Array of plain-text warning strings derived from active non-`info` flags. Kept for simple integrations that only need display text. |
| `flags[].content` | Flag message text. |
| `flags[].severity` | One of `info`, `warning`, or `critical`. |
| `flags[].endDate` | Unix timestamp when the flag expires. Past flags are not returned. |
| `flags[].resolution` | Optional resolution note explaining how the flagged issue was addressed. Omitted for unresolved flags. |
Use `flags` to surface active protocol notices in your UI, such as paused deposits, ongoing audits, migration notices, or resolved incidents that are still within their display window. Use `flags[].resolution` when present to show that an issue has been mitigated or otherwise addressed.
`warnings` is a convenience text array for backward-compatible displays. Prefer `flags` for new integrations because it includes severity, expiry, and resolution context.
Active flags can reduce the vault's Reputation Score. Resolved flags may still appear and may still contribute a reduced penalty while the Reputation Score recovers — see [Flag penalties](/methodology/reputation-score#flag-penalties) for how severity and decay work.
***
## Transactional Support
| Field | Description |
| - | - |
| `isTransactional` | Whether this vault supports the Transactions API for deposit, redeem, and claim flows. |
| `transactionalProperties.depositStepsType` | `instant` (single tx) or `complex` (multi-step, e.g. requires approval). |
| `transactionalProperties.redeemStepsType` | `instant` or `complex`. |
| `transactionalProperties.rewardsSupported` | Whether reward claim transactions are supported for this vault. |
See [Transaction Flows](/concepts/transaction-flows) for full details on building deposit and withdrawal flows.
***
## Other Metadata
| Field | Description |
| - | - |
| `additionalIncentives` | Free-text description of any non-token incentives (e.g. points, airdrop eligibility). |
| `childrenVaults` | For aggregator vaults: the list of sub-vaults the vault allocates to, each with their own asset and LP token info. |
| `userEventsIndexed` | Whether deposit and withdrawal events for this vault are indexed and queryable via the portfolio endpoints. |
| `isCorrupted` | Flags vaults where the indexed data is known to be unreliable. Exclude these from production displays. |
***
## Historical Time-Series
The following is available from the historical endpoints (`GET /v2/historical/{network}/{vaultId}`).
Each data point in the time series includes:
| Field | Description |
| - | - |
| `timestamp` | Unix timestamp of the snapshot. |
| `blockNumber` | Block number of the snapshot. |
| `apy.base` / `apy.reward` / `apy.total` | APY breakdown at that point in time. |
| `tvl.usd` / `tvl.native` | TVL at that point in time. |
| `sharePrice` | Share price of the vault at that block. |
Separate endpoints allow fetching APY-only, TVL-only, or share price-only history for lower cost. See [Historical](/api-reference/historical).
***
## Near Real-Time Metrics
For applications that need the most current vault state (deposit previews, live dashboards, liquidation monitoring), the NRT endpoints query onchain state directly rather than relying on the hourly index.
| Endpoint | Returns |
| - | - |
| `/v2/nrt/vault/{network}/{vaultId}` | All four metrics in one call |
| `/v2/nrt/vault/{network}/{vaultId}/sharePrice` | Current share price |
| `/v2/nrt/vault/{network}/{vaultId}/totalAssets` | Total assets in asset-wei |
| `/v2/nrt/vault/{network}/{vaultId}/totalSupply` | Total LP token supply in asset-wei |
| `/v2/nrt/vault/{network}/{vaultId}/underlyingAssetPrice` | Current USD price of the underlying asset |
***
## User Position Data
The portfolio endpoints return per-wallet position data for any vault where `userEventsIndexed` is `true`.
### Current position
`GET /v2/portfolio/positions/{userAddress}/{network}/{vaultId}`
| Field | Description |
| - | - |
| `asset.balanceNative` | Position value in the underlying asset's native units. |
| `asset.balanceUsd` | Position value in USD (omitted if asset price unavailable). |
| `asset.unclaimedNative` | Unclaimed reward balance in native units. |
| `asset.unclaimedUsd` | Unclaimed reward value in USD. |
| `asset.positionValueInAsset` | Position value expressed in asset precision. |
| `lpToken.balanceNative` | LP token balance held by the user. |
| `lpToken.balanceUsd` | LP token balance in USD. |
| `lpToken.assetPriceInUsd` | Current LP token price in USD. |
### Total returns
`GET /v2/portfolio/total-returns/{userAddress}/{network}/{vaultId}`
| Field | Description |
| - | - |
| `returnsNative` | Total yield earned by this address in this vault, in native token units. |
| `symbol` / `name` / `assetPriceInUsd` | Asset details for display. |
### Transaction history
`GET /v2/portfolio/events/{userAddress}/{network}/{vaultId}`
| Field | Description |
| - | - |
| `eventType` | Transaction type: deposit, withdrawal, or reward claim. |
| `timestamp` | Unix timestamp of the transaction. |
| `assetAmountNative` | Asset amount moved, in native units. |
| `sharePrice` | LP token share price at time of transaction. |
| `lpTokenAmount` | Number of LP tokens minted or burned. |
| `transactionHash` | Onchain transaction hash. |
| `logIndex` | Log index for disambiguation within a block. |
# Yield & Market Data
Source: https://docs.vaults.fyi/concepts/yield-and-market-data
Query standardized APY, TVL, fees, the Reputation Score, and rewards across 1,000+ vaults via hourly onchain indexing — all from a single API.
The Vaults.fyi API gives you standardized market data for over 1,000 DeFi yield vaults across 80+ protocols, 20+ EVM chains, and Solana/SVM vault coverage in Beta. Instead of building and maintaining one-off integrations per protocol, you get a single endpoint family that returns consistent, comparable data for supported vaults.
Data is indexed onchain on an hourly basis, so you always have current metrics alongside the full historical record you need for backtesting and trend analysis.
## What data is available
Each vault object includes APY across four time windows, TVL in USD and native units, a fee breakdown, the Reputation Score with component scores, reward token rates, holder counts, capacity limits, and flags for active protocol notices — among other fields.
APY, TVL, fees, and the Reputation Score are computed consistently across all protocols. APY values are net of performance and management fees; the `fees` object is for display and does not need to be subtracted from APY.
For a complete field-by-field reference covering everything the API can tell you about a vault, see [Vault Discovery](/concepts/vault-discovery).
## Endpoints
Filter and sort vaults by APY, TVL, protocol, network, asset, reputation score, and more.
Full detail on a specific vault including current and historical APY, TVL, fees, rewards, and the Reputation Score.
Time-series APY, TVL, and asset price data over configurable date ranges and granularity.
USD and ETH benchmark rates aggregated across top vaults for performance comparison.
You can also query reference data — supported networks, assets, and protocols — using `GET /v2/networks`, `GET /v2/assets`, and `GET /v2/protocols`. These are useful for building filter dropdowns and validating user input.
## How data is sourced
Vaults.fyi indexes vault state directly from onchain contract calls, not from third-party price feeds or protocol-reported numbers. This approach means:
* **Hourly updates.** Vault metrics refresh every hour from onchain data.
* **Consistent methodology.** APY is calculated using the same formula across all protocols, so comparisons are meaningful.
* **Historical depth.** Time-series data is available for backtesting, charting, and reporting without you needing to store it yourself.
Use the `apy7d` or `apy30d` fields rather than `apy` when you want to smooth out short-term volatility and show users a more stable yield estimate.
## Coverage
One integration gives you data across 1,000+ vaults, 80+ protocols, 20+ EVM chains, and Solana/SVM vault coverage in Beta. For the full list of supported protocols and networks, see [Supported Protocols and Networks](/concepts/supported-protocols).
# Vaults.fyi: The API for DeFi Yield
Source: https://docs.vaults.fyi/introduction
Vaults.fyi gives you a single API to access market data, execute transactions, and track portfolios across 1,000+ DeFi yield strategies on 80+ protocols, including Solana/SVM coverage in Beta.
Vaults.fyi is the unified API for onchain yield. Whether you're building a wallet, a data analytics tool, or an AI agent, a single integration gives you standardized access to 1,000+ DeFi yield strategies across 80+ protocols, 20+ EVM chains, and Solana/SVM vault coverage in Beta — without building a DeFi team or managing per-protocol integrations.
See how teams use Vaults.fyi for yield data, risk context, transactions, portfolios, attribution, and agents.
Install the TypeScript or Python SDK and make your first API call in minutes.
Explore all v2 endpoints for vaults, portfolio, transactions, and benchmarks.
Understand vault discovery, yield data, transaction flows, portfolio tracking, and borrowing.
Use the MCP server or x402 pay-per-request for autonomous agent workflows.
## Why teams use Vaults.fyi
Standardized APY, TVL, fees, and the Reputation Score across all protocols — sourced hourly direct from onchain contracts.
Ready-to-sign deposit, redeem, and claim payloads for hundreds of vaults. No intermediary contracts, fully non-custodial.
Track user positions, detect idle assets, and surface personalized yield opportunities matched to wallet holdings.
## Get started
[Create an account](https://portal.vaults.fyi/) to get access. You'll receive an API key to authenticate all requests.
Install the `@vaultsfyi/sdk` package (TypeScript) or `vaultsfyi` package (Python) and initialize the client with your key.
Call `getAllVaults()` or `GET /v2/detailed-vaults` to browse available yield opportunities filtered by network, protocol, asset, or APY.
Use transactional endpoints to prepare deposit and redeem payloads, and portfolio endpoints to track user positions and PnL.
## Trusted by leading teams
Vaults.fyi powers yield analytics, dashboards, and transaction flows for [Arbitrum Earn](/resources/case-studies/arbitrum), [Jumper](https://jumper.exchange/earn), [Kraken Wallet](https://www.kraken.com/wallet), [Gauntlet](https://gauntlet.xyz/), [Maple Finance](https://maple.finance/), [KPK](https://kpk.io/), and more. See the [case studies](/resources/case-studies) for integration details.
# USD and ETH Benchmark Rates Explained
Source: https://docs.vaults.fyi/methodology/benchmark-rates
Understand how Vaults.fyi constructs USD and ETH benchmark rates from top vaults by TVL, and how to use them to compare yields across networks.
Benchmark rates give you a consistent baseline for evaluating vault performance. Instead of comparing a vault's APY to an arbitrary number, you can compare it to what the largest, most liquid vaults in the same denomination are actually returning right now.
## What benchmarks measure
A benchmark represents the TVL-weighted average APY across the five largest vaults in a given denomination and network, each with at least \$1M in TVL. Vaults.fyi publishes separate **USD** and **ETH** benchmarks for Ethereum mainnet and every supported L2.
Benchmarks use the same trailing APY calculations — 1-day, 7-day, and 30-day windows — as individual vaults. You can compare a vault's APY at any time horizon directly against the benchmark for that same window.
## USD benchmark
The USD benchmark tracks stablecoin lending yield. It is constructed from the five largest USD-denominated vaults on a given network by TVL, weighted proportionally to their TVL at the time of calculation.
On Ethereum mainnet, the legacy v1 USD benchmark is built from four fixed markets:
| Protocol | Market |
| - | - |
| Aave v3 | USDT |
| Aave v3 | USDC |
| MakerDAO | Savings DAI (sDAI) |
| Compound v3 | USDC |
The current v2 benchmark dynamically selects the top five vaults by TVL on each network, so the composition can change as the market evolves.
Use the USD benchmark to answer the question: "Is this stablecoin vault returning more or less than the best passive yield available right now on this network?"
## ETH benchmark
The ETH benchmark tracks ETH staking yield. It is constructed from the five largest ETH-denominated vaults on a given network by TVL, weighted proportionally to their TVL.
On Ethereum mainnet, the legacy v1 ETH benchmark uses four fixed liquid staking tokens (LSTs):
| Protocol | Token |
| - | - |
| Lido | stETH |
| ether.fi | eETH |
| Coinbase | cbETH |
| Rocket Pool | rETH |
As with the USD benchmark, the v2 version dynamically selects the top five ETH vaults by TVL on each supported network.
ETH benchmark rates reflect consensus-layer and execution-layer staking rewards. They are typically more stable than lending rates because they do not respond to short-term changes in borrow demand.
## Comparing vaults across networks
Because benchmarks are published per network, you can normalize vault comparisons across chains. A vault yielding 6% APY on Arbitrum is performing differently relative to its market than a 6% APY vault on Ethereum mainnet if the underlying benchmark rates differ.
When building a yield ranking UI, display the spread between a vault's APY and the benchmark for its network and denomination. This gives users a more meaningful signal than raw APY alone.
## Accessing benchmark data
Retrieve current and historical benchmark APYs via the API:
```
GET /v2/benchmarks/{network}
```
This endpoint returns both USD and ETH benchmarks for the specified network, including 1-day, 7-day, and 30-day trailing APYs.
Vaults.fyi publishes benchmarks for Ethereum mainnet and all supported L2s. If fewer than five vaults with at least \$1M TVL exist in a given denomination on a network, the benchmark uses however many qualify — down to a minimum of one vault.
The v1 benchmarks use a fixed set of protocols on Ethereum mainnet only and are available via the legacy endpoint and the chart explorer. The v2 benchmarks are dynamic, cover all supported networks, and are available via `GET /v2/benchmarks/{network}`. Use v2 for new integrations.
Benchmarks update on the same hourly cadence as vault data — Vaults.fyi indexes onchain state every hour and recalculates all APYs and benchmarks from fresh data.
# How Vaults.fyi Calculates APY
Source: https://docs.vaults.fyi/methodology/calculating-apy
Learn how Vaults.fyi derives APY from onchain share prices using trailing windows, TVL-weighted averages, and reward token accounting.
Vaults.fyi calculates APY by comparing a vault's share price across fixed trailing windows — 1 day, 7 days, and 30 days — rather than relying on instantaneous or self-reported rates. This approach smooths out short-term noise and gives you a yield figure that reflects what depositors actually earned over the period.
## Net APY
All APY values returned by Vaults.fyi are **net of fees**. Performance and management fees reflected in vault share price or yield accrual are already accounted for in the APY.
The fee breakdown is still exposed through the `fees` object on detailed-vault responses so integrators can display fees alongside yield. Do not subtract those fees from returned APY values again.
## Share price method
Every yield-bearing vault issues shares that represent a depositor's proportional stake. As the vault earns yield, the total value it holds grows relative to the number of shares outstanding, so each share becomes worth more. Vaults.fyi reads these values directly from onchain contracts hourly and derives APY from the change in share price over the chosen window.
The share price at any point in time is:
```
share price = total shares value / total shares
```
The interest rate over a window is then:
```
interest rate = (current share price / previous share price) - 1
```
## APY formulas
For vaults that compound automatically, Vaults.fyi uses the compounding formula:
```
APY = [(1 + interest rate) ^ (year / time)] - 1
```
For vaults that distribute simple (non-compounding) interest:
```
APY = interest rate × (year / time)
```
`time` is the length of the window in seconds and `year` is the number of seconds in a year (31,536,000).
## Why trailing averages, not spot rates
A spot rate captures yield at a single instant, which can be skewed by temporary liquidity events, large deposits or withdrawals, or the timing of reward distributions. Trailing averages over 1d, 7d, and 30d give you a more stable picture of what a vault actually returned across different time horizons.
The 1-day APY is the most responsive to recent changes. The 30-day APY is the most stable but slower to reflect strategy shifts. Use the window that matches your use case.
## Adjusting for TVL fluctuations
When a vault's total value locked (TVL) changes significantly within a window, a simple average overstates or understates yield. Vaults.fyi applies a TVL-weighted average to correct for this.
Each observation is weighted by the **minimum** TVL between two consecutive data points — a conservative approach that avoids inflating yield during periods of large inflows:
```
weight_t = min(TVL_t, TVL_(t-1))
```
The weighted interest rate over the window is then:
```
interest rate = (Σ (share_price_t / share_price_(t-1)) × weight_t) / (Σ weight_t) - 1
```
This weighting matters most for newer vaults or vaults that experience sudden large deposits, where TVL can swing by orders of magnitude within a single measurement window.
## Reward token APY
Some vaults distribute yield in a token that is different from the deposit asset. Vaults.fyi accounts for reward tokens separately and adds them to the base vault APY.
To calculate reward APY over a given window:
1. Compute the number of reward tokens distributed per deposited token over the period, using a TVL-weighted average of the emission rate.
2. Calculate the time-weighted average price ratio between the reward token and the deposit asset (Price In Token, or PIT).
3. Convert the accumulated reward value into deposit-asset terms using that ratio.
4. Compare the converted value to the initial deposit to derive APY.
If a vault's total APY looks higher than what the share price growth alone would suggest, the difference is likely coming from reward token emissions. Check the breakdown between `baseApy` and `rewardApy` in the API response.
## The `apyComposite` field
The API returns an `apyComposite` object that breaks APY into two components:
| Field | Description |
| - | - |
| `totalApy` | The fully compounded APY, combining the vault's own yield with any underlying protocol yield (e.g., a vault built on top of an LST). |
| `intrinsicApy` | The staking or protocol-level yield from the underlying asset alone, before the vault strategy adds its own return. |
Protocol UIs often display forward-looking or instantaneous rates based on the current supply/borrow utilization model. Vaults.fyi reports trailing realized APY based on what share prices actually did over the window. The two can differ — especially when rates changed recently, or when a protocol's model assumes continuous compounding that does not match how yield actually accrues.
Some vaults — particularly liquid staking tokens (LSTs) and Yearn-style strategies — accrue yield in batches rather than continuously. When an earnings update lands, the share price jumps sharply, which inflates the short-term APY reading for that window. Vaults.fyi surfaces this behavior honestly; the 7d and 30d windows tend to give a cleaner picture for these vault types.
Yes. Rebasing vaults (such as Aave aTokens) grow the user's token balance directly rather than the share price. Staking mechanism vaults (such as StakeWise) separate principal and reward tokens. RWA vaults use oracle prices to compute share value. Each type requires its own onchain data extraction — see [Indexing Onchain Data](/methodology/indexing-onchain-data) for details.
# How Vaults.fyi Indexes Onchain Vault Data
Source: https://docs.vaults.fyi/methodology/indexing-onchain-data
See how Vaults.fyi reads vault share prices hourly using static smart contract calls, with no gas cost, via Infura, Alchemy, and Ankr RPC providers.
Vaults.fyi reads vault state directly from the blockchain every hour. This direct indexing approach — rather than relying on third-party data APIs — is what gives yield figures their accuracy and independence from self-reported protocol numbers.
## The indexing pipeline
Each hour, Vaults.fyi executes specialized smart contracts that fetch and transform vault data in a single function call. These contracts are deployed as **static calls**: they execute transiently without writing to blockchain storage, so they cost no gas and leave no onchain footprint.
This architecture has two key advantages over standard multi-call patterns:
* **Efficiency**: One result can feed the next calculation within the same call. Standard multi-call requires separate calls for each value.
* **Accuracy**: Share prices are read at a consistent block height, so all values used in a single APY calculation come from the same chain state.
Once retrieved, data is stored in the Vaults.fyi backend database for use in APY calculations and API responses.
Vaults.fyi uses Infura, Alchemy, and Ankr as RPC providers. Requests are distributed across providers to maximize reliability and minimize the impact of any single provider's downtime on data freshness.
## How share price is read by vault type
Different vault standards expose share price through different contract interfaces. Vaults.fyi handles each type explicitly.
ERC-4626 is the standard interface for tokenized yield-bearing vaults. Vaults.fyi calls two functions directly:
* `totalSupply()` — returns total shares outstanding
* `totalAssets()` — returns the total value of assets held by the vault
Share price is then `totalAssets / totalSupply`.
For vaults that predate or do not implement ERC-4626, Vaults.fyi derives equivalent values from other contract functions — typically `mint`, `deposit`, `burn`, or `redeem`. These functions expose the relationship between shares and assets in their parameters or return values.
Each non-standard vault may require individual integration work. The functions listed above cover the most common cases, but some vaults have unique interfaces.
For LSTs such as Lido stETH and LRTs, Vaults.fyi uses `totalSupply()` and `getEthValue(totalSupply())` to determine total shares and total value respectively.
LSTs often update their earnings in periodic batches rather than continuously. When a batch posts, the share price jumps sharply, which can inflate the 1-day APY reading for that window. The 7-day and 30-day windows smooth this out — see [Calculating APY](/methodology/calculating-apy) for how irregular update intervals affect trailing averages.
Rebasing vaults, such as Aave aTokens, increase the user's token balance directly rather than increasing the share price. The share-to-value ratio is inverted compared to standard vaults.
Vaults.fyi reads these using:
* `scaledTotalSupply()` — treated as total shares
* `totalSupply()` — treated as total shares value
This reversal is necessary to correctly compute the share price growth that underlies APY calculations.
Some vaults, such as StakeWise, do not compound interest automatically. Users must manually harvest and redeposit rewards. Because the shares-to-value ratio does not reflect actual yield in these vaults, Vaults.fyi simulates share price using a derived formula:
```
total principal value = sETH2.totalSupply()
total rewards value = rETH2.totalSupply()
TVL = total principal value + total rewards value
share price = 1 + rETH2.rewardPerToken()
totalSupply = TVL / share price
```
The `totalSupply` value produced here is a simulation — it is not read directly from the contract. This lets Vaults.fyi apply the same APY formula consistently across vault types.
RWA vaults are ERC-20 tokens that represent interests in off-chain financial assets. Share price cannot be derived from onchain balances alone — it requires oracle prices for both the RWA token and its underlying stablecoin.
Vaults.fyi uses three functions:
* `totalSupply()` — total shares
* `RWAOracle.price()` — price of the RWA share in USD
* `StablecoinOracle.price()` — price of the underlying deposit asset in USD
Total value in asset terms is then:
```
total shares in USD = total shares × RWA oracle price
total shares in asset = total shares in USD / stablecoin oracle price
total shares value = total shares in asset
```
## Data freshness
Vaults.fyi indexes all vaults on an hourly cadence. API responses reflect the most recent hourly snapshot. Because Vaults.fyi reads directly from chain rather than consuming third-party data feeds, yield figures are not subject to delays or data gaps introduced by intermediate data providers.
APY values in API responses represent the state at the last hourly index. If a vault's onchain state changed in the past hour — for example, due to a large deposit or an earnings update — the API will not reflect that change until the next indexing cycle completes.
## Why direct indexing matters
Many yield aggregators source APY data from protocol APIs or front-end endpoints, which can return model-based or forward-looking rates rather than realized yields. Vaults.fyi reads raw contract state and derives all yield figures from first principles. This means:
* **No dependency on protocol reporting**: Vaults.fyi does not rely on a protocol to correctly report its own APY.
* **Consistent methodology**: Every vault uses the same trailing share price calculation, regardless of how the protocol presents its own data.
* **Verifiability**: Any APY figure Vaults.fyi reports can be reproduced by anyone with access to an archive node and the block heights used in the calculation.
# Vault Reputation Score: Risk Filtering Guide
Source: https://docs.vaults.fyi/methodology/reputation-score
Learn how the Vaults.fyi Reputation Score works, what four weighted component scores it uses, how flag penalties apply, and how to use minVaultScore to filter vaults programmatically.
The Vaults.fyi Reputation Score is a proprietary metric that gives you a single, objective number to assess how battle-tested a vault is. It is not a comprehensive risk rating — it is a signal about protocol and vault history securing capital, holder adoption, underlying asset reliability, and applicable risk-flag penalties.
In API responses, reputation data is returned as the `score` object. The composite Reputation Score is `score.vaultScore`; the active component scores and penalty details explain how the final value is calculated. The deprecated `score.networkScore` field remains available for backwards compatibility and diagnostics, but has zero weight in the composite score.
## What the Reputation Score measures
The Reputation Score favors protocols that are "Lindy" — the longer a protocol has secured large amounts of capital without incident, the higher the vault tends to score. A low Reputation Score does not mean a vault is unsafe; it means the vault has not yet accumulated the track record that the metric rewards.
The Reputation Score complements — but does not replace — detailed risk reviews from auditors and risk managers like LlamaRisk, Chaos Labs, and Gauntlet. Use it for programmatic filtering; use risk reports for deeper due diligence.
## Component scores
Vaults.fyi calculates the Reputation Score from four weighted component scores:
Measures the scale of trust a protocol has earned over its operational history. This component captures how much TVL the protocol has secured and for how long, using logarithmic scaling to prevent a handful of massive protocols from dominating. A protocol with \$500M TVL sustained for two years contributes more positively than one that briefly touched the same TVL for a week.
Accounts for liquidity characteristics at the individual pool level, not just the protocol level. A large protocol can host pools with very different liquidity profiles — for example, Aave v3 USDT on mainnet ($5B TVL) behaves differently from Aave v3 pyUSD on mainnet ($12M TVL). This component uses the same TVL-over-time approach as protocol integrity, applied to the specific pool.
Measures holder distribution and diversity. More unique holders indicate broader trust and reduce concentration risk. Future improvements to this component will include filtering low-value addresses, distinguishing individual holders from protocol-owned positions, and analyzing the ability of large holders to exit and affect liquidity.
Evaluates the stability and creditworthiness of the vault's deposit asset. For stablecoins and pegged assets (ETH/BTC derivatives), this component measures historical price stability relative to the peg, plus/minus 2% liquidity depth in onchain markets, and CEX and DEX trading volume. Assets with a consistent peg and deep liquidity contribute more positively.
The composite score uses the following formula, with a minimum result of zero:
```text theme={null}
vaultScore = max(0,
0.45 * protocolTvlScore
+ 0.25 * vaultTvlScore
+ 0.15 * holderScore
+ 0.15 * assetScore
- totalScorePenalty
)
```
Blockchain security is not a weighted component of the current Reputation Score.
## Flag penalties
Active vault flags — security incidents, protocol risk warnings, and similar indicators — directly reduce the Reputation Score. Higher-severity flags carry larger deductions. Only the single largest active penalty applies; multiple flags do not stack.
When a flag is resolved, the penalty does not necessarily disappear immediately. Vaults.fyi can mark a flag with resolution details and reduce the effective penalty to reflect how much of the issue has been addressed. This lets a vault recover trust incrementally rather than resetting overnight.
The `score.penaltyComponents` field in [detailed-vaults](/api-reference/detailed-vaults) responses shows each active or decaying flag penalty, its severity, current penalty value, expiry, and optional `resolution` note. The `score.totalScorePenalty` field shows the total penalty currently applied to the composite Reputation Score. The same optional `resolution` note is also returned on `flags[]` entries.
## Interpreting the Reputation Score
A higher Reputation Score reflects the combined contribution of protocol and vault history, holder adoption, and underlying asset reliability, after flag penalties. It does not assess the security of the blockchain the vault runs on. A high score does not guarantee safety — it means the vault has passed more of the tests that time imposes.
The Reputation Score does not incorporate smart contract audit results, governance risk, or nuanced risk assessments of protocol architecture. Do not use it as a substitute for security research.
## Using the Reputation Score to filter vaults
You can filter the detailed-vaults API response to only return vaults above a minimum Reputation Score threshold using the `minVaultScore` query parameter:
```
GET /v2/detailed-vaults?minVaultScore=60
```
This is useful when building integrations where you want to surface only established vaults to end users, without needing to maintain your own allowlist.
Set `minVaultScore` to match your product's risk tolerance. Consumer wallets typically want higher thresholds (70+). Yield aggregators serving sophisticated users may set lower thresholds to capture emerging opportunities.
The Reputation Score is also visible in the Vaults.fyi app at [app.vaults.fyi](https://app.vaults.fyi/) and returned by the [detailed vaults endpoint](/api-reference/detailed-vaults) as `score.vaultScore`.
## Known limitations
The Reputation Score is objective and formula-driven, which means it has edges. A genuinely risky protocol with a long history can score well. A well-audited new protocol will score low until it builds a track record. Keep these limitations in mind when making risk decisions.
* The Reputation Score does not account for governance risk, upgrade mechanisms, or admin key exposure.
* Blockchain security does not contribute to the current score. Assess network risk separately.
* Smart contract audit status is not currently a direct input to the Reputation Score.
* Flag penalties reflect known incidents surfaced by vaults.fyi — they do not capture all possible risk vectors.
For a deeper explanation of the methodology and the thinking behind the Lindy-based approach, read the [Vaults.fyi reputation score blog post](https://blog.vaults.fyi/beyond-apy-the-vaultsfyi-reputation/).
# API Credits & Compute Units Explained
Source: https://docs.vaults.fyi/plans/credits
Learn how vaults.fyi Credits (Compute Units) work, and see the full table of base costs and per-datapoint costs for v2 and Beta endpoints.
Every vaults.fyi API request consumes Credits. Credits — also called Compute Units (CUs) — measure the compute resources consumed by each request. Subscription plans include a monthly Credit budget, while pay as you go charges a flat **\$0.002 per credit**. This model lets you pay proportionally for what you actually use, rather than treating a simple lookup the same as a rich multi-vault data pull.
## How Credits Work
Each API call consumes Credits in two parts:
* **Base CU per call** — a fixed cost charged for every request to that endpoint, regardless of how many results are returned.
* **CU per datapoint returned** — an additional cost multiplied by the number of records in the response.
**Example:** `/v2/detailed-vaults` has a base cost of 1 CU plus 3 CU per vault returned. If your query returns 50 vaults, the total cost is 1 + (50 × 3) = **151 CUs**.
By contrast, `/v2/detailed-vaults/{network}/{vaultAddress}/apy` costs only 1 CU total because it returns a single APY value for a single vault.
To minimize credit consumption, use targeted single-vault endpoints when you only need data for a specific address, and use the list endpoints when you need to compare across many vaults.
## v2 Endpoint Credit Costs
### General
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/assets` | 1 | — |
| `GET /v2/curators` | 1 | — |
| `GET /v2/networks` | 1 | — |
| `GET /v2/protocols` | 1 | — |
| `GET /v2/tags` | 1 | — |
| `GET /v2/vaults` | 1 | — |
### Detailed Vaults
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/detailed-vaults/{network}/{vaultId}/apy` | 1 | — |
| `GET /v2/detailed-vaults/{network}/{vaultId}/tvl` | 1 | — |
| `GET /v2/detailed-vaults` | 1 | 3 |
| `GET /v2/detailed-vaults/{network}/{vaultId}` | 3 | — |
### Benchmarks
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/benchmarks/{network}` | 3 | — |
| `GET /v2/historical-benchmarks/{network}` | 3 | 3 |
### Historical
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/historical/{network}/{vaultId}/apy` | 1 | 1 |
| `GET /v2/historical/{network}/{vaultId}/sharePrice` | 1 | 1 |
| `GET /v2/historical/{network}/{vaultId}/tvl` | 1 | 1 |
| `GET /v2/historical/asset-prices/{network}/{assetAddress}` | 1 | 1 |
| `GET /v2/historical/{network}/{vaultId}` | 3 | 3 |
### Portfolio
All plans can access portfolio endpoints.
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/portfolio/positions/{userAddress}/{network}/{vaultId}` | 1 | — |
| `GET /v2/portfolio/total-returns/{userAddress}/{network}/{vaultId}` | 1 | — |
| `GET /v2/portfolio/best-deposit-options/{userAddress}` | 1 | 2 |
| `GET /v2/portfolio/best-vault/{userAddress}` | 2 | — |
| `GET /v2/portfolio/events/{userAddress}/{network}/{vaultId}` | 3 | — |
| `GET /v2/portfolio/idle-assets/{userAddress}` | 5 | — |
| `GET /v2/portfolio/positions/{userAddress}` | 5 | — |
### Transactions
All plans can access transaction endpoints.
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /v2/transactions/suffix/{userAddress}/{vaultId}` | 1 | — |
| `GET /v2/transactions/context/{userAddress}/{network}/{vaultId}` | 3 | — |
| `GET /v2/transactions/rewards/context/{userAddress}` | 3 | — |
| `GET /v2/transactions/{action}/{userAddress}/{network}/{vaultId}` | 5 | — |
| `GET /v2/transactions/rewards/claim/{userAddress}` | 5 | — |
## Beta Endpoint Credit Costs
Beta endpoints use the same base-cost and per-datapoint model as v2 endpoints.
| Endpoint | Base CU per call | CU per datapoint |
| - | -: | -: |
| `GET /beta/amm/deep/positions/{userAddress}/{network}/{vaultId}` | 1 | — |
| `GET /beta/borrow/markets/nrt` | 1 | — |
| `GET /beta/borrow/portfolio/position` | 1 | — |
| `GET /beta/borrow/portfolio/positions/asset` | 1 | — |
| `GET /beta/svm/portfolio/events-vault` | 1 | — |
| `GET /beta/svm/portfolio/idle-asset` | 1 | — |
| `GET /beta/svm/vaults` | 1 | — |
| `POST /beta/advanced-analytics` | 1 | Varies by selected fields |
| `POST /beta/advanced-analytics/{network}/{vaultId}` | 1 | Varies by selected fields |
| `GET /beta/amm/deep/detailed-vaults` | 1 | 3 |
| `GET /beta/svm/detailed-vaults` | 1 | 3 |
| `GET /beta/borrow/markets` | 1 | 5 |
| `GET /beta/portfolio/partial-returns/{userAddress}/{network}/{vaultId}` | 2 | — |
| `GET /beta/borrow/markets/transactions/context` | 3 | — |
| `GET /beta/borrow/portfolio/events` | 3 | — |
| `GET /beta/fixed-term/context/{userAddress}/{network}/{vaultId}` | 3 | — |
| `GET /beta/fixed-term/detailed/{network}/{vaultId}` | 3 | — |
| `GET /beta/svm/detailed-vault` | 3 | — |
| `GET /beta/svm/portfolio/events` | 3 | — |
| `GET /beta/svm/transactions/context` | 3 | — |
| `GET /beta/borrow/markets/historical` | 3 | 3 |
| `GET /beta/amm/deep/deposit/{userAddress}/{network}/{vaultId}` | 5 | — |
| `GET /beta/amm/deep/withdraw/{userAddress}/{network}/{vaultId}` | 5 | — |
| `GET /beta/borrow/markets/transactions/action` | 5 | — |
| `GET /beta/fixed-term/transactions/{action}/{userAddress}/{network}/{vaultId}` | 5 | — |
| `GET /beta/svm/portfolio/idle-assets` | 5 | — |
| `GET /beta/svm/portfolio/positions` | 5 | — |
| `GET /beta/svm/transactions` | 5 | — |
| `GET /beta/borrow/portfolio/positions` | 6 | — |
### Advanced analytics
Both `POST /beta/advanced-analytics` and `POST /beta/advanced-analytics/{network}/{vaultId}` cost 1 base credit per request. Add the following costs for each returned item:
| Selected field | Credits per returned item |
| - | -: |
| `maxDrawdown` | 2 |
| `detailedVault` | 3 |
| `withdrawalPauseRatio` | 2 |
| `composition` | 3 |
| `utilizationRate` | 3 |
The field costs are cumulative. Calculate the total request cost as `1 + number of returned items × sum of selected field costs`.
For example, a request that returns 10 items with `maxDrawdown` and `composition` costs `1 + (10 × (2 + 3)) = 51` credits.
## Legacy v1 API Credits
The v1 API uses a simpler flat-credit model — each endpoint has a single fixed cost with no per-datapoint multiplier, except for a few endpoints that scale with the number of results requested.
The v1 (legacy) API endpoints remain fully supported and maintained. You can access the full v1 documentation in the [Legacy v1 Endpoints](/api/legacy/overview) reference.
| Endpoint | Credit Cost |
| - | - |
| `GET /v1/networks` | 1 credit |
| `GET /v1/tags` | 1 credit |
| `GET /v1/tokens` | 1 credit |
| `GET /v1/transactions/assets` | 1 credit |
| `GET /v1/transactions/vaults` | 1 credit |
| `GET /v1/vaults` | 1 credit |
| `GET /v1/vaults/{network}/{vaultAddress}/apy` | 1 credit |
| `POST /v1/portfolio/best-deposit-options/{userAddress}` | 1 credit base + 2 credits per vault |
| `GET /v1/detailed/vaults` | 1 credit base + 4 credits per vault |
| `POST /v1/portfolio/best-vault/{userAddress}` | 2 credits |
| `GET /v1/top-vault/{network}/{userAddress}` | 2 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/historical-apy/{timestamp}` | 2 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/historical-tvl/{timestamp}` | 2 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/historical-apy` | 2 credits base + 1 credit per datapoint |
| `GET /v1/benchmarks` | 3 credits |
| `GET /v1/transactions/vaults/actions/details` | 3 credits |
| `GET /v1/vaults/{network}/{vaultAddress}` | 3 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/holder-events/{holder}` | 3 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/holder-total-returns/{holder}` | 3 credits |
| `GET /v1/vaults/{network}/{vaultAddress}/historical-data` | 4 credits base + 2 credits per historical point |
| `GET /v1/portfolio/positions/{userAddress}` | 5 credits |
| `GET /v1/portfolio/wallet-balances` | 5 credits |
| `GET /v1/transactions/vaults/claim-redeem` | 5 credits |
| `GET /v1/transactions/vaults/claim-rewards` | 5 credits |
| `GET /v1/transactions/vaults/deposit` | 5 credits |
| `GET /v1/transactions/vaults/redeem` | 5 credits |
| `GET /v1/transactions/vaults/request-redeem` | 5 credits |
# Vaults.fyi API Plans & Pricing Overview
Source: https://docs.vaults.fyi/plans/overview
Compare pay-as-you-go, Analyst, Growth, Builder, and Enterprise API plans — pricing, credit allowances, rate limits, and support to find the right fit.
The vaults.fyi API offers usage-based and subscription plans designed to match different usage levels, from individual analysts to enterprise-scale applications. Every API key can access all endpoints; plans differ by pricing model, included credits, rate limits, and support. Usage is measured in [Credits (Compute Units)](/plans/credits) that reflect the actual compute cost of each request.
## Plan Comparison
| Feature | Pay as you go | Analyst | Growth | Builder | Enterprise |
| - | - | - | - | - | - |
| **Price** | \$0.002 / credit | \$399 / mo | \$599 / mo | \$999 / mo | Custom |
| **Included credits** | None — pay for usage | 250k / mo | 500k / mo | 1M / mo | Custom |
| **Endpoint access** | All endpoints | All endpoints | All endpoints | All endpoints | All endpoints |
| **Rate limits** | Standard | 10 req/s | 20 req/s | 50 req/s | Custom |
## Plan Details
**\$0.002 / credit**
Best for testing, variable workloads, and teams that want access to the full API without committing to a monthly credit package.
* No monthly credit commitment
* Flat \$0.002 per credit
* Access to all endpoints
* Standard rate limits
* Upgrade to a subscription plan when usage becomes predictable
**\$399 / month**
Best for researchers and data teams that need comprehensive data across protocols and chains.
* 250,000 credits / month
* 10 requests per second
* Access to all endpoints
* Priority support, \<24 hr SLAs
* Standard product roadmap requests
**\$599 / month**
Best for product teams launching yield features that need higher included usage and more throughput.
* 500,000 credits / month
* 20 requests per second
* Access to all endpoints
* Priority support, \<24 hr SLAs
* Prioritized integrations for requested protocols
**\$999 / month**
Best for scaling applications with high throughput requirements and deep protocol coverage.
* 1,000,000 credits / month
* 50 requests per second
* Access to all endpoints
* Priority support, \<24 hr SLAs
* Prioritized integrations for requested protocols and chains
* Prioritized API features
**Custom pricing**
Best for institutional teams and platforms that need dedicated support, custom SLAs, and bespoke features.
* Custom credit volume
* Custom rate limits
* Access to all endpoints
* Dedicated support, \<24 hr SLAs, on-call for critical issues
* Prioritized integrations, API features, and custom feature development
* [Submit interest](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) to discuss
## Subscribe or Upgrade
To start on pay as you go, subscribe to a paid plan, or upgrade your existing plan, [sign up at the vaults.fyi portal](https://portal.vaults.fyi/signup). For Enterprise inquiries, [submit interest](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) and the team will follow up.
**Using AI agents or building agentic workflows?** Pay as you go gives you usage-based API-key access. The vaults.fyi API also supports keyless pay-per-request access via [x402](/ai-agents/x402), a micropayment protocol for autonomous systems that prefer to pay from an onchain wallet instead of managing an API key.
## Understanding Credits
API usage is measured in Credits (Compute Units), which reflect the resources required to fulfill each type of request. Lightweight endpoints like `/v2/assets` cost 1 CU per call, while data-heavy endpoints return multiple datapoints and cost more per response. On pay as you go, each credit costs \$0.002.
See the full breakdown of endpoint credit costs on the [Credits](/plans/credits) page.
# Brand Kit
Source: https://docs.vaults.fyi/resources/brand
Logos, colors, and typography for vaults.fyi. For press coverage, integration listings, and co-marketing.
## Logos
### Logo lockup
The logo lockup pairs the symbol with the "vaults.fyi" wordmark. Three color variants are available depending on background.
### Logo usage
Never crop, distort, recolor, rotate, or add effects to the logo. Do not change the relative proportions of the symbol and logotype.
| Do | Don't |
| - | - |
| Use the gradient symbol on light or dark backgrounds | Place the color logo on busy or patterned backgrounds |
| Use the white logo on brand blue surfaces | Recolor the symbol to a non-brand color |
| Use black or white versions for single-color print contexts | Stretch, skew, or rotate the logo |
| Keep clear space around the logo | Use the symbol alone where the full lockup fits |
***
## Colors
### Primary
### Accent palettes
Extended palettes for multi-series charts and data visualizations. Each palette has stops at 50, 400, 500, 600, and 950.
| Palette | 50 | 400 | 500 | 600 | 950 |
| - | - | - | - | - | - |
| teal | `#F0FDFA` | `#2DD4BF` | `#14B8A6` | `#0D9488` | `#042F2E` |
| violet | `#F5F3FF` | `#A78BFA` | `#8B5CF6` | `#7C3AED` | `#2E1065` |
| fuchsia | `#FDF4FF` | `#E879F9` | `#D946EF` | `#C026D3` | `#4A044E` |
| pink | `#FDF2F8` | `#F472B6` | `#EC4899` | `#DB2777` | `#500724` |
| orange | `#FFF7ED` | `#FF8905` | `#FF6900` | `#F54900` | `#441306` |
| emerald | `#ECFDF5` | `#00D492` | `#00BC7D` | `#009966` | `#002C21` |
| cyan | `#ECFEFF` | `#00D3F2` | `#00B8DB` | `#0092B8` | `#073345` |
| rose | `#FEF1F2` | `#FF637E` | `#FF1F57` | `#EC0040` | `#4D0218` |
| blue | `#EFF9FF` | `#50A2FF` | `#2C7FFF` | `#145DFB` | `#162455` |
| yellow | `#FEFCE8` | `#FEC700` | `#F0B000` | `#D18700` | `#431F05` |
***
## Name and usage
The brand name is **vaults.fyi** — always lowercase, always with the dot. Lowercase is intentional, not a typo.
| Context | Form |
| - | - |
| Prose, social, UI copy | `vaults.fyi` |
| Document titles, app store listings, co-marketing tables | `Vaults.fyi` |
| URLs | `vaults.fyi`, `app.vaults.fyi` |
The dot is part of the name. Never write `vaultsfyi`, `VaultsFYI`, `vaults.FYI`, or `VAULTS.FYI`.
**Sentence starts.** Restructure to avoid opening with the name — `"vaults.fyi launched..."` reads as a typo to most people. Lead with context instead: `"Today we launched..."` or `"The new vaults.fyi feature..."`.
**Products.** `app.vaults.fyi` and the vaults.fyi API are distinct products under the vaults.fyi brand. Use the full product name when referring to a specific one, not just "vaults.fyi."
***
## Typography
| Font | Use |
| - | - |
| **Geist** | Body text, headings, UI labels |
| **Geist Mono** | Table headers, code, numeric data |
Both fonts are available from [Vercel's Geist font page](https://vercel.com/font).
***
## Press and media
For press inquiries or co-marketing requests, reach out at [gm@wallfacer.io](mailto:gm@wallfacer.io) or via [@vaultsfyi](https://twitter.com/vaultsfyi) on X.
# Customer Case Studies
Source: https://docs.vaults.fyi/resources/case-studies
How Arbitrum, Jumper Earn, Kraken Wallet, Gauntlet, KPK, Otus, and Maple Finance use the vaults.fyi API for yield discovery, analytics, benchmarking, transactions, and agent-managed yield.
Leading teams across ecosystem portals, wallets, trading platforms, research firms, and block explorers use the vaults.fyi API to power yield discovery, personalized insights, independent data validation, and onchain transactions.
Native yield discovery inside the Arbitrum Portal, powered by standardized market data, transaction payloads, position tracking, and attribution.
Unified cross-chain yield discovery and execution powered by vaults.fyi market data, transaction payloads, position tracking, and attribution.
Personalized DeFi yield suggestions surfaced inside the wallet UI, with multi-chain coverage across Ethereum, Base, Optimism, Arbitrum, and Polygon.
Normalized yield data integrated into quantitative research models for DeFi risk analysis — safeguarding over \$42B in digital assets.
Unified vault data, transaction flows, and position tracking supporting KPK’s DAO treasury mandates and the infrastructure behind the KPK app.
Agent-managed Smart Yield account powered by vaults.fyi discovery, Reputation Scores, transaction payloads, portfolio tracking, and attribution.
Real-time benchmark comparisons and independent third-party APY validation for syrupUSDC, building investor trust through transparent performance data.
Ready to build? [Sign up](https://portal.vaults.fyi/signup) to get an API key and start integrating.
# Arbitrum: Native Yield Discovery in the Arbitrum Portal
Source: https://docs.vaults.fyi/resources/case-studies/arbitrum
How Arbitrum Earn uses the vaults.fyi API to surface standardized DeFi opportunities, transaction payloads, position tracking, and attribution inside the Arbitrum Portal.
[Arbitrum](https://arbitrum.io/) has one of DeFi's richest and most diverse ecosystems. The opportunity was making that ecosystem easier to access from one native surface.
Arbitrum Earn brings yield discovery into the Arbitrum Portal, giving users a cleaner way to compare opportunities, understand key metrics, and move from discovery to execution without leaving the ecosystem experience.
## The Challenge: Making DeFi Easier to Navigate
Yield opportunities on Arbitrum span many protocols, assets, and strategy types. For users, that creates discovery friction: each protocol has its own interface, terminology, data model, and execution flow.
Arbitrum Earn addresses that by presenting opportunities in a consistent format. Users can compare APY, TVL, asset, and protocol details side by side, then move from discovery to execution on a single Arbitrum-native surface.
Protocol selection for Earn uses vaults.fyi's Reputation Scores as one input. Users see a curated set of opportunities in the interface, while Reputation Scores stay in the background rather than appearing as a user-facing ranking.
## The Solution: One API for Standardized Yield Infrastructure
Arbitrum Earn runs on the vaults.fyi API. Rather than build and maintain a separate integration for every protocol, the Portal uses one API layer for standardized yield data, transaction payloads, and position tracking across the ecosystem.
The integration also preserves self-custody. Transactions route directly to the underlying protocol, with no vaults.fyi proxy contract, no intermediary contract holding funds, and no additional wrappers on top. The position a user opens through Arbitrum Earn is the same underlying protocol position they would receive by going to the protocol directly.
## Better Discovery and Attribution for the Ecosystem
Arbitrum Earn helps protocols reach users who already hold assets on Arbitrum. Being included in an ecosystem-level earn surface means users can find a protocol's opportunities in context, next to other relevant options, without needing to know every protocol interface in advance.
For the Arbitrum ecosystem, Earn creates a shared layer for yield discovery and execution that can expand as new protocols, assets, and opportunities come online.
It also creates the foundation for measurable distribution. vaults.fyi attribution can show which surfaces, campaigns, and integrators drive deposits into protocols. That helps ecosystems understand what is working, helps protocols reward distribution partners, and gives integrators a clear record of the TVL they create.
## API Capabilities Used
* **Market data:** Standardized APY, TVL, asset, protocol, and vault metadata for yield discovery and comparison.
* **Transaction support:** Ready-to-sign payloads that let users deposit into supported opportunities directly from the Portal experience.
* **Position tracking:** Portfolio visibility across supported vault positions without protocol-specific indexing work.
* **Attribution and TVL tracking:** Measurement of deposits driven by ecosystem surfaces, campaigns, and integrators.
## What's Next
Bringing Earn to the Portal is the first step in a longer collaboration between Arbitrum and vaults.fyi. The teams are working alongside Offchain Labs and the broader Arbitrum ecosystem to keep making DeFi yield more accessible to users across the network.
The first user benefit is simple access to yield. Over time, the same infrastructure can support better incentive programs, smarter ecosystem growth, and more ways for users to discover productive opportunities on Arbitrum.
***
Want to add native yield discovery and execution to your ecosystem portal? [Get API access](https://portal.vaults.fyi/signup) to explore the market data, transaction, position tracking, and attribution APIs powering Arbitrum Earn.
# Gauntlet: Normalized Onchain Yield Data for DeFi Risk Research
Source: https://docs.vaults.fyi/resources/case-studies/gauntlet
How Gauntlet uses the vaults.fyi API to access normalized yield data across protocols for quantitative DeFi research and risk modeling.
[Gauntlet](https://www.gauntlet.xyz/) is a leader in data-driven onchain yield strategy. The team provides applied research and risk management services to clients including Coinbase, Morpho, Uniswap, Arbitrum, and NEAR, with models safeguarding over **\$42 billion** in digital assets across the crypto ecosystem.
To enhance internal research and protocol modeling, Gauntlet integrated the vaults.fyi API as a data source. This provides their team with normalized, up-to-date yield data across dozens of protocols and networks, without the overhead of maintaining bespoke indexers or reconciling disparate sources.
## The Challenge: Fragmented, High-Maintenance Yield Data
Gauntlet's models depend on high-quality onchain data, but aggregating yield data at scale presents compounding challenges:
* **Data fragmentation:** Yield mechanisms differ widely across protocols, making standardized comparisons difficult without normalization for metrics such as supply/borrow APYs, staking rewards, and real-world asset returns.
* **Maintenance burden:** In-house indexers require constant updates as protocols evolve, consuming engineering resources that could go toward modeling.
* **Cross-chain complexity:** Coverage across multiple L1s and L2s multiplies the surface area to monitor, and errors at the data layer propagate into research outputs.
For a firm where data quality directly affects the integrity of risk models, these aren't just operational problems. They're risks.
## The Solution: A Single API for Normalized Yield Data
By integrating vaults.fyi, Gauntlet can:
* Access normalized APY data across protocols and blockchain networks through a single interface.
* Pull historical yield trends to analyze volatility, time-based behavior, and protocol-specific risk.
* Incorporate live and historical vault data into quantitative models without building custom pipelines per protocol.
* Eliminate maintenance overhead as protocols update, upgrade, or launch new products.
This lets Gauntlet focus on what it does best — building simulations and strategies — while relying on vaults.fyi for the underlying yield data infrastructure.
## Outcome
vaults.fyi serves as a data partner supporting Gauntlet's research across DeFi. As Gauntlet pushes the frontier of onchain economic modeling, normalized yield data from vaults.fyi feeds directly into the risk models that protect billions in digital assets.
***
Integrating DeFi yield data into your research stack? [Get API access](https://portal.vaults.fyi/signup) to explore the historical and market data endpoints Gauntlet uses.
# Jumper Earn: Cross-Chain Yield Discovery Powered by vaults.fyi
Source: https://docs.vaults.fyi/resources/case-studies/jumper-earn
How Jumper Earn uses the vaults.fyi API to unify yield discovery, transaction execution, position tracking, and attribution across DeFi chains and protocols.
[Jumper Earn](https://jumper.exchange/earn/) is a personalized yield discovery and execution engine that moves users from idle assets to earning positions through a single, intent-based workflow. By integrating the vaults.fyi API, Jumper accesses standardized yield data, ready-to-sign transaction payloads, position tracking, and attribution infrastructure — without maintaining protocol-specific integrations.
## The Problem: Fragmented Cross-Chain Yields
Despite DeFi's growth, yield opportunities remain scattered across chains and protocols. Users face compounding sources of friction:
* **Discovery fragmentation:** Yields are spread across dozens of networks and protocols, each with different interfaces and standards.
* **Asset mismatch:** Users rarely hold the exact token a vault requires, making swaps or bridges a prerequisite.
* **Execution complexity:** Moving from an asset on Chain A to a vault on Chain B can require five or more manual steps: approve → swap → bridge → swap → deposit.
* **Data staleness:** Inaccurate or delayed yield data leads to failed or suboptimal transactions.
These frictions reduce the conversion from yield discovery to actual deposits and create substantial integration overhead for any application trying to unify the experience.
## How Jumper Uses the vaults.fyi API
### Market and Vault Data
Jumper uses vaults.fyi as its data layer for vault metadata and strategy descriptions, real-time and historical APY and TVL, and yield and incentive breakdowns. This standardized coverage enables consistent comparisons across protocols and removes the need for custom data pipelines per integration.
### Transaction Payloads
For supported vaults, vaults.fyi provides ready-to-sign calldata for token approvals, deposits, and withdrawals — including multi-step flows where users enter a redemption queue. These payloads feed directly into Jumper's routing engine. For cross-chain or multi-step flows, Jumper orchestrates via LI.FI Composer, bundling actions into a single user-facing confirmation.
### Position Tracking
vaults.fyi position endpoints power Jumper's portfolio visibility: detecting existing vault positions, tracking deposited balances, and supporting cross-chain views — without requiring direct integration with each protocol's indexing logic.
### Attribution and TVL Tracking
vaults.fyi provides infrastructure for measuring distribution and adoption. Jumper uses it to track inflows originating from Jumper Earn, monitor net TVL associated with its integration, and attribute deposits to specific vault providers. This creates a shared, onchain-based source of truth for both integrators and vault curators — eliminating the need for manually reported analytics.
## Example User Flow
1. **Wallet connection:** Jumper detects existing assets and vault positions.
2. **Yield discovery:** Relevant vaults are surfaced based on the user's holdings.
3. **Execution:** The user selects a vault and confirms. Swaps, bridges, and deposits are orchestrated using vaults.fyi payloads where applicable.
4. **Post-execution tracking:** Positions are tracked via vaults.fyi and other sources.
## Results
* **Reduced integration overhead** — a single API replaced many custom protocol integrations.
* **Improved conversion** — streamlined discovery-to-deposit flows reduced time-to-yield for users.
* **Measurable distribution** — attribution and TVL tracking gave both Jumper and vault providers a neutral source of truth.
* **Consistent yield data** — standardized APY and TVL improved comparability and user decision-making.
***
Jumper Earn shows how integrators can deliver end-to-end yield experiences by combining vaults.fyi for data, transaction support, and attribution with Jumper and LI.FI for routing and cross-chain execution. [Get API access](https://portal.vaults.fyi/signup) to build a similar integration.
# KPK: From Treasury Data to Full-Stack Yield Infrastructure
Source: https://docs.vaults.fyi/resources/case-studies/kpk
How KPK's relationship with vaults.fyi expanded from normalized yield data into non-custodial DAO treasury workflows, vault integrations, position tracking, and the APIs supporting app.kpk.io.
[KPK](https://kpk.io/) works with vaults.fyi across several workflows: market data, monitoring, position tracking, and vault integrations. The relationship started with a focused data need and expanded into one of the integration layers KPK uses to support its curated vault products.
**Who Is KPK**
KPK is a non-custodial onchain asset manager. Founded in 2021 as karpatkey, KPK manages capital for DAOs and institutions through treasury mandates, funds, and vaults.
In 2025, KPK expanded beyond DAO treasury management into curated vaults for DeFi protocols and retail participants.
**The Starting Point**
KPK first came to vaults.fyi for its analytics. Their team needed normalized yield, TVL, vault metadata, and historical APY data across protocols and chains.
That data supported internal allocation work for KPK's treasury and vault teams. Building and maintaining those integrations in-house would have pulled engineering time away from strategy design, risk management, and customer-facing product work. Vaults.fyi handled the data layer so KPK could focus on the work their clients and depositors rely on them to do.
**How The Relationship Expanded**
**1. Deeper Vault Coverage**\
As KPK expanded its vault products, vaults.fyi expanded coverage around the protocols and products that mattered most to them. That includes the vaults KPK wanted to monitor internally, the products they wanted to expose to depositors, and the APIs, SDKs, and tools they needed to make those products accessible to integrators.
The same coverage supports discovery, reporting, and integration. KPK can track their own products in the same normalized system that third-party platforms can use to discover and route into those vaults.
**2. Data and Monitoring for DAO Treasury Workflows**
KPK uses vaults.fyi to support DAO treasury workflows that depend on accurate, normalised data. The treasury team pulls address holdings, position data, and historical metrics through the API to monitor exposures and run internal calculations. When execution is needed, KPK signs from its own wallet and executes against the underlying protocol, fully non-custodial throughout.
That matters for teams operating DAO treasuries across multiple vault protocols. They need reliable data, consistent vault metadata, and a workflow that does not require rebuilding every protocol integration from scratch.
**3. Portfolio And Position Tracking**
KPK also uses vaults.fyi position data to support portfolio visibility. The API can return balances, accrued yield, and historical performance across supported vault positions.
For KPK, that data can supplement customer reporting and internal monitoring. For integrators, the same infrastructure makes vault positions easier to show inside wallets, dashboards, and custom applications.
**4. Infrastructure For KPK's Own App**
KPK's vault portal at [app.kpk.io](https://app.kpk.io/) uses vaults.fyi APIs as its underlying yield infrastructure. Vault metadata, market data, transaction payloads, and position tracking all come from the same API surface.
That lets KPK own the user experience and curation layer while vaults.fyi handles the integration layer underneath. KPK focuses on strategy design, curation, and the depositor experience. Vaults.fyi provides one of the integration layers that helps make those vaults accessible across surfaces.
**Why It Matters**
KPK shows one expansion path for serious vault teams. Data is the entry point. Once a team works with the data layer, the same infrastructure can support monitoring, attribution, and custom distribution.
That expansion compounds because each layer uses the same underlying integrations, which reduces duplication across data, monitoring, and distribution workflows.
*"vaults.fyi has been a useful data partner from the start. Their coverage across protocols meant we could move quickly on [app.kpk.io](https://app.kpk.io/) and on internal monitoring without rebuilding every integration ourselves."* — João Bandeira, Product Engineering Lead, KPK
**What's Next**
KPK and vaults.fyi continue to expand the relationship as KPK launches new vault structures and distribution paths. The next stage is deeper integrator support, better fee accounting feedback loops, and clearer reporting around the TVL that each channel drives.
The relationship started with a single data feed. It now points toward a broader infrastructure partnership for curated vault products.
# Kraken Wallet: Personalized DeFi Yield Inside a Self-Custody Wallet
Source: https://docs.vaults.fyi/resources/case-studies/kraken-wallet
How Kraken Wallet uses the vaults.fyi API to surface personalized DeFi earning opportunities inside its native wallet UI across Ethereum, Base, Optimism, Arbitrum, and Polygon.
[Kraken Wallet](https://www.kraken.com/wallet) is a self-custody wallet built to connect users to the decentralized web safely and securely. Through the vaults.fyi API, Kraken powers analytics, personalized yield suggestions, and portfolio tracking across multiple protocols and networks — all within the native wallet interface.
This integration is a core part of Kraken's strategy to establish itself as a leading wallet for DeFi, treating Earn as a first-class product experience rather than an afterthought.
## How It Works
**Token-level yield suggestions.** When users view their balances and select a specific asset, the vaults.fyi API surfaces relevant Earn opportunities for that token, meeting users at the moment of intent.
**Explore tab.** Powered by vaults.fyi market data, the Explore tab lets users browse DeFi opportunities across major protocols without leaving the wallet.
**Multi-chain coverage.** The integration spans Ethereum Mainnet, Base, Optimism, Arbitrum, and Polygon, giving users a cross-chain view of yield opportunities from a single interface.
**Curated protocol selection.** Users can access yields from dozens of leading protocols and filter by their preferences.
## API Capabilities Used
The integration relies on core vaults.fyi API categories:
* **Market data:** APY, TVL, and vault metadata (icons, descriptions, etc.) across protocols and networks.
* **Portfolio tracking:** Accurate position values, transaction events, and returns accrued on each yield-bearing position.
## Why Kraken Built This with vaults.fyi
Building DeFi yield analytics in-house would require maintaining protocol-specific indexers, normalizing yield calculations across incompatible schemas, and tracking coverage across five networks continuously. By integrating vaults.fyi, Kraken reduced that to a single API, enabling the team to focus on product experience rather than data infrastructure.
**For users, this means:**
* Personalized earning suggestions based on actual holdings.
* Yield discovery without leaving the wallet.
* Multi-chain opportunities in one place.
* Real-time data from verified onchain sources.
***
Ready to add DeFi yield discovery to your wallet or app? [Get API access](https://portal.vaults.fyi/signup) to explore the market data and portfolio endpoints Kraken uses.
# Maple Finance: Independent APY Benchmarking for Institutional DeFi
Source: https://docs.vaults.fyi/resources/case-studies/maple-finance
How Maple Finance uses the vaults.fyi API to benchmark syrupUSDC yields against the DeFi market and provide independently verified APY data — building investor trust through third-party transparency.
[Maple Finance](https://maple.finance/) is a leading onchain asset manager offering institutional products across secured lending, structured products, and institutional staking. Maple blends DeFi efficiency with the underwriting standards and custody solutions expected by sophisticated capital allocators.
To benchmark syrupUSDC's performance and display competitive yields transparently, Maple integrated the vaults.fyi API as both a market intelligence tool and an independent, third-party data source.
## The Challenge: Benchmarking Yield and Building Investor Trust
For institutional asset managers, context matters. Investors want to know how yields compare to other available opportunities — and they need confidence that the numbers aren't self-reported.
Maple faced two specific challenges:
* **Competitive benchmarking:** Accessing real-time stablecoin yields across DeFi to measure syrupUSDC's performance against the market.
* **Independent validation:** Displaying externally sourced APY data to reduce reliance on self-reported metrics and build investor trust.
Without a standardized, comprehensive DeFi yield dataset, solving both would have required significant development and ongoing data sourcing effort.
## The Solution: Third-Party Yield Data from vaults.fyi
By integrating vaults.fyi, Maple Finance now has:
* **Real-time benchmarks** — live comparison of syrupUSDC against leading stablecoin vaults across DeFi.
* **Independent APY validation** — third-party metrics that transparently display syrupUSDC's performance without relying on internal figures.
* **Historical yield tracking** — time-series data to analyze syrupUSDC's competitiveness over time.
The integration was completed in days, enabling Maple to streamline performance monitoring and confidently surface independent data to investors. Maple published yield comparisons using vaults.fyi onchain data in their [Maple Yield Performance 2024](https://maple.finance/insights/maple-yield-performance-2024) report.
## Why Independent Validation Matters
Using a third-party data source signals to investors that Maple isn't grading its own homework. As vaults.fyi aggregates yield data directly from onchain sources using a consistent methodology, the numbers displayed on Maple's platform carry independent credibility — the same standard institutional investors expect in traditional finance.
This approach aligns Maple with an emerging practice in DeFi: leveraging neutral, onchain-based data providers to validate performance rather than relying solely on protocol-reported figures.
**Key outcomes:**
* Instant market context for benchmarking syrupUSDC against competing vaults.
* Third-party APY data that builds user and investor trust.
* No custom data infrastructure to build or maintain.
* Integration completed in days rather than weeks.
***
Looking to benchmark your protocol's yield against the DeFi market? [Get API access](https://portal.vaults.fyi/signup) to explore the benchmarks and market data endpoints Maple uses.
# Otus: Smart Yield Account Powered by vaults.fyi
Source: https://docs.vaults.fyi/resources/case-studies/otus
How Otus uses the vaults.fyi API to power Smart Yield, an agent-managed stablecoin account backed by DeFi yield infrastructure.
[Otus](https://www.otus.io/) is building a consumer finance app around one account that can access DeFi yield. Users deposit stablecoins, and Otus manages allocation and rebalancing across an approved set of yield sources.
Otus uses vaults.fyi as the yield infrastructure behind that experience. The Otus team can focus on agent logic, embedded wallets, and consumer UX while vaults.fyi handles vault discovery, risk signals, transaction payloads, position tracking, and attribution across supported DeFi protocols.
## How it works
Smart Yield combines embedded wallets, agent decisioning, and vaults.fyi transaction infrastructure.
**Example User Flow**
1. A user opens a Smart Yield account and deposits stablecoins.
2. The Otus agent evaluates a whitelisted set of yield sources.
3. vaults.fyi provides vault metadata, market data, and Reputation Scores to help narrow the approved universe.
4. vaults.fyi returns ready-to-sign transaction payloads for deposits, rebalances, and withdrawals.
5. Otus signs and submits transactions through its Privy-powered wallet experience.
6. vaults.fyi portfolio endpoints track where funds sit and what each user has earned.
The result is a single user-facing balance backed by multiple DeFi vaults, with the custody and signing experience kept separate from the yield infrastructure.
## API capabilities used
The Otus integration uses several vaults.fyi API categories:
* **Vault discovery:** Live and historical APY, TVL, protocol, asset, fee, and metadata across supported EVM vaults.
* **Reputation Scores:** Protocol, network, and vault-level signals used to narrow the agent's approved universe.
* **Transaction payloads:** Ready-to-sign deposit, redeem, and claim transactions that Otus routes through its wallet stack.
* **Portfolio tracking:** Unified position and return data across the underlying protocols a user may be allocated to.
* **TVL attribution:** Reporting on deposits routed through Otus, with vault-level and address-level detail for reconciliation.
* **Referral and rebate support:** Attribution data that can support referral and rebate programs where available.
## Risk scoring and curation
Otus does not expose the full DeFi yield universe directly to users. It filters vaults into a conservative set focused on established lending and savings protocols, including over-collateralized money markets. Reputation Scores help the Otus agent evaluate protocol health, network health, and vault history before a strategy can enter the approved set.
Otus focuses on saver-style yields from established markets and treats unusually high-risk sources as out of scope.
## Why Otus built this with vaults.fyi
Smart Yield depends on breadth and reliability. The agent needs current data, risk context, transaction execution, and position tracking across many protocols, not a single hardcoded vault. Building that in-house would mean maintaining protocol-specific integrations, monitoring rate changes, normalizing portfolio data, and building attribution workflows across multiple DeFi systems.
With vaults.fyi, Otus gets one API layer for discovery, risk filtering, transactions, portfolio tracking, attribution, and referral or rebate support. That lets the team keep its engineering focus on the agent and account experience.
***
Ready to build an agent-managed yield account? [Get API access](https://portal.vaults.fyi/signup) to start integrating.
# Vaults.fyi API & App Changelog
Source: https://docs.vaults.fyi/resources/changelog
A week-by-week log of all API and app updates shipped by vaults.fyi, including new protocols, endpoints, and product improvements.
This page tracks all notable updates to the vaults.fyi API and application, organized by week.
***
## Week 40, 2026 — Sep 29–Oct 5
**API**
* Expanded **composition analytics for supported Morpho V2 vaults**. `select.composition` can now include allocations held through Morpho V1 vault adapters alongside idle assets, with allocation percentages calculated against live onchain total assets.
* Added **two Base vaults**: KPK USDC Yield and AlphaGrowth Base AI. The tracker now covers **1,847 vaults across 20 networks**.
**App**
* Launched **X-Ray**, a read-only wallet exposure analyzer for Morpho vault positions. Enter an EVM address or ENS name to see exposure grouped by underlying Morpho market, filter by network or asset, and trace each market back to the source vaults.
***
## Week 39, 2026 — Sep 22–28
**API**
* Improved **same-chain transaction intents** in Alpha. Rhinestone-backed intent flows can now return usable quotes for supported same-chain position changes instead of rejecting the provider's settlement path.
* Added dedicated **pricing support for tGLD, weETHs, and USST**, improving current and historical USD valuations for vaults using these assets.
* Added **13 vaults** across Ethereum, Base, and Unichain. The tracker now covers **1,846 vaults across 20 networks**. The largest additions included Sky USDS Farm, Staked Frax USD, Noon Ecosystem Vault, and Clearstar cbXRP Yield Vault.
***
## Week 38, 2026 — Sep 15–21
**API**
* Added **curator display names** to V2. `GET /v2/curators` and both detailed-vault routes now return optional `curator.displayName` alongside the canonical `curator.name`, giving integrators presentation-ready curator labels without changing identifiers used for filtering.
* Added **Aave V4 Standard Spoke borrowing** in Beta on Ethereum. Supported markets can now expose market data, wallet positions, and transaction payloads for supply, withdraw, borrow, and repay flows.
* Expanded **borrow risk data** with optional `borrowRateMultiplier`, exposing the collateral risk multiplier applied to the base borrow rate where the protocol provides one.
* Added **three Ink xStocks vaults** for SPYx, QQQx, and NVDAx, including asset pricing and queued-withdrawal support.
* Fixed **TOKE pricing** using TOKE/WETH liquidity, improving USD valuation for vault rewards paid in TOKE.
* Expanded vault coverage by **14 vaults**, bringing the tracked total to **1,837 vaults across 20 networks**. The largest additions included Sentora x Spark RLUSD, Axis Origin USDx, Compound Institutional USDC, and RockawayX Confidential RWA USDC.
**App**
* Added curator display names across vault cards, curator filters, opportunity metadata, and analytics views. Also fixed a crash when the curator filter had no available entries.
* Updated **borrow-market charts** to match the vault performance experience, with separate expandable views for borrow APY, utilization, and total supplied.
***
## Week 37, 2026 — Sep 8–14
**API**
* Added **Solana vault LP-token metadata** in Beta. Detailed vault responses now include an optional `lpToken` object with the token’s mint address, name, symbol, decimals, and CAIP-19 identifier where available.
* Expanded **Solana portfolio data** in Beta. Idle-asset responses now include token names, symbols, and logos where available. Position responses also expose `asset.positionValueInAsset`, expressing the position value in underlying asset units at the asset’s precision. This mirrors `balanceNative`, not an additional balance.
* Optimized **Solana portfolio position lookups** by batching balance requests and reusing protocol connections, reducing RPC overhead when retrieving wallet positions.
* Updated **borrow portfolio filtering** so wallet-wide position lists include only markets with outstanding debt. Supply-only and collateral-only markets are excluded from these lists.
* Fixed **native-token wallet balances in borrow portfolio responses**, using the chain’s native balance lookup instead of treating native assets as ERC-20 tokens.
**App**
* Expanded **vault performance charts** so yield, TVL, and share price are visible together on opportunity pages, with an expanded view for each chart.
* Improved **borrow market comparisons** with charts showing supply and borrow APY together, plus total supplied and total borrowed balances.
***
## Week 36, 2026 — Sep 1–7
**API**
* Added **borrow support for Fluid** in Beta, covering supported single-collateral, single-debt markets, with position tracking and supply, withdraw, borrow, and repay transaction flows.
* Improved **borrow transaction context** with protocol-specific action steps, including collateral and controller activation where required. Integrators can follow the returned sequence when preparing transactions.
* Improved **vault composition accuracy** across supported multi-strategy vaults. Allocation discovery now includes positions held directly by the vault, and small incidental balances no longer hide underlying Morpho market allocations.
* Fixed **Jupiter Lend pricing** on Solana, addressing missing asset prices and USD TVL that caused affected vaults to disappear from discovery and become unavailable through transaction routes.
* Added **ether.fi eBTC withdrawal-queue support on Optimism**, extending queued redemption support through the shared Transactions API.
* Improved **Kamino transaction payload generation** for deposits and withdrawals, using address lookup tables to produce more compact transactions.
***
## Week 35, 2026 — Aug 25–31
**API**
* Added full **protocol IDs** to API responses and filtering. `protocol.protocolId` distinguishes protocol products and versions, while `allowedProtocols` and `disallowedProtocols` can now target either a broad protocol name or a specific protocol ID.
* Added **Aave V4 transaction support**. Supported Aave V4 Standard Spoke opportunities can now provide instant deposit and withdrawal context and payloads through the shared Transactions API.
* Expanded **Advanced Analytics composition coverage** with persisted allocation data. `select.composition` can now return stored underlying positions for more custody-based and composite strategies, alongside existing protocol-specific composition sources.
**App**
* Added **Fixed Term to Discover**. Users can now browse active Pendle principal-token markets, filter and sort by asset, network, APY, TVL, liquidity, or maturity, and open dedicated market pages with projected yield, maturity context, and related opportunities.
* Improved **Reputation Score display** by withholding ratings when holder data is unavailable, rather than showing an incomplete score as if it were fully assessed.
***
## Week 34, 2026 — Aug 18–24
**API**
* Expanded **fixed-term market data** in Beta. `GET /beta/fixed-term/` and `GET /beta/fixed-term/detailed/{network}/{vaultId}` now return richer Pendle market, asset, liquidity, maturity, protocol, and yield context through a more consistent response model.
* Added **Flying Tulip coverage**, including analytics for Flying Tulip Lend markets and the sftUSD savings vault, plus transaction support for supported Flying Tulip Lend deposit and withdrawal flows.
* Added **Sky stUSDS coverage**, making stUSDS opportunities available through vault discovery and related vault data surfaces.
* Expanded **vault composition coverage** for Yearn V3 and restored accurate allocation discovery for additional supported protocols, including Overnight Plus. Advanced Analytics can now explain the underlying positions of more multi-strategy vaults.
* Corrected **Wildcat capacity data** so remaining deposit capacity is based on the market's actual deposit limit rather than its current liquid assets. This prevents markets with available capacity from appearing full.
* Improved **Aave borrow position health factors**. Supply-only positions with no debt now return the appropriate no-debt health state instead of an invalid or misleading value.
* Added optional **API usage alerts** for customers who want email notifications when their keys encounter repeated credit or rate-limit errors.
***
## Week 33, 2026 — Aug 11–17
**API**
* Added **fixed-term market discovery** in Beta with `GET /beta/fixed-term/`. Integrators can discover active Pendle principal-token markets with current fixed APY, maturity, TVL, and liquidity, then filter and sort the results for fixed-yield experiences.
* Expanded **borrow market filtering**. Beta borrow discovery now supports protocol filters alongside the broader vault-style network, asset, TVL, pagination, and sorting controls.
* Standardized **SVM APY values** to the same decimal format used by V2 endpoints. For example, a 5% APY is now returned as `0.05` instead of `5`. This is a breaking correction for Beta SVM clients using the previous display-percent format.
* Added **curator metadata to SVM vault responses**, helping integrators show who manages supported Solana vault strategies.
* Improved **Drift APY accuracy** by including unsettled funding in vault equity snapshots, reducing cases where short-window APY appeared flat despite active funding gains or losses.
* Added normalized **Veda fee metadata** to detailed-vault responses, giving integrators clearer performance- and management-fee information for supported Veda/BoringVault opportunities.
* Expanded **composition analytics** across more multi-strategy protocols, including Yearn V2, Notional, Mellow, Syrup, Upshift, and additional Morpho V2 vaults.
***
## Week 32, 2026 — Aug 4–10
**API**
* Added **Aave transaction support on Monad**. Supported Monad Aave opportunities can now provide deposit and withdrawal transaction context and payloads through the shared Transactions API.
* Improved numeric vault filters so explicit zero values are handled correctly, including filters such as `maxTvl=0`, instead of being treated as omitted.
* Expanded **vault composition accuracy** across several multi-strategy protocols, improving how Advanced Analytics identifies and reports underlying allocations for supported Beefy, Harvest, IPOR Fusion, Lazy Summer, Notional, Superform, Syrup, and other composite vaults.
**App**
* Improved borrow-market charts with both supply and borrow rates, clearer protocol context, and available-to-borrow liquidity.
***
## Week 31, 2026 — Jul 28–Aug 3
**API**
* Moved **Advanced Analytics into Beta**. Integrators can now request heavier vault analytics from the Beta API with `POST /beta/advanced-analytics` and `POST /beta/advanced-analytics/{network}/{vaultId}`, including max drawdown, withdrawal pause ratio, composition, utilization rate, and embedded detailed-vault data.
* Added **Euler borrow market coverage** in Beta. `GET /beta/borrow/markets/` can now return Euler markets alongside existing borrow-market sources, helping integrators build broader borrow dashboards and account-health views through the shared Beta borrow model.
* Improved **borrow position chaining**. Borrow position responses now include market-specific asset identifiers, making it easier to connect a user's supplied or borrowed asset position to the matching market detail, historical data, events, NRT data, or transaction context.
* Expanded **Morpho V2 composition analytics**. Advanced Analytics can now return allocation data for additional Morpho V2 vaults where composition data is available, helping integrators show how vault assets are deployed underneath the top-level opportunity.
**App**
* Added **borrow market detail pages**. Users can now inspect supported borrow markets in a dedicated view with market-level context instead of only seeing borrow opportunities in list views.
* Improved opportunity pages for agent and search discovery. Opportunity pages now expose clearer structured vault metadata and onchain identity information, making them easier for search engines and AI agents to interpret.
***
## Week 30, 2026 — Jul 21–27
**API**
* Added **utilization rate** to Alpha advanced analytics. Integrators can now request `select.utilizationRate` on `POST /alpha/advanced-analytics` and `POST /alpha/advanced-analytics/{network}/{vaultId}` to see how much of a vault or lending reserve is currently utilized. The field returns Morpho allocator utilization, Aave/Spark reserve utilization where available, and `null` when utilization is not supported.
* Updated Reputation Score behavior so `score.networkScore` is no longer included in the active vault score. The field remains in V2 detailed-vault responses as deprecated diagnostic data for backwards compatibility.
* Added Morpho Blue liquidation-penalty support to Beta borrow market data. Morpho borrow-market responses can now include the pair-level liquidation penalty derived from the market LLTV, helping integrators show clearer liquidation-risk context.
* Expanded Merkl reward ingestion for **Aave net-lending campaigns**, improving reward APY coverage for eligible Aave-style lending opportunities.
* Improved wrapped-asset discovery and unwrapping support so vaults that rely on wrapped or receipt-token assets can be indexed and priced more reliably.
**App**
* Added a **Show APY as avg. of** control on vault detail pages, letting users switch the displayed yield window directly from the opportunity view.
* Improved borrow-market discovery previews by sorting collateral icons by collateral TVL, so the most relevant assets appear first in compact market cards.
* Made the dashboard more resilient when borrow positions fail to load. App vault positions can still render even if the borrow-position request errors.
* Added an in-app case-studies panel so users can browse customer and partner examples without leaving the app.
***
## Week 29, 2026 — Jul 14–20
**API**
* Added near-real-time **borrow market data** in Beta. Integrators can now call `GET /beta/borrow/markets/nrt/{network}/{marketId}/{assetId}` to fetch current market-asset values such as oracle price, supply rate, borrow rate, utilization, total supplied, total borrowed, and available liquidity.
* Expanded borrow market liquidity fields. Beta borrow market responses now expose `availableLiquidity` and `availableToBorrow` where available, alongside supplied and borrowed balances, making it easier to show whether a borrow asset has usable capacity now, not just whether the market exists.
* Improved borrow market detail lookups and vault aliasing. `GET /beta/borrow/markets/{network}/{marketId}` now returns richer market metadata and asset-level data, and detailed-vault market aliases are more consistent with borrow market identifiers.
* Improved borrow market freshness. Borrow endpoints now use the most recent historical market data available, and `minTvl` filtering is calculated from aggregation asset prices so borrow-market discovery behaves more predictably across assets.
* Improved **Morpho composition** analytics. Alpha advanced analytics now includes idle assets in `select.composition` results, so allocation breakdowns can account for both deployed markets and undeployed vault assets.
* Fixed Aave withdrawal-pause event handling for advanced analytics, improving `withdrawalPauseRatio` accuracy for Aave-based vaults.
**App**
* Added **borrow positions** to the dashboard. Users can now see supplied and borrowed positions from supported borrow markets directly in their portfolio view, with borrow debt reflected in the header portfolio total.
* Added **vault composition** to opportunity pages. Vault detail pages can now show current allocations for supported vaults, giving users a clearer view of where deposited assets are deployed.
* Improved borrow and transaction messaging. Unsupported and not-eligible transaction states now have clearer copy, reducing confusion when a vault action is unavailable.
* Improved discovery result visibility by showing the filtered vault count in search/filter surfaces.
***
## Week 28, 2026 — Jul 7–13
**API**
* Added single-vault **advanced analytics** in Alpha. Integrators can now call `POST /alpha/advanced-analytics/{network}/{vaultId}` to request analytics for one vault directly, instead of filtering through the paginated list endpoint. The same `select` model applies for `maxDrawdown`, `withdrawalPauseRatio`, `composition`, and `detailedVault`.
* Expanded **Morpho composition** coverage in Alpha advanced analytics. `select.composition` now supports MetaMorpho-style vaults in addition to Morpho Vault V2 adapter-based vaults, returning market-level allocations where available.
* Added richer **Beta borrow market filtering**. `GET /beta/borrow/markets` and `GET /beta/borrow/markets/{network}` now support filters for borrow assets, collateral assets, included/excluded networks, and `minTvl`, making it easier to build focused borrow-market discovery views.
* Standardized borrow-market asset identifiers. Borrow market historical, transaction, portfolio-event, and asset-position routes now use `{assetId}` in the path, and borrow market responses expose `assetsData[].marketAssetId` for market-specific asset lookups.
* Improved Aave transaction/event handling so rebasing-interest `Burn` events are only treated as withdrawals when they belong to the user. This reduces false withdrawal entries in Aave portfolio history and return calculations.
**App**
* Added the **Borrow** page to the main app navigation.
* Improved borrow-market discovery by defaulting the page toward markets above \$100k TVL, tightening filter options around the visible market set, and showing result counts after filters are applied.
* Refined borrow and discovery filter menus so long option lists scroll more cleanly without pushing the rest of the interface around.
* Updated category icons and colors across the app for clearer visual grouping of vault categories.
***
## Week 27, 2026 — Jun 30–Jul 6
**API**
* Added **Robinhood** network support across V2 network-aware endpoints. `GET /v2/networks` now includes `robinhood` / `eip155:4663`, and Robinhood vaults can be discovered through standard V2 vault filters such as `allowedNetworks=robinhood`.
* Added initial **Morpho vault coverage on Robinhood**. V2 detailed vault responses now include Robinhood Morpho opportunities with the same vault metadata, APY, TVL, capacity, transaction-readiness, and app links used on other supported networks.
* Added protocol **display names** to API responses. Protocol objects now include `displayName` where available, giving integrators user-facing labels such as `Morpho`, `Aave`, or `Ether.fi` while preserving the canonical `name` field for filtering and stable identifiers.
* Expanded withdrawal-pause analytics coverage in Alpha. `POST /alpha/advanced-analytics` can now calculate `withdrawalPauseRatio` for more protocols that expose pause/unpause events, and only returns the metric when all required event topics have been indexed and backfilled.
* Improved x402 payment metadata for API clients. Payment-required responses now use the externally forwarded HTTPS URL when building the payment resource, include `USDC` in payment asset metadata, and can return the x402 flow for eligible endpoints without requiring a separate opt-in header.
* Improved Portal API-key activation. Newly created API keys now trigger an API-key cache refresh, reducing the delay between creating a key in the Portal and using it against the API.
**App**
* Updated protocol labels across vault discovery, dashboard positions, analytics breakdowns, opportunity pages, and protocol filters to use display names instead of raw protocol slugs.
* Improved protocol search and filtering so users can find protocols by either their canonical slug or their display name.
***
## Week 26, 2026 — Jun 23–29
**API**
* Expanded Beta borrow market coverage with **Compound V3** and **Spark** market support, and improved borrow position handling so live oracle issues on a market do not hide otherwise available user position data.
* Moved **SVM / Solana vault endpoints into Beta**. Solana vault discovery, detailed vaults, portfolio positions, portfolio events, idle assets, transaction context, and transaction payloads now live under `/beta/svm/...`, matching their current stability level in the API Reference.
* Added **SVM idle asset tracking** for Solana portfolios. `GET /beta/svm/portfolio/idle-assets/{userAddress}` returns idle token balances for a user, while `GET /beta/svm/portfolio/idle-assets/{userAddress}/{assetAddress}` scopes the result to a single asset.
* Added optional **SVM transaction simulation** with `simulate=true` on `GET /beta/svm/transactions/{action}/{userAddress}/{vaultAddress}`. Responses can now include simulation status plus token amounts expected to be spent or received, helping integrators preview Solana vault actions before signing.
* Expanded SVM detailed-vault filtering. `GET /beta/svm/detailed-vaults` now supports filters such as `allowedAssets`, `allowedProtocols`, and `minTvl`, making Solana vault discovery easier to narrow down programmatically.
* Expanded V2 vault and portfolio filters. `GET /v2/detailed-vaults`, `GET /v2/portfolio/best-vault/{userAddress}`, and `GET /v2/portfolio/best-deposit-options/{userAddress}` now expose additional filtering options including `maxApy`, `maxTvl`, `tags`, and `curators`. The portfolio endpoints now default toward app-featured vaults and exclude warning-flagged vaults unless requested.
* Added vault **composition** to Alpha advanced analytics. `POST /alpha/advanced-analytics` can now request `select.composition`, returning the vault's underlying investments and allocation percentages where available.
* Improved x402 payment infrastructure with batch settlement support and Bazaar-compatible bigint handling for payment validation flows.
***
## Week 25, 2026 — Jun 16–22
**API**
* Moved borrow endpoints into **Beta**. Borrow market discovery, historical market data, portfolio positions, portfolio events, and transaction/context routes now live under `/beta/borrow/...`, matching the current stability level of the borrowing API.
* Added pagination to borrow market discovery and borrow event history. `GET /beta/borrow/markets` and `GET /beta/borrow/markets/{network}` now return paginated responses with `itemsOnPage`, `nextPage`, and `data`, making large borrow-market lists easier to consume reliably.
* Added **historical balances** in Alpha with `GET /alpha/historical-balances/{userAddress}/{timestamp}`. Integrators can now reconstruct a user's vault positions and balances at a specific historical timestamp, with the same filtering model used across portfolio-style endpoints.
* Added **SVM portfolio events** in Alpha. `GET /alpha/svm/portfolio/events/{userAddress}` returns Solana/SVM vault activity across supported vaults, while `GET /alpha/svm/portfolio/events/{userAddress}/{vaultAddress}` scopes the result to a single vault.
* Improved transaction support for **Veda / BoringVault** redeem flows by enabling instant redeems where the vault configuration supports them.
* Improved x402 payment handling, including CDP facilitator authentication, `upto` settlement support, and Bazaar-compatible x402 validation.
* Added automatic redirects for older API version paths during version moves, reducing breakage for clients still calling recently moved Alpha/Beta routes.
**App**
* Added a public widget showcase for embedded vault experiences, with follow-up UI refinements shipped during the week.
* Added chart brushing / zoom controls across analytics and vault performance charts, making dense historical data easier to inspect.
* Added vaults.fyi watermarks to app charts and refined their placement so exported/shared charts carry clearer product attribution without covering the data.
***
## Week 24, 2026 — Jun 9–15
**API**
* Made `sharePrice` values more consistent across V2 historical, near-real-time, and portfolio event responses, especially for protocols with custom price-per-share units.
* Increased API path-parameter support for longer vault identifiers and descriptors. Integrators using stable `vaultId` values, non-address market identifiers, or descriptor-style IDs can now send longer path params without hitting the previous request parser limit.
* Improved **Accountable** vault aggregation so TVL and share-price calculations use the protocol-specific `convertToAssets(totalSupply)` path instead of relying on the generic ERC-4626 `totalAssets()` value. This reduces incorrect historical rows for Accountable vaults whose `totalAssets()` value does not reflect the vault's redeemable assets.
* Added a one-command MCP setup path for agent integrations with `npx @vaultsfyi/scripts init-mcp --api-key YOUR_VAULTS_API_KEY`, covering Claude Desktop, Claude Code, Cursor, Windsurf, VS Code, Zed, Amazon Q, and GitHub Copilot CLI.
**App**
* Shipped the first version of the vaults.fyi widget for embedded earn experiences. More public integration materials will follow.
* Young vaults now display as **Not Rated** instead of showing a numeric Reputation Score too early. This avoids presenting immature vault history as a mature risk signal.
***
## Week 23, 2026 — Jun 2–8
**API**
* Added **vault deployment timestamps** to V2 detailed vault responses. Integrators can now sort, filter, or label vaults by launch age without doing a separate chain lookup. The new `creationData.deploymentTimestamp` field is available on `GET /v2/detailed-vaults` and `GET /v2/detailed-vaults/{network}/{vaultId}`.
* Improved **partial returns** in Beta so time-window return calculations use stored historical vault data points more reliably. This makes period-specific user return views more dependable, especially when the requested start or end timestamp does not line up exactly with an indexed event.
* Expanded **borrow transaction support** for Morpho markets through the shared Beta borrow transaction surface. Integrators can build borrow-market transaction flows against the same model used for generalized borrow integrations, instead of wiring protocol-specific transaction logic. Use `GET /beta/borrow/markets/transactions/context/{userAddress}/{network}/{marketId}/{assetAddress}` and `GET /beta/borrow/markets/transactions/{action}/{userAddress}/{network}/{marketId}/{assetAddress}` for transaction context and action payloads.
* Updated x402 handling for historical endpoints to support `upto` payment requirements. Payment-aware clients can now handle variable-sized historical queries more cleanly across historical vault data, APY, TVL, share price, asset prices, and benchmarks.
* Added **Savings GHO** support to Aave protocol coverage.
* Clarified max drawdown documentation in Alpha advanced analytics. MDD is now described as the largest observed peak-to-trough drop in vault price per share over the selected window, rather than a generic drawdown metric.
**App**
* Improved Discover filters so active user input is no longer overwritten while debounced filters sync.
* Improved analytics and best-performing vault views by using raw vault-history cache data for cleaner historical performance calculations.
* Renamed APY language to **Yield** on Discover, matching how users evaluate vault returns across base yield, rewards, and composite vault behavior.
***
## Week 22, 2026 — May 26–Jun 1
**API**
* Added **advanced vault analytics** in Alpha with `POST /alpha/advanced-analytics`. The endpoint mirrors detailed-vault filtering and pagination, while letting integrators opt into heavier per-vault analytics sections such as max drawdown, withdrawal pause ratio, and the full detailed-vault payload.
* Added **max drawdown (MDD)** as an advanced analytics selector. This helps integrators compare vaults by their largest observed peak-to-trough decline over the tracked period.
* Added **withdrawal pause ratio** as an advanced analytics selector. This gives integrators a structured way to screen how often vault withdrawals have been paused over the tracked window, returning `null` when the protocol or event source does not support the metric yet.
* Cleaned up the Beta borrow API by removing older protocol-specific Aave and Morpho borrow routes from the OpenAPI surface. Integrators should use the generalized borrow market and borrow portfolio endpoints under `/beta/borrow/markets/...` and `/beta/borrow/portfolio/...` instead.
* Updated x402 payment response schemas across V2 and Alpha documentation to use structured payment-resource metadata and amount fields, improving compatibility with payment-aware clients and generated SDKs.
**App**
* Redesigned the vault performance section for a clearer view of vault-level performance data.
* Improved mobile discovery and dashboard UX, including redesigned filters on the Discover page and a redesigned dashboard vault card on mobile.
* Updated chart colors and vault reward display conditions so app visuals and reward visibility are cleaner across vault pages.
***
## Week 21, 2026 — May 19–25
**API**
* Added **partial returns** in Beta with `GET /beta/portfolio/partial-returns/{userAddress}/{network}/{vaultId}`. The endpoint calculates a user’s vault returns for a specific time window using `fromTimestamp` and optional `toTimestamp`, returning native-token returns plus asset metadata. This gives integrators a way to measure period-specific performance instead of only lifetime total returns.
* Added **historical user positions** with `GET /alpha/historical-positions/{userAddress}`. The endpoint returns vaults a user held during a selected time window, including positions that existed at the start of the window or were opened during it. This helps apps reconstruct previous user exposure, not just current balances.
* Added **borrow portfolio positions** to the Beta API, including list, market-level, and asset-level views via `GET /beta/borrow/portfolio/positions/{userAddress}`, `GET /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}`, and `GET /beta/borrow/portfolio/positions/{userAddress}/{network}/{marketId}/{assetAddress}`. These endpoints expose supplied and borrowed asset positions, LTV, health factor, and optional filters for networks, assets, value thresholds, and sorting.
* Added **daily vault flow history** with `GET /alpha/historical/{network}/{vaultId}/daily-flows`, exposing UTC daily deposit and redemption totals for a vault over a date range.
* Standardized API error documentation across V2 and Alpha endpoints: validation-style failures are now documented as `422 Unprocessable Entity`, and obsolete `502 Bad Gateway` response entries were removed from the OpenAPI spec.
* Improved API metadata quality by ensuring endpoint definitions include `operationId` and `summary`, improving SDK generation and API explorer output.
**App**
* Improved dashboard portfolio views with tab-linked state, cleaner side-panel layout, hidden empty states, updated copy, and average APY by group.
* Refined dashboard analytics and benchmark copy, including a clearer benchmark-rate section and reordered breakdown-chart legend items.
* Improved transaction and swap UX with safer swap route selection, guarded swap execution, better loading states for returns queries, and updated fee/safety messaging.
* Added agent-readiness improvements, including markdown negotiation, agent skills, and MCP fixes for AI integrations.
***
## Week 20, 2026 — May 12–18
**API**
* **Beta borrow market transactions** now support context and action payloads for supply, withdraw, borrow, and repay flows via `GET /beta/borrow/markets/transactions/context/{userAddress}/{network}/{marketId}/{assetAddress}` and `GET /beta/borrow/markets/transactions/{action}/{userAddress}/{network}/{marketId}/{assetAddress}`.
* Added **borrow market portfolio events** with `GET /beta/borrow/portfolio/events/{userAddress}/{network}/{marketId}/{assetAddress}`, giving integrators user-level event history for a specific borrow market and asset.
* Added protocol-specific borrow transaction payloads for **Aave** Beta borrow integrations, including deposit/redeem/borrow/repay actions. Morpho borrow transaction flows are still in progress and are not ready for production use yet.
* Improved API-key flows: invite codes are no longer required for Portal signup, so users can now sign up and generate API keys directly at [portal.vaults.fyi/signup](https://portal.vaults.fyi/signup). Credit top-up and exhausted-credit messages now point users back to the Portal.
**App**
* Redesigned the **Analytics** page for a cleaner market overview and comparison experience.
* Added a **score filter** to the discovery table, making it easier to screen vaults by vault quality.
* Updated app signup CTAs to point directly to the self-service Portal signup flow.
* Improved dashboard position visibility for low-TVL vaults, plus smaller table, filter, side-panel, and mobile transaction-panel UX fixes.
***
## Week 19, 2026 — May 5–11
**API**
* `GET /v2/vaults` now includes `name`, making it easier to build vault selectors and search UIs without fetching full vault details.
* **All new API keys now include access to every endpoint** — future keys are no longer split by endpoint access tier. Plans now differ by credits, rate limits, and support rather than which endpoints are available.
* Added **Liquity** protocol coverage and 52 new vaults, bringing total tracked coverage to 1,525 vaults across 20 networks.
* Expanded **Beta borrow markets** with historical market data and portfolio event tracking for borrow positions.
**App**
* Vault suggestions now filter out lower-quality vaults from personalized and trending surfaces.
* Added UI support for vault score penalties and resolutions, making risk and warning context clearer in the app.
* Improved transaction and side-panel UX, including estimated returns, missing actions, mobile transaction panel styling, and CCTP disabled states.
* Added the pay-as-you-go API pricing tier to the pricing page.
***
## Week 18, 2026 — Apr 28–May 4
**API**
* **[Reputation Score](/methodology/reputation-score) now reflects active vault flags** — warnings and risk indicators directly apply severity-based penalties to each vault's Reputation Score: critical flags carry the largest deduction, warning flags moderate, and info-level flags minimal. Vaults with active warnings will show a lower Reputation Score, providing a more accurate signal of current vault health. This change is backwards compatible. Responses now include a `penaltyComponents` field detailing each active flag and its resolution status.
* **New `GET /v2/transactions/suffix/{userAddress}/{vaultId}` [endpoint](/api-reference/transactions)** — returns a raw hex suffix to append to transaction calldata, enabling onchain attribution of deposits and withdrawals back to your API key.
* **New borrow markets endpoints ([Beta](/api-reference/beta#borrow-markets))** — four endpoints for discovering and analyzing borrowing opportunities:
* `GET /beta/borrow/markets/` — all supported borrow markets across networks
* `GET /beta/borrow/markets/{network}` — filter by network
* `GET /beta/borrow/markets/{network}/{marketId}` — detailed data for a single market, including rates, utilization, and collateral
* `GET /beta/borrow/markets/historical/{network}/{marketId}/{assetAddress}` — historical rates and utilization over time for a specific asset within a market
* **StakeWise V3 transactional support** — deposit and withdrawal flows now available for StakeWise V3 vaults. See the [transactions reference](/api-reference/transactions).
* **Expanded Solana vault coverage** — Jupiter and Kamino Vaults are now fully integrated, extending beyond the data aggregates added in Week 16 to include complete vault support.
* **Improved BoringVault support** — async deposit and withdrawal queues are now handled correctly throughout the transaction lifecycle.
**App**
* Updated landing page at [vaults.fyi](https://www.vaults.fyi/).
* Redesigned side panel on vault detail pages.
***
## Week 17, 2026 — Apr 21–27
**API**
• Introduced`vaultId` — a new stable identifier field on vault responses and a new path parameter across detailed-vaults, historical, NRT, portfolio, and transactions endpoints. `vaultId` supports both contract addresses and non-address identifiers like Morpho market IDs. Fully backwards compatible: existing vault addresses continue to work.
• **Faster holder queries** — vault holder data now returns significantly faster, especially for high-holder-count vaults.
**• Near real-time (NRT) endpoints** moved out of Alpha API, now exclusively available on the V2 production API.
• Rhinestone intent transactions now **reject partial solves** instead of silently returning incomplete execution paths.
**App**
• Continued **app redesign** rollout: refreshed top navigation bar, updated vault page layout, redesigned table UI, and new input styling.
• Updated **vault score thresholds** in the UI display.
***
## Week 16, 2026 — Apr 14–20
**API**
* **NRT endpoints promoted to production** — [near-real-time vault data](/api-reference/nrt) (`/v2/nrt/vault/...`) is now available on the V2 API, delivering live share price, total supply, total assets, and underlying asset price.
* All 34 V2 endpoints now include `operationId` and `summary` fields in the OpenAPI spec, improving SDK code generation and API explorer usability.
* New descriptive tags across all endpoint groups (General, Detailed Vaults, Benchmarks, Historical, Portfolio, Transactions, NRT) for better API navigation.
* `apyComposite` on [detailed-vaults](/api-reference/detailed-vaults) responses now includes `assetGroup` and `assetPriceInUsd` for the underlying asset.
* Removed **ERC-4626 restriction** for Rhinestone intent quotes, broadening cross-chain deposit support to non-ERC-4626 vaults.
* Added **Kamino** and **Jupiter Earn** vault aggregates for Solana coverage.
**App**
* **Intrinsic APY** now displays on the dashboard for vaults with nested yield sources.
***
## Week 15, 2026 — Apr 7–13
**API**
* Added transactional support for **IPOR** and **Advanced Strategies BTC**, enabling deposit and withdrawal flows for these protocols.
* Added **Convex** protocol-specific position data to the positions endpoint.
**App**
* Launched the first phase of the **app redesign** with refreshed navigation, updated icons, and the new Geist typeface.
* Improved **search accuracy** across the vault table with tuned fuzzy matching.
***
## Week 14, 2026 — Mar 31–Apr 7
**API**
* Added **APYx**, **Aave V4** (tokenized spokes), and **Ember** as new protocol integrations.
* New [`GET /v2/protocols`](/api-reference/general) endpoint returns the full list of available protocols with name, product, and version. Useful for populating filter dropdowns and validating `allowedProtocols` params.
* New `apyComposite` field on [detailed-vaults](/api-reference/detailed-vaults) responses replaces `intrinsic`, with a richer structure: `totalApy` (compounded vault + underlying APY) and `intrinsicApy` (yield intrinsic to the underlying asset, e.g. staking yield), each with 1day / 7day / 30day intervals including base, reward, and total.
* New `minVaultScore` filter on [detailed-vaults](/api-reference/detailed-vaults) endpoints for filtering by vault quality score.
* Shipped **auto-indexing** for new vaults — newly deployed vaults are now surfaced in the API faster.
**Migration required:** All `/experimental/` endpoints have been renamed to `/alpha/`. Update any integrations using `/experimental/` paths. See the [Alpha API reference](https://api.vaults.fyi/experimental/documentation/static/index.html).
**App**
* The **/analytics page** gained split network benchmarks, shared Y-axis scaling for chart comparison, and updated default vault comparison lists.
* **Fee transparency** improved with Fluid withdrawal fee notes and generic fee indicators.
* Added **protocol tooltip** to the vault table, APY format capping above 1,000% for cleaner display, and updated protocol/curator images.
***
## Week 13, 2026 — Mar 24–30
**API**
* **Vault capacity** landed in the `detailed-vaults` endpoint — integrators can now see deposit caps and utilization.
* Added **vault flags with severity** to the API, surfacing warning indicators for vaults.
* **CCTP forwarding fee optimization** skips unnecessary fees for same-chain operations.
**App**
* Shipped major **/analytics page** upgrades: TVL sections, shareable benchmark URLs via URL params, improved benchmark dropdown, and repositioned APY range toggle and period selector.
* **Vault flags** now display as warning indicators on vault listings.
***
## Week 12, 2026 — Mar 17–23
**API**
* Added **Etherlink** as a new network with Morpho vault factories.
* Launched **OpenCover** protocol support with solver-based async deposit settlement tracking.
* Vault **capacity data** is now aggregated and stored, with the pipeline ready for API exposure.
* Introduced **vault warnings with severity levels**.
**App**
* **Etherlink** fully integrated in the app.
* The **asset scoring system** was revamped for more accurate reputation calculations, and **intrinsic yield indicators** now display in the UI.
* **CCTP transfer tracking** added to the frontend.
***
## Week 11, 2026 — Mar 10–16
**API**
* Added **Ultrayield** as a new protocol.
* Introduced **multi-asset Upshift vaults**, a **Gauntlet gtBTC vault**, and **capacity indicators** that show when vaults are near their supply cap.
**App**
* Shipped the **CCTP cross-chain bridging page**, enabling users to bridge assets between supported networks directly in the app.
* The **vault opportunity page** was redesigned with improved SEO and layout.
***
## Week 10, 2026 — Mar 3–9
**API**
* Added **Concrete V2** protocol with full async request-redeem flows.
* Shipped **NRT endpoints** (alpha) and moved **deep AMM endpoints** to the new beta API section.
* Reorganized alpha API structure for clearer endpoint grouping.
**App**
* Major **vault page redesign** went live.
***
## Week 9, 2026 — Feb 24–Mar 2
**API**
* Added [**near-real-time ("NRT") endpoints**](https://api.vaults.fyi/alpha/documentation/static/index.html#/NRT) (alpha) for current data on vault share price, total assets, total supply, and underlying asset price.
* Shipped **historical asset prices endpoint** (`/v2/historical/asset-prices/{network}/{address}`) for USD price time series.
* Introduced **APY update timestamps for LLMs** to help AI consumers know data freshness.
* Expanded **Upshift** support with separate handling for distinct vault types.
***
## Week 8, 2026 — Feb 17–23
**API**
* Launched **vault fees in the API** — the `detailed-vaults` endpoint now returns fee data (performance, management, deposit) read from onchain contracts.
***
## Week 7, 2026 — Feb 10–16
**API**
* Shipped **Aera vaults on additional chains** (beyond mainnet).
**App**
* Added external links on vault pages and curator name truncation.
* Improved **wallet connectivity** with enhanced capabilities detection.
***
## Week 6, 2026 — Feb 3–9
**API**
* Added **Monad** chain setup and initial configuration.
* Improved **position tracking accuracy** with daily user balance computation.
* Added the [**intent status endpoint**](https://api.vaults.fyi/experimental/documentation/static/index.html#/Cross%20Chain/get_alpha_transactions_intent_status) (alpha) and expanded intent quote responses with asset decimals and expiration timestamps.
* Added **Avon** protocol with analytics and transactional support.
**App**
* Fixed holders chart rendering for edge cases.
***
## Week 5, 2026 — Jan 27–Feb 2
**API**
* Added the **Pendle transactions endpoint** (alpha) for constructing Pendle position entry/exit flows, plus a **Pendle transactions context endpoint** for pre-flight data.
* Shipped **Veda** vault event tracking for improved queue monitoring and position visibility.
* Introduced **isCorrupted flag** in vault responses to surface data quality issues transparently.
* Launched **CCTP cross-chain bridge transaction endpoints** (alpha) — context, execution, and status tracking for Circle CCTP transfers.
* Improved holder computation performance and balance calculation accuracy.
***
## Week 4, 2026 — Jan 20–26
**API**
* Shipped [**intent-based cross-chain transactions**](https://api.vaults.fyi/alpha/documentation/static/index.html#/Cross%20Chain) (alpha) with Rhinestone integration, enabling cross-chain deposit flows via EIP-712 signed quotes.
* APY min/max filters were expanded for more flexible vault queries.
* Added **Kelp restaking analytics** support.
**App**
* Added **multiple rewards claiming UI** overhaul for better multi-vault reward management.
* Refined network filter sorting with proper chain name handling.
***
## Week 3, 2026 — Jan 13–19
**API**
* Introduced the **alpha [Pendle market read endpoint](https://api.vaults.fyi/experimental/documentation/static/index.html)**, laying groundwork for fixed-term yield products.
* Added **deposit limit visibility** — the `detailed-vaults` endpoint now returns `maxDeposit` data.
* Shipped **Mellow multi-vault transactional support** and split the Mellow protocol into distinct services.
* Added **Euler on Linea** and the **Katana MetaMorpho** integration.
**App**
* Deposit limit indicators now display in the app UI.
* Frontend optimizations reduced memory usage and bundle size for faster page loads.
***
## Week 2, 2026 — Jan 6–12
**API**
* Launched the **curators endpoint** (`/v2/curators`) as a new first-class API resource for vault curator discovery and filtering.
* Added **Katana** network support with Yearn and MetaMorpho vaults, including token aliases and image handling.
* Shipped **Mellow Core** protocol support, plus **Veda** vault integration via Lido.
* Introduced **Lagoon** vault discovery via API and Morpho V2 factory support.
* Improved position tracking accuracy with upgraded balance calculations and holder computation.
**App**
* Added curator sorting in filters.
# Vaults.fyi API Frequently Asked Questions
Source: https://docs.vaults.fyi/resources/faq
Answers to common questions about yield calculations, data freshness, vault inclusion criteria, and how to request new protocols or features.
Find answers to the most common questions about how vaults.fyi collects data, calculates yields, and decides which vaults to include.
## Why do yields on vaults.fyi look different from other sources?
While other applications calculate interest rates using varying assumptions and methodologies, vaults.fyi standardizes yield calculations across the entire platform.
Yields are calculated as 1-day, 7-day, and 30-day trailing averages by observing changes in vault share price over each time frame. This approach provides a more accurate representation of vault performance compared to more volatile interest rates measured over shorter timeframes (such as a single block).
Data for these calculations is fetched directly from the blockchain, minimizing assumptions and reliance on external APIs. For full details, see the [Methodology](/methodology/calculating-apy) page.
## How often does data on vaults.fyi update?
Data updates hourly. Onchain data is fetched once per hour.
For use cases requiring more frequent data, the stable [near-real-time (NRT) endpoints](/api-reference/nrt) return current vault share price, total assets, total supply, and underlying asset price outside the hourly cycle.
## How does vaults.fyi get its data?
Vaults.fyi uses specialized smart contracts that fetch and transform onchain data in a single function call. These contracts are deployed as static calls — temporary reads that do not write to blockchain storage and therefore incur no gas costs.
This architecture allows data from one read to feed directly into the next calculation within the same call, which is not possible with standard multi-call approaches. RPC providers including Infura, Alchemy, and Ankr are used to execute these calls. Once retrieved, the data is stored in the vaults.fyi backend database.
Learn more in the [Indexing Onchain Data](/methodology/indexing-onchain-data) methodology doc.
## What causes significant fluctuations in APY?
Some vaults update their earnings at irregular intervals rather than on every block. When a vault that has been accumulating yield for hours or days finally posts an update, the resulting share price jump creates a large but temporary spike in the calculated APY.
Understanding this behavior is essential for accurately interpreting APY figures on vaults.fyi. For a detailed explanation, see [Calculating APY](/methodology/calculating-apy).
## How can I stay up to date with the latest activity?
Follow [@vaultsfyi](https://twitter.com/vaultsfyi) on X (formerly Twitter) for new product updates, newly added vaults, and insights on DeFi yield and TVL trends. The account also posts on Farcaster.
You can also check the [Changelog](/resources/changelog) page for a week-by-week log of API and app updates.
## How do I request new vaults or features?
Reach out to [@vaultsfyi](https://twitter.com/vaultsfyi) directly on X or Farcaster. The team actively monitors both channels for integration and feature requests.
If you represent a protocol and want your vault added, submit the [protocol request form](https://listings.vaults.fyi/). The team reviews each protocol before integrating and welcomes direct communications from protocol teams.
## How are new vaults added to vaults.fyi?
New vaults are added based on customer requests, with priority given to protocols with significant traction. The team started with yield opportunities for stablecoins, ETH, and liquid staking tokens across established DeFi protocols — including Aave, Compound, MakerDAO, Yearn, Lido stETH, and Rocket Pool rETH — and has since expanded coverage through user demand.
If you represent a protocol, submit the [protocol request form](https://listings.vaults.fyi/). The team researches each protocol before integrating.
## What are the requirements for vaults to be listed on vaults.fyi?
For a vault to be included, **all key data must be available onchain**. From a contract address (or set of addresses), the following fields must be extractable:
* `tvl` — total value locked in the vault, denominated in the underlying token
* `totalSupply` — total supply of the LP token issued by the vault (if applicable)
* `pricePerShare` — normally `tvl / totalSupply`, or an equivalent growth indicator if LP tokens are not used
* `maxDeposit` — maximum amount of tokens any user can deposit
* `liquidity` — amount of tokens directly available for withdrawal
* `asset` — address of the underlying ERC-20 token
* `name` — name of the vault
* `lpTokenAddress` — address of the LP token issued by the vault
* `rewardTokens` — addresses of reward tokens distributed by the vault
* `rewardTokenEmissionsPerSecond` — emission rate of reward tokens
Vaults that conform to the [ERC-4626](https://ethereum.org/en/developers/docs/standards/tokens/erc-4626/) standard make this data straightforward to access. For vaults that require reading data from multiple contracts through a chain of calls, the team appreciates protocol teams reaching out with instructions on how to locate the fields above.
# Get Started with the Vaults.fyi SDK
Source: https://docs.vaults.fyi/sdk/quickstart
Install the TypeScript or Python SDK, configure your API key, and make your first call to the Vaults.fyi yield API in under five minutes.
The Vaults.fyi SDK gives you typed access to 1,000+ DeFi yield strategies across 80+ protocols. This guide walks you through installation, authentication, and your first API call.
Add the SDK to your project using your preferred package manager.
```bash npm theme={null}
npm install @vaultsfyi/sdk
```
```bash yarn theme={null}
yarn add @vaultsfyi/sdk
```
```bash pnpm theme={null}
pnpm add @vaultsfyi/sdk
```
```bash bun theme={null}
bun add @vaultsfyi/sdk
```
```bash pip theme={null}
pip install vaultsfyi
```
```bash poetry theme={null}
poetry add vaultsfyi
```
Export your API key as an environment variable so the SDK can authenticate your requests.
```bash theme={null}
export VAULTS_FYI_API_KEY="your_api_key_here"
```
You need an API key to use the SDK. [Sign up at the vaults.fyi portal](https://portal.vaults.fyi/signup) to generate one. We offer a Pay-As-You-Go plan so you only pay for what you use, with no commitments.
Import the SDK and create a client instance using your API key from the environment.
```javascript index.js theme={null}
import pkg from '@vaultsfyi/sdk';
const { VaultsSdk } = pkg;
const vaultsFyi = new VaultsSdk({
apiKey: process.env.VAULTS_FYI_API_KEY,
});
```
```python main.py theme={null}
import os
from vaultsfyi import VaultsSdk
api_key = os.getenv("VAULTS_FYI_API_KEY")
client = VaultsSdk(api_key=api_key)
```
Call `getDepositOptions` to fetch personalized yield opportunities for a wallet address. The response is filtered by the assets you specify.
```javascript index.js theme={null}
const depositOptions = await vaultsFyi.getDepositOptions({
path: { userAddress: '0xdB79e7E9e1412457528e40db9fCDBe69f558777d' },
query: { allowedAssets: ['USDC', 'USDS'] }
});
console.log(depositOptions);
```
```python main.py theme={null}
user_address = "0xdB79e7E9e1412457528e40db9fCDBe69f558777d"
deposit_options = client.get_deposit_options(
user_address,
allowed_assets=["USDC", "USDS"]
)
print(deposit_options)
```
`getDepositOptions` ranks results by APY and filters out vaults below minimum TVL thresholds. It's the fastest way to surface relevant opportunities for a specific wallet.
## Next steps
Now that your client is working, explore the full set of SDK methods or follow a tutorial for your use case.
* [SDK Reference](/sdk/reference) — every method, parameter, and response type
* [Wallet integration tutorial](/sdk/tutorials/wallet-integration) — detect idle assets, build deposit flows, and track positions
* [Data analytics tutorial](/sdk/tutorials/data-analytics) — fetch vault data, historical APY, and benchmark comparisons
# SDK Method Reference
Source: https://docs.vaults.fyi/sdk/reference
Complete method reference for the TypeScript and Python Vaults.fyi SDKs — vault discovery, historical data, portfolio, transactions, rewards, and benchmarks.
For installation and client setup, see the [quickstart guide](/sdk/quickstart).
## Installation & setup
```bash TypeScript theme={null}
npm install @vaultsfyi/sdk
```
```bash Python theme={null}
pip install vaultsfyi
```
```typescript TypeScript theme={null}
import { VaultsSdk } from '@vaultsfyi/sdk'
const sdk = new VaultsSdk({ apiKey: 'YOUR_API_KEY' })
```
```python Python theme={null}
from vaultsfyi import VaultsSdk
client = VaultsSdk(api_key="YOUR_API_KEY")
```
The Python client also accepts optional `api_base_url`, `timeout` (default 30s), and `max_retries` (default 3) constructor arguments.
***
## Vault discovery
### `getAllVaults` / `get_all_vaults`
Returns a paginated, filterable list of vaults with full performance metrics.
```typescript TypeScript theme={null}
const vaults = await sdk.getAllVaults({
query: {
page: 0,
perPage: 100,
allowedNetworks: ['mainnet', 'base'],
allowedProtocols: ['aave', 'morpho'],
allowedAssets: ['USDC', 'USDT'],
minTvl: 1000000,
maxTvl: 100000000,
minApy: 0.03,
sortBy: 'apy7day',
sortOrder: 'desc',
onlyTransactional: true,
}
})
```
```python Python theme={null}
vaults = client.get_all_vaults(
page=0,
per_page=100,
allowed_networks=["mainnet", "base"],
allowed_protocols=["aave", "morpho"],
allowed_assets=["USDC", "USDT"],
min_tvl=1_000_000,
max_tvl=100_000_000,
min_apy=0.03,
sort_by="apy7day",
sort_order="desc",
only_transactional=True,
)
```
### `getVault` / `get_vault`
Returns full detail for a single vault by network and address.
```typescript TypeScript theme={null}
const vault = await sdk.getVault({
path: {
network: 'mainnet',
vaultAddress: '0x9D39A5DE30e57443BfF2A8307A4256c8797A3497'
}
})
```
```python Python theme={null}
vault = client.get_vault(
network="mainnet",
vault_address="0x9D39A5DE30e57443BfF2A8307A4256c8797A3497",
)
```
### `getVaultApyBreakdown` / `get_vault_apy_breakdown`
Returns only the APY breakdown for a vault — lighter than fetching the full vault object.
```typescript TypeScript theme={null}
const apy = await sdk.getVaultApyBreakdown({
path: {
network: 'mainnet',
vaultAddress: '0x1234...'
}
})
```
```python Python theme={null}
apy = client.get_vault_apy_breakdown(
network="mainnet",
vault_address="0x1234...",
)
```
### `getAssets` / `get_assets`
Lists all tracked assets across networks.
```typescript TypeScript theme={null}
const assets = await sdk.getAssets({
query: { page: 0, perPage: 100 }
})
```
```python Python theme={null}
assets = client.get_assets(page=0, per_page=100)
```
***
## Historical data
### `getVaultHistoricalData` / `get_vault_historical_data`
Returns combined APY, TVL, and share price time-series for a vault.
```typescript TypeScript theme={null}
const history = await sdk.getVaultHistoricalData({
path: {
network: 'mainnet',
vaultAddress: '0x1234...'
},
query: {
page: 0,
perPage: 90,
apyInterval: '7day',
granularity: '1day',
fromTimestamp: 1735689600,
toTimestamp: 1743465600
}
})
```
```python Python theme={null}
history = client.get_vault_historical_data(
network="mainnet",
vault_address="0x1234...",
page=0,
per_page=90,
apy_interval="7day",
granularity="1day",
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
### `getVaultHistoricalApy` / `get_vault_historical_apy`
APY-only time series. Lighter than the combined endpoint when TVL is not needed.
```typescript TypeScript theme={null}
const apyHistory = await sdk.getVaultHistoricalApy({
path: { network: 'mainnet', vaultAddress: '0x1234...' },
query: {
apyInterval: '7day',
granularity: '1day',
fromTimestamp: 1735689600,
toTimestamp: 1743465600
}
})
```
```python Python theme={null}
apy_history = client.get_vault_historical_apy(
network="mainnet",
vault_address="0x1234...",
apy_interval="7day",
granularity="1day",
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
### `getVaultHistoricalTvl` / `get_vault_historical_tvl`
TVL-only time series.
```typescript TypeScript theme={null}
const tvlHistory = await sdk.getVaultHistoricalTvl({
path: { network: 'mainnet', vaultAddress: '0x1234...' },
query: { fromTimestamp: 1735689600, toTimestamp: 1743465600 }
})
```
```python Python theme={null}
tvl_history = client.get_vault_historical_tvl(
network="mainnet",
vault_address="0x1234...",
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
### `getVaultHistoricalSharePrice` / `get_vault_historical_share_price`
Share price time series.
```typescript TypeScript theme={null}
const sharePriceHistory = await sdk.getVaultHistoricalSharePrice({
path: { network: 'mainnet', vaultAddress: '0x1234...' },
query: { fromTimestamp: 1735689600, toTimestamp: 1743465600 }
})
```
```python Python theme={null}
share_price_history = client.get_vault_historical_share_price(
network="mainnet",
vault_address="0x1234...",
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
### `getHistoricalAssetPrices` / `get_historical_asset_prices`
Historical USD prices for a tracked asset.
```typescript TypeScript theme={null}
const prices = await sdk.getHistoricalAssetPrices({
path: {
network: 'mainnet',
assetAddress: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48'
},
query: {
granularity: '1day',
fromTimestamp: 1735689600,
toTimestamp: 1743465600
}
})
```
```python Python theme={null}
prices = client.get_historical_asset_prices(
network="mainnet",
asset_address="0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
granularity="1day",
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
***
## Portfolio
### `getPositions` / `get_positions`
Returns all active vault positions for a wallet, optionally filtered and sorted.
```typescript TypeScript theme={null}
const positions = await sdk.getPositions({
path: { userAddress: '0xYourWallet' },
query: {
allowedNetworks: ['mainnet', 'base'],
apyInterval: '7day',
sortBy: 'balanceUsd',
sortOrder: 'desc'
}
})
```
```python Python theme={null}
positions = client.get_positions(
user_address="0xYourWallet",
allowed_networks=["mainnet", "base"],
apy_interval="7day",
sort_by="balanceUsd",
sort_order="desc",
)
```
### `getPosition` / `get_position`
Returns a single vault position for a specific wallet and vault.
```typescript TypeScript theme={null}
const position = await sdk.getPosition({
path: {
userAddress: '0xYourWallet',
network: 'mainnet',
vaultAddress: '0x1234...'
},
query: { apyInterval: '7day' }
})
```
```python Python theme={null}
position = client.get_position(
user_address="0xYourWallet",
network="mainnet",
vault_address="0x1234...",
apy_interval="7day",
)
```
### `getIdleAssets` / `get_idle_assets`
Returns assets sitting in a wallet not currently earning yield.
```typescript TypeScript theme={null}
const idle = await sdk.getIdleAssets({
path: { userAddress: '0xYourWallet' },
query: {
allowedNetworks: ['mainnet', 'base'],
minUsdAssetValueThreshold: 10,
sortBy: 'balanceUsd',
sortDirection: 'desc'
}
})
```
```python Python theme={null}
idle = client.get_idle_assets(
user_address="0xYourWallet",
allowed_networks=["mainnet", "base"],
min_usd_asset_value_threshold=10,
sort_by="balanceUsd",
sort_direction="desc",
)
```
### `getDepositOptions` / `get_deposit_options`
Returns ranked vault recommendations for each idle asset in a wallet.
```typescript TypeScript theme={null}
const options = await sdk.getDepositOptions({
path: { userAddress: '0xYourWallet' },
query: {
allowedNetworks: ['mainnet', 'base'],
allowedAssets: ['USDC', 'USDT'],
minTvl: 1000000,
onlyTransactional: true,
apyInterval: '7day',
maxVaultsPerAsset: 3,
alwaysReturnAssets: ['USDC']
}
})
```
```python Python theme={null}
options = client.get_deposit_options(
user_address="0xYourWallet",
allowed_networks=["mainnet", "base"],
allowed_assets=["USDC", "USDT"],
min_tvl=1_000_000,
only_transactional=True,
apy_interval="7day",
max_vaults_per_asset=3,
always_return_assets=["USDC"],
)
```
### `getBestVault` / `get_best_vault`
Returns the single highest-yielding vault opportunity for a wallet's current balances.
```typescript TypeScript theme={null}
const best = await sdk.getBestVault({
path: { userAddress: '0xYourWallet' },
query: {
allowedNetworks: ['mainnet', 'base'],
onlyTransactional: true,
apyInterval: '7day'
}
})
```
```python Python theme={null}
best = client.get_best_vault(
user_address="0xYourWallet",
allowed_networks=["mainnet", "base"],
only_transactional=True,
apy_interval="7day",
)
```
### `getUserVaultTotalReturns` / `get_vault_total_returns`
Returns total yield earned in a specific vault since the wallet's first deposit.
```typescript TypeScript theme={null}
const returns = await sdk.getUserVaultTotalReturns({
path: {
userAddress: '0xYourWallet',
network: 'mainnet',
vaultAddress: '0x1234...'
}
})
```
```python Python theme={null}
returns = client.get_vault_total_returns(
user_address="0xYourWallet",
network="mainnet",
vault_address="0x1234...",
)
```
### `getUserVaultEvents` / `get_vault_holder_events`
Returns the full deposit and withdrawal history for a wallet in a specific vault.
```typescript TypeScript theme={null}
const events = await sdk.getUserVaultEvents({
path: {
userAddress: '0xYourWallet',
network: 'mainnet',
vaultAddress: '0x1234...'
}
})
```
```python Python theme={null}
events = client.get_vault_holder_events(
user_address="0xYourWallet",
network="mainnet",
vault_address="0x1234...",
)
```
***
## Transactions
### `getTransactionsContext` / `get_transactions_context`
Returns the current state for a vault interaction: available action steps, token balances, and allowance status. Call this before `getActions` to determine what step is next.
```typescript TypeScript theme={null}
const context = await sdk.getTransactionsContext({
path: {
userAddress: '0xYourWallet',
network: 'mainnet',
vaultAddress: '0x1234...'
}
})
```
```python Python theme={null}
context = client.get_transactions_context(
user_address="0xYourWallet",
network="mainnet",
vault_address="0x1234...",
)
```
### `getActions` / `get_actions`
Returns ready-to-sign transaction calldata for a vault action. Execute `actions` in order — each must confirm onchain before sending the next.
The `action` parameter accepts: `deposit`, `redeem`, `request-redeem`, `claim-redeem`, `request-deposit`, `claim-deposit`, `claim-rewards`, `start-redeem-cooldown`.
```typescript TypeScript theme={null}
const actions = await sdk.getActions({
path: {
action: 'deposit',
userAddress: '0xYourWallet',
network: 'mainnet',
vaultAddress: '0x1234...'
},
query: {
assetAddress: '0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48',
amount: '1000000000' // 1000 USDC (6 decimals)
}
})
```
```python Python theme={null}
actions = client.get_actions(
action="deposit",
user_address="0xYourWallet",
network="mainnet",
vault_address="0x1234...",
asset_address="0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
amount="1000000000", # 1000 USDC (6 decimals)
)
```
***
## Rewards
### `getRewardsTransactionsContext` / `get_rewards_context`
Returns all claimable reward balances for a wallet across every supported network.
```typescript TypeScript theme={null}
const rewardsContext = await sdk.getRewardsTransactionsContext({
path: { userAddress: '0xYourWallet' }
})
```
```python Python theme={null}
rewards_context = client.get_rewards_context(
user_address="0xYourWallet",
)
```
### `getRewardsClaimActions` / `get_rewards_claim`
Returns transaction calldata to claim one or more pending rewards. Pass `claimIds` from the rewards context response.
```typescript TypeScript theme={null}
const claimActions = await sdk.getRewardsClaimActions({
path: { userAddress: '0xYourWallet' },
query: {
claimIds: ['claim-id-1', 'claim-id-2']
}
})
```
```python Python theme={null}
claim_actions = client.get_rewards_claim(
user_address="0xYourWallet",
claim_ids=["claim-id-1", "claim-id-2"],
)
```
***
## Benchmarks
### `getBenchmarks` / `get_benchmarks`
Returns current benchmark APY rates for a network. Use `code` to specify `usd` or `eth` denomination.
```typescript TypeScript theme={null}
const benchmarks = await sdk.getBenchmarks({
path: { network: 'mainnet' },
query: { code: 'usd' }
})
```
```python Python theme={null}
benchmarks = client.get_benchmarks(
network="mainnet",
code="usd",
)
```
### `getHistoricalBenchmarks` / `get_historical_benchmarks`
Returns paginated historical benchmark rates within a time range.
```typescript TypeScript theme={null}
const historicalBenchmarks = await sdk.getHistoricalBenchmarks({
path: { network: 'mainnet' },
query: {
code: 'usd',
page: 0,
perPage: 90,
fromTimestamp: 1735689600,
toTimestamp: 1743465600
}
})
```
```python Python theme={null}
historical_benchmarks = client.get_historical_benchmarks(
network="mainnet",
code="usd",
page=0,
per_page=90,
from_timestamp=1735689600,
to_timestamp=1743465600,
)
```
***
## Error handling
```typescript TypeScript theme={null}
import { VaultsSdk, HttpResponseError } from '@vaultsfyi/sdk'
try {
const vault = await sdk.getVault({
path: { network: 'mainnet', vaultAddress: '0xinvalid' }
})
} catch (error) {
if (error instanceof HttpResponseError) {
console.error(`API error ${error.statusCode}: ${error.message}`)
}
}
```
```python Python theme={null}
from vaultsfyi import VaultsSdk
from vaultsfyi.exceptions import (
AuthenticationError,
ForbiddenError,
RateLimitError,
HttpResponseError,
NetworkError,
)
try:
vault = client.get_vault(
network="mainnet",
vault_address="0xinvalid",
)
except AuthenticationError:
print("Invalid or missing API key")
except ForbiddenError:
print("API key has exhausted available credits")
except RateLimitError:
print("Rate limit exceeded — slow down requests")
except HttpResponseError as e:
print(f"API error {e.status_code}: {e}")
except NetworkError:
print("Network connectivity issue")
```
The Python SDK exposes five exception classes, all inheriting from `VaultsFyiError`:
| Exception | Cause |
| - | - |
| `HttpResponseError` | Any non-2xx HTTP response |
| `AuthenticationError` | Invalid or missing API key |
| `ForbiddenError` | API key has exhausted available credits |
| `RateLimitError` | Too many requests |
| `NetworkError` | Connection or timeout failure |
***
## TypeScript types
The TypeScript SDK ships full type definitions generated from the OpenAPI spec. All response types are inferred automatically — no manual casting required.
```typescript theme={null}
// Types are inferred from the API spec
const vaults = await sdk.getAllVaults() // DetailedVault[]
const vault = await sdk.getVault({ … }) // DetailedVault
```
# Build DeFi Yield Analytics with Vaults.fyi
Source: https://docs.vaults.fyi/sdk/tutorials/data-analytics
Learn how to fetch vault data, retrieve historical APY and TVL, compare against benchmarks, and build charts or reports using the Vaults.fyi SDK.
This tutorial shows you how to use the Vaults.fyi SDK to power a data analytics workflow: fetching and filtering vault listings, pulling historical time-series data, comparing APY against benchmark rates, and assembling the results into a report or chart.
This pattern is useful for dashboards, research tools, protocol monitoring, and any application that needs standardized DeFi yield data across multiple protocols.
All code examples use the TypeScript SDK (`@vaultsfyi/sdk`). The Python SDK exposes the same functionality using snake\_case method names. See the [SDK Reference](/sdk/reference) for both.
## Initialize the client
```javascript analytics.js theme={null}
import pkg from '@vaultsfyi/sdk';
const { VaultsSdk } = pkg;
const sdk = new VaultsSdk({
apiKey: process.env.VAULTS_FYI_API_KEY,
});
```
***
## Step 1: Fetch and filter vault listings
Use `getAllVaults` to retrieve available vaults. Apply filters to narrow results by network, protocol, asset, or TVL range. Use `page` and `perPage` to paginate through large result sets.
```javascript analytics.js theme={null}
async function fetchVaults() {
const vaults = await sdk.getAllVaults({
query: {
page: 0,
perPage: 100,
allowedNetworks: ['mainnet', 'polygon', 'arbitrum'],
allowedAssets: ['USDC', 'USDT', 'DAI'],
minTvl: 5000000, // at least $5M TVL
onlyTransactional: false
}
});
return vaults;
}
```
Each vault in the response includes its protocol name, asset, network, current APY, TVL, and whether transactional support is available. Use these fields to build filters, sort orders, or summary tables.
Set `minTvl` to exclude low-liquidity vaults from analytics. Vaults with very low TVL often have volatile APY data that can skew aggregated metrics.
***
## Step 2: Fetch historical APY and TVL data
Once you have a vault of interest, use the historical data methods to pull time-series metrics. Choose between the combined endpoint or the lighter focused endpoints depending on what you need.
### Fetch combined APY and TVL history
```javascript analytics.js theme={null}
async function fetchVaultHistory(network, vaultAddress) {
// Unix timestamps for a 90-day window
const toTimestamp = Math.floor(Date.now() / 1000);
const fromTimestamp = toTimestamp - 90 * 24 * 60 * 60;
const history = await sdk.getVaultHistoricalData({
path: { network, vaultAddress },
query: {
page: 0,
perPage: 365,
apyInterval: '7day', // 7-day rolling average APY
fromTimestamp,
toTimestamp
}
});
return history;
}
```
The `apyInterval` parameter controls the smoothing window for APY values. Use `'1day'` for precise daily readings, `'7day'` for a weekly moving average, or `'30day'` for a longer-term trend line.
### Fetch APY-only history
Use `getVaultHistoricalApy` when you only need APY data and want a lighter API response.
```javascript analytics.js theme={null}
async function fetchApyHistory(network, vaultAddress) {
const toTimestamp = Math.floor(Date.now() / 1000);
const fromTimestamp = toTimestamp - 30 * 24 * 60 * 60; // last 30 days
const apyHistory = await sdk.getVaultHistoricalApy({
path: { network, vaultAddress },
query: {
page: 0,
perPage: 100,
fromTimestamp,
toTimestamp
}
});
return apyHistory;
}
```
### Fetch TVL-only history
Use `getVaultHistoricalTvl` to track capital flow into and out of a vault over time.
```javascript analytics.js theme={null}
async function fetchTvlHistory(network, vaultAddress) {
const toTimestamp = Math.floor(Date.now() / 1000);
const fromTimestamp = toTimestamp - 30 * 24 * 60 * 60;
const tvlHistory = await sdk.getVaultHistoricalTvl({
path: { network, vaultAddress },
query: {
page: 0,
perPage: 100,
fromTimestamp,
toTimestamp
}
});
return tvlHistory;
}
```
***
## Step 3: Compare against benchmark rates
Benchmark rates let you put vault APY in context. Use `getBenchmarks` to retrieve the current reference rate, and `getHistoricalBenchmarks` to overlay it on your APY chart.
### Fetch current benchmarks
```javascript analytics.js theme={null}
async function fetchBenchmarks(network) {
const benchmarks = await sdk.getBenchmarks({
path: { network },
query: { code: 'usd' } // 'usd' or 'eth'
});
return benchmarks;
}
```
### Fetch historical benchmarks
```javascript analytics.js theme={null}
async function fetchHistoricalBenchmarks(network) {
const toTimestamp = Math.floor(Date.now() / 1000);
const fromTimestamp = toTimestamp - 90 * 24 * 60 * 60;
const historicalBenchmarks = await sdk.getHistoricalBenchmarks({
path: { network },
query: {
code: 'usd',
page: 0,
perPage: 365,
fromTimestamp,
toTimestamp
}
});
return historicalBenchmarks;
}
```
Use the benchmark series as a baseline series in your chart alongside vault APY, making it easy to see when a vault outperforms or underperforms the reference rate.
***
## Step 4: Assemble a vault report
Combine the methods above to build a complete snapshot for a single vault. The example below fetches current data, 30-day APY history, and the benchmark comparison in parallel.
```javascript analytics.js theme={null}
async function buildVaultReport(network, vaultAddress) {
const [vault, apyHistory, benchmarks] = await Promise.all([
sdk.getVault({ path: { network, vaultAddress } }),
sdk.getVaultHistoricalApy({
path: { network, vaultAddress },
query: {
page: 0,
perPage: 100,
fromTimestamp: Math.floor(Date.now() / 1000) - 30 * 24 * 60 * 60,
toTimestamp: Math.floor(Date.now() / 1000)
}
}),
sdk.getBenchmarks({
path: { network },
query: { code: 'usd' }
})
]);
return {
name: vault.name,
protocol: vault.protocol,
asset: vault.asset,
currentApy: vault.apy,
tvl: vault.tvl,
apyHistory: apyHistory,
benchmarkRate: benchmarks
};
}
```
Use `Promise.all` to fetch independent data in parallel. Fetching vault details, APY history, and benchmarks concurrently cuts total latency by up to two-thirds compared to sequential calls.
***
## Step 5: Handle errors and pagination
Wrap API calls in error handling and iterate over pages for large data sets.
### Error handling
```javascript analytics.js theme={null}
import { VaultsSdk, HttpResponseError } from '@vaultsfyi/sdk';
try {
const vaults = await sdk.getAllVaults({ query: { page: 0, perPage: 100 } });
} catch (error) {
if (error instanceof HttpResponseError) {
console.error(`API error ${error.message}`);
} else {
throw error;
}
}
```
### Paginating through all vaults
```javascript analytics.js theme={null}
async function fetchAllVaults() {
const allVaults = [];
let page = 0;
const perPage = 100;
while (true) {
const result = await sdk.getAllVaults({
query: { page, perPage, minTvl: 1000000 }
});
allVaults.push(...result);
// Stop when a page returns fewer results than requested
if (result.length < perPage) break;
page += 1;
}
return allVaults;
}
```
***
## What to build next
With vault listings, historical data, and benchmarks in hand, you can:
* **Render an APY chart** — plot `apyHistory` as a line series with `historicalBenchmarks` as a reference line using any charting library (Recharts, Chart.js, Observable Plot).
* **Build a protocol leaderboard** — sort vaults by 30-day average APY or by TVL growth to identify top-performing strategies.
* **Track historical share price** — use `getVaultHistoricalSharePrice` to calculate compounded returns over any period for a more accurate performance metric than raw APY.
* **Export to CSV or JSON** — serialize the assembled report into a flat file for use in spreadsheets, notebooks, or downstream data pipelines.
See the [SDK Reference](/sdk/reference) for the full parameter and response documentation for every method used in this tutorial.
# Add Yield to a Wallet App with Vaults.fyi
Source: https://docs.vaults.fyi/sdk/tutorials/wallet-integration
Learn how to detect idle assets, surface deposit options, execute vault transactions, and track user positions in a wallet integration.
This tutorial walks you through building a yield integration for a wallet application. You will detect idle assets in a user's wallet, show them personalized deposit opportunities, prepare and execute a deposit transaction, and then track the resulting position.
The full example code is available in the official tutorial repositories:
```bash javascript theme={null}
git clone https://github.com/WallfacerLabs/js-examples.git
```
```bash python theme={null}
git clone https://github.com/WallfacerLabs/python-examples.git
```
## Run the example
```bash javascript theme={null}
cd js-examples/
npm install
```
```bash python theme={null}
cd python_examples/
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
```
```bash theme={null}
export VAULTS_FYI_API_KEY="your_api_key_here"
```
```bash javascript theme={null}
npm run wallet_integration
```
```bash python theme={null}
python wallet_integration.py
```
***
## Step-by-step walkthrough
### 1. Initialize the SDK
Create the client once and reuse it across all calls.
```javascript index.js theme={null}
import pkg from '@vaultsfyi/sdk';
const { VaultsSdk } = pkg;
const vaultsFyi = new VaultsSdk({
apiKey: process.env.VAULTS_FYI_API_KEY,
});
```
```python main.py theme={null}
import os
from vaultsfyi import VaultsSdk
client = VaultsSdk(api_key=os.getenv("VAULTS_FYI_API_KEY"))
```
### 2. Detect idle assets
Call `getIdleAssets` to find tokens sitting in a wallet that are not currently earning yield. This is the starting point for any yield nudge or suggestion UI.
```javascript index.js theme={null}
async function getUserBalances(userAddress) {
const idleAssets = await vaultsFyi.getIdleAssets({
path: { userAddress }
});
return idleAssets;
}
```
```python main.py theme={null}
def get_user_balances(user_address):
idle_assets = client.get_idle_assets(user_address)
return idle_assets
```
The response includes each asset's symbol, balance, and USD value. Use this data to decide which assets to surface deposit options for.
Filter out assets below a minimum USD threshold before presenting options to the user. Small balances often produce high gas costs relative to yield earned.
### 3. Get personalized deposit options
Call `getDepositOptions` with a list of assets the user holds. The API returns ranked vault opportunities filtered to those assets, sorted by APY.
```javascript index.js theme={null}
async function getBestDepositOptions(userAddress) {
const depositOptions = await vaultsFyi.getDepositOptions({
path: { userAddress },
query: { allowedAssets: ['USDC', 'USDS'] }
});
return depositOptions;
}
```
```python main.py theme={null}
def get_best_deposit_options(user_address):
deposit_options = client.get_deposit_options(
user_address,
allowed_assets=["USDC", "USDS"]
)
return deposit_options
```
Each option in the response includes the vault address, network, protocol name, current APY, and TVL — everything you need to render a yield card in your UI.
### 4. Check transaction context
Before building a deposit transaction, call `getTransactionsContext` to confirm the vault is ready to accept a deposit. The response tells you which steps are required (for example, an ERC-20 approval before the deposit itself) and the current deposit limits.
```javascript index.js theme={null}
async function getTransactionContext(userAddress, network, vaultAddress) {
const context = await vaultsFyi.getTransactionsContext({
path: { userAddress, network, vaultAddress }
});
return context;
}
```
```python main.py theme={null}
def get_transaction_context(user_address, network, vault_address):
context = client.get_transactions_context(
user_address=user_address,
network=network,
vault_address=vault_address
)
return context
```
### 5. Build the deposit transaction
Call `getActions` with `action: 'deposit'` to receive ready-to-sign transaction calldata. Pass the calldata directly to the user's wallet or signer library — no intermediate contract needed.
```javascript index.js theme={null}
async function generateDepositTransaction(
userAddress,
network,
vaultAddress,
assetAddress,
amount
) {
const transaction = await vaultsFyi.getActions({
path: {
action: 'deposit',
userAddress,
network,
vaultAddress
},
query: {
amount,
assetAddress
}
});
return transaction;
}
```
```python main.py theme={null}
def generate_deposit_transaction(
user_address, network, vault_address, asset_address, amount
):
transaction = client.get_actions(
action="deposit",
user_address=user_address,
network=network,
vault_address=vault_address,
amount=amount,
asset_address=asset_address,
)
return transaction
```
`getActions` may return multiple steps when an approval is required before the deposit. Execute each step in order using the user's wallet.
Always call `getTransactionsContext` before `getActions`. Skipping the context check can result in failed transactions if deposit limits are reached or approvals are stale.
### 6. Track the user's position
After the deposit confirms onchain, call `getPositions` to retrieve the user's updated vault positions. Display the balance, current APY, and accumulated returns in your portfolio view.
```javascript index.js theme={null}
async function getUserPositions(userAddress) {
const positions = await vaultsFyi.getPositions({
path: { userAddress }
});
return positions;
}
```
```python main.py theme={null}
def get_user_positions(user_address):
positions = client.get_positions(user_address)
return positions
```
To show total earnings for a specific vault, use `getUserVaultTotalReturns` with the same `userAddress`, `network`, and `vaultAddress`.
***
## What to build next
* Surface pending rewards with `getRewardsTransactionsContext` and let users claim in one tap using `getRewardsClaimActions`.
* Show per-vault event history (deposits and withdrawals) with `getUserVaultEvents`.
* Compare the vault's current APY against benchmark rates using `getBenchmarks` to give users context on whether the yield is competitive.
See the [SDK Reference](/sdk/reference) for full parameter details on every method used in this tutorial.
# Embeddable Widget
Source: https://docs.vaults.fyi/use-cases/embeddable-widget
Add a branded yield experience to your app with curated vault discovery, transactions, and position views.
The vaults.fyi widget gives wallets, exchanges, and consumer apps a configurable interface for surfacing yield opportunities, supporting user actions, and showing positions.
The widget is currently available to select partners. [Contact us](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) to learn more.
## Widget vs. API or SDK
Use the widget when you want a branded Earn experience without designing every vault list, deposit form, position view, and transaction state yourself. Use the API or SDK when you want full control over the interface and business logic.
| Integration path | Best for |
| - | - |
| Embeddable widget | Branded Earn surfaces, partner launches, curated vault lists, portfolio views, and transaction-ready flows with less product and frontend work |
| API or SDK | Fully custom discovery, routing, portfolio, transaction, attribution, or analytics experiences built inside your own application |
## A yield experience configured for your product
Choose the opportunity set that fits your users. Configure:
* `allowedNetworks`, including EVM networks and Solana/SVM coverage
* `allowedAssets`, `allowedProtocols`, `allowedVaults`, curators, and tags
* `minTvlUsd`, `minReputationScore`, and APY filters
* APY window, sort order, and number of opportunities shown
* Discover and Positions views
* Visible columns and data displayed in each view
Surface a focused set of vault opportunities from 80+ protocols, 20+ EVM chains, and Solana/SVM coverage.
## Match your product’s brand
Configure the widget’s presentation to fit your application:
* Light or dark mode
* Accent color
* Font and corner radius
* Widget title
* Optional vaults.fyi attribution
* Visible columns for APY, TVL, protocol, curator, score, redemption type, balances, and returns
## Support discovery, positions, and transactions
The widget can present a compact Discover experience, a user’s existing positions, or both.
For transaction-enabled integrations, it supports host-controlled signing and custody handoff flows. Your product keeps control of the wallet experience while vaults.fyi provides the underlying opportunity data and transaction context.
## How integration works
Choose the networks, assets, protocols, vaults, curators, tags, TVL thresholds, reputation score threshold, APY window, sort order, and views available in the widget.
Set the theme, accent color, font, corner radius, widget title, attribution preference, and visible data fields.
Add the generated embed code or React component to your app. Your team controls where the widget appears and which mode is shown.
Let the widget use the connected wallet context or pass the relevant wallet state from your host app, including EVM and Solana accounts where supported.
For live transaction flows, vaults.fyi provides the opportunity data and transaction context while your product controls signing, broadcasting, and custody handoff.
## Non-custodial by design
Vaults.fyi does not custody user funds. Transaction-enabled widget flows use vaults.fyi infrastructure for data and transaction preparation, while your app keeps control of the wallet experience. Users sign with their own wallet, and funds route to the target protocol contracts.
## Built on vaults.fyi coverage
The widget uses vaults.fyi’s normalized vault data and transaction infrastructure across supported EVM networks and Solana/SVM coverage. Teams can keep their interface focused while extending coverage as their product grows.
## Get the widget
[Contact us](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) to learn more. Include the target users, chains and assets, desired views, wallet model, signing or custody requirements, and brand constraints you want the widget to support.
Our team can help you create a branded Earn experience.
# DeFi Yield Data and Analytics for Researchers
Source: https://docs.vaults.fyi/use-cases/for-analysts
Query standardized APY, TVL, the Reputation Score, and benchmark rates across 1,000+ vaults. No blockchain parsing — clean, normalized data via REST API.
Vaults.fyi delivers clean, standardized metrics so you can focus on analysis instead of data wrangling. You get normalized historical and real-time APY, TVL, utilization rates, and the Reputation Score across 1,000+ vaults — sourced directly from onchain contracts and updated hourly.
## Why it matters
Most yield analysis starts with data cleanup: protocols report APY differently, rewards are often separated from base yield, and historical TVL or share-price data is not always easy to compare. Vaults.fyi normalizes the market into one queryable dataset.
Use Vaults.fyi to:
* Compare base APY, reward APY, and total APY across 1 hour, 1 day, 7 day, and 30 day windows.
* Pull historical APY, TVL, and benchmark data without running your own indexers.
* Screen vaults by reputation score, active warnings, curator, protocol, asset, network, capacity, or TVL.
* Build dashboards, research notes, and allocator reports from a consistent data model.
## What data is available
Access total APY split into base yield and reward token components. Compare net yields across protocols on a like-for-like basis.
Pull daily APY and TVL history for any vault. Build backtests, identify yield cycles, and track how protocols respond to market conditions.
Query the Vaults.fyi USD and ETH benchmark rates — aggregated risk-adjusted reference yields for stablecoin and ETH strategies.
Each vault carries a reputation score based on longevity, TVL stability, yield volatility, and underlying asset health. Use it to filter out high-risk outliers.
## Key endpoints for analysis
| Endpoint | What it returns |
| - | - |
| `GET /v2/detailed-vaults` | Current APY, TVL, fees, rewards, and reputation score for all vaults. Filterable by asset, network, protocol. |
| `GET /v2/historical/{network}/{vaultAddress}` | Daily APY and TVL time series for a specific vault. |
| `GET /v2/benchmarks/{network}` | USD and ETH benchmark reference rates over time. |
| `GET /v2/portfolio/positions/{userAddress}` | Wallet-level positions and flow data across DeFi. |
## Fetch historical vault data
```python python theme={null}
import requests
import time
API_KEY = "your_api_key"
VAULT_ADDRESS = "0xBEEF..."
NETWORK = "mainnet"
to_ts = int(time.time())
from_ts = to_ts - 90 * 24 * 60 * 60 # 90 days
response = requests.get(
f"https://api.vaults.fyi/v2/historical/{NETWORK}/{VAULT_ADDRESS}/apy",
params={
"fromTimestamp": from_ts,
"toTimestamp": to_ts,
"perPage": 100,
},
headers={"Authorization": f"Bearer {API_KEY}"},
)
data = response.json()
for entry in data["data"]:
print(entry["timestamp"], entry["apy"]["total"])
```
```javascript javascript theme={null}
const API_KEY = "your_api_key";
const VAULT_ADDRESS = "0xBEEF...";
const NETWORK = "mainnet";
const toTs = Math.floor(Date.now() / 1000);
const fromTs = toTs - 90 * 24 * 60 * 60; // 90 days
const response = await fetch(
`https://api.vaults.fyi/v2/historical/${NETWORK}/${VAULT_ADDRESS}/apy?` +
new URLSearchParams({
fromTimestamp: fromTs,
toTimestamp: toTs,
perPage: 100,
}),
{
headers: { Authorization: `Bearer ${API_KEY}` },
}
);
const data = await response.json();
for (const entry of data.data) {
console.log(entry.timestamp, entry.apy.total);
}
```
The `apy.total` field is the net annualized yield. Use `apy.base` and `apy.rewards` to separate native protocol yield from token incentives.
## Cross-protocol comparison
Because Vaults.fyi normalizes data across protocols, you can make direct comparisons that would otherwise require building per-protocol adapters. APY calculations follow a standardized [methodology](/methodology/calculating-apy) so the numbers mean the same thing regardless of the underlying protocol.
Use cases this enables:
* **Benchmark analysis** — compare a specific vault's yield against the Vaults.fyi USD benchmark rate to assess relative performance
* **Protocol health monitoring** — track TVL inflows and outflows across competing protocols over time
* **Risk-adjusted screening** — filter vaults by reputation score to identify strategies worth tracking
## Flows and position data
Beyond vault-level metrics, you can query wallet-level position data to analyze where capital is flowing across DeFi. This includes stablecoin, ETH, and ERC-20 positions held in yield strategies, along with estimated returns per position.
Push data directly into your analytics stack (Databricks, BigQuery, etc.) using the REST API on a scheduled basis. The API supports pagination for bulk historical pulls.
## Interactive exploration
Explore the data without writing code using the [analytics dashboard](https://app.vaults.fyi/analytics). It surfaces yield trends, protocol comparisons, and benchmark charts built on the same underlying API.
Need more API access or higher rate limits? [Sign up](https://portal.vaults.fyi/signup) for Pay-As-You-Go access with no commitments. For custom metrics or specific vault coverage, [submit interest](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) and the team will follow up.
# Get Your Vaults Discovered and Integrated
Source: https://docs.vaults.fyi/use-cases/for-protocols
List your DeFi vaults on Vaults.fyi to reach wallets, apps, and analysts. Earn attribution, monitor integration performance, and improve discovery.
Vaults.fyi is the distribution layer that connects DeFi protocols to the wallets and apps their users already trust. When your vaults are indexed by Vaults.fyi, they become accessible to every integration built on the API — including ecosystem surfaces like [Arbitrum Earn](/resources/case-studies/arbitrum), wallets like Kraken Wallet, aggregators like Jumper Earn, and analytics tools used by researchers and asset managers.
## Why it matters
Protocols need distribution, but partners need more than a vault address. They need APY methodology, risk context, transaction support, and a way to measure the capital they drive. Vaults.fyi packages that information in one integration.
Use Vaults.fyi to:
* Make vaults discoverable through wallets, apps, analytics tools, and agent workflows.
* Give integrators standardized APY, TVL, fees, rewards, curator, and risk fields.
* Show performance relative to market benchmark rates.
* Measure attributed deposits, withdrawals, and retained TVL from partner surfaces.
## How your vaults get discovered
Vaults.fyi indexes yield strategies directly from onchain contracts. Once your vault meets the inclusion criteria, it appears in API responses for any application querying for vaults by asset, network, or protocol.
Your vaults appear in `GET /v2/detailed-vaults` responses. Any developer building on the API can filter, rank, and surface your vaults to their users.
Wallets and consumer apps that use Vaults.fyi for yield discovery automatically include your vaults in their product — no separate partnership required.
Researchers and analysts querying DeFi yield data will see your vaults alongside competitors, with standardized metrics that make comparison straightforward.
Track how much volume flows into your vaults through Vaults.fyi integrations. Understand which wallets and apps are driving deposits.
## Vault inclusion criteria
Vaults.fyi indexes vaults that meet a baseline quality threshold. Factors considered include:
* **Audit status** — vaults should have a public audit by a recognized security firm
* **Minimum TVL** — a meaningful TVL floor filters out inactive or test deployments
* **Contract verification** — onchain contract code must be verified and readable
* **Asset support** — the underlying asset must be a recognized stablecoin, ETH, or major ERC-20
Inclusion is not guaranteed and Vaults.fyi reserves the right to exclude vaults that pose material risk to users. If your vault has been excluded and you believe it meets the criteria, [contact us](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) to discuss.
## Reputation scores
Every indexed vault receives a reputation score that signals its relative safety and reliability to integrators and users. The score is calculated from:
* **Longevity** — how long the vault has been live onchain
* **TVL trajectory** — whether TVL has been stable, growing, or declining
* **Yield volatility** — how much APY fluctuates over time
* **Underlying asset health** — the risk profile of the assets held in the vault
A higher reputation score means your vault is more likely to be surfaced in filtered discovery flows (for example, when a wallet only shows vaults above a certain score). Improving vault stability and longevity over time naturally improves the score.
You can query your own vault's reputation score at any time using `GET /v2/detailed-vaults` filtered by your vault address. Use this to monitor how your score changes as your vault matures.
## Position data and portfolio intelligence
Vaults.fyi tracks wallet-level positions inside your vaults. This means users who deposit through any Vaults.fyi-powered integration can see their position, accrued returns, and estimated APY in the portfolio view — with your vault correctly attributed.
Protocols can use the same portfolio endpoints to:
* Understand the distribution of user positions in their vaults
* Identify large depositors across integrated wallets
* Measure user retention and redemption patterns
## Benchmark performance context
Your vault's yield is displayed alongside the [Vaults.fyi USD benchmark rate](/methodology/benchmark-rates) — the risk-adjusted reference rate for DeFi stablecoin strategies. This gives users and analysts immediate context for whether your vault is outperforming or underperforming the market.
Performing above the benchmark is a signal that surfaces well in discovery flows and analyst workflows. Methodology for APY calculation is [fully documented](/methodology/calculating-apy) so you can verify how your vault's yield is represented.
## Getting listed
Review the vault requirements above and confirm your vault is audited, verified onchain, and has meaningful TVL.
[Sign up](https://portal.vaults.fyi/signup) and submit your vault addresses, networks, and audit links. The team will confirm eligibility and expected timeline.
Once indexed, query `GET /v2/detailed-vaults` with your vault address to confirm it appears with correct APY, TVL, and metadata.
Use the analytics endpoints to track deposit volume, position counts, and which integrations are driving activity to your vaults.
If you are a protocol or product team and want to discuss a deeper integration — including co-marketing with wallet partners — [contact us](https://vaultsfyi.fillout.com/t/tLA9t6HyAFus) to collaborate.
# Embed Yield and Borrowing in Wallets and Consumer Apps
Source: https://docs.vaults.fyi/use-cases/for-wallets-and-apps
Give users earn and borrow features with the data, risk context, transaction payloads, portfolio tracking, attribution, and fee logic your team needs.
Vaults.fyi gives wallets, exchanges, neobanks, fintech apps, portfolio tools, and aggregators the building blocks for embedded earn and borrow experiences across 80+ protocols, 20+ EVM chains, and Solana/SVM vault coverage in Beta. Use normalized vault and market data as the foundation, then add transaction payloads, portfolio tracking, borrowing views, attribution, or fee logic as your product evolves.
## Why it matters
Consumer platforms already have the user relationship, asset context, and trust surface for earn and borrow features. The hard part is turning fragmented DeFi markets into product-safe options: which opportunities to show, how to explain them, how to route the user, and how to track what happens after capital moves.
Vaults.fyi gives your team the components to do that without rebuilding the market stack. Start with ranked vaults, APY windows, TVL, protocol metadata, rewards, fees, capacity, and risk/return context. Then add the workflows that matter for your roadmap: non-custodial execution, portfolio tracking, TVL attribution, borrowing views, and monetization.
Use Vaults.fyi to:
* Match yield opportunities to the assets a user already holds.
* Filter out vaults that do not meet your risk/return policy.
* Compare APY, TVL, fees, rewards, capacity, curators, networks, and protocols with one schema.
* Prepare non-custodial transactions for deposits, withdrawals, and reward claims when you want execution.
* Show position balances, returns, and history when you want portfolio tracking.
* Measure retained TVL when you want partner reporting, rebates, or commercial attribution.
## What you can build
Surface ranked vault opportunities filtered by asset, network, APY, and reputation score. Users see exactly where their idle funds can earn.
Launch a branded Earn surface with curated discovery, positions, and transaction-ready flows without designing the full UI from scratch.
Build discovery screens, internal allowlists, comparison tables, or routing logic from normalized vault data without adding transactions.
Generate ready-to-sign deposit and redeem payloads for any supported vault. Transactions go directly from the user's wallet to the target protocol.
Show users their current positions, accrued returns, and PnL across all yield strategies they've entered through your app.
Show borrow markets, supplied and borrowed positions, risk metrics, and supported supply, withdraw, borrow, and repay actions.
Track the deposits, withdrawals, and retained TVL your app drives into each vault, protocol, curator, and network.
Attach flat or percentage-based fees to deposit and withdrawal transactions. Configure fee logic through the API without touching smart contracts.
## How integration works
Most teams start by fetching vault data. The later steps are optional modules you can add when your product needs execution, attribution, portfolio tracking, or borrowing.
Call `GET /v2/detailed-vaults` to retrieve a filtered, ranked list of vaults with APY, TVL, the Reputation Score, and protocol metadata. Apply filters for asset, network, or minimum reputation score to match your users' needs.
Call the transactions endpoint with the vault address, user wallet, and deposit amount. The API returns a ready-to-sign payload with no intermediary contracts involved.
Pass the payload to the user's wallet for signing. Your app broadcasts the transaction. The user interacts directly with the target protocol.
Transactions generated through Vaults.fyi include TVL tracking automatically, so you can measure retained balances and vault-level flows in portal.vaults.fyi. If you build vault transactions yourself, append a free attribution suffix instead. Learn more in [TVL Attribution](/concepts/tvl-attribution).
Use the portfolio endpoints to display the user's current balance in each vault, yield earned since deposit, and estimated annual return.
Use the Beta borrowing API to show supported borrow markets, supplied and borrowed positions, risk metrics, and available supply, withdraw, borrow, or repay actions.
## Non-custodial by design
All transaction payloads route funds directly from the user's wallet to the target protocol. Vaults.fyi never holds or controls user funds. This means:
* No intermediary smart contracts inflating gas costs
* Fewer attack surfaces compared to proxy or aggregator architectures
* Full UX control stays with your app
Both externally owned accounts (EOAs) and smart wallets are supported. For smart wallets, you can bundle fee transactions with the user's deposit in a single atomic operation.
## Monetize yield integrations
You can attach fees to any deposit or withdrawal routed through your app. The API supports multiple fee structures so you can design the model that fits your business.
Charge a fixed amount per deposit or withdrawal, regardless of transaction size.
Take a percentage of yield earned over time, aligning your revenue with user outcomes.
Fee logic is implemented directly in the API payload. No custom smart contract development required. For bespoke fee modules, the Vaults.fyi team works with you to design and validate the implementation.
With EIP-7702, you can implement fee flows for traditional EOAs without requiring users to migrate to a smart wallet. This expands your monetization reach across all wallet types.
## Who's already using this
[Arbitrum Earn](/resources/case-studies/arbitrum) uses Vaults.fyi to bring native yield discovery and execution into the Arbitrum Portal. [Kraken Wallet](https://www.kraken.com/wallet) surfaces yield opportunities directly inside the wallet interface, while [Jumper Earn](https://jumper.exchange/) integrates the same API to power its cross-chain yield aggregation experience.
[Sign up](https://portal.vaults.fyi/signup) to get API access. Pricing details are on the [Plans](/plans/overview) page.
# Why use Vaults.fyi?
Source: https://docs.vaults.fyi/why-vaultsfyi
Use one API for DeFi earn and borrow data, risk context, transaction preparation, portfolio tracking, TVL attribution, fees, and agent workflows.
Vaults.fyi is the API layer for onchain earn and borrow features. Use one integration to discover vaults, compare risk/return, prepare non-custodial transactions, track portfolios, measure attributed TVL, and support borrow workflows across 1,000+ strategies, 80+ protocols, 20+ EVM chains, and Solana/SVM vault coverage in Beta.
Use Vaults.fyi when your product needs to do more than show APYs: decide which vaults and markets are eligible, explain why they matter, route users into deposits, withdrawals, borrows, or repayments, and report what happened after capital moved.
## What Vaults.fyi replaces
Query one schema instead of maintaining custom adapters, transaction builders, and data pipelines for every protocol.
Compare APY, TVL, fees, rewards, capacity, and vault metadata using a normalized methodology across protocols and chains.
Use reputation scores, warnings, flags, holder data, curator metadata, and benchmark context before surfacing a vault.
Track positions, returns, reward balances, borrow activity, history, idle assets, and attributed TVL after users take action.
## Who it's for
Add earn and borrow features to wallets, exchanges, neobanks, fintech apps, portfolio tools, and aggregators that already hold user balances or wallet context.
* Turn idle balances and wallet context into relevant earn and borrow options.
* Generate revenue through configurable fees on earn and borrow flows when they fit your product and partner model.
* Curate the right options with current and historical APY, TVL, protocol details, rewards, fees, capacity, and risk/return context.
* Let users deposit, withdraw, claim rewards, borrow, and repay from your app without taking custody.
* Keep users informed after deposit or borrow actions by showing positions, returns, rewards, borrow activity, and history.
* Understand which products, partners, and integrations drive retained TVL and repeat activity.
[See the wallets and apps guide](/use-cases/for-wallets-and-apps).
Use clean DeFi yield data without building an indexing stack.
* Query standardized APY, TVL, fees, rewards, and vault metadata across the market.
* Separate base yield from reward APY across 1-hour, 1-day, 7-day, and 30-day windows.
* Pull historical APY, TVL, and share-price data for analysis, dashboards, and reporting.
* Compare vaults against USD and ETH benchmark rates.
* Filter by reputation score, warnings, asset, network, protocol, curator, TVL, or capacity.
[See the analysts guide](/use-cases/for-analysts).
Help wallets, apps, analysts, and agents understand your vaults without every partner rebuilding your metadata, yield, risk, and attribution stack.
* Surface vaults through API integrations used by wallets, apps, and dashboards.
* Provide standardized vault metadata, APY, TVL, fees, rewards, and risk context to integrators.
* Track attributed deposits, withdrawals, and retained TVL from partner surfaces.
* Show performance against market benchmarks.
* Give partners the data they need to explain the vault before a user deposits.
[See the protocols guide](/use-cases/for-protocols).
Give agents a structured yield toolset instead of fragmented protocol-specific integrations.
* Discover vaults and compare risk/return with structured filters.
* Fetch vault detail, history, benchmarks, portfolio state, and transaction context.
* Prepare transaction payloads for user approval.
* Use the hosted MCP server for tool-based workflows.
* Use x402 for keyless, pay-per-request access.
[See the AI and agents guide](/ai-agents/overview).
## Core capabilities
| Capability | What you get |
| - | - |
| Market data | APY, TVL, fees, rewards, capacity, assets, protocols, curators, networks, and vault metadata. |
| Risk/return context | Reputation scores, component scores, warnings, flags, holder data, benchmarks, and historical context. |
| Borrowing | Borrow markets, supplied and borrowed positions, risk metrics, and supported supply, withdraw, borrow, and repay actions. |
| Transactions | Ready-to-sign payloads for deposits, redemptions, withdrawals, reward claims, and supported borrow actions with no Vaults.fyi wrapper contract. |
| Portfolio | Wallet-level positions, returns, history, idle assets, deposit options, and borrow activity. |
| Attribution and fees | Partner-level tracking and configurable fees for earn and borrow flows, including deposits, withdrawals, retained TVL, vaults, protocols, curators, networks, and assets. Use them for reporting, rebates, fee programs, and commercial discussions. |
| Agent access | Hosted MCP server and x402 access for autonomous workflows. |
## Start small, then scale
Start with API key access and the SDKs for a single workflow, or use x402 pay-per-request access for keyless agent workflows. Teams can move from a small data integration to transactions, portfolio tracking, borrowing, fees, and attribution without changing providers.
For products that route deposits or borrow actions, attribution provides a shared record of retained TVL and user flows by vault, protocol, curator, network, and asset. Use it for partner reporting, rebate programs, fee programs, and commercial discussions without adding custody or wrapper contracts.
## Trusted integrations
Teams including [Arbitrum Earn](/resources/case-studies/arbitrum), [Jumper Earn](/resources/case-studies/jumper-earn), [Kraken Wallet](/resources/case-studies/kraken-wallet), [Gauntlet](/resources/case-studies/gauntlet), [Maple Finance](/resources/case-studies/maple-finance), and [KPK](/resources/case-studies/kpk) use Vaults.fyi for yield analytics, dashboards, transaction flows, and portfolio infrastructure.
Review the endpoint groups for vault data, transactions, portfolios, benchmarks, and near real-time state.
Install the TypeScript or Python SDK and make your first request in minutes.
Add a branded Earn experience with curated discovery, positions, and transaction-ready flows.
