lend_deposit

ing.crank/crank · Verify this server

Deposit assets to earn yield on Kamino or Marginfi (non-custodial). Returns an UNSIGNED base64 tx to sign + broadcast, plus supply APY. amount is in base units of token. protocol: kamino | marginfi -- pin one to keep exact prior behaviour. Marginfi needs marginfi_account (create via the sidecar). Past the daily free tier an x402 payment_header is required. The deposited token is authenticity-verified first; set allow_unverified=true to supply an unverified token at own risk. ``venue_hint`` / auto-route: pass ``protocol="auto"`` (or ``""``) -- optionally with ``venue_hint`` as an advisory alias, same naming as jupiter_swap/trade_equity -- to route through the SAME primary+fallback health-failover the internal earn/lending trade bridge already applies: an empty rate snapshot on the primary protocol fails over to the configured fallback. Extends this tool instead of adding a separate earn_quote/trade_earn surface, so lend_deposit is now the one first-class MCP path for both a pinned protocol and an auto-routed deposit. A router-resolved call also carries the smart-contract counterparty-risk disclosure in the response (``disclosures``), matching the internal bridge. Workflow: EXECUTE step (yield leg) -- supply idle stables/tokens after comparing get_lending_rates; monitor with get_health_factor. See get_trading_workflow. ``idempotency_key`` (optional): a client-generated UUID. Retrying with the same key + same args replays the original result instead of re-depositing. Reuse the SAME key across the build call and its ``signed_transaction`` completion call -- the two legs dedupe independently, so this never raises IDEMPOTENCY_CONFLICT; a NEW key means a genuinely new deposit. ``signed_transaction`` / ``verify`` (two-phase execution): re-call this tool with the SIGNED base64 tx and Crank broadcasts it, then awaits on-chain confirmation and re-reads BOTH the deposited token's balance and the obligation's health -- the response carries a real ``verification`` block ({confirmed, slot, post_state, expected_vs_actual}). Gate follow-on borrowing on ``verification.confirmed``, never on tx_signature alone. verify=false skips only the confirmation wait. When the build leg auto-routed (protocol="auto"), pass back the SAME resolved ``protocol`` the build response reported -- re-resolving from "auto"/ venue_hint again on the completion leg could pick a different venue if health changed between calls.