> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dionysus.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Smart contract risk

> It's all code. Code can fail.

Your vault, the venues it uses, the tokens it holds, the oracles that price them — all smart contracts, all capable of failure. This page maps the layers.

## Our contracts

Your vault is our code. What we do about that:

* **Audited before launch.** See [Audits](/reference/security/audits) for reports as they are published.
* **Designed to fail toward you.** The recurring pattern in the vault's design: when something is wrong, automation stops, fees are waived or deferred, and exits keep working. A pause cannot trap funds; a broken fee transfer still pays the owner; a stale oracle waives the fee instead of guessing. See [Guardrails](/agent/guardrails).
* **A narrow operator surface.** The worst a fully compromised agent key can do is manage badly within rate limits and swap caps — the contract gives it no path to theft. See [What the agent can and cannot do](/vault/what-the-agent-can-and-cannot-do).
* **One vault per user.** A vault compromised through owner error (a phished wallet, say) is one user's loss, not a protocol-wide drain. There is no honeypot contract holding everyone's funds.

## Contracts we depend on

Your vault interacts with venue contracts (DEXes, gauges), token contracts, and price feeds — none of which we control. A venue exploit or a malicious token can cost a vault money that our own code's correctness cannot prevent. This is why [venue vetting](/strategies/how-pools-are-chosen) is deliberately conservative and probing happens with real transactions before real size.

## The honest bottom line

Audits reduce risk; they do not zero it. Novel chains, new venues, and composability create failure modes nobody has enumerated yet. Treat smart-contract risk as irreducible background radiation — and size your deposit accordingly.
