# Vault Shares

Every dedicated vault issues its own share token on deployment. These shares represent the client's position in the vault — the accounting mechanism by which deposits, yield, and withdrawals are tracked on-chain.

### One token per vault

Each vault is a standalone ERC‑4626 contract and its own ERC‑20 share token. Share symbols follow the `te{Asset}` convention — `teUSDC`, `teWETH`, `teWBTC` — matching the vault's underlying asset.

When a client deposits, shares are minted to their wallet. When they withdraw, shares are burned proportionally to the amount withdrawn. The total supply of a given vault's shares always corresponds to 100% ownership of that vault — since there's one vault per client, the client holds the full supply.

### Share price and auto-compounding

A vault's share price is `totalAssets / totalSupply`. As yield accrues into the vault's positions, `totalAssets` grows; `totalSupply` stays constant (no new shares are issued for yield). The share price goes up, and each existing share becomes worth more of the underlying asset.

This is auto-compounding by construction — there is no separate rewards token, no claim step, and no re-staking. The yield is inside the vault from the moment it's earned, and it keeps earning.

Convert between shares and underlying assets using standard ERC‑4626 views:

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

### Non-transferable

Vault shares are **non-transferable** outside of permitted operational flows (deposit, withdrawal, scheduled-withdrawal mechanics). `transfer` and `transferFrom` to arbitrary addresses will revert.

This is deliberate and structural:

* **Regulatory.** Shares are non-transferable by design, which is intended to keep the DCV outside securities and collective-investment-scheme characterisation. Tesseract's legal analysis supporting this design is available to institutional counterparties under NDA.
* **Ownership integrity.** The vault's owner on-chain is the wallet that deployed it. Non-transferability preserves that identity through the vault's entire lifetime.
* **Compliance.** Whitelist-based access means every address interacting with the vault is KYC'd — transferring shares to a non-whitelisted wallet would bypass this.

The practical consequence: shares are cryptographic proof of position, not a tradable instrument. They can be read, priced, and redeemed, but not sold on a secondary market.

### Reading client positions

For a simple "how much is this client's position worth":

```ts
const shares = await vault.balanceOf(owner)
const assets = await vault.convertToAssets(shares)
```

For decoded transaction history (deposits, withdrawals, share mints and burns) and performance time-series, use the [Public API](/dedicated-client-vaults/reference/public-api.md).

### On deployment

The deployer pulls the initial deposit from the caller and mints shares in the same transaction — see [Deploying a Vault](/dedicated-client-vaults/integration-guide/scenario-a/deploying-a-vault.md) for the exact mechanics. The first share price is close to 1:1 against the underlying and drifts upward as yield accrues.


---

# 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/vault-shares.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.