> For the complete documentation index, see [llms.txt](https://docs.yo.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.yo.xyz/protocol/yo-v2-security-framework.md).
# YO V2 Security Framework
v2 is a ground-up revamp of the core protocol, and it changes two things at once: what your money is exposed to, and how your money is allowed to move.
Exposure is targeted. Each vault algorithmically allocates across a small list of positions, each one selected on the quality of its collateral, its liquidity, its audit history, and the risk of everything it depends on, and published in full on the vault page.
Movement is closed-loop. Every path a dollar can take is written into immutable adapters and timelocked registries: from the vault, into an approved position, and back to the vault. There is no other route.
That is what we mean by closed-loop by design. A closed set of exposures. A closed set of paths. All of it verifiable by anyone.
### What's new in v2
**New**
* **Onchain Adapters**: Immutable, single-purpose contracts between the vault and every protocol. The receiver is hardcoded to the vault, approvals reset to zero after each use, and adapters can neither call arbitrary contracts nor be upgraded.
* **Targeted exposures**: Each vault allocates across a short list of positions, each selected on collateral quality, liquidity, audit history, and dependency risk. The full list is published on every vault page and onchain.
* **Approval Registry:** Onchain, timelocked caps on how much of each asset a vault may approve to each contract: vault, asset, contract, and amount fixed in advance.
* **Crosschain Bridge Adapters**: One immutable adapter per bridge. Token pinned at deployment, fees capped in code, never holding funds between transactions.
* **Bridge Route Registry:** Every cross-chain route allowlisted down to the vault, adapter, token, destination chain, and recipient. Same asset in, same asset out.
* **48-Hour Timelock**: Every upgrade is audited, queued, and published on a [public dashboard](https://app.yo.xyz/upgrade) with a mandatory 48-hour delay and sign-off from a 4-of-6 multi-sig of geographically distributed signers.
**Carried forward, now inside the loop**
* **Automated Offchain Simulation**: Every transaction replayed against live chain state and rejected if the outcome differs from the intent, with price-impact and slippage checks and automated co-signers.
* **Oracle Guard**: Share prices validated against a rolling anchor; manipulated or zero prices rejected.
* **Roles Authority**: Onchain access control that now forms the outer gate of the loop: vaults are configured to call adapters only, never external protocols directly.
### Follow a dollar through YO v2
The easiest way to understand v2 is to watch a deposit move through it.
**1. You deposit.** You put USDC into the yoUSD Edge vault and receive yoUSD Edge: a token whose value rises as the vault earns. YO is non-custodial. The assets sit in a vault contract onchain, in plain view, and you hold yoUSD Edge in your wallet.
**2. The engine picks from a targeted list.** yoUSD Edge doesn't allocate to everything that pays. It allocates across a short list of exposures that have earned their place, weighted for risk-adjusted return, and pulls back from any position whose risk profile changes. Fewer exposures means deeper diligence on each one, tighter monitoring, faster exits, and a list you can read in one glance. Quality over quantity is the v2 rule.
**3. Your dollar travels through an adapter.** The vault never calls Morpho, Aave, or Lido directly. It calls an Onchain Adapter: a small, immutable contract built for one job. For example, the Lido adapter can stake WETH into stETH, request an unstake, and claim the withdrawal back as WETH. That is its entire vocabulary. It cannot call arbitrary contracts, cannot be upgraded, always returns funds to the vault it serves, and resets its approvals to zero after every use.
**4. The amount is capped before it leaves.** The Approval Registry fixes, onchain and behind the timelock, the maximum of each asset a given vault can approve to a given contract: for example, the yoETH vault to the Lido adapter, up to 500 WETH. A request outside the predefined vault, asset, contract, and amount is simply rejected.
**5. Every move is simulated first.** Before any transaction is submitted, YO replays it against live chain state and inspects the result: every transfer, every balance change. If the outcome differs from the intent, it is rejected before it is ever sent. Trades are checked for price impact and slippage, automated co-signers screen for unexpected flows and recipients, and an Oracle Guard validates share prices against a rolling anchor so a manipulated price can't be acted on.
**6. If it crosses chains, the loop crosses with it.** Each bridge gets its own immutable adapter. The CCTP adapter moves native USDC through Circle's CCTP and nothing else, with the token pinned at deployment, fees capped in code, and no funds ever held between transactions. The Bridge Route Registry allowlists every route down to the vault, token, destination chain, and recipient. Same asset in, same asset out.
**7. It comes home.** When you withdraw, the vault unwinds through the same adapters it entered by, funds return to the vault, and your yoUSD Edge is redeemed for USDC in your wallet. That is the loop: one way in, one way out, and no way to redirect either.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.yo.xyz/protocol/yo-v2-security-framework.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
