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

# System Design

Lucidly Yields is built on the [boring-vault](https://github.com/veda-Labs/boring-vault/) architecture built and pioneered by Veda Labs.

* Users can mint `syAssets` in a single atomic transaction using whitelisted tokens. Withdrawals are asynchronous and take 6-24 hours to process in the current production setup.
* Underlying deposits are allocated to select strategies by strategist roles and are segregated by risk and liquidity profiles, i.e., a strategist whitelisted to `supply`/`withdraw` USDC from AaveV3 can only do that and nothing else.
* `syAssets` are deployed on multiple networks and can use generic interop protocols - ccip, layerzero, wormhole etc.

The protocol stack consists of 2 components - 

* onchain - The smart contracts powering syTokens are built on the [boring-vault](https://github.com/veda-Labs/boring-vault/) architecture built and pioneered by Veda Labs.
* offchain - Asset management and relayer services for transaction creation and handling used to interact with the smart contract layer.

#### Onchain Stack

<div align="left" data-full-width="false"><figure><img src="/files/0Ige8knyCn2z6QvzvHFm" alt=""><figcaption></figcaption></figure></div>

#### Flow of funds

<figure><img src="/files/FbLmbVWPN9Ub6wFw31sY" alt=""><figcaption><p>deposit flow</p></figcaption></figure>

<figure><img src="/files/Iy5TKZlIhAZDKVdleyTz" alt=""><figcaption><p>allocation flow</p></figcaption></figure>

<figure><img src="/files/nFeiLTTNpTy7yl2QsL10" alt=""><figcaption><p>redemption flow</p></figcaption></figure>

#### Offchain stack&#x20;

* **AUM service** - Handles accounting for global assets and liabilities using oracles and updates `exchangeRate` on the `Accountant` smart contract.
* **Solver service** - Monitors pending withdrawal requests on the `Queue` smart contract and processes them.
* **Manager service** - The core and the most important part of the stack, is used to create transactions based on offchain algorithms and restricted calldata, prepares merkle proofs and interacts with the `Manager` smart contract.

{% code title="example\_manager\_script.py" %}

```python
for leaf in all_leafs:
    if (leaf.target.lower() == from_token.lower()
        and leaf.signature == "approve(address,uint256)"
        and leaf.argument_addresses[0].lower() == swap_tx["to"].lower()):
        approve_leaf = leaf

    elif (leaf.signature == "swapCompact()"
          and leaf.argument_addresses[1].lower() == to_token.lower()
          and leaf.argument_addresses[2].lower() == self.boring_vault_address.lower()
          and leaf.argument_addresses[3].lower() == odos_executor.lower()):
        swap_leaf = leaf

if not approve_leaf or not swap_leaf:
    raise ValueError("Valid leafs not found in Merkle tree.")

proofs = _get_proofs_using_tree([approve_leaf, swap_leaf], tree)

tx = await self.manager.functions.manageVaultWithMerkleVerification(
    proofs,
    [self.sanitizer_address] * 2,
    [from_token, swap_tx["to"]],
    [self.encode_approve(swap_tx["to"], 2**256 - 1), swap_tx["data"]],
    [0, 0]
).build_transaction({
    "from": self.account.address,
    "nonce": await self.w3.eth.get_transaction_count(self.account.address),
})
```

{% endcode %}

A `sanitizer` parameter is used when creating transactions that restricts addresses included in calldata based on an ADMIN\_ROLE set preset.

Github link - <https://github.com/lucidlylabs/boring-vault>

We welcome new strategists to ideate on novel onchain yield strategies, DM us on X or send an email to <hello@lucidly.finance> for support.


---

# 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 dynamically by asking a question.

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

```
GET https://docs.lucidly.finance/system-design.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.