# Contract Methods

Public, read-accessible methods that integrators call directly on-chain. Full ABIs are available via Etherscan for each contract — see [Contract Addresses](/dedicated-client-vaults/reference/contract-addresses.md).

### Whitelisting

The access-control contract that gates all vault operations. A wallet must have a non-expired whitelist entry before it can deploy a vault or be the active signer on vault operations that require whitelisting.

```solidity
function isWhitelisted(address account) external view returns (bool);
function whitelistExpiration(address account) external view returns (uint256);
```

`isWhitelisted` returns `true` while the wallet's KYC is valid. `whitelistExpiration` returns the Unix timestamp of expiry (`0` means never whitelisted). Renewal typically requires the client to re-complete the KYC flow — Tesseract emails the client with instructions shortly before expiry, and the new expiration is written back on-chain once checks clear.

Write functions (`setWhitelist`, `setWhitelistBatch`) are restricted to the Tesseract operator role and are not part of the integration surface.

### Vault Deployer (per asset)

Call the deployer for the asset you want to hold. The deployer creates a fully configured dedicated vault in a single transaction and mints initial shares to the caller.

```solidity
function deployVault(
    uint256 initialDeposit,
    uint256 maxManagementFee,
    uint256 maxPerformanceFee
) external returns (FusionInstance memory);

function deployVaultWithPermit(
    uint256 initialDeposit,
    uint256 maxManagementFee,
    uint256 maxPerformanceFee,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external returns (FusionInstance memory);
```

Both functions revert with `NotWhitelisted` if the caller is not on the `Whitelisting` contract. `maxManagementFee` / `maxPerformanceFee` are slippage guards on current configured fees; pass generous upper bounds (or the exact current values) to avoid the transaction reverting on an in-flight fee update.

The address of the new vault is returned and emitted in `VaultDeployed`.

**View helpers** (read current configuration):

```solidity
function minInitialDeposit() external view returns (uint256);
function UNDERLYING_TOKEN() external view returns (address);
```

**Events:**

```solidity
event VaultDeployed(
    address indexed plasmaVault,
    address indexed owner,
    address accessManager,
    address feeManager,
    address rewardsManager,
    address withdrawManager,
    address contextManager,
    address priceManager
);
```

Index `VaultDeployed` to track new vaults as they're created. `plasmaVault` is the main vault address; `withdrawManager` is the per-vault manager used for scheduled withdrawals (see below).

### Vault (ERC‑4626)

Each vault is a standard ERC‑4626 share vault. Standard deposit / withdrawal / balance methods work as defined in [EIP‑4626](https://eips.ethereum.org/EIPS/eip-4626):

```solidity
function deposit(uint256 assets, address receiver) external returns (uint256 shares);
function mint(uint256 shares, address receiver) external returns (uint256 assets);

function withdraw(uint256 assets, address receiver, address owner) external returns (uint256 shares);
function redeem(uint256 shares, address receiver, address owner) external returns (uint256 assets);

function totalAssets() external view returns (uint256);
function convertToShares(uint256 assets) external view returns (uint256);
function convertToAssets(uint256 shares) external view returns (uint256);

function balanceOf(address account) external view returns (uint256);
function asset() external view returns (address);
```

`withdraw` / `redeem` are **instant withdrawals** — they pull from idle cash and pre-authorized instant-withdrawal routes and execute in a single transaction. If the requested amount can't be satisfied instantly, the call reverts and you must fall back to the scheduled flow below.

In addition to the standard ERC‑4626 methods, the vault exposes an EIP‑2612 convenience entry point for deposits:

```solidity
function depositWithPermit(
    uint256 assets,
    address receiver,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external returns (uint256 shares);
```

`depositWithPermit` atomically consumes a permit signature on the underlying token and performs the deposit in a single transaction — no separate `approve` is needed. Only available for underlying tokens that implement EIP‑2612 (e.g. USDC). There are no permit variants for `mint`, `withdraw`, `redeem`, or `requestShares`.

Vault shares are **non-transferable** outside the permitted set — `transfer` / `transferFrom` are gated to operational flows.

For ABI inspection and tooling setup, use any deployed vault as a reference — e.g. [`0xe1c3a197d16eF96a7c8E7c5F6B83B5E032cD76a9`](https://etherscan.io/address/0xe1c3a197d16ef96a7c8e7c5f6b83b5e032cd76a9#code).

### Scheduled withdrawal (WithdrawManager + Vault)

For amounts that can't clear instantly, use the three-step scheduled flow. Each vault has its own `WithdrawManager` — its address is in the `VaultDeployed` event and also available from the vault via its access-manager setup.

```solidity
// On WithdrawManager — called by the vault owner
function requestShares(uint256 shares) external;

// On the vault — called by the vault owner once Tesseract releases funds
function redeemFromRequest(
    uint256 shares,
    address receiver,
    address owner
) external returns (uint256 assets);
```

Flow:

1. **Approve** the vault to spend your shares (or use permit if supported).
2. Call `requestShares(shares)` on the vault's `WithdrawManager`. This opens a withdrawal window and locks the requested shares.
3. **Wait.** Tesseract prepares liquidity in the background (minutes to hours, capped at \~24h) and releases funds.
4. While the window is still open, call `redeemFromRequest(shares, receiver, owner)` on the vault to receive the underlying asset.

If the window expires before you claim, the request must be re-issued.

Read current state with:

```solidity
function requestInfo(address account) external view returns (WithdrawRequestInfo memory);
function getLastReleaseFundsTimestamp() external view returns (uint256);
function getWithdrawWindow() external view returns (uint256);
```

Strategy assignment is an off-chain flow (EIP‑712 signature submitted to the Public API) — see [Public API → Strategy assignment](/dedicated-client-vaults/reference/public-api.md#strategy-assignment-eip-712).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.tesseract.fi/dedicated-client-vaults/reference/contract-methods.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.