Skip to main content

Roadmap

Internal Document

This page tracks the forward-looking architectural plan and open questions. It is intended for maintainers and contributors.

Immediate Priority — Sequential Pipeline Execution (v1)​

The parser/validation hardening phase is complete. The next priority is shipping sequential command execution on top of the stabilized dispatch boundary.

Current Scope (Proposed 2026-03-05)​

MilestoneDescription
1. Pipeline parser + interpolationAdd && step splitting, => $name capture parsing, and $name.field/$_ interpolation
2. CLI execution integrationRefactor executeCommandForTab() into reusable single-step and pipeline executors
3. Output normalizationAdd/standardize pipelineOutput on swap/bridge first, then lending flows
4. Tx-aware sequencingDefault post-transaction gating between steps, plus --dry-run and --confirm behaviors
5. 7702 preparationKeep backend boundary ready for delegated execution fallback per-step

Execution Rules (v1)​

  1. Abort on first failed step and report partial completion.
  2. Cross-fiber chaining is only allowed from global context.
  3. In active protocol context, cross-fiber steps are blocked.
  4. Confirm/cancel lifecycle remains the same for intent-backed write steps.

Recently Completed (March 2026)​

  1. Parser and validation architecture completed and merged.
  2. Dispatch boundary stabilized: parse -> rho resolve -> applyContract -> run.
  3. Parser diagnostics made non-fatal and shown as warnings.
  4. Validation execution moved before command run(); validation errors separated from execution errors.
  5. Contracts/schemas added across core commands and protocol plugins, including expanded Aave coverage.

Target Architecture — Headless Execution Engine​

The current architecture conflates the execution runtime with the CLI rendering component (cli.tsx). The target architecture separates them:

ExecutionEngine (headless)
├── Command resolution (π, ρ, ρ_f operators)
├── Command + handler lifecycle
├── Execution context / history management
├── Typed event emission
└── Per-tab queue / scheduling

Interface Adapters
├── CLI Adapter (text parsing + terminal rendering)
└── Desktop/UI Adapter (typed forms + graphical flow)

Design guardrails:

  1. UI must never bypass the execution engine for protocol operations.
  2. Text parsing remains CLI-specific; the runtime API remains typed.
  3. Plugin handlers return structured outputs, not UI-specific side effects.
  4. Logging is gated/structured (debugLog), not ad-hoc runtime noise.

Pipeline DSL — Phased Rollout (After Hardening)​

The sequential command DSL remains phased:

Phase A — Sequential Execution​

quote 1 eth usdc && swap 1 eth usdc
  • cmd1 && cmd2 syntax only.
  • Step 2 runs only if step 1 succeeds.

Phase B — Variable Capture​

quote 1 eth usdc => $q && swap $q.amountOut eth usdc
  • => $var captures the pipelineOutput from the previous step.
  • $var.field interpolation for accessing captured values.

Phase C — Workflow Flags and Extended Backends​

quote 1 eth usdc && swap 1 eth usdc --confirm --dry-run
  • --dry-run simulates without sending transactions.
  • --confirm adds an explicit user confirmation gate between steps.
  • Future: optional execution backends (including 7702-eligible paths) per step.

Open Questions​

1. G_alias Roll-Out​

  • Define alias selection rules when multiple protocols implement the same action (e.g., bridge available on LiFi, Wormhole, Stargate).
  • Decide on default protocol ordering: user preference vs. chain context vs. fee optimization.
  • Document conflict resolution and fallback behavior when the active protocol does not implement an aliased command.

2. Unified Status Tracking​

  • Shared polling utilities across bridge protocols (LiFi, Wormhole, Stargate).
  • Standard status model: PENDING / DONE / FAILED / TIMED_OUT.
  • Common explorer link formatting utilities reusable across all protocols.

3. Protocol Metrics and Telemetry​

  • Standardize quote/execute timing metrics across all protocol plugins.
  • Capture error classes and upstream failure rates per protocol.
  • Define storage schema and retention policy for analytics events.

4. Testing Harnesses​

  • Mock servers for protocol APIs (1inch, LiFi, Wormhole, Stargate, Aave).
  • Deterministic fixtures for command outputs (stable quote shapes, tx receipts).
  • Integration tests for multi-step transaction flows (approve → bridge → status polling).

5. Shared Transaction Executor​

  • A single executor that processes ordered transaction lists from any protocol.
  • Hooks for user confirmation dialogs, retry logic, and receipt awaiting.
  • Reusable across all plugins to eliminate duplicated signing/broadcasting code.

6. Protocol State Schema​

  • A minimal typed schema for protocolState entries with common fields:
    • lastQuote — most recent quote result
    • lastUpdated — timestamp of last state mutation
    • execution — current execution status
  • Enables CLI debugging commands (inspect, state) to display typed state.

Security Milestones​

MilestoneStatusDescription
Protect analytics endpointsOpenApply auth gate to all /api/analytics/* routes
Protect 1inch proxy routesOpenApply auth gate to all unauthenticated 1inch proxy routes
Redis-backed rate limitingOpenReplace in-memory rate limiter with shared store
Server-side plugin executionDeferredMove plugin execution server-side; remove API key exposure risk
Fix faucet IP spoofingOpenUse platform-provided request IP, reject user headers

See Security Findings for the full findings list and priority order.