> For the complete documentation index, see [llms.txt](https://docs.lagoon.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.lagoon.finance/vault/cross-chain-vaults.md).
# Cross-chain vaults
Give investors on several chains access to a single strategy, using a main vault and sub-vaults.
A Lagoon vault lives on one chain. The same vault cannot be deployed across several chains and kept in sync.
When a strategy must be reachable from several chains, the pattern is a **vault of vaults**: one **main vault** on the chain where the strategy is executed, and one **sub-vault** per chain where investors are. Each sub-vault has a single allocation: the main vault.
{% hint style="info" %}
This is a custom setup. The [deployer interface](/vault/deploy-your-vault.md) deploys standalone vaults, the main/sub-vault wiring is done manually after deployment. Reach out [here](https://tally.so/r/nGBGyz) if you want support setting it up.
{% endhint %}
## Architecture
Assets are held in one place, the main vault on the hub chain. Every sub-vault is a **virtual vault**: its only asset is the main vault shares held by its own curator address on the hub chain. It exists to abstract the bridging away from investors, who deposit and redeem on their own chain, in their own asset, and never leave it.
An investor ends up holding sub-vault shares, main vault shares, or both, depending on where they deposited.
{% hint style="info" %}
**One curator, one address per vault and per chain**
The same entity curates every vault of the structure, but it operates through a distinct address for each vault on each chain:
* the **sub-vault address on the spoke chain** settles the sub-vault and sends the assets over the bridge,
* the **sub-vault address on the hub chain** receives them, deposits into the main vault, and holds the main vault shares,
* the **main vault address** receives the main vault assets and deploys them into the strategies.
Keeping them separate is what makes the accounting readable: the sub-vault position is exactly what its own address holds on the hub chain, and nothing else.
{% endhint %}
## Deposit flow
1. **Deposit in the sub-vault** — the investor submits a standard [async deposit request](/developer-hub/integration/async-deposit-flow.md) on their own chain.
2. **Settle: assets to the sub-vault address** — the curator settles the sub-vault batch, the assets land on the curator sub-vault address on the spoke chain.
3. **Bridge to the hub chain** — the assets are bridged to the curator sub-vault address on the hub chain.
4. **Deposit in the main vault** — that same address submits a deposit request on the main vault.
5. **Main shares to the sub-vault address** — once the main vault settles, that address claims the shares. They are the sub-vault's only asset.
6. **Assets to the main vault address** — the main vault sends the settled assets to its own curator address.
7. **Allocate to the strategies** — the main vault address deploys them, exactly as for a single-chain vault.
8. **Sub-vault shares to the investors** — after the sub-vault NAV is updated and the batch settled, investors claim their shares.
Investors already on the hub chain skip all of it:
9. **Direct deposit in the main vault** — a standard deposit request on the main vault.
10. **Shares to the direct investors** — claimed once the main vault settles, at the same price per share as the sub-vault address.
Two settlement cycles plus a bridge sit between a sub-vault request and the shares. Set the sub-vault settlement cadence accordingly.
## Redemption flow
Redemption runs the same path backwards.
1. **Request a redemption** — the investor submits a redemption request on the sub-vault.
2. **Redeem from the main vault** — the curator sub-vault address on the hub chain requests a redemption on the main vault for the corresponding amount.
3. **Unwind the strategies** — the main vault address frees the liquidity needed to settle the batch.
4. **Assets back to the main vault** — the main vault address returns them so the batch can settle.
5. **Assets to the sub-vault address** — the sub-vault address claims its share of the settled assets.
6. **Bridge back to the spoke chain** — the assets are bridged to the sub-vault address on the spoke chain.
7. **Settle the redemption batch** — the sub-vault NAV is updated, then the batch is settled.
8. **Return the assets to the investors** — investors claim on their own chain.
And for the investors on the hub chain:
9. **Direct redemption request** — submitted on the main vault.
10. **Assets to the direct investors** — claimed once the main vault settles, without bridge.
Liquidity on a sub-vault is bounded by the main vault redemption cycle: a sub-vault can never settle faster than the main vault it depends on.
## Valuation
**Each vault keeps its own NAV and its own price per share. Updating one does not propagate to the others.**
### Sub-vault
The sub-vault holds no strategy position. Its NAV is what its curator address holds on both chains, plus its position in the main vault:
```
subVaultNAV = underlying held by the curator sub-vault address on the spoke chain
+ underlying held by the curator sub-vault address on the hub chain
+ mainVaultShares × mainVaultPricePerShare
```
The first two lines cover the assets in transit: settled on the spoke chain but not yet bridged, or bridged but not yet deposited in the main vault. Omitting them under-reports the sub-vault price per share.
The sub-vault valuation provider reads the main vault price per share on the hub chain and pushes the resulting NAV to the sub-vault. See [Vault valuation](/vault/vault-valuation.md) for the update and settlement procedure.
### Main vault
The main vault is valued like any single-chain Lagoon vault:
```
mainVaultNAV = underlying held by the curator main vault address
+ value of the strategy positions
```
{% hint style="warning" %}
**These are theoretical NAVs**
Both formulas describe the standard setup. A specific configuration, several sub-vaults sharing an address, a different underlying on each chain, positions held outside the curator addresses, or fees charged at the sub-vault level, changes what has to be counted. Validate the computation against your own setup before running it in production.
{% endhint %}
## TVL
Assets deposited through a sub-vault increase the main vault `totalAssets`, and therefore the TVL of the hub chain. Aggregating the main vault TVL and the sub-vault TVLs would double count them.
## Trade-offs
* Investors never leave their chain, and the strategy is executed once, in one place.
* Deploying several vaults adds no cost to a Lagoon setup.
* Latency: a deposit crosses two settlement cycles and a bridge before it is invested. Same for a redemption.
* Operational load: one NAV update process per sub-vault, plus the bridging.
