diff --git a/skills/zerion-vaultsfyi-deposit/SKILL.md b/skills/zerion-vaultsfyi-deposit/SKILL.md new file mode 100644 index 00000000..b40de60f --- /dev/null +++ b/skills/zerion-vaultsfyi-deposit/SKILL.md @@ -0,0 +1,163 @@ +--- +name: zerion-vaultsfyi-deposit +description: > + Research a DeFi vault using vaults.fyi due diligence (risk, performance, fees, benchmarks), build a deposit transaction via vaults.fyi with pre-flight safety checks, and use Zerion CLI for asset acquisition and post-deposit verification. +license: MIT +--- + +# vaults.fyi Safe Deposit + +**Purpose:** Run vault due diligence via vaults.fyi and execute deposits through Zerion CLI, with safety gates that block critical-flagged vaults and require explicit approval for warned ones. + +## When to use +- "Deposit into [vault name] on [network]" +- "Is this vault safe to deposit into?" +- "Put my USDC into Morpho on Base" +- "Research this vault before I deposit" +- "Stake into a yield vault" +- Any request to deposit, enter, or stake into a specific DeFi vault with a safety or due diligence step + +## Key Commands +- `zerion portfolio
` — check current holdings and balances +- `zerion positions
` — see existing DeFi positions +- `zerion swap ` — swap into the vault's deposit asset if needed +- `zerion bridge ` — bridge assets cross-chain +- vaults.fyi MCP: `vault_details` — full vault metadata, score, flags, fees, curator +- vaults.fyi MCP: `vault_apy_history` — historical APY over 30 days +- vaults.fyi MCP: `vault_tvl_history` — historical TVL over 30 days +- vaults.fyi MCP: `benchmark_apy` — network benchmark rate for comparison +- vaults.fyi MCP: `transaction_context` — deposit asset, decimals, wallet balance, available actions +- vaults.fyi MCP: `build_vault_tx` — construct unsigned deposit transaction +- vaults.fyi MCP: `vaults_search` — resolve vault by name if no address given + +## Requirements +- Zerion CLI: `npm install -g zerion-cli` +- Zerion API key: `export ZERION_API_KEY="zk_..."` +- [vaults.fyi hosted MCP v2](https://mcp.vaults.fyi/mcp) connected +- A funded wallet with sufficient balance of the deposit asset + +## Workflow + +### 1. Confirm wallet readiness + +Check the wallet's current state with Zerion to confirm it has the assets needed. + +```bash +zerion portfolio
+``` + +Note the available balances. If the user needs to acquire the deposit token first, flag the gap and ask how they'd like to proceed before taking any action. + +### 2. Resolve the vault + +If the user provided a vault name rather than an address: + +- Call `vaults_search` with the name, asset, and network to find the matching vault. +- Confirm the match with the user if multiple results come back. + +If the user provided an address, call `vault_details` directly with the address and network. + +### 3. Run due diligence + +Gather the full risk and performance picture: + +- Call `vault_details` for score, flags, fees, curator, protocol, capacity, and underlying asset. +- Call `vault_apy_history` for 30-day APY trend. Set `fromTimestamp` to 30 days ago (current unix timestamp minus 2592000) to get recent data. +- Call `vault_tvl_history` for 30-day TVL trend. Set `fromTimestamp` the same way. +- Call `benchmark_apy` with the matching benchmark (`usd` for stablecoins, `eth` for ETH-denominated vaults) on the vault's network. + +Use `apyComposite.totalApy` when present instead of top-level APY. + +Present a due diligence summary: + +| Field | Value | +|-------|-------| +| Vault | name, protocol, curator, network | +| APY | 1d / 7d / 30d, composite if applicable | +| vs Benchmark | spread over network benchmark | +| TVL | current, 30d trend | +| Score | value out of 100, penalty notes | +| Flags | active warnings or critical incidents | +| Fees | performance, management, withdrawal | +| Capacity | deposit cap or remaining capacity | + +### 4. Safety gate + +This is the hard safety check before building any transaction. + +- **Critical flag active:** STOP. Do not proceed to transaction building. Report: "BLOCKED: this vault has an active critical incident. Do not deposit." +- **Warning flag active:** Present the warning details and require explicit user confirmation before continuing. +- **Clean (no flags, score above threshold):** Proceed with a green status. + +### 5. Check balance and prepare the deposit asset + +Call `transaction_context` with the wallet address, network, and vault ID to get: +- Required deposit asset and decimals +- Wallet balance of that asset +- Available deposit actions + +If the wallet doesn't have enough of the deposit asset, **stop and notify the user**. Explain clearly: +- Which asset is required and how much +- What the wallet currently holds on this network +- Whether the wallet holds the asset on other networks (potential bridge) or holds other tokens on this network (potential swap) + +Ask the user whether they want to: +1. **Swap** — convert another token on the same chain into the deposit asset +2. **Bridge** — bring the asset from another chain + +Only proceed after the user confirms which option they prefer. + +For a swap: + +```bash +zerion swap +``` + +For a bridge: + +```bash +zerion bridge --cheapest +``` + +### 6. Check deposit flow type + +Inspect `transactionalProperties.depositStepsType` from `vault_details` or `transaction_context`: + +- **`"instant"`**: Standard single-step deposit. Proceed to building the transaction. +- **`"complex"`**: Multi-step deposit flow. This may require multiple sequential transactions (e.g., approve → deposit → stake, or deposit → bridge → confirm). Present all steps to the user upfront with the expected sequence and any delays between steps. Some complex flows require waiting for on-chain confirmations between steps before the next step can execute. + +### 7. Build the deposit transaction + +After safety and balance checks pass: + +- Call `build_vault_tx` with `action: "deposit"`, `userAddress`, `network`, `vaultId`, and preferably `humanAmount` (e.g. "10") + `decimals` from `transaction_context` (e.g. 6 for USDC, 18 for WETH). The tool converts to base units automatically. +- For complex deposit flows, `build_vault_tx` returns multiple ordered steps. Present all steps with their sequence and any required delays. +- Present the unsigned transaction steps and decoded calls to the user. +- Do not sign or broadcast. The user must explicitly approve. + +### 8. Post-deposit tracking + +After the user signs and broadcasts the transaction: + +- Call `submit_tx_hash` with `sessionId` and `stepId` (from the `build_vault_tx` response) and the broadcast `txHash`. +- Call `get_transaction_status` to confirm the deposit landed. +- Verify the new position with Zerion: + +```bash +zerion positions
+``` + +## Common Blockers +- **Vault not found:** Name-based search returns no results. Ask the user for the contract address and network directly. +- **Insufficient balance:** The wallet lacks the deposit asset. Notify the user and ask whether they want to swap or bridge before retrying. +- **Critical flag blocks deposit:** This is intentional. Do not bypass. Explain the incident to the user. +- **Approval step already satisfied:** `build_vault_tx` may include a token approval step that's redundant if the wallet already has sufficient allowance. Note this rather than presenting every approval as required. +- **Vault at capacity:** Some vaults have deposit caps. If capacity is exhausted, say so and suggest alternatives via `vaults_search`. +- **Complex deposit flow (`depositStepsType: "complex"`):** Some vaults require multiple sequential transactions to complete a deposit. Steps may include approvals, deposits into intermediate contracts, staking, or bridging. Present the full sequence to the user before starting. Some steps require on-chain confirmation before the next step can execute — do not batch them blindly. +- **Complex redeem flow on later exit (`redeemStepsType: "complex"`):** Even if the deposit is instant, the vault may have complex withdrawal mechanics (request-then-claim with delays, cooldown periods, quarterly settlement windows). Surface this during due diligence so the user knows the liquidity profile before entering. Check `transactionalProperties.redeemStepsType` and any vault-specific data about withdrawal timing. + +## Related Skills +- **zerion-trading** — swap and bridge commands for acquiring deposit assets +- **zerion-analyze** — wallet analysis before depositing +- **zerion-vaultsfyi-yield-optimizer** — find the best vault before depositing +- **zerion-vaultsfyi-market-intel** — market context and vault comparisons diff --git a/skills/zerion-vaultsfyi-market-intel/SKILL.md b/skills/zerion-vaultsfyi-market-intel/SKILL.md new file mode 100644 index 00000000..cfb24805 --- /dev/null +++ b/skills/zerion-vaultsfyi-market-intel/SKILL.md @@ -0,0 +1,171 @@ +--- +name: zerion-vaultsfyi-market-intel +description: > + Get the current state of the DeFi yield market using vaults.fyi benchmark rates, compare vaults side-by-side, evaluate curators, and check how a Zerion wallet's positions stack up against market rates. +license: MIT +--- + +# vaults.fyi Market Intelligence + +**Purpose:** Combine vaults.fyi market data (benchmarks, vault comparisons, curator profiles) with Zerion wallet context to answer "how does the yield market look right now and how does my portfolio compare?" + +## When to use +- "How does the yield market look right now?" +- "Compare these two vaults" +- "What are the best USDC yields?" +- "Tell me about Gauntlet's vaults" +- "Are rates high or low right now?" +- "Which vault should I pick?" +- Any request to compare vaults, check market rates, evaluate a curator, or understand the current yield environment + +## Key Commands +- `zerion portfolio
` — portfolio value and top positions +- `zerion positions
` — detailed DeFi positions +- `zerion chains` — list supported chains +- vaults.fyi MCP: `benchmark_apy` — current benchmark rate for a network (USD or ETH) +- vaults.fyi MCP: `benchmark_apy_history` — 30-day benchmark trend +- vaults.fyi MCP: `vaults_search` — find and rank vaults by asset, network, APY, TVL, curator +- vaults.fyi MCP: `vault_details` — full vault metadata for comparison +- vaults.fyi MCP: `vault_apy_history` — 30-day APY history for a specific vault +- vaults.fyi MCP: `curators` — list curators and normalize names +- vaults.fyi MCP: `networks` — all supported networks + +## Requirements +- Zerion CLI: `npm install -g zerion-cli` +- Zerion API key: `export ZERION_API_KEY="zk_..."` +- [vaults.fyi hosted MCP v2](https://mcp.vaults.fyi/mcp) connected + +## Workflow + +### Market Snapshot + +Use this flow when the user asks "how does the yield market look?" or wants a general overview. + +### 1. Establish benchmark rates + +For each target network (default: mainnet, Base, Arbitrum, Optimism): + +- Call `benchmark_apy` with `code: "usd"` and `code: "eth"`. +- Call `benchmark_apy_history` for the last 30 days for both benchmarks. + +Classify each rate environment: +- **Elevated:** current rate > 1.5x the 30-day average +- **Compressed:** current rate < 0.7x the 30-day average +- **Normal:** between those bounds + +### 2. Surface top opportunities by asset + +For each target asset (default: USDC, WETH, USDS): + +- Call `vaults_search` with `sortBy: "apy30day"`, `sortOrder: "desc"`, `minTvl: 5000000`, `perPage: 20`. +- Exclude vaults with active critical flags. +- Use `apyComposite.totalApy` when present for yield-bearing or nested vaults. + +### 3. Compile the snapshot + +Present: + +| Section | Content | +|---------|---------| +| Benchmark rates | USD and ETH rate by network, current vs 30d average, environment label | +| Top opportunities | Top 3-5 vaults per asset: name, curator, network, 30d APY, TVL, score | +| Market observations | Protocol or curator concentration in top yields, likely incentive campaigns | + +### 4. Compare to a wallet (optional) + +If the user provides a wallet address, pull their positions from both sources: + +```bash +zerion positions
+``` + +Then call vaults.fyi `positions` with the wallet address to get vault-specific APY, score, and flag data. Zerion shows the broad portfolio and USD values; vaults.fyi adds yield metrics and risk context for vault positions specifically. For each vault position, compare the position's yield against the benchmark and top alternatives surfaced in step 2. Flag positions trailing the benchmark. + +--- + +### Vault Comparison + +Use this flow when the user asks to compare specific vaults side-by-side. + +### 1. Resolve vaults + +For each vault (2-4): + +- If the user gave an address, call `vault_details` with the address and network. +- If the user gave a name, call `vaults_search` to resolve it first. + +Confirm whether the vaults share the same underlying asset. If they don't, note the comparison is cross-asset and avoid simple APY ranking. + +### 2. Gather history and benchmarks + +For each vault: + +- Call `vault_apy_history` for 30 days. +- Call `benchmark_apy` for the vault's network and asset type. + +### 3. Present the comparison + +| Field | Vault A | Vault B | Vault C | +|-------|---------|---------|---------| +| Network | | | | +| Protocol | | | | +| Curator | | | | +| Asset | | | | +| 1d / 7d / 30d APY | | | | +| vs Benchmark | | | | +| TVL | | | | +| Score | | | | +| Flags | | | | +| Fees | | | | +| APY stability (30d) | | | | + +Recommend: +- **Best risk-adjusted yield:** highest 30d APY among clean, high-score vaults +- **Maximum APY option:** if different from above and not critical-flagged +- **Fee caveat:** if fees materially change the ranking + +Critical-flagged vaults cannot be recommended. + +--- + +### Curator Overview + +Use this flow when the user asks about a specific curator (e.g., "tell me about Gauntlet's vaults"). + +### 1. Resolve the curator + +Call `curators` to normalize the name. Users may type "Steakhouse" when the canonical name is "Steakhouse Financial". + +### 2. Pull the curator's vaults + +Call `vaults_search` with `curators: [curator_name]`, `sortBy: "tvl"`, `sortOrder: "desc"`. Apply optional asset and network filters if the user specified them. + +### 3. Present the overview + +- **Curator profile:** name, vault count, total TVL, active networks, assets managed +- **Vault list:** vault, asset, network, TVL, 30d APY, score, flags +- **Aggregates:** TVL-weighted average APY, average score, min/max score +- **Incidents:** any warning or critical flags by vault +- **Best pick:** highest 30d APY vault with no active flags and score above 80. If no vault meets that bar, say so. + +### 4. Compare to wallet (optional) + +If the user has a wallet, check whether they hold any of this curator's vaults: + +```bash +zerion positions
+``` + +Surface whether their exposure to this curator is concentrated or diversified. + +## Common Blockers +- **Benchmark data unavailable for a network:** Some newer or smaller networks may lack benchmark history. Note the gap rather than omitting the network silently. +- **Curator name not found:** `curators` didn't match. Ask the user for the exact name or try a partial search via `vaults_search` with a curator filter. +- **Cross-asset comparison:** Two vaults with different underlying assets can't be ranked by APY alone. Flag this and compare them as separate opportunities. +- **Too many vaults for comparison:** Cap at 4. If the user asks for more, suggest narrowing by asset or network. +- **Complex deposit/redeem flows:** When recommending vaults or comparing options, note when a vault has `depositStepsType: "complex"` or `redeemStepsType: "complex"`. A vault with 2% higher APY but a quarterly settlement window or multi-step deposit may not be the right pick for a user who values liquidity. + +## Related Skills +- **zerion-analyze** — wallet analysis and PnL +- **zerion-vaultsfyi-yield-optimizer** — full portfolio audit with opportunity cost +- **zerion-vaultsfyi-deposit** — act on a vault pick with safety checks diff --git a/skills/zerion-vaultsfyi-rebalance/SKILL.md b/skills/zerion-vaultsfyi-rebalance/SKILL.md new file mode 100644 index 00000000..ee608c6d --- /dev/null +++ b/skills/zerion-vaultsfyi-rebalance/SKILL.md @@ -0,0 +1,168 @@ +--- +name: zerion-vaultsfyi-rebalance +description: > + Move assets from one DeFi vault to another using vaults.fyi for exit/entry transaction construction and safety checks, with Zerion CLI handling swaps and cross-chain bridging between positions. +license: MIT +--- + +# vaults.fyi Rebalance + +**Purpose:** Execute a full vault-to-vault rebalance using vaults.fyi for withdrawal and deposit transaction construction (with safety gates at every step) and Zerion CLI for any swaps or cross-chain bridges needed between the exit and entry. + +## When to use +- "Move my USDC from this Morpho vault to that Aave vault" +- "Rebalance from vault A to vault B" +- "Exit this position and put it into a better vault" +- "Rotate my yield position to a higher-APY vault on another chain" +- "Switch curators" +- Any request to move assets between DeFi vaults, including cross-chain and cross-asset rebalances + +## Key Commands +- `zerion portfolio
` — confirm wallet state before and after +- `zerion positions
` — verify DeFi positions +- `zerion swap ` — swap between assets if the destination vault takes a different token +- `zerion bridge ` — bridge assets cross-chain between exit and entry +- vaults.fyi MCP: `vault_details` — inspect both source and destination vaults +- vaults.fyi MCP: `position_details` — current position value and state in the source vault +- vaults.fyi MCP: `transaction_context` — pre-flight check for both withdrawal and deposit +- vaults.fyi MCP: `build_vault_tx` — construct unsigned withdrawal and deposit transactions +- vaults.fyi MCP: `vaults_search` — find the destination vault if not specified +- vaults.fyi MCP: `benchmark_apy` — confirm the rebalance actually improves yield vs benchmark +- vaults.fyi MCP: `submit_tx_hash` / `get_transaction_status` — track transactions post-signing + +## Requirements +- Zerion CLI: `npm install -g zerion-cli` +- Zerion API key: `export ZERION_API_KEY="zk_..."` +- [vaults.fyi hosted MCP v2](https://mcp.vaults.fyi/mcp) connected +- An existing vault position to exit + +## Workflow + +### 1. Confirm the current position + +Check the wallet's state and identify the source vault position. + +```bash +zerion positions
+``` + +Call vaults.fyi `position_details` with the wallet address and source vault to get: current value, unrealized returns, the vault's withdrawal mechanics, and any active flags. + +### 2. Check for withdrawal constraints + +Call `vault_details` on the source vault and call `transaction_context` to inspect the redeem flow: + +- **Redeem flow type (`redeemStepsType`):** Check `transactionalProperties.redeemStepsType`. If `"instant"`, withdrawal is a single transaction. If `"complex"`, the exit requires multiple steps with potential delays between them (e.g., request withdrawal → wait for processing → claim). Complex redeems may involve cooldown periods (hours or days), withdrawal queues, or settlement windows. The `vaultSpecificData` field in `transaction_context` may contain timing details. +- **Cooldown period:** Some vaults require initiating a cooldown before withdrawal is available. If a cooldown is required, the agent must call the cooldown action first and inform the user of the wait time before proceeding. Do not attempt to wait — cooldowns can be hours or days. +- **Withdrawal queue:** Some vaults process withdrawals asynchronously. Note the expected timeline. +- **Exit fees:** Withdrawal or performance fees that reduce the rebalanced amount. +- **Active flags:** If the source vault has a critical flag, that may actually strengthen the case for exiting. Note this. + +### 3. Inspect the destination vault + +Call `vault_details` on the destination vault. Run the same safety checks as the deposit skill: + +- **Critical flag:** STOP. Do not proceed. Suggest alternatives via `vaults_search`. +- **Warning flag:** Present the warning and require explicit user confirmation. +- **Score check:** If the destination vault scores lower than the source, flag the tradeoff. +- **Capacity:** Confirm the destination can accept the deposit amount. + +Call `benchmark_apy` for the destination vault's network and asset type. Confirm the rebalance produces a meaningful APY improvement (at least 1 percentage point after fees). + +### 4. Present the rebalance plan + +Before building any transactions, show the user: + +| Field | Source Vault | Destination Vault | +|-------|-------------|-------------------| +| Vault name | | | +| Curator | | | +| Network | | | +| Asset | | | +| 30d APY | | | +| Score | | | +| Flags | | | +| Fees (exit/entry) | | | + +- **Net APY improvement** after accounting for exit fees, entry fees, and any swap/bridge costs +- **Route:** same-chain direct, same-chain with swap, or cross-chain with bridge +- **Estimated steps:** cooldown (if needed) → withdraw → swap/bridge (if needed) → deposit +- **Risks:** cooldown wait time, bridge slippage, temporary undeployed period + +Require explicit user approval before proceeding. + +### 5. Execute the withdrawal + +Call `build_vault_tx` with `action: "redeem"` (or `"request-redeem"` for complex flows), `userAddress`, `network`, and `vaultId` for the source vault. Present the unsigned transaction to the user for signing. + +After signing and broadcasting: + +- Call `submit_tx_hash` with `sessionId`, `stepId` (from the `build_vault_tx` response), and the broadcast `txHash` to track the withdrawal. +- Call `get_transaction_status` to confirm the withdrawal settled. +- Verify the assets arrived in the wallet: + +```bash +zerion portfolio
+``` + +### 6. Route assets to the destination (if needed) + +If the destination vault is on the same chain and accepts the same asset, skip to step 7. + +If the withdrawn asset doesn't match what the destination vault requires (different token or different chain), **stop and present the routing options to the user**: + +- Explain what was withdrawn and what the destination vault needs +- Show the available routes: swap (same chain, different token), bridge (different chain), or both + +Ask the user to confirm which route to take before executing. + +For a swap (same chain, different token): + +```bash +zerion swap +``` + +For a bridge (different chain): + +```bash +zerion bridge --cheapest +``` + +For cross-chain + different asset, bridge first, then swap on the destination chain. + +### 7. Execute the deposit + +Call `transaction_context` for the destination vault to confirm the deposit asset, decimals, and wallet balance. + +Call `build_vault_tx` with `action: "deposit"`, `userAddress`, `network`, `vaultId`, and preferably `humanAmount` + `decimals` from `transaction_context` (the tool converts to base units automatically). Present the unsigned transaction for signing. + +After signing and broadcasting: + +- Call `submit_tx_hash` with `sessionId`, `stepId`, and `txHash` to track the deposit. +- Call `get_transaction_status` to confirm the deposit settled. + +### 8. Verify the rebalance + +Confirm the new position with both Zerion and vaults.fyi: + +```bash +zerion positions
+``` + +Call `position_details` on the destination vault to confirm the position is active with the expected value. + +## Common Blockers +- **Complex redeem on source vault (`redeemStepsType: "complex"`):** The exit may require multiple transactions with delays between them. Common patterns: (1) request-then-claim with a processing period, (2) cooldown initiation followed by a waiting period before withdrawal unlocks (e.g., Ethena sUSDe), (3) quarterly settlement windows where withdrawals only process at specific dates. Check `transaction_context` for the specific flow and `vaultSpecificData` for timing. Inform the user upfront that the rebalance will span multiple sessions. +- **Complex deposit on destination vault (`depositStepsType: "complex"`):** The entry may also require multiple sequential transactions. Present the full deposit sequence after the withdrawal completes so the user knows the total operational cost. +- **Cooldown required on source vault:** The agent must initiate the cooldown action first and inform the user they'll need to return later to complete the withdrawal. Do not attempt to wait — cooldowns can be hours or days. +- **Withdrawal queue delays:** Some vaults process exits asynchronously. Note the expected timeline and pause the workflow until the withdrawal settles. +- **Rebalance not worth it:** If the net APY improvement after fees and slippage is less than 1 percentage point, recommend staying in the current vault rather than churning. Factor in the operational complexity — a complex redeem + complex deposit rebalance has higher friction cost than an instant-to-instant move. +- **Destination vault at capacity:** Suggest alternative vaults via `vaults_search` with the same asset and network. +- **Cross-chain bridge slippage:** Large rebalances across chains may face meaningful slippage. Show the estimated bridge output before proceeding. +- **Temporary undeployed period:** Between withdrawal settling and deposit completing, assets sit idle in the wallet earning nothing. For large positions, this opportunity cost matters. Note the expected gap duration. + +## Related Skills +- **zerion-vaultsfyi-yield-optimizer** — identifies which positions should be rebalanced +- **zerion-vaultsfyi-deposit** — standalone deposit with full due diligence +- **zerion-trading** — swap and bridge execution +- **zerion-vaultsfyi-risk-monitor** — monitors positions post-rebalance diff --git a/skills/zerion-vaultsfyi-risk-monitor/SKILL.md b/skills/zerion-vaultsfyi-risk-monitor/SKILL.md new file mode 100644 index 00000000..af05adeb --- /dev/null +++ b/skills/zerion-vaultsfyi-risk-monitor/SKILL.md @@ -0,0 +1,161 @@ +--- +name: zerion-vaultsfyi-risk-monitor +description: > + Continuous risk monitoring for DeFi vault positions using vaults.fyi flags, incident tracking, score changes, benchmark deviations, and withdrawal constraints, paired with Zerion wallet data for full portfolio context. +license: MIT +--- + +# vaults.fyi Risk Monitor + +**Purpose:** Monitor a wallet's DeFi vault positions for risk events using vaults.fyi's flag and scoring infrastructure alongside Zerion wallet context, catching problems before they become losses. + +## When to use +- "Are any of my positions in trouble?" +- "Check my vaults for risk flags" +- "Is it safe to stay in this vault?" +- "Monitor my positions for problems" +- "Did anything change with my vaults?" +- "Are there any incidents I should know about?" +- Any request to check safety, monitor risk, or scan for problems across vault positions + +## Key Commands +- `zerion positions
` — current DeFi positions +- `zerion portfolio
` — total portfolio value +- `zerion history
--limit 20` — recent transactions for context +- vaults.fyi MCP: `positions` — vault positions with scores, flags, and curator data +- vaults.fyi MCP: `vault_details` — deep inspection of flagged or concerning vaults +- vaults.fyi MCP: `vault_apy_history` — detect APY collapse or volatility +- vaults.fyi MCP: `vault_tvl_history` — detect capital flight from a vault +- vaults.fyi MCP: `benchmark_apy` — compare position yield against market baseline +- vaults.fyi MCP: `vaults_search` — find safer alternatives for positions that need to be exited +- vaults.fyi MCP: `transaction_context` — check withdrawal availability and constraints + +## Requirements +- Zerion CLI: `npm install -g zerion-cli` +- Zerion API key: `export ZERION_API_KEY="zk_..."` +- [vaults.fyi hosted MCP v2](https://mcp.vaults.fyi/mcp) connected + +## Workflow + +### 1. Pull all positions + +Get the full picture from both Zerion and vaults.fyi: + +```bash +zerion positions
+``` + +Call vaults.fyi `positions` with the wallet address to get vault positions with scores, flags, APY, and curator data. + +**How these two tools work together:** Zerion shows all DeFi positions with USD values — broad coverage across protocols. vaults.fyi shows vault-specific yield intelligence: APY methodology, risk scores, curator attribution, incident flags. A position may appear in one but not the other (Zerion covers protocols outside vaults.fyi's scope; vaults.fyi may index newer vaults Zerion hasn't added). Use Zerion for the portfolio-wide view and vaults.fyi as the authoritative source for vault risk and yield data. + +### 2. Flag scan (highest priority) + +For every position, check for active flags. Classify by severity: + +**CRITICAL — Immediate action required:** +- Active critical flags (exploit, depeg, insolvency, frozen withdrawals) +- Action: surface immediately with incident details. Recommend exit if withdrawals are available. + +**WARNING — Attention needed:** +- Active warning flags (elevated risk, audit concern, unusual behavior) +- Action: surface with context. Assess whether the warning is informational or actionable. + +**WATCH — Monitor closely:** +- Score below 50 +- Score dropped more than 15 points from the vault's historical baseline +- Action: note as degraded. Check allocation and TVL trends for supporting evidence. + +### 3. Yield health check + +For each position, compare current performance against benchmarks: + +- Call `benchmark_apy` for the position's network and asset type (USD or ETH). +- Flag positions where 30d APY is more than 2 percentage points below the benchmark. +- Call `vault_apy_history` with `fromTimestamp` set to 30 days ago (current unix timestamp minus 2592000) to detect APY decay (declining trend over the last 7-14 days). + +Classify: + +- **Healthy:** APY at or above benchmark, stable trend +- **Underperforming:** APY below benchmark but stable +- **Decaying:** APY trending downward, losing more than 1 percentage point over 14 days +- **Collapsed:** APY dropped more than 50% from 30-day average + +### 4. Capital flow analysis + +For positions above $10,000 in value: + +- Call `vault_tvl_history` with `fromTimestamp` set to 30 days ago. +- Flag vaults where TVL dropped more than 20% in the last 14 days — capital flight often precedes or accompanies problems. +- Flag vaults where TVL spiked more than 50% — sudden inflows can dilute yield or signal mercenary capital chasing temporary incentives. + +### 5. Withdrawal readiness + +For any position flagged in steps 2-4: + +- Call `transaction_context` to check whether withdrawal is currently available. +- Check `transactionalProperties.redeemStepsType`: if `"complex"`, the exit requires multiple transactions with potential delays. The `vaultSpecificData` field may contain cooldown durations, queue positions, or settlement window dates. +- Identify cooldown requirements, withdrawal queues, request-then-claim patterns, or timelock constraints. +- If immediate exit isn't possible, surface the earliest available exit path and timeline. For vaults with complex redeem flows, note whether the user needs to initiate a cooldown/request action now to start the clock. + +### 6. Concentration risk + +Across the full portfolio, flag: + +- **Single vault:** >50% of deployed capital in one vault +- **Single curator:** >50% of deployed capital managed by one curator +- **Single protocol:** >50% of deployed capital in one protocol +- **Single network:** >70% of deployed capital on one network + +### 7. Compile the risk report + +Present in priority order: + +**1. Critical alerts** (if any) +- Vault name, flag description, incident details, current position value +- Withdrawal availability +- Recommended action + +**2. Warnings** +- Vault name, warning description, score, position value +- Whether the warning is new or ongoing + +**3. Yield health** +- Positions by health classification (healthy / underperforming / decaying / collapsed) +- Benchmark comparison for underperformers + +**4. Capital flow signals** +- Vaults with significant TVL changes and what that might indicate + +**5. Concentration risk** +- Portfolio-level concentration flags + +**6. Portfolio status** +- Total deployed value, number of positions, overall risk posture (clean / caution / action needed) + +### 8. Suggest actions + +For each flagged position, recommend a specific next step: + +- **Critical flag:** "Exit this position. Use `zerion-vaultsfyi-rebalance` to move to a safer alternative." +- **Decaying yield:** "APY has dropped X%. Consider rotating to [alternative] which is currently yielding Y%." +- **Capital flight:** "TVL down Z% in 14 days. Monitor closely or preemptively exit before withdrawal congestion increases." +- **Concentration:** "Over 50% in [curator/protocol]. Diversify across at least 2-3 curators." + +For exit recommendations, confirm alternatives exist: + +- Call `vaults_search` for the same asset with `minTvl: 5000000`, excluding critical-flagged vaults. +- Present the top 2-3 clean alternatives with APY, score, and curator. + +## Common Blockers +- **No active flags across all positions:** Good news. Report the portfolio as clean with current scores and benchmark comparisons. A clean report is still valuable. +- **Flag data is point-in-time:** Flags reflect current state, not history. A vault may have had a critical flag last week that's since been resolved. Note that flag monitoring is most useful when run regularly. +- **Withdrawal not available due to cooldown:** Some exit paths require initiating a cooldown first. Surface the timeline so the user can plan. +- **False positives on TVL changes:** TVL can drop because a single large depositor withdrew (whale exit), not because of a vault problem. Note this possibility when flagging TVL declines. + +## Related Skills +- **zerion-vaultsfyi-rebalance** — execute exits and rotations flagged by the risk monitor +- **zerion-vaultsfyi-yield-optimizer** — broader yield optimization beyond risk +- **zerion-vaultsfyi-strategist** — deep historical analysis on flagged vaults +- **zerion-vaultsfyi-watchlist** — extend risk monitoring to tracked wallets beyond your own +- **zerion-analyze** — Zerion's wallet analysis for portfolio context diff --git a/skills/zerion-vaultsfyi-strategist/SKILL.md b/skills/zerion-vaultsfyi-strategist/SKILL.md new file mode 100644 index 00000000..138051c9 --- /dev/null +++ b/skills/zerion-vaultsfyi-strategist/SKILL.md @@ -0,0 +1,189 @@ +--- +name: zerion-vaultsfyi-strategist +description: > + Institutional-grade yield strategy analysis using vaults.fyi historical data, benchmark rate environments, share price trends, and curator track records, paired with Zerion wallet context. +license: MIT +--- + +# vaults.fyi Strategist + +**Purpose:** Run deep strategy analysis using vaults.fyi's historical data and benchmark infrastructure alongside Zerion wallet context to answer questions no other DeFi data source can. + +## When to use +- "If I'd been in vault A instead of vault B, how much more would I have earned?" +- "Are rates high right now or should I wait?" +- "Which curator has the best track record?" +- "Compare Gauntlet vs Steakhouse vs RE7 over the last 30 days" +- "Why is this vault's APY so high?" +- "Break down where this vault's yield is coming from" +- Any request for backtesting, rate environment assessment, or curator evaluation + +## Key Commands +- `zerion portfolio
` — current portfolio for context +- `zerion positions
` — existing DeFi positions +- `zerion pnl
` — realized P&L for comparison with vault returns +- vaults.fyi MCP: `vault_details` — full vault metadata, score, curator, protocol, fees +- vaults.fyi MCP: `vault_apy_history` — historical APY over configurable windows +- vaults.fyi MCP: `vault_tvl_history` — historical TVL trends +- vaults.fyi MCP: `vault_history` — share price history for precise return calculation +- vaults.fyi MCP: `vault_returns` — realized returns for a specific wallet +- vaults.fyi MCP: `benchmark_apy` — current network benchmark rate +- vaults.fyi MCP: `benchmark_apy_history` — historical benchmark for rate environment analysis +- vaults.fyi MCP: `curators` — list and normalize curator names +- vaults.fyi MCP: `vaults_search` — search by curator, asset, network, protocol + +## Requirements +- Zerion CLI: `npm install -g zerion-cli` +- Zerion API key: `export ZERION_API_KEY="zk_..."` +- [vaults.fyi hosted MCP v2](https://mcp.vaults.fyi/mcp) connected + +## Workflow + +### Backtest: "What if I'd been in vault X instead?" + +Compare historical performance of two or more vaults to quantify the difference a decision would have made. + +### 1. Gather historical data + +For each vault being compared: + +- Call `vault_apy_history` for the comparison window (30, 60, or 90 days). Set `fromTimestamp` to the start of the window (e.g. current unix timestamp minus 2592000 for 30 days) — without it, the API returns data from vault creation. +- Call `vault_history` for share price data over the same period. Use the same `fromTimestamp`. +- Call `vault_tvl_history` to understand capital flow context. Use the same `fromTimestamp`. +- Call `vault_details` for current score, fees, and flags. + +### 2. Calculate comparative returns + +Using share price history (the most accurate method): + +- **Period return:** `(end_share_price - start_share_price) / start_share_price` +- **Annualized return:** compound the period return to a yearly figure +- **For a specific amount:** `hypothetical_value = deposit_amount * (end_share_price / start_share_price)` + +Account for fees: share price already reflects performance fees on most vaults, but note management fees or withdrawal fees that would apply on exit. + +### 3. Add wallet context + +If the user provides an address, show their actual returns in the current vault: + +```bash +zerion pnl
+``` + +Call vaults.fyi `vault_returns` with the wallet address and vault to get realized return data. Compare actual returns against what the alternative vault would have delivered. + +### 4. Present the backtest + +| Metric | Current Vault | Alternative Vault | +|--------|--------------|-------------------| +| Period return | | | +| Annualized return | | | +| Hypothetical value on $10,000 | | | +| APY stability (high/low range) | | | +| TVL trend | | | +| Score | | | +| Fees | | | + +State the dollar difference clearly: "Over the last 30 days, vault B would have earned $X more on a $10,000 position." + +--- + +### Rate Environment: "Are rates high or low right now?" + +Use benchmark infrastructure to characterize the current yield market and identify anomalies. + +### 1. Build the benchmark picture + +For target networks (default: mainnet, Base, Arbitrum, Optimism): + +- Call `benchmark_apy` with `code: "usd"` and `code: "eth"` for current rates. +- Call `benchmark_apy_history` for 30-day and 90-day windows. + +### 2. Classify the environment + +For each network and benchmark: + +- **Elevated:** current rate > 1.5x the 30-day average +- **Compressed:** current rate < 0.7x the 30-day average +- **Normal:** between those bounds +- **Trending:** compare 7-day average vs 30-day average for direction + +### 3. Identify what's driving the environment + +When rates are elevated: + +- Call `vaults_search` sorted by `apy30day` descending to find the top-yielding vaults. +- Check whether high yields are concentrated in a single protocol, curator, or asset — that usually signals an incentive campaign or temporary liquidity event. +- Call `vault_details` on the top yielders to check for reward tokens or incentive flags. + +### 4. Make a recommendation + +- **Elevated rates:** "Rates are high. Lock in yield now, but be aware this may be incentive-driven and temporary." +- **Compressed rates:** "Rates are low. Consider shorter-duration positions or waiting for better entry points." +- **Normal rates:** "Rates are in line with recent history. Standard deployment criteria apply." + +If the user has a wallet, compare their current positions against the environment: + +```bash +zerion positions
+``` + +Flag positions that are earning below the compressed benchmark — those are underperforming even in a bad market. + +--- + +### Curator Track Record: "Who should I trust with my capital?" + +Evaluate curators by their historical performance, risk management, and vault quality. + +### 1. Resolve and compare curators + +Call `curators` to normalize names. Then for each curator: + +- Call `vaults_search` with `curators: [name]`, `sortBy: "tvl"`, `sortOrder: "desc"` to get all their vaults. +- For each vault, call `vault_apy_history` for 30-day performance. +- Call `vault_details` for score, flags, and fees. + +### 2. Build curator scorecards + +For each curator, aggregate: + +| Metric | Curator A | Curator B | Curator C | +|--------|-----------|-----------|-----------| +| Vaults managed | | | | +| Total TVL | | | | +| TVL-weighted avg APY (30d) | | | | +| Average score | | | | +| Score range (min–max) | | | | +| Active incidents | | | | +| Historical incidents | | | | +| Networks active on | | | | +| Assets managed | | | | +| APY consistency (range over 30d) | | | | + +### 3. Verdict + +Rank curators on: +1. **Risk management:** incident frequency, score consistency, flag history +2. **Yield delivery:** TVL-weighted APY vs benchmark +3. **Consistency:** APY stability over 30 days +4. **Diversification:** breadth across markets, assets, and networks + +If the user holds positions with any of these curators, show their exposure: + +```bash +zerion positions
+``` + +## Common Blockers +- **Limited historical data for new vaults:** Vaults launched recently won't have 90-day history. Note the available data window and compare only within it. +- **Benchmark not available for all networks:** Smaller or newer networks may lack benchmark history. Note the gap. +- **Curator comparison across different assets:** Comparing a stablecoin curator to an ETH curator on raw APY is misleading. Group by asset class and compare within groups. +- **Complex deposit/redeem flows affect strategy viability:** When recommending vaults or curators, factor in `transactionalProperties`. A vault with `redeemStepsType: "complex"` (e.g., quarterly settlement, multi-day cooldowns) is less suitable for active rebalancing strategies. A vault with `depositStepsType: "complex"` has higher operational cost to enter. Include flow type in curator and vault assessments. +- **Zerion positions vs vaults.fyi positions:** Zerion shows all DeFi positions (broad coverage, USD values). vaults.fyi adds vault-specific yield intelligence (APY methodology, scores, flags, curator data). When the user provides a wallet for context, use both — Zerion for the portfolio-wide picture, vaults.fyi for the yield analysis layer. + +## Related Skills +- **zerion-vaultsfyi-yield-optimizer** — act on strategist findings by identifying rebalance opportunities +- **zerion-vaultsfyi-rebalance** — execute the moves the strategist recommends +- **zerion-vaultsfyi-market-intel** — lighter-weight market overview +- **zerion-analyze** — Zerion's wallet analysis for portfolio context diff --git a/skills/zerion-vaultsfyi-watchlist/SKILL.md b/skills/zerion-vaultsfyi-watchlist/SKILL.md new file mode 100644 index 00000000..34ebf5b5 --- /dev/null +++ b/skills/zerion-vaultsfyi-watchlist/SKILL.md @@ -0,0 +1,133 @@ +--- +name: zerion-vaultsfyi-watchlist +description: > + Track wallets with Zerion's watchlist and run yield audits against vaults.fyi data to monitor positions, spot yield decay, detect new deployments, and surface opportunities across watched addresses. +license: MIT +--- + +# vaults.fyi Watchlist Monitor + +**Purpose:** Combine Zerion's wallet watchlist with vaults.fyi yield intelligence to continuously monitor tracked wallets for yield changes, risk events, and opportunities. + +## When to use +- "Watch this wallet and track its yield positions" +- "What vaults is this address using?" +- "Monitor my positions for yield decay" +- "Track this whale's DeFi strategy" +- "Add this wallet to my watchlist and audit its yield" +- Any request to track, monitor, or follow a wallet's DeFi vault positions over time + +## Key Commands +- `zerion watch
--name