Skip to main content

LST / LRT mint · withdraw-request · claim · cancel

GET 
/v1/actions/vaults/lst

Build calldata for LST / LRT (and Lagoon) actions — mint, withdraw-request, claim, and cancel — via the unified LST dispatchers. The protocol is resolved from the calldata-sdk registry by (chainId, shareToken), or forced with kind= (required for Lagoon — kind=lagoon&mode=sync|async — and any unregistered vault).

Deposits also work through the unified /v1/actions/vaults/deposit — pass the LST share token as vault and it routes here automatically (no need to know it's an LST). This endpoint stays as the explicit LST route and is the home for the exit-side actions (request-withdraw / claim / cancel), which the generic deposit endpoint does not cover.

How an integrator knows what to pay with (acceptedInputs)​

LSTs are not uniform ERC-4626 vaults — each protocol accepts a different set of pay assets (native ETH, an unwrapped sibling like stETH/eETH, or specific ERC-20s) and some paths require extra slippage/intermediate options. Rather than hard-coding this, fetch the vault data first and let it drive the request:

  1. GET /v1/data/vaults?chainId=…&providers=lst → each LST carries a providerMeta block:
    • isMintable — false ⇒ no on-chain mint (e.g. cbETH); don't call this endpoint.
    • mintContract — the deposit target.
    • exchangeRate / convertToShares — to compute expected output and a minOut.
    • acceptedInputs[] — the machine-readable accept-set (see below).
  2. Pick the acceptedInputs entry whose asset matches what the user holds.
  3. Call this endpoint with action=deposit, payAsset=<that asset>, and the entry's needs[] supplied as query params.

acceptedInputs[] entry shape​

fieldmeaning
asset"native" (pay with the chain coin → pass payAsset=0x000…000) or a lowercased ERC-20 address to pass as payAsset.
symboloptional UI hint (e.g. stETH).
modedirect (single call) · wrap (approve + wrap a base LST the user already holds) · submit-wrap (native → base → wrapped; needs the realised base amount).
needsoption keys the caller must pass for this path (e.g. ["minMETHAmount"], ["eEthAmount"], ["stEthAmount"]). Absent ⇒ none.

Example — wstETH advertises three paths:

"acceptedInputs": [
  { "asset": "native", "mode": "direct" },
  { "asset": "0xae7ab9…", "symbol": "stETH", "mode": "wrap" },
  { "asset": "native", "mode": "submit-wrap", "needs": ["stEthAmount"] }
]
  • Pay with ETH → payAsset=0x000…000 (one-step receive()).
  • Pay with stETH you already hold → payAsset=0xae7ab9… (approve + wrap).

Multi-step results​

wrap / submit-wrap paths produce multiple ordered transactions. The response's actions.transactions[] is the sequence to execute in order, and actions.permissions[] carries any ERC-20 approvals to run first. Single-step mints return one transaction and (for native) no permissions. Always iterate transactions[]; never assume a single tx.

Slippage / required options​

Paths whose needs includes a min-out (minMETHAmount, minRSETHAmountExpected, …) require the caller to compute the floor from the data's exchangeRate and pass it. Native one-step mints (stETH, ETHx, ezETH, ynETH, pufETH, wstETH-receive) need nothing beyond amount.

Actions​

  • deposit — mint. amount required; payAsset (default native); path options per acceptedInputs[].needs.
  • request-withdraw — start an exit (queue/cooldown). amount required; inputAsset?, outputAsset?, owner?.
  • claim — settle a matured exit. Identifier params: requestIds/hints/amounts (CSV), tokenId, id, shares, assets, controller, user, recipient.
  • cancel — cancel a pending request (same identifier params).

Request​

Responses​

Ordered transactions[] (execute in sequence) + ERC-20 permissions[] (execute first). Single-step mints return one transaction.