Core Reference (Standalone, no React)

All three classes are static-method namespaces — never instantiated. They take a viem PublicClient and (for writes) a SendTransactionFn:

type SendTransactionFn = (tx: TransactionRequest) => Promise<string>; // returns tx hash

interface DepositResult { approveHash?: Hash; depositHash: Hash; }
interface TxResult { txHash: Hash; }

See the standalone quickstart for a worked example, and API Clients for standalone financial data.

VaultReader — read-only

Method	Returns	Notes
getMetadata(client, vault)	Promise<VaultMetadata>	Two multicalls: vault fields, then token decimals/symbols
getUserState(client, vault, user, vaultType = 'ASYNC', depositAssetDecimals = 6)	Promise<VaultUserState>	Batched multicalls; deposit-request reads only for ASYNC vaults; isLoading always false here
getAllowance(client, token, owner, spender)	Promise<bigint>	ERC-20 allowance
getBalance(client, token, account)	Promise<bigint>	ERC-20 balance
getMaxDeposit(client, vault, receiver)	Promise<bigint>	ERC-4626 maxDeposit
getMaxRedeem(client, vault, owner)	Promise<bigint>	ERC-4626 maxRedeem
convertToAssets(client, vault, shares)	Promise<bigint>	share → asset value at current price
convertToShares(client, vault, assets)	Promise<bigint>	asset → share value at current price

VaultActions — orchestrated write flows

Each method sends via the provided sendTransaction and waits for the receipt before resolving. Amounts marked human are strings parsed with the given decimals; amounts marked raw are bigint.

VaultActions methods throw

Unlike the hooks (whose actions never throw and surface failures in error state), VaultActions methods throw on failure — wrap in try/catch.

Method	Signature (after client, sendTransaction, vaultAddress)	Notes
deposit	(amount: string /*human*/, userAddress, assetAddress, assetDecimals, vaultType = 'ASYNC') → DepositResult	Checks allowance; approves first if needed (waits for approval receipt); then requestDeposit (ASYNC) or deposit (sync). Throws 'Amount must be greater than 0' on zero/negative.
claimDeposit	(assets: bigint /*raw*/, userAddress) → TxResult	Throws 'No assets to claim' if assets <= 0n
requestRedeem	(shares: string /*human*/, userAddress, shareDecimals = 18) → TxResult	Throws 'Shares must be greater than 0'
claimRedeem	(shares: bigint /*raw*/, userAddress) → TxResult	Throws 'No shares to claim'
cancelRedeem	(userAddress) → TxResult
claimCancelRedeem	(userAddress) → TxResult
cancelDeposit	(userAddress) → TxResult	ASYNC vaults only (caller's responsibility here — no type guard at this layer)
claimCancelDeposit	(userAddress) → TxResult	ASYNC vaults only

VaultTxBuilder — raw calldata

Builds TransactionRequest objects ({ to, data, value: 0n }) without sending. For teams with their own tx pipeline (relayers, AA bundlers, multisigs). All amounts are raw bigint — callers do their own parseUnits.

Method	On-chain call encoded
buildDepositTx(vault, assets, receiver, vaultType = 'ASYNC')	ASYNC: requestDeposit(assets, receiver, receiver); sync: deposit(assets, receiver)
buildApproveTx(token, spender, amount)	ERC-20 approve(spender, amount)
buildRequestRedeemTx(vault, shares, controller, owner)	requestRedeem(shares, controller, owner)
buildClaimRedeemTx(vault, shares, receiver, controller)	redeem(shares, receiver, controller)
buildClaimDepositTx(vault, assets, receiver)	ERC-4626 deposit(assets, receiver) (the async-deposit claim)
buildCancelRedeemTx(vault, controller)	cancelRedeemRequest(0, controller)
buildClaimCancelRedeemTx(vault, receiver, controller)	claimCancelRedeemRequest(0, receiver, controller)
buildCancelDepositTx(vault, controller)	cancelDepositRequest(0, controller)
buildClaimCancelDepositTx(vault, receiver, controller)	claimCancelDepositRequest(0, receiver, controller)

0 is the constant requestId per the single-request model — see Concepts.