> For the complete documentation index, see [llms.txt](https://docs.dexponent.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dexponent.com/protocol-overview.md).

# How the protocol works

## From deposit to withdrawal

1. A manager creates a supported DTF through the beta onboarding flow.
2. The deployed vault accepts its configured base asset.
3. An LP deposits and receives DTF shares.
4. The strategy holds or trades assets; NAV changes with results and costs.
5. Applicable performance fees are accounted for through fee shares.
6. The LP redeems shares for the available base-asset amount, subject to the DTF's execution and settlement rules.

For Perpetual DTFs, assets and positions can also sit at the trading venue. Withdrawals may require returning collateral and settling a queued claim.

## Shares and valuation

A DTF share represents proportional participation in a specific vault. Its value is based on the vault's net assets and share supply. It is not a fixed-value deposit receipt.

Deposits, withdrawals, P\&L and fee-share issuance all affect the accounting. Read [fees and costs](/fees-and-costs.md) before interpreting changes in your balance.

## Control during beta

Managers operate within the supported controls for their DTF. Protocol administrators handle configuration and other authorized lifecycle actions. Some actions depend on backend services, fresh valuation data or team intervention.

This beta does not implement token-holder governance or require production DXP to operate. It does not automatically route DTF fees into a DXP liquidity pool.

## External dependencies

Base handles the beta's user-facing vault transactions. Spot and Index execution depends on supported trading integrations; Perpetual DTFs also depend on Hyperliquid and collateral settlement.

See [DTF types](/dtf-types.md) and [beta scope and risks](/beta-scope-and-risks.md).