From dc9581c8babc1e757dd4d568fa46e56a2cad72f2 Mon Sep 17 00:00:00 2001 From: nje <8985830+Nalon@users.noreply.github.com> Date: Thu, 13 Aug 2026 02:23:54 -0700 Subject: [PATCH 1/6] update Confidential Workflows overview and private beta callouts --- src/content/cre-templates/ai-audit-firewall.mdx | 3 ++- .../cre-templates/automated-liquidation-protection.mdx | 3 ++- .../cre-templates/automated-portfolio-rebalancing.mdx | 3 ++- src/content/cre/concepts/confidential-workflows.mdx | 7 ++++--- src/content/cre/llms-full-go.txt | 7 ++++--- src/content/cre/llms-full-ts.txt | 7 ++++--- 6 files changed, 18 insertions(+), 12 deletions(-) diff --git a/src/content/cre-templates/ai-audit-firewall.mdx b/src/content/cre-templates/ai-audit-firewall.mdx index 6b28b707db0..eafd01b509b 100644 --- a/src/content/cre-templates/ai-audit-firewall.mdx +++ b/src/content/cre-templates/ai-audit-firewall.mdx @@ -23,7 +23,8 @@ import { Aside } from "@components" This standalone CRE project implements a confidential pre-execution security firewall for smart contract interactions. diff --git a/src/content/cre-templates/automated-liquidation-protection.mdx b/src/content/cre-templates/automated-liquidation-protection.mdx index c9eb2b18933..2b87c239fe4 100644 --- a/src/content/cre-templates/automated-liquidation-protection.mdx +++ b/src/content/cre-templates/automated-liquidation-protection.mdx @@ -23,7 +23,8 @@ import { Aside } from "@components" This standalone CRE project implements a confidential liquidation-defense workflow for DeFi lending positions. diff --git a/src/content/cre-templates/automated-portfolio-rebalancing.mdx b/src/content/cre-templates/automated-portfolio-rebalancing.mdx index 0b3feb789e7..1606df1228d 100644 --- a/src/content/cre-templates/automated-portfolio-rebalancing.mdx +++ b/src/content/cre-templates/automated-portfolio-rebalancing.mdx @@ -23,7 +23,8 @@ import { Aside } from "@components" This standalone CRE project implements a confidential portfolio rebalancing workflow for crypto allocations. diff --git a/src/content/cre/concepts/confidential-workflows.mdx b/src/content/cre/concepts/confidential-workflows.mdx index 16564a9deb7..37eb128b279 100644 --- a/src/content/cre/concepts/confidential-workflows.mdx +++ b/src/content/cre/concepts/confidential-workflows.mdx @@ -10,7 +10,7 @@ metadata: import { Aside } from "@components" -A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. +A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. Confidential Workflows serve as the confidential compute foundation to unlock Private Smart Contracts, where encrypted transactions are processed through confidential offchain computation and resulting state is committed onchain or other DA layers. Confidential Workflows are fundamentally standard CRE workflows with an explicit confidential execution path added where you need it, composing freely with standard workflow logic in the same application. Secrets fetched inside the enclave, and any computation you mark as confidential, are intended to remain confidential from node operators during execution. You decide what stays inside the enclave and what crosses back out to the Workflow DON for consensus-verified execution, such as generating a report to submit onchain. @@ -18,10 +18,11 @@ For hands-on steps, jump straight to [Making a Workflow Confidential](/cre/guide -## Where this fits in CRE +## Where this Ifits in CRE If you're new to CRE workflows, start with [Getting Started](/cre/getting-started/overview) to build a standard workflow first—one where your handler's logic runs on Workflow DON nodes like any other capability call. Confidential Workflows extends that same model: once you're comfortable with handlers, triggers, and callbacks, this page and the [guide](/cre/guides/workflow/using-confidential-workflows) show you how to carve out a confidential execution path for the parts of a workflow that need it, without changing how the rest of your workflow is built, deployed, or operated. diff --git a/src/content/cre/llms-full-go.txt b/src/content/cre/llms-full-go.txt index 1100a05c75c..5e84150f95d 100644 --- a/src/content/cre/llms-full-go.txt +++ b/src/content/cre/llms-full-go.txt @@ -8374,7 +8374,7 @@ CRE has two features designed to keep part of a workflow confidential from Workf Source: https://docs.chain.link/cre/concepts/confidential-workflows Last Updated: 2026-07-28 -A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. +A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. Confidential Workflows serve as the confidential compute foundation to unlock Private Smart Contracts, where encrypted transactions are processed through confidential offchain computation and resulting state is committed onchain or other DA layers. Confidential Workflows are fundamentally standard CRE workflows with an explicit confidential execution path added where you need it, composing freely with standard workflow logic in the same application. Secrets fetched inside the enclave, and any computation you mark as confidential, are intended to remain confidential from node operators during execution. You decide what stays inside the enclave and what crosses back out to the Workflow DON for consensus-verified execution, such as generating a report to submit onchain. @@ -8382,10 +8382,11 @@ For hands-on steps, jump straight to [Making a Workflow Confidential](/cre/guide -## Where this fits in CRE +## Where this Ifits in CRE If you're new to CRE workflows, start with [Getting Started](/cre/getting-started/overview) to build a standard workflow first—one where your handler's logic runs on Workflow DON nodes like any other capability call. Confidential Workflows extends that same model: once you're comfortable with handlers, triggers, and callbacks, this page and the [guide](/cre/guides/workflow/using-confidential-workflows) show you how to carve out a confidential execution path for the parts of a workflow that need it, without changing how the rest of your workflow is built, deployed, or operated. diff --git a/src/content/cre/llms-full-ts.txt b/src/content/cre/llms-full-ts.txt index a3056a24fb1..d5afc603409 100644 --- a/src/content/cre/llms-full-ts.txt +++ b/src/content/cre/llms-full-ts.txt @@ -8197,7 +8197,7 @@ CRE has two features designed to keep part of a workflow confidential from Workf Source: https://docs.chain.link/cre/concepts/confidential-workflows Last Updated: 2026-07-28 -A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. +A **Confidential Workflow** is a CRE [workflow](/cre/key-terms#workflow) that designates part of its logic to run inside a secure [enclave](/cre/key-terms#enclave)—a running instance of a [Trusted Execution Environment (TEE)](/cre/key-terms#tee-trusted-execution-environment), a hardware-isolated environment designed to keep the computation and data it processes confidential from the machine's own operator during execution—instead of on Workflow DON nodes. Confidential Workflows serve as the confidential compute foundation to unlock Private Smart Contracts, where encrypted transactions are processed through confidential offchain computation and resulting state is committed onchain or other DA layers. Confidential Workflows are fundamentally standard CRE workflows with an explicit confidential execution path added where you need it, composing freely with standard workflow logic in the same application. Secrets fetched inside the enclave, and any computation you mark as confidential, are intended to remain confidential from node operators during execution. You decide what stays inside the enclave and what crosses back out to the Workflow DON for consensus-verified execution, such as generating a report to submit onchain. @@ -8205,10 +8205,11 @@ For hands-on steps, jump straight to [Making a Workflow Confidential](/cre/guide -## Where this fits in CRE +## Where this Ifits in CRE If you're new to CRE workflows, start with [Getting Started](/cre/getting-started/overview) to build a standard workflow first—one where your handler's logic runs on Workflow DON nodes like any other capability call. Confidential Workflows extends that same model: once you're comfortable with handlers, triggers, and callbacks, this page and the [guide](/cre/guides/workflow/using-confidential-workflows) show you how to carve out a confidential execution path for the parts of a workflow that need it, without changing how the rest of your workflow is built, deployed, or operated. From 861ae57cc67755f57fd7075e07e4a6ccb2d14c2f Mon Sep 17 00:00:00 2001 From: nje <8985830+Nalon@users.noreply.github.com> Date: Thu, 13 Aug 2026 02:28:49 -0700 Subject: [PATCH 2/6] added note about best practices --- src/content/cre/concepts/confidential-workflows.mdx | 3 ++- src/content/cre/llms-full-go.txt | 3 ++- src/content/cre/llms-full-ts.txt | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/content/cre/concepts/confidential-workflows.mdx b/src/content/cre/concepts/confidential-workflows.mdx index 37eb128b279..b414833f5ef 100644 --- a/src/content/cre/concepts/confidential-workflows.mdx +++ b/src/content/cre/concepts/confidential-workflows.mdx @@ -70,7 +70,8 @@ You remain responsible for not leaking confidential information back out through -This standalone CRE project implements a confidential portfolio rebalancing workflow for crypto allocations. +## What this template does -## Description +This CRE workflow implements a confidential portfolio rebalancing system for crypto allocations. It runs on a cron schedule, continuously monitors the drift between current and target asset weights, and automatically executes trades to restore the portfolio when a configurable threshold is exceeded. Exchange credentials, LLM reasoning, target allocations, and all execution preferences remain protected inside confidential execution. -The workflow continuously tracks allocation drift and triggers rebalancing when policy thresholds are exceeded. It -is designed to restore user-defined target weights while protecting sensitive operational inputs, including -exchange credentials, model credentials, policy thresholds, and execution preferences inside confidential execution. +**Data flow:** -## Target Customer +1. Fetch current portfolio state: holdings, asset prices, volatility index, and stablecoin reserve depth. +2. Calculate per-asset allocation drift from configured target weights (BTC, ETH, USDC). +3. If maximum drift across all assets is below the policy threshold, exit with `NOOP` and take no action. +4. Send portfolio state and policy to an LLM reasoning model for trade selection. +5. Reconcile LLM-proposed trades against policy constraints: venue overrides and slippage caps take precedence over LLM suggestions. +6. Reject any trade that would breach the reserve floor. Cap oversized trades and split them into chunks. +7. Separate trades into on-chain and off-chain execution routes and submit the full plan to the execute API. -- Professional retail traders -- Developer shops -- Founders building trading products +## Policy Constraints and Risk Flags -## Structure +### Policy constraints -- `project.yaml`: project-level target settings -- `secrets.yaml`: secret ID mappings used by the workflow -- `mock-server.js`: local deterministic API server -- `automated-portfolio-rebalancing-ts/`: TypeScript workflow implementation -- `automated-portfolio-rebalancing-go/`: Go workflow implementation +All policy values are loaded from secrets at runtime and enforced before any trade is submitted to the execute API. -## Private Inputs +| Constraint | Description | +| ------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | +| Target allocations | Target weight for each asset as a decimal (e.g., `0.5` = 50% BTC). All three values must sum to `1.0`. | +| Drift threshold | Minimum drift percentage that triggers a rebalance. The workflow exits with `NOOP` if no asset exceeds this. | +| Maximum trade size | Per-chunk trade size cap in USD. Trades above this are split into equal-sized chunks. | +| Reserve floor | Minimum USDC that must remain after all buy trades. Buy capacity is reduced to protect the floor; trades that breach it are rejected. | +| Slippage limit | Maximum acceptable slippage in basis points. LLM-proposed slippage values are clamped to this ceiling. | +| Trade ordering | Sequence in which trades execute: `sells-first`, `buys-first`, or `model-order` | +| Preferred venues | Comma-separated venue priority list used when the LLM does not specify a venue | -The following inputs are handled as confidential: +### Drift monitoring -- Exchange API credentials used to read holdings, reserve data, and execution context, including stablecoin reserve depth and cash balance. -- LLM reasoning API credentials. -- Portfolio policy settings such as target allocation mix, minimum drift threshold, maximum trade size per execution, and required stablecoin reserve floor. -- Execution preferences such as venue priority, slippage limits, and trade chunking/ordering behavior. +The workflow computes allocation drift for each asset and triggers a rebalance when any asset exceeds the threshold: -## Workflow Notes +``` +currentWeight = assetValueUsd / totalPortfolioValueUsd +drift = |currentWeight − targetWeight| × 100 +``` + +If `maxDrift < driftThresholdPct` across all assets, the workflow exits with `NOOP`. Otherwise, it builds sell orders for overweight assets and buy orders for underweight assets. + +### Trade execution guardrails + +- **Reserve floor**: Buy capacity is computed as `stablecoinReserve − reserveFloor + totalPlannedSellUsd`. Trades that would cause the reserve to drop below the floor are rejected. +- **Slippage**: Each trade's slippage is clamped to `min(llmProposed, maxSlippageBps)`. +- **Trade chunking**: Trades larger than `maxTradeUsd` are split into chunks of up to `maxTradeUsd` each (the final chunk may be smaller), tracked with `chunkIndex` and `chunkCount`. +- **LLM reconciliation**: LLM-proposed trade symbols and directions must align with policy-computed targets. Policy venue and slippage values override LLM suggestions when they conflict. -1. Monitor portfolio state. - The workflow gathers market prices, current asset weights, drift from target allocations, reserve health, and volatility signals. -2. Enforce user-defined portfolio constraints. - Confidential reasoning validates weight constraints, drift triggers, rebalance sizing limits, reserve protection requirements, and slippage controls. -3. Build a rebalance action plan. - The plan can include buying underweight assets, selling overweight assets, enforcing reserve floors, capping per-trade notionals, and optimizing execution through chunking and smart venue routing. -4. Execute rebalance actions across venues. - Depending on route selection, the workflow can execute both on-chain operations (such as swaps) and off-chain operations (such as centralized exchange API trades). +## Prerequisites -Note: Reasoning stages can be implemented with deterministic rule-based logic instead of an LLM when a fully rules-driven execution model is preferred. +- [Bun](https://bun.sh) runtime +- CRE CLI (`cre`) +- An exchange or portfolio API that exposes current holdings, asset prices, and reserve data +- An LLM API endpoint for reasoning (e.g., an OpenAI-compatible endpoint) -## Required Environment Variables +## Configuration -Copy `.env.example` to `.env` and provide values for: +The workflow ships with two config files: -- `CRE_ETH_PRIVATE_KEY` (optional for local simulate) -- `MOCK_PORT` -- `MOCK_EXCHANGE_API_KEY` -- `MOCK_OPENAI_API_KEY` -- `MOCK_REBALANCING_TARGET_ALLOCATION_BTC_PCT` -- `MOCK_REBALANCING_TARGET_ALLOCATION_ETH_PCT` -- `MOCK_REBALANCING_TARGET_ALLOCATION_USDC_PCT` -- `MOCK_REBALANCING_DRIFT_THRESHOLD_PCT` -- `MOCK_REBALANCING_MAX_TRADE_USD` -- `MOCK_REBALANCING_RESERVE_FLOOR_USDC` -- `MOCK_REBALANCING_MAX_SLIPPAGE_BPS` -- `MOCK_REBALANCING_PREFERRED_VENUES` -- `MOCK_REBALANCING_ORDER_SEQUENCE_PREFERENCE` +- `automated-portfolio-rebalancing-ts/config.staging.json` (TypeScript) and `automated-portfolio-rebalancing-go/config.staging.json` (Go): targets mock server endpoints +- `automated-portfolio-rebalancing-ts/config.production.json` (TypeScript) and `automated-portfolio-rebalancing-go/config.production.json` (Go): same structure with empty URLs for you to populate -The local mock server for this project only exposes routes under `/rebalancing/*`. +Key fields: -**Quick navigation:** +| Field | Description | +| --------------- | ----------------------------------------------------------- | +| `schedule` | Cron expression. Default: `0 */5 * * * *` (every 5 minutes) | +| `mock_base_url` | Base URL for the exchange or portfolio API | +| `openai_url` | LLM reasoning endpoint | +| `openai_model` | Model identifier (e.g., `gpt-4.1-mini`) | +| `secrets_ids.*` | Secret IDs for API keys and all policy parameters | -- [TypeScript Quick Start](#typescript-quick-start) -- [Go Quick Start](#go-quick-start) +## Secrets -## TypeScript Quick Start +Copy `.env.example` to `.env` and populate all values before running locally. The workflow enforces a strict limit of exactly 11 secrets and 5 HTTP calls per invocation. + +| Environment variable | Secret ID | Purpose | +| --------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------- | +| `MOCK_EXCHANGE_API_KEY` | `exchange_api_key` | Authenticates exchange API requests | +| `MOCK_OPENAI_API_KEY` | `openai_api_key` | Authenticates LLM reasoning API requests | +| `MOCK_REBALANCING_TARGET_ALLOCATION_BTC_PCT` | `rebalancing_target_allocation_btc_pct` | Target BTC weight as a decimal (e.g., `0.5`) | +| `MOCK_REBALANCING_TARGET_ALLOCATION_ETH_PCT` | `rebalancing_target_allocation_eth_pct` | Target ETH weight as a decimal (e.g., `0.3`) | +| `MOCK_REBALANCING_TARGET_ALLOCATION_USDC_PCT` | `rebalancing_target_allocation_usdc_pct` | Target USDC weight as a decimal (e.g., `0.2`) | +| `MOCK_REBALANCING_DRIFT_THRESHOLD_PCT` | `rebalancing_drift_threshold_pct` | Drift percentage that triggers rebalancing (e.g., `5`) | +| `MOCK_REBALANCING_MAX_TRADE_USD` | `rebalancing_max_trade_usd` | Maximum USD per trade chunk (e.g., `5000`) | +| `MOCK_REBALANCING_RESERVE_FLOOR_USDC` | `rebalancing_reserve_floor_usdc` | Minimum USDC to keep in reserve (e.g., `2000`) | +| `MOCK_REBALANCING_MAX_SLIPPAGE_BPS` | `rebalancing_max_slippage_bps` | Maximum slippage in basis points (e.g., `50`) | +| `MOCK_REBALANCING_PREFERRED_VENUES` | `rebalancing_preferred_venues` | Comma-separated venue list (e.g., `binance,coinbase,onchain`) | +| `MOCK_REBALANCING_ORDER_SEQUENCE_PREFERENCE` | `rebalancing_order_sequence_preference` | `model-order`, `sells-first`, or `buys-first` | +| `CRE_ETH_PRIVATE_KEY` | _(framework-level)_ | Optional for local simulation. Required for on-chain swap execution. | + +## Quick start + +**TypeScript** + +Run all commands from the `automated-portfolio-rebalancing` directory (the project root). 1. Install dependencies -```bash -bun install -``` + ```bash + cd automated-portfolio-rebalancing-ts && bun install && cd .. + ``` 2. Create environment file -```bash -cp .env.example .env -``` + ```bash + cp .env.example .env + ``` 3. Start mock server -```bash -bun run mock:server -``` + ```bash + cd automated-portfolio-rebalancing-ts && bun run mock:server + ``` -4. In another terminal, run checks +4. In another terminal, run checks and simulate -```bash -bun run typecheck -bun run test -``` + ```bash + cd automated-portfolio-rebalancing-ts + bun run typecheck + bun run test + cd .. && cre workflow simulate ./automated-portfolio-rebalancing-ts --project-root ./ --target=staging-settings --env ./.env + ``` -5. Simulate workflow +**Go** -```bash -cre workflow simulate ./automated-portfolio-rebalancing-ts --target=staging-settings -``` +Run all commands from the `automated-portfolio-rebalancing` directory (the project root). -## Go Quick Start +1. Create environment file -1. Create environment file (at the shared project root) + ```bash + cp .env.example .env + ``` -```bash -cp ../.env.example ../.env -``` +2. Start the mock server from the TypeScript directory (requires Node or Bun) -2. Start the mock server (requires Node or Bun) + ```bash + cd automated-portfolio-rebalancing-ts && bun run mock:server + ``` -```bash -bun mock-server.js -``` +3. In another terminal, run checks and simulate -3. In another terminal, run checks + ```bash + cd automated-portfolio-rebalancing-go + go vet ./... + go test ./... + cd .. && cre workflow simulate ./automated-portfolio-rebalancing-go --project-root ./ --target=staging-settings --env ./.env + ``` -```bash -go vet ./... -go test ./... -``` +## Production checklist -4. Simulate workflow +- Populate `config.production.json` with real `mock_base_url` and `openai_url`. +- Register all 11 secrets in the CRE secrets manager and verify secret IDs match those defined in `config.production.json` under `secrets_ids`. +- Confirm target allocation secrets sum to `1.0` across BTC, ETH, and USDC before registering. +- Set `MOCK_REBALANCING_RESERVE_FLOOR_USDC` to a value that provides a meaningful liquidity buffer for your portfolio size. +- Set `CRE_ETH_PRIVATE_KEY` if on-chain swap routes are enabled. +- Confirm the exchange API returns the expected portfolio state schema before deploying. +- Run `bun run typecheck && bun run test` (TypeScript) or `go vet ./... && go test ./...` (Go) before registering. +- Run `cre workflow simulate` against production endpoints to validate end-to-end behavior. +- Register the workflow: + - TypeScript: `cre workflow register ./automated-portfolio-rebalancing-ts --project-root ./ --target=production-settings` + - Go: `cre workflow register ./automated-portfolio-rebalancing-go --project-root ./ --target=production-settings` -```bash -cd .. && cre workflow simulate ./automated-portfolio-rebalancing-go --target=staging-settings -``` +## Troubleshooting + +**Workflow exits with NOOP** + +This is expected behavior when allocation drift is below the configured threshold. Check current versus target allocations and compare against `MOCK_REBALANCING_DRIFT_THRESHOLD_PCT`. Lower the threshold value to trigger rebalancing more frequently. + +**Reserve floor breach error** + +If you see `trade X breaches reserve floor: projected Y < floor Z`, a planned buy trade would consume too much of the stablecoin reserve. Decrease `MOCK_REBALANCING_RESERVE_FLOOR_USDC`, reduce `MOCK_REBALANCING_MAX_TRADE_USD`, or reduce the proportion of buy trades. + +**Config validation error** + +If you see `config requires schedule, mock_base_url, openai_url, and openai_model`, one of those fields is missing from the active config file. Verify that all four fields are populated in `config.production.json` (or `config.staging.json`). + +**LLM response format mismatch** + +If the LLM response cannot be parsed, the model must return an `output_text` field containing a JSON object with `shouldRebalance`, `reasoning`, and `trades` fields. Check that your LLM endpoint returns this structure and that the API key is valid. + +**HTTP request failures** + +If you see `request failed status=4XX`, confirm the mock server is running and that `MOCK_EXCHANGE_API_KEY` and `MOCK_OPENAI_API_KEY` in `.env` match the values expected by the mock server. + +**Secrets must be finite numbers** + +If you see `secret X must be a finite number`, one of the numeric policy secrets was set to a non-numeric value. Confirm that all numeric environment variables in `.env` are valid floats or integers. + +## Optional on-chain delivery + +The workflow classifies each trade as on-chain or off-chain based on its venue field and builds a separate execution plan for each route: + +| Venue value | Classification | +| ---------------------------------------- | -------------- | +| `onchain` (exact match) | On-chain | +| Any value containing `uniswap` | On-chain | +| Any value containing `1inch` | On-chain | +| Any value containing `dex` | On-chain | +| All others (e.g., `binance`, `coinbase`) | Off-chain | + +The execute API request includes separate `onchain_trades` and `offchain_trades` arrays alongside the full unified `trades` list, letting your backend route each trade to the appropriate execution system independently. + +To enable on-chain swap execution: + +1. Set `CRE_ETH_PRIVATE_KEY` to a funded wallet private key or a 1Password reference (`op://vault/item/field`). +2. Add `"onchain"`, `"uniswap"`, or `"1inch"` to `MOCK_REBALANCING_PREFERRED_VENUES`. +3. Extend the execute endpoint to route on-chain trades to the appropriate DEX router (e.g., Uniswap `SwapRouter` or 1inch `AggregationRouterV5`). + +The staging config does not include an on-chain write target. For production on-chain execution, update `project.yaml` to include your target chain configuration. From ce45abfb91fbc7ea9fc730b9db60de4e4753d942 Mon Sep 17 00:00:00 2001 From: nje <8985830+Nalon@users.noreply.github.com> Date: Mon, 17 Aug 2026 02:35:08 -0700 Subject: [PATCH 6/6] update liquidation protection and portfolio rebalancing pages --- .../automated-liquidation-protection.mdx | 12 ---------- .../automated-portfolio-rebalancing.mdx | 22 ------------------- 2 files changed, 34 deletions(-) diff --git a/src/content/cre-templates/automated-liquidation-protection.mdx b/src/content/cre-templates/automated-liquidation-protection.mdx index 137467e1ef4..41189a5b8f4 100644 --- a/src/content/cre-templates/automated-liquidation-protection.mdx +++ b/src/content/cre-templates/automated-liquidation-protection.mdx @@ -226,15 +226,3 @@ If you see `request failed status=4XX`, confirm the mock server is running (`bun **Workflow logs `liquidation-no-action`** This is expected behavior when the position is healthy. The log includes `proximity=X threshold=Y reason=Z` to confirm the position state and why no action was taken. - -## Optional on-chain delivery - -The workflow supports on-chain execution venues alongside centralized exchange execution. Actions that include `venue: "onchain"` in the LLM response are classified as on-chain trades and routed accordingly by the execute API. - -To enable on-chain execution: - -1. Set `CRE_ETH_PRIVATE_KEY` to a funded wallet private key or a 1Password reference (`op://vault/item/field`). -2. Add `"onchain"` to the `MOCK_LIQUIDATION_PREFERRED_VENUES` list. -3. Extend the execute endpoint integration to route on-chain actions to your lending protocol's smart contract interface. - -The staging config targets Ethereum Sepolia for testnet validation. Update `project.yaml` to target `ethereum-mainnet` for production on-chain execution. diff --git a/src/content/cre-templates/automated-portfolio-rebalancing.mdx b/src/content/cre-templates/automated-portfolio-rebalancing.mdx index 276e201a770..a9b5c781833 100644 --- a/src/content/cre-templates/automated-portfolio-rebalancing.mdx +++ b/src/content/cre-templates/automated-portfolio-rebalancing.mdx @@ -215,25 +215,3 @@ If you see `request failed status=4XX`, confirm the mock server is running and t **Secrets must be finite numbers** If you see `secret X must be a finite number`, one of the numeric policy secrets was set to a non-numeric value. Confirm that all numeric environment variables in `.env` are valid floats or integers. - -## Optional on-chain delivery - -The workflow classifies each trade as on-chain or off-chain based on its venue field and builds a separate execution plan for each route: - -| Venue value | Classification | -| ---------------------------------------- | -------------- | -| `onchain` (exact match) | On-chain | -| Any value containing `uniswap` | On-chain | -| Any value containing `1inch` | On-chain | -| Any value containing `dex` | On-chain | -| All others (e.g., `binance`, `coinbase`) | Off-chain | - -The execute API request includes separate `onchain_trades` and `offchain_trades` arrays alongside the full unified `trades` list, letting your backend route each trade to the appropriate execution system independently. - -To enable on-chain swap execution: - -1. Set `CRE_ETH_PRIVATE_KEY` to a funded wallet private key or a 1Password reference (`op://vault/item/field`). -2. Add `"onchain"`, `"uniswap"`, or `"1inch"` to `MOCK_REBALANCING_PREFERRED_VENUES`. -3. Extend the execute endpoint to route on-chain trades to the appropriate DEX router (e.g., Uniswap `SwapRouter` or 1inch `AggregationRouterV5`). - -The staging config does not include an on-chain write target. For production on-chain execution, update `project.yaml` to include your target chain configuration.