For the complete documentation index, see llms.txt. This page is also available as Markdown.

Contract Methods

Public, read-accessible methods that integrators call directly on-chain. Full ABIs are available via Etherscan for each contract — see Contract Addresses.

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.

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.

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):

Events:

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. Share tokens carry two more decimals than the underlying asset (teUSDC 8, teWBTC 10, teWETH 20, tecbETH 20) — read decimals() on the vault rather than reusing the asset's.

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:

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.

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.

Flow:

  1. Call requestShares(shares) on the vault's WithdrawManager. This records the request and opens a withdrawal window (getWithdrawWindow(), currently 7 days) counted from the request. No share approval is needed; the shares stay in your wallet and are not locked. Calling requestShares again replaces the previous request.

  2. Wait. Tesseract prepares liquidity in the background and releases funds within 24–48 hours, depending on the strategy.

  3. While the window is still open, call redeemFromRequest(shares, receiver, owner) on the vault to receive the underlying asset. Partial claims are allowed.

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

Read current state with:

Strategy assignment is an off-chain flow (EIP‑712 signature submitted to the Public API) — see Public API → Strategy assignment.

Last updated

Was this helpful?