> For the complete documentation index, see [llms.txt](https://docs.ensemble.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ensemble.io/how-it-works/capital-deployment-and-rebalancing.md).

# Capital deployment and rebalancing

How vaults move USDC and adjust positions toward their configured exposure.

The vault divides capital between cash for withdrawals and collateral for trading. It moves money and adjusts positions as needed, but those maintenance actions take time to settle. A submitted request and a confirmed result are separate steps.

## Moving capital

Capital deployment moves USDC between the withdrawal buffer and the trading account. The vault records a transfer as pending until it can confirm settlement.

```mermaid
flowchart LR
    Buffer["EVM USDC buffer"] -->|"Excess above target"| Deploy["deployCapital"]
    Deploy --> Bridge["EVM-to-Core action"]
    Bridge --> Pending["Pending bridge state"]
    Pending -->|"Observed settled"| Confirm["confirm bridge"]
    Pending -->|"Timeout"| Cancel["cancel stale bridge"]
```

The vault aims to keep its configured cash buffer on HyperEVM. Eligible excess can move to HyperCore; a shortfall can trigger a request to bring trading capital back. The buffer is a target, so pending work and market changes can make the actual cash balance differ.

For accounting, the return path preserves a configured Core reserve. For a requested return `x`, the transfer from perpetual collateral to Core spot USDC is `x + max(configured reserve - existing Core spot USDC, 0)`. Sending `x` onward adds only the missing reserve and preserves existing spot capital. The funded reserve is excluded from shareholder NAV once.

## Rebalancing

Rebalancing adjusts positions when the strategy becomes eligible for maintenance. Orders may fill only partly, so the vault checks the resulting positions before confirming completion.

```mermaid
stateDiagram-v2
    [*] --> Balanced
    Balanced --> Eligible: "interval or drift threshold"
    Eligible --> Pending: "submit IOC orders"
    Pending --> Balanced: "confirm observed positions"
    Pending --> Cancelled: "confirmation timeout"
    Cancelled --> Eligible: "policy allows retry"
    Balanced --> Emergency: "unsafe condition"
```

All six production vaults currently use a four-hour routine interval and a 10% drift threshold. An interval is an eligibility setting, not a promise that trading will complete on schedule. Larger drift can open an urgent path, and unsafe margin can trigger emergency handling. The raw portfolio target is NAV times target leverage; the EVM cash buffer is not an additional discount to that leverage. Execution costs adjust the common target before orders are placed.

## Execution safety

The vault can reduce or defer an order when execution conditions or available margin do not meet its policy.

The contract can limit acceptable prices, split orders into smaller amounts, and reduce retry size after failed attempts. A wide spread, insufficient margin, or another safety check can delay an order. Each increase must be safe if it fills independently; it cannot assume that a different order has already released collateral.

An exposure target can remain unmet for these reasons even when automation is working. Read the current eligibility and pending state before treating the gap as an automation failure.

## Asynchronous confirmation

The initiating EVM receipt proves that an action was submitted, not that HyperCore state already reflects it. Public status should distinguish requested, pending, confirmed, cancelled, and failed.