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

# System Overview

Dream V2 combines an onchain wallet and funding layer with an offchain options execution system.

Trading is facilitated through institutional liquidity providers using a request-for-quote (RFQ) model.

### System Architecture

Dream's infrastructure consists of several components that handle funding, execution, position management, and settlement.

| Component           | Responsibility                                                                               | Boundary                                                                 |
| ------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| Onchain Wallet      | Holds onchain Cash and supports deposits, withdrawals, and wallet interactions.              | Wallet assets are separate from Buying Power and open options positions. |
| Buying Power        | Tracks funds available for options trading and receives proceeds from closes and settlement. | Managed through Dream's brokerage infrastructure.                        |
| RFQ Execution       | Requests executable quotes for specified options contracts and sizes.                        | Execution depends on available quotes.                                   |
| Position Management | Tracks open contracts, cost basis, position values, and P\&L.                                | Managing open positions depends on Dream's infrastructure.               |
| Settlement          | Processes cash-settlement payouts at expiration.                                             | Settlement follows the contract's expiry and pricing rules.              |

### Execution Architecture

Dream does not operate a traditional options order book.

Trade requests are routed to eligible institutional liquidity providers, which return executable quotes for the requested contract and size.

When a trade executes, the selected provider assumes the opposing market exposure.

Dream manages the user-facing brokerage experience, including trading balances, position tracking, and settlement.

### Custody Boundaries

Onchain wallet assets are held separately from funds allocated to options trading.\
\
If Dream’s frontend becomes unavailable, users may still access assets held in their onchain wallets through compatible external wallet software using exported keys. Buying Power and the management of open options positions depend on Dream’s brokerage infrastructure. Funds committed to open positions are held by the institutional counterparty, not in the user’s onchain wallet.

When users open options positions, funds committed to those positions are custodied by the institutional counterparty.

Exporting an onchain wallet's private key does not provide access to open options positions or their committed funds.

### Onchain and Offchain Responsibilities

**Onchain**

* Wallet balances
* Deposits
* Withdrawals
* Private-key access

**Offchain**

* Options quote requests
* Execution through institutional liquidity providers
* Buying Power management
* Position tracking

This separation allows Dream to combine onchain wallet functionality with institutional options execution.


---

# 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.dreamos.app/system-overview.md?ask=<question>&goal=<user_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.