> For the complete documentation index, see [llms.txt](https://docs.townsq.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.townsq.xyz/institution-backed-yield-vault-features/yield-vault/risks.md).

# Risks

## Risks and trust assumptions

{% hint style="warning" %}
This page is deliberately direct. Every item below is drawn from the protocol's own technical documentation (`docs/KNOWN_ISSUES.md`, `docs/INVARIANTS.md`) and from the contract code. None of it is hypothetical.
{% endhint %}

### Counterparty risk

**Your funds are not held onchain.**

Deposits are forwarded to the Manager contract and then transferred to an **offchain trading counterparty**. What the vault holds is an accounting record of what you are owed — not the assets themselves.

Once capital leaves via `execute()`, onchain enforcement ends. Recovery depends on the counterparty honouring an offchain agreement.

**Enforced by code:** deposits reach only the Manager; capital can only go to addresses governance has whitelisted; every whitelist change and every deployment emits an event, so the destination set is publicly auditable.

**Not enforced by code:** which addresses get whitelisted, how much leaves, when it returns, and whether any reserve is kept back.

### Unverifiable yield reporting

The share price is set entirely by an offchain engine's reports. There is no oracle, and the vault has no view of the strategy's actual balances.

From the code's own comment:

> Nothing onchain can verify this: the vault has no view of strategy balances, so the split is trusted input from the offchain engine.

**What bounds it:** by default at most 0.5% of vault assets per report, at most one report roughly every 22 hours, strict epoch sequencing, duplicate rejection.

**What does not bound it:** the truth of the figure. And the caps are per-report, not cumulative — sustained reporting at the limit compounds. At the default rate, roughly 5.5% per week could be reported in either direction indefinitely.

Both the magnitude cap and the interval are governance-adjustable, and the interval has no enforced minimum.

### Withdrawals can be paused

The guardian (instantly) or the admin (through the timelock) can pause the vault. Pause blocks `withdraw`, `redeem`, and `redeemFor` as well as deposits — so a pause makes matured redemptions temporarily uncollectable. Unpausing is admin-only, so it always takes at least 48 hours.

Most vaults deliberately keep the exit path open while pausing entry. This one does not. The protocol documents this as an accepted risk on the basis that pause is a short-lived emergency measure.

#### **Upgradeability, behind a 48-hour timelock**

All three contracts are UUPS-upgradeable. Upgrade authority (`DEFAULT_ADMIN_ROLE`) is held by a `TimelockController` with a 48-hour delay, so an upgrade must be scheduled publicly and wait 48 hours before it can execute.

Watch `CallScheduled` on the timelock. See Governance and the timelock.

### Broad admin powers

`ADMIN_ROLE` is also held by the timelock, so each of these now takes 48 hours and is visible in advance — but each is still possible:

* Whitelist any destination address, after which the operator can deploy capital to it immediately
* Call `emergencyRecover` to transfer any token out of the vault 
* Set the minimum reporting interval as low as 1 second, effectively removing the rate limit
* Repoint the Manager address, changing which contract controls vault accounting
* Change the treasury, redirecting all fee accrual
* Unpause the vault

Two actions are deliberately **not** delayed. The Safe holds `GUARDIAN_ROLE`, which can `pause()` the vault and remove whitelist entries instantly. It cannot unpause, add to the whitelist, or change anything else.

{% hint style="warning" %}
**Pause fast, resume slow.** The guardian can pause instantly, but lifting a pause takes a 48-hour timelock proposal — and a pause blocks withdrawals. A pause placed while a governance change is pending would stop depositors from using the 48-hour window to exit. 
{% endhint %}

### Design behaviours that are not bugs

These are intentional, but they will surprise you if you assume standard ERC-4626:

* **No cancel.** A redemption request cannot be undone or amended.
* **Amount frozen at request.** You forgo profit and are insulated from loss during cooldown.
* **One request at a time.** Large positions must be exited sequentially.
* **Self-collection only.** Allowance-based withdrawal is disabled; no other address can withdraw for you, ever.
* **`maxWithdraw` / `maxRedeem` over-report.** They are not overridden.
* **An operator can settle your request before the cooldown ends** via `redeemFor`. It can only pay you your locked amount, but it can end your position early.