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

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

Events:

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:

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:

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.

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.

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

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.