zerion-vaultsfyi-rebalance

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 <address> — confirm wallet state before and after
• zerion positions <address> — verify DeFi positions
• zerion swap <chain> <amount> <from> <to> — swap between assets if the destination vault takes a different token
• zerion bridge <from-chain> <token> <amount> <to-chain> <token> — 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 connected
• An existing vault position to exit

Workflow

1. Confirm the current position

Check the wallet's state and identify the source vault position.

zerion positions <address>

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:

zerion portfolio <address>

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 destination vault accepts a different asset:

zerion swap <chain> <amount> <withdrawn-token> <deposit-token>

If the destination vault is on a different chain:

zerion bridge <source-chain> <token> <amount> <dest-chain> <token> --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:

zerion positions <address>

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