# 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 characterization. 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.