> ## Documentation Index
> Fetch the complete documentation index at: https://docs.superform.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Strategy Canvas

> Build, order, run, and monitor automated SuperVault strategies.

The Strategy Canvas is where managers define automated vault behavior. Strategies evaluate rules on ticks and dispatch DeFiX intents to the OMS when conditions pass.

The canvas is organized by action lane:

| Lane      | Actions                       | Purpose                                |
| --------- | ----------------------------- | -------------------------------------- |
| Inflow    | `DEPOSIT`                     | Deploy idle assets into yield sources  |
| Outflow   | `WITHDRAWAL`, `CLAIM`         | Source liquidity and claim proceeds    |
| Rebalance | `REBALANCE`, `SWAP`, `BRIDGE` | Move capital between sources or routes |

## Strategy Lifecycle

| State      | Meaning                                          |
| ---------- | ------------------------------------------------ |
| `CREATED`  | Drafted but not active                           |
| `IDLE`     | Ready but not ticking                            |
| `RUNNING`  | Evaluating rules and eligible to publish intents |
| `ERROR`    | Runtime error; inspect logs/events               |
| `ARCHIVED` | Soft-deleted                                     |

The Strategy Engine API currently models these states directly. Vault-level kill switches and emergency locks can still prevent a strategy from publishing even when the stored state is `RUNNING`.

## Create or Update a Strategy

A strategy contains:

* Name.
* Indicators.
* Rule tree.
* Action config.
* Conviction config.
* Risk parameters.
* Cooldown and concurrency controls.

Create and update calls do **not** carry priority. Ordering is handled by the dedicated reorder endpoint.

Updates require a `version` for optimistic concurrency. A stale version returns `409 Conflict`.

## Rule Trees

Rules are boolean trees:

| Node   | Meaning                   |
| ------ | ------------------------- |
| `EXPR` | Evaluate one expression   |
| `AND`  | All children pass         |
| `OR`   | At least one child passes |
| `NOT`  | Negate one child          |
| `VOTE` | N-of-M children pass      |

Conviction config can require repeated passing ticks before publishing an intent.

## Action Config

Action config tells the engine what to do after rules pass. Common fields include:

* `action`
* `size_expr`
* `objective`
* `execution_name`
* `execution_address`
* `target_address`
* `from_address`
* `target_type`
* `execution_params`
* `max_slippage_bps`

A target must be whitelisted and authorized by the active merkle root before OMS execution can succeed.

## Reorder Strategies

Drag within a lane to change priority. The UI persists order through:

```bash theme={null}
POST /api/v1/strategies/reorder
```

The request includes `vault_id`, `lane`, and the complete ordered list of non-archived strategy IDs for that lane. The backend atomically assigns priorities `1..N` from list position.

<Note>
  The ordered list must include every non-archived strategy in the lane exactly once. Priority is server-managed; create and update requests no longer set it.
</Note>

## Emergency Locks

Emergency liquidity exits create target-scoped locks. While a lock exists for a yield source address:

* User-defined strategies targeting that address cannot publish new intents.
* Affected toggles and reorder handles are disabled in the UI.
* Strategies on other targets remain operable.
* The paired `EMERGENCY_EXIT` strategy is controlled from [Pause Operations](/curate/ui/pause), not the normal editor.

The canvas reads `emergency_locks` from shard / vault state and displays a banner when active.

## Intent History

The Intent History view is the operator-facing execution ledger for strategies. It maps Strategy Engine projections to OMS events and fills.

Use it to answer:

* Which strategy created the intent?
* What lifecycle state is it in?
* Which OMS events have arrived?
* Were fills mined?
* What gas was used?
* Which transaction hash settled the fill?

Prefer the search endpoint for new tooling:

```bash theme={null}
GET /api/v1/intents
GET /api/v1/intents/{intent_id}/events
GET /api/v1/intents/{intent_id}/fills
GET /api/v1/fills
```

See [Strategy Engine API](/curate/api/strategy) and [OMS API](/curate/api/oms).

## Session Key Gate

Strategies need OMS execution readiness. If a vault lacks a valid session key, the canvas blocks automation and points managers to grant or renew the key.

See [OMS API](/curate/api/oms#session-keys) for the session-key endpoints.

## API Reference

| Endpoint                                 | Method | Description                          |
| ---------------------------------------- | ------ | ------------------------------------ |
| `/api/v1/strategies`                     | GET    | List strategies with filters         |
| `/api/v1/strategies`                     | POST   | Create strategy                      |
| `/api/v1/strategies/{id}`                | GET    | Get strategy                         |
| `/api/v1/strategies/{id}`                | PUT    | Update strategy with version         |
| `/api/v1/strategies/{id}`                | DELETE | Archive strategy                     |
| `/api/v1/strategies/{id}/state`          | PATCH  | Transition lifecycle state           |
| `/api/v1/strategies/reorder`             | POST   | Persist lane order                   |
| `/api/v1/intents`                        | GET    | Search intent history                |
| `/api/v1/intents/facets`                 | GET    | Intent filter facets                 |
| `/api/v1/intents/{intent_id}/events`     | GET    | OMS event timeline                   |
| `/api/v1/intents/{intent_id}/fills`      | GET    | Fills for one intent                 |
| `/api/v1/fills`                          | GET    | Search fills across intents          |
| `/api/v1/engine/shards/{vault_id}/state` | GET    | Live shard state and emergency locks |
