# Protocol Overview

CurveYield 2.0 is organized as modular liquidity infrastructure. Each layer can operate independently, but the system is designed so compatible layers reinforce one another.

## Five-layer model

| Layer                        | Function                                                                                                      |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------- |
| Liquidity Layer              | CurveYield DEX pools, pool creation, routing, settlement, creator fees, partner fees, and permanent liquidity |
| Vault Layer                  | Tokenized strategies that automate staking, reward collection, compounding, and strategy accounting           |
| Credit Layer                 | Lending and borrowing markets for approved productive collateral                                              |
| Cross-Chain Layer            | Vault-asset bridging and rate publishing across supported EVM chains                                          |
| Governance and Revenue Layer | DAO ownership, treasury routing, incentives, automation, and risk-parameter control                           |

## System flow

```
Users / Protocols / DAO
        |
        v
CurveYield DEX  <---->  Vault Layer  <---->  Credit Layer
        |                    |                  |
        v                    v                  v
Fee Settlement       Yield Strategies      Lending Markets
        |                    |                  |
        v                    v                  v
Permanent POL       Keepers / BoostHub     cyUSD / Borrow Liquidity
        |                    |                  |
        +----------> DAO Treasury <---------+
                         |
                         v
              Cross-Chain Governance
              Cross-Chain Vault Assets
```

## Product interaction

CurveYield does not require every product to use every layer. A pool can exist without a credit market. A vault can operate before it becomes collateral. A bridge route can support selected vault assets. A partner integration can use only the pieces it needs.

The system becomes more powerful when compatible layers are connected: vault shares can become pool assets, pool assets can become collateral, fees can build permanent liquidity, and DAO-owned positions can support deeper markets.

## User groups

| Group               | Main use                                                                                                                     |
| ------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| Users               | Access pools, vault shares, credit positions, and reward streams without manually operating every strategy step              |
| Liquidity providers | Provide liquidity to pools that may include incentives, yield-bearing assets, creator economics, or protocol-owned liquidity |
| Partner protocols   | Launch pools, build owned liquidity, route treasury assets, and connect productive assets into CurveYield infrastructure     |
| DAO participants    | Govern fees, treasuries, risk parameters, ownership paths, incentives, and product deployment priorities                     |

## How to read these docs

The [Executive Summary](/curveyield-summary.md) gives the shortest overview. Product pages explain specific systems. [Product Status](/reference/product-status.md), [Contracts](/reference/contracts.md), and [Risks](/reference/risks.md) are the source-of-truth reference pages for deployment status, public addresses, and risk disclosure.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.curveyield.com/protocol-overview.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.