## 1) approveMax / maxUint256

In `approveMax`, we hardcode `2n ** 256n - 1n`:

``` ts
export async function approveMax(...): Promise<ApproveResult> {
  return approve(walletClient, publicClient, {
    token,
    spender,
    amount: 2n ** 256n - 1n, // I think viem exposes maxUint256 / some constant we can reuse?
  })
}
```

Maybe we should use a shared constant (from viem or our own) so we don’t
repeat this / avoid magic numbers.

------------------------------------------------------------------------

## 2) Safe math utils for share/slippage math

In `packages/core/src/actions/deposit.ts`:

``` ts
const minShares = expectedShares - (expectedShares * BigInt(slippageBps)) / 10000n
```

Can we add a `safeMath` util (we already have something similar in
backend/dapp) and use it consistently for these calculations?
Mainly to avoid edge cases (underflow, rounding surprises, etc.) and
keep it uniform.

------------------------------------------------------------------------

## 3) Missing input validation

Right now it looks like we don’t validate some basics:

-   No validation that vault addresses are supported on the current
    chain
-   No validation that amounts are `> 0`
-   No address format validation

At minimum we should validate addresses + amounts.

Also: do we already have a helper/util that exports `yoVaultsAddresses`
(or supported vaults) for easy access? If not, might be worth adding.

------------------------------------------------------------------------

## 4) Vault address validation (invalid / unsupported vaults)

How do we prevent invalid vault addresses or addresses that are not part
of our supported contracts?

Right now it looks like we rely on the contract call reverting, but
maybe we should:

-   Validate address format (basic checksum / `isAddress` check)
-   Check that the vault exists in our supported `yoVaultsAddresses`
    list for the current chain

This would prevent accidental misuse and improve DX.

------------------------------------------------------------------------

## 5) Checking if vault is paused

Do we expose a way to check if a vault is paused?

Technically the transaction will revert if it’s paused, but from a UI/UX
perspective it might be better if we:

-   Export an `isPaused` (or similar) call
-   Let integrators check this before attempting deposit/withdraw

That way frontends can disable actions instead of relying on a revert.

------------------------------------------------------------------------

## 6) Idle balance / available liquidity

We might also want to export available idle balance from yoContracts.

For example for yoUSD: - What is the available idle balance? - How much
USDC is currently in the contract?

This is important because if `withdraw amount > idle balance`, the
withdraw might take up to 24h.

Having this exposed in the SDK would allow better UX (e.g. warning users
before they withdraw).

------------------------------------------------------------------------

## 7) Fragile string matching for errors

In `packages/core/src/api/user.ts`:

``` ts
catch (error) {
  if (error instanceof Error && error.message.includes('404')) {
    return null
  }
  throw error
}
```

This is pretty fragile (string matching on `"404"`).
Better to check status codes in a structured way if possible.

------------------------------------------------------------------------

## 8) Generic errors + unclear error surface

Currently we throw generic `Error`s, e.g.:

``` ts
throw new Error('Wallet client must have an account')
```

No error codes, no custom types.
From a dev UX perspective it’s hard to know what actually happened /
what to handle.

Related: in `packages/core/src/api/vault.ts` we bypass Zod validation:

``` ts
if (!parsed.success) {
  return response as VaultSnapshot // returns unvalidated data
}
```

That can silently pass bad data forward.

I’d suggest structured errors (codes + context), e.g.:

``` ts
class YoError extends Error {
  constructor(
    public code: string,
    message: string,
    public context?: Record<string, any>
  ) {
    super(message)
  }
}

class VaultNotFoundError extends YoError {}
class InsufficientBalanceError extends YoError {}
class SlippageExceededError extends YoError {}
```

Main point: make it obvious to SDK users what error they hit and how to
react.

------------------------------------------------------------------------

## 9) useYoKit vs useYoClient

`useYoKit` and `useYoClient` look very similar — both seem to create a
client.
Is there a real difference intended here, or can we merge / clarify
naming?

------------------------------------------------------------------------

## 10) previewDeposit vs quotePreviewDeposit

    client.previewDeposit()
    client.quotePreviewDeposit()

Are these doing different things, or are they basically the same?
If they’re meant to differ, maybe we should document the difference or
rename for clarity.