From 8af08bd091dfa2c2924152d6761a47a5516f0427 Mon Sep 17 00:00:00 2001 From: brunota20 Date: Tue, 2 Jun 2026 17:04:19 -0300 Subject: [PATCH 1/5] docs(adr): add 0001-0007 capturing engine and CoW architecture decisions --- .gitignore | 8 ++ .../adr/0001-cow-twap-ethflow-host-helpers.md | 134 ++++++++++++++++++ .../0002-patch-cowprotocol-to-bleu-cow-rs.md | 60 ++++++++ docs/adr/0003-local-store-namespacing.md | 57 ++++++++ .../0004-cow-api-via-cached-orderbookapi.md | 65 +++++++++ .../0005-provider-pool-transport-by-scheme.md | 59 ++++++++ ...06-engine-toml-separate-from-nexum-toml.md | 65 +++++++++ .../0007-upstream-protocol-logic-to-cow-rs.md | 87 ++++++++++++ 8 files changed, 535 insertions(+) create mode 100644 docs/adr/0001-cow-twap-ethflow-host-helpers.md create mode 100644 docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md create mode 100644 docs/adr/0003-local-store-namespacing.md create mode 100644 docs/adr/0004-cow-api-via-cached-orderbookapi.md create mode 100644 docs/adr/0005-provider-pool-transport-by-scheme.md create mode 100644 docs/adr/0006-engine-toml-separate-from-nexum-toml.md create mode 100644 docs/adr/0007-upstream-protocol-logic-to-cow-rs.md diff --git a/.gitignore b/.gitignore index 357bddc..25b6a11 100644 --- a/.gitignore +++ b/.gitignore @@ -21,3 +21,11 @@ Thumbs.db # Environment .env .env.* + +# Agent skills / AI tooling — installed locally, never committed. +.agents/ +.claude/ +skills-lock.json + +# Engine runtime state (default state_dir from engine.toml). +data/ diff --git a/docs/adr/0001-cow-twap-ethflow-host-helpers.md b/docs/adr/0001-cow-twap-ethflow-host-helpers.md new file mode 100644 index 0000000..8daefce --- /dev/null +++ b/docs/adr/0001-cow-twap-ethflow-host-helpers.md @@ -0,0 +1,134 @@ +--- +status: proposed +--- + +# TWAP and EthFlow as intent helpers in `shepherd:cow@0.2.0` + +## Context + +The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook +access (REST passthrough + `submit-order`). Two further CoW workflows show up +in every non-trivial module: ComposableCoW conditional orders (TWAP being the +canonical example) and EthFlow native-ETH orders. Both share a tight pattern +— observe an on-chain event, derive a signed `OrderCreation`, submit it to +the orderbook — but the derivation has enough protocol detail (digest, +signature scheme, app-data resolution, `getTradeableOrderWithSignature` +eth_call against ComposableCoW) that a guest module would either ship that +logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or +make ten round-trips to the host through generic `chain`/`cow-api` calls. + +The protocol logic itself — TWAP polling, EthFlow log decoding, app-data +resolution — is not engine-specific. Every Rust consumer of CoW Protocol +(indexers, bots, this engine) needs the same primitives. Per ADR-0007, those +primitives belong in the `cowprotocol` crate, not in `nexum-engine`. This +ADR consequently scopes the engine-side helpers to the WIT surface and the +glue that wires the upstream primitives into the host call boundary. + +## Decision + +Add two new interfaces to package `shepherd:cow@0.2.0`: + +```wit +interface twap { + use nexum:host/types@0.2.0.{chain-id, log, host-error}; + use cow-api.{order-uid}; + poll-and-submit: func( + chain-id: chain-id, + registration: log, + ) -> result, host-error>; +} + +interface ethflow { + use nexum:host/types@0.2.0.{chain-id, log, host-error}; + use cow-api.{order-uid}; + submit-from-log: func( + chain-id: chain-id, + placement: log, + ) -> result; +} +``` + +Both interfaces ship in the existing `shepherd` world alongside `cow-api`. +`order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, +validated host-side) and reused by all three interfaces; `cow-api/submit-order` +keeps returning it instead of `string`. Capability names `"twap"` and +`"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare +them under `[capabilities].required`. + +Host implementations are thin wrappers (~20–30 LOC each) over three +upstream primitives that land in `cowprotocol` first (see ADR-0007): + +- `cowprotocol::composable::poll_and_build_order(provider, owner, params, + proof)` — returns `Ready(OrderCreation, signature)` or `NotReady` on + contract revert. Backs `twap.poll-and-submit`. +- `cowprotocol::eth_flow::decode_placement(log)` — returns + `(owner, OrderCreation, OrderUid)` from an `OrderPlacement` event log. + Backs `ethflow.submit-from-log`. +- `cowprotocol::app_data::OrderBookAppDataResolver` — given a chain id and + a `bytes32` hash, returns the JSON document (with `EMPTY_APP_DATA_HASH` + fast-path and LRU cache built in). Used by both helpers and any future + module-facing path. + +The engine wires these primitives into HostState and maps their errors to +`host-error` kinds; no protocol logic lives in `nexum-engine`. Modules +continue to declare their own log subscriptions via `[[subscription]]` in +`nexum.toml`; the helpers only decode and submit, they do not +auto-subscribe. + +## Considered options + +- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, + `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, + but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW + glue. mfw78's "reuse over reimplement" applied: that derivation already + lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and + should not be re-shipped in every WASM artifact. +- **Implement the protocol glue inside `nexum-engine` host code, port + upstream later.** Rejected per ADR-0007: every line of TWAP polling or + EthFlow decoding that lives in the engine is a line that future Rust + consumers cannot reuse, and a line that diverges as cow-rs evolves. +- **Single combined interface** `shepherd:cow/orders` with both helpers. + Cheaper world surface but harder to gate per-capability — a module that + only watches EthFlow shouldn't have to import TWAP and vice versa. + Splitting keeps `[capabilities].required` honest. +- **Symmetric `result, host-error>` for both.** TWAP and + EthFlow are genuinely asymmetric: TWAP is poll-driven and a `None` ("not + tradeable yet") is the normal steady-state; EthFlow is event-driven and + every accepted log produces exactly one UID. Forcing symmetry obscures + semantics for callers. +- **`log-json: list` payload** instead of the typed `nexum:host/types.log` + record. The record already exists and the engine's event dispatch already + projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both + ergonomics and "no duplicate decoders". +- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper + only handles `ComposableCoW.create()` (empty proof, single conditional + order). `setRoot` polling requires off-chain proof derivation that itself + warrants a separate helper (`twap.poll-and-submit-with-proof`) once a + module actually needs it. +- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding + imports to an existing world is additive under WIT subsumption rules. + Modules compiled against the current 0.2.0 surface continue to build. + +## Consequences + +- `cow-api/submit-order` return type changes from `string` to `order-uid`. + No external consumers today (0.2 is unreleased), so this is internal. +- Host helpers require a chain to be configured in `[chains.]` — + uncovered chains return `host-error.unsupported`. Same posture as + `cow-api`. +- Orderbook idempotency (same UID on duplicate submit) is preserved but + invisible to the module. Modules that need dedup must record UIDs in + `local-store` themselves. +- App-data resolution adds a GET to `api.cow.fi/{chain}/api/v1/app_data/{hash}` + on the first sighting of a non-empty hash. The LRU cache and the GET + itself live in `cowprotocol::app_data::OrderBookAppDataResolver` + (ADR-0007 item 3); cache miss + orderbook miss surfaces as + `host-error.unavailable`. +- Implementation order: the three `cowprotocol` primitives (`composable:: + poll_and_build_order`, `eth_flow::decode_placement`, + `app_data::OrderBookAppDataResolver`) land in `bleu/cow-rs` first; + `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump + (ADR-0002). Host-side issues stay blocked on upstream merges. +- Failure modes map onto existing `host-error-kind` variants + (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, + `unsupported`, `internal`). No new error taxonomy. diff --git a/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md b/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md new file mode 100644 index 0000000..ed73ccb --- /dev/null +++ b/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md @@ -0,0 +1,60 @@ +--- +status: proposed +implemented-in: nullislabs/shepherd#10 +--- + +# Patch `cowprotocol` crate to `bleu/cow-rs` main + +## Context + +`cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from +`cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. The published artifact +predates 18 follow-up commits on `bleu/cow-rs` main that the engine +materially depends on, in particular: + +- `composable::Proof` byte-width fix (consumed by the TWAP poll path); +- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding + from mfw78's review of PR #5); +- `order_book` / `composable` submodule splits (cleaner imports on the + engine side, no more `cowprotocol::order_book::*` re-export gymnastics). + +ADR-0007 additionally commits us to pushing TWAP / EthFlow / app-data +protocol logic upstream into `cowprotocol` first and consuming it via the +same patched dependency, so the patch surface will continue growing +through M2. + +There is no published `alpha.4` and no scheduled date for one. + +## Decision + +Add a workspace-level `[patch.crates-io]` redirecting `cowprotocol` to +`https://github.com/bleu/cow-rs` at commit `c012404`. Every crate that +declares `cowprotocol = "1.0.0-alpha.3"` (engine, modules, future SDK) +silently picks up the patched build with no `Cargo.toml` change at the +dependent site. + +## Considered options + +- **Vendor the missing types locally.** Rejected: re-implementing + `composable::Proof`, `OrderCreation`, etc. in the engine repo is exactly + the AI-duplication anti-pattern mfw78 flagged in cow-rs PR #5. Reuse + over reimplement applies. +- **Pin every dependent to `cow-rs` git directly.** Works but every new + workspace member has to remember the git source. `[patch.crates-io]` + centralises the override. +- **Wait for `alpha.4` to publish.** No ETA; the TWAP/EthFlow milestone + cannot land without `composable::Proof` correct. + +## Consequences + +- `cargo update` will re-resolve to the same `rev` — the lock pins it. +- Bumping the rev is a single-line workspace edit; reviewers see one diff. +- Drop the patch entirely once a published `cowprotocol` release contains + both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions + (`composable::poll_and_build_order`, `eth_flow::decode_placement`, + `app_data::OrderBookAppDataResolver`). Until then, expect the patch + rev to advance with every cow-rs merge that the engine consumes. +- Modules built against this workspace inherit the patch transitively; + modules built standalone against crates.io will see `alpha.3` and may + hit the very bugs the patch closes — flag in the SDK README when M3 + lands. diff --git a/docs/adr/0003-local-store-namespacing.md b/docs/adr/0003-local-store-namespacing.md new file mode 100644 index 0000000..ee5be1e --- /dev/null +++ b/docs/adr/0003-local-store-namespacing.md @@ -0,0 +1,57 @@ +--- +status: proposed +implemented-in: nullislabs/shepherd#8 +--- + +# Per-module namespacing in `local-store` via `[len:u8][module][key]` prefix + +## Context + +`nexum:host/local-store` is a key-value store shared across all modules +the engine runs. Two modules using the same key string (e.g. +`"last-block"`) must see disjoint values; one module must never read or +overwrite another's data. The engine knows each module's name at +instantiation time, so namespacing is a host-side concern. + +## Decision + +Single redb database file at `EngineConfig.engine.state_dir`, single +shared table `nexum:local-store`. Every key handed to redb is composed +host-side as: + +``` +[len: u8] [module_name: len bytes] [raw key: rest of the bytes] +``` + +Module names longer than 255 bytes are rejected at `LocalStore` +construction (matches the one-byte length prefix). Modules see plain +key strings on both the read and write paths; the prefix is invisible +to the WIT-facing API. + +## Considered options + +- **Separator string** (`{module}:{key}`). Rejected: any module name + containing `:` collides with another module's `:`-bearing key. Length + prefix is unambiguous regardless of payload bytes. +- **One redb database file per module.** Rejected: multiplies open + file handles linearly in modules, blocks any future cross-module + atomic operations (not currently planned but cheap to keep on the + table), and complicates backup tooling (N files vs 1). +- **One redb *table* per module within a single file.** Rejected: redb + `TableDefinition` lifetimes are `'static`, so table names must be + known at compile time. Dynamic table opening per module would force + string-leak workarounds and exposes the same name-collision question + as separator-based keys. + +## Consequences + +- Module data is physically interleaved in the redb tree (range scans + for one module's keys are O(log n + module-key-count) — fine for our + workload). +- Migrations changing the namespacing layout break every existing + module's persisted state. The format must stay stable through 0.x. +- A module's `list-keys` (when added) iterates over the namespace + range; the host strips the prefix before returning to the guest. +- 255-byte module-name limit is enforced loudly at construction, so + configuration errors surface at boot rather than silently corrupting + data at first write. diff --git a/docs/adr/0004-cow-api-via-cached-orderbookapi.md b/docs/adr/0004-cow-api-via-cached-orderbookapi.md new file mode 100644 index 0000000..bf4fd1a --- /dev/null +++ b/docs/adr/0004-cow-api-via-cached-orderbookapi.md @@ -0,0 +1,65 @@ +--- +status: proposed +implemented-in: nullislabs/shepherd#8 +--- + +# `cow-api` host backend routes both `request` and `submit-order` through `cowprotocol::OrderBookApi` + +## Context + +`shepherd:cow/cow-api` exposes two operations: a generic REST passthrough +(`request`) and a typed order submission (`submit-order`). Either could +be implemented with raw `reqwest` against `api.cow.fi/{slug}/api/v1`, +but the published `cowprotocol` crate already ships an `OrderBookApi` +client that knows the chain-specific base URL, the canonical paths, and +the `post_order` codec. + +## Decision + +At engine boot, construct one `cowprotocol::OrderBookApi` per +`cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, +ArbitrumOne, Base) into a `BTreeMap` keyed by EVM +chain id. Both `cow-api` operations consult this pool: + +- `request` resolves the chain's `OrderBookApi`, reads + `api.base_url()` for the prefix, joins the module-supplied path, + and dispatches via a shared `reqwest::Client`. +- `submit-order` deserialises the JSON `OrderCreation` and calls + `OrderBookApi::post_order` directly. The crate handles signing-scheme + encoding, error mapping, and `OrderUid` extraction. + +Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` +at the host call boundary. + +## Considered options + +- **Raw `reqwest` for both.** Rejected: forces us to maintain the + chain → base-URL table (drifts whenever cowprotocol adds a chain) and + reimplement `post_order`'s body codec and error mapping — the exact + duplication mfw78 called out in cow-rs PR #5. +- **`OrderBookApi` for `submit-order`, raw `reqwest` for `request`.** + Tempting (request is opaque to the crate) but means two separate + chain-resolution paths, two HTTP clients, and a second place to keep + the chain set in sync. +- **Build `OrderBookApi` lazily on first call per chain.** Rejected: + hides config errors at runtime. Up-front boot construction surfaces + unknown chains immediately and amortises away the per-call cost. + +## Consequences + +- Operator-supplied custom orderbook URLs (barn, staging, forked + deployments) are out of scope for the default constructor and require + a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` + constructor in the cow-rs crate (ADR-0007, upstream item 4 — not + vendored locally). +- App-data resolution moves out of the engine entirely once ADR-0007 + item 3 lands: `OrderBookPool` exposes an `AppDataResolver` constructed + from the same per-chain `OrderBookApi` clients, and both `cow-api` + call sites and the new twap/ethflow helpers (ADR-0001) consume that + shared resolver. No engine-side LRU. +- Adding a chain means a `cowprotocol::Chain` variant lands in cow-rs + first; the engine inherits it on the next patched rev bump. +- The shared `reqwest::Client` enables connection pooling across both + `request` and `submit-order` paths. +- TWAP and EthFlow helpers (ADR-0001) reuse the same pool — no + duplicated client construction in those host wrappers. diff --git a/docs/adr/0005-provider-pool-transport-by-scheme.md b/docs/adr/0005-provider-pool-transport-by-scheme.md new file mode 100644 index 0000000..aba0a72 --- /dev/null +++ b/docs/adr/0005-provider-pool-transport-by-scheme.md @@ -0,0 +1,59 @@ +--- +status: proposed +implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 +--- + +# Per-chain alloy provider transport selected by URL scheme + +## Context + +`nexum:host/chain` covers both generic JSON-RPC dispatch (`request`) +and event subscriptions (`subscribe-blocks`, `subscribe-logs`). +Subscriptions require a duplex transport (`eth_subscribe` is push-only +over a long-lived connection); request/response works on either HTTP +or WebSocket. The operator configures one RPC endpoint per chain in +`engine.toml`; the engine has to decide which alloy transport to use. + +## Decision + +The `ProviderPool::from_config` constructor reads each chain's +`rpc_url` and switches by URL scheme prefix: + +- `ws://` or `wss://` → `ProviderBuilder::new().connect_ws(WsConnect::new(url))`. + Pubsub transport. Subscriptions and request/response both work. +- `http://` or `https://` → `ProviderBuilder::new().connect_http(parsed)`. + HTTP transport. Request/response only; `subscribe-blocks` and + `subscribe-logs` surface as a host error to the guest. + +Both transports erase to `DynProvider` so the rest of the engine is +transport-agnostic. + +## Considered options + +- **Force WSS everywhere.** Rejected: many providers (Alchemy, Infura, + self-hosted RPC) expose HTTP-only on free tiers, and modules that + only need `request` (no subscriptions) shouldn't be blocked by a + WSS requirement. +- **Explicit `transport = "ws" | "http"` field per chain in + `engine.toml`.** Rejected for 0.2: redundant with the URL scheme, + and operators already distinguish `wss://` from `https://` + endpoints when copying them from their RPC provider's dashboard. + Revisit if we add IPC (`/path/to/geth.ipc`) — scheme alone won't + carry that. +- **Open both an HTTP and a WSS connection per chain.** Rejected: doubles + connection count for the common case where one endpoint serves + both, and forces operators to provide two URLs even when their + provider returns identical data on both. + +## Consequences + +- Operators that need subscriptions must supply WSS URLs; HTTP-only + chains downgrade to request-only mode at the host call boundary. +- Connection failures at boot are fatal (the engine refuses to start + with a broken chain). This is intentional — silent fall-back to a + half-functioning state masks misconfiguration that a module then + rediscovers at first event. +- Adding IPC support is additive: extend the scheme match with + `/` / `file://` and call `connect_ipc`. +- The `DynProvider` erasure costs a virtual dispatch per call — a + measurable concern at scale, deferred to M4 if profiling shows it. diff --git a/docs/adr/0006-engine-toml-separate-from-nexum-toml.md b/docs/adr/0006-engine-toml-separate-from-nexum-toml.md new file mode 100644 index 0000000..57f0dd7 --- /dev/null +++ b/docs/adr/0006-engine-toml-separate-from-nexum-toml.md @@ -0,0 +1,65 @@ +--- +status: proposed +implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 +--- + +# Operator config (`engine.toml`) is separate from module manifest (`nexum.toml`) + +## Context + +The engine needs two distinct kinds of configuration: what the +**operator** decides at deployment time (which chains to connect to, +where the local-store database lives, which modules to boot) and +what the **module developer** declares at build time (required and +optional capabilities, HTTP allowlist, module-specific config keys). +These have different reviewers, different threat models, and change +on different cadences. + +## Decision + +Two distinct files, distinct schemas, distinct loaders: + +- **`engine.toml`** — operator-owned, lives next to the engine binary + or pointed to by `--engine-config`. Defines `[engine]` (state_dir, + log_level), `[chains.]` (rpc_url), and `[[modules]]` (path, + manifest). Loaded by `engine_config::EngineConfig::load`. +- **`nexum.toml`** — module-developer-owned, ships in the module's + bundle alongside its `.wasm` component. Defines `[module]`, + `[capabilities]` (required, optional, http allowlist), `[config]`. + Loaded by `manifest::load`. + +The engine config carries the path to each module's manifest; the +two never collapse into one file. + +## Considered options + +- **Single `shepherd.toml` with `[engine]`, `[chains]`, `[[modules]]` + *and* nested `[modules..capabilities]` per module.** Rejected: + conflates operator and developer concerns. A module's capability + declaration is a property of the build, not the deployment — it + belongs in the artifact, not in the operator's local file. Auditing + a module's capabilities also becomes a per-deployment exercise + instead of a property visible in the published bundle. +- **`nexum.toml` inside the engine config (module entries embed it + inline).** Rejected for the same reason; also bloats `engine.toml`. +- **Drop `engine.toml` entirely; pass everything as CLI flags or + env vars.** Rejected: per-chain RPC URLs and module lists are + awkward as flags, and `RUST_LOG` already covers the only thing + that env vars naturally express. + +## Consequences + +- A deployment needs both files. A missing `engine.toml` falls back + to "no chains, default state_dir" — the example logging module + still runs; cow-api / chain backends report `unsupported`. +- A missing `nexum.toml` triggers the 0.1-compat deprecation warning + in `manifest::fallback_manifest()` (defined in + `crates/nexum-engine/src/manifest.rs`) and treats every linked + capability as required. This fallback is scheduled for removal in + 0.3 per `docs/migration/0.1-to-0.2.md`. +- Module-bundle redistribution carries `nexum.toml` with the + artifact; engines do not need to ship templates. +- Future content-addressed module distribution (0.3) embeds + `nexum.toml` in the bundle hash; `engine.toml` references modules + by content address rather than filesystem path. The split survives + that migration unchanged. diff --git a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md new file mode 100644 index 0000000..e60c895 --- /dev/null +++ b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md @@ -0,0 +1,87 @@ +--- +status: proposed +--- + +# Push CoW Protocol logic to `cow-rs` first, adopt in `nexum-engine` second + +## Context + +Implementing ADR-0001 (twap + ethflow host helpers) and ADR-0004 (cow-api +backend) surfaces a recurring question: when the engine needs a piece of +CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose +(TWAP polling glue, EthFlow log decoding, app-data hash-to-document +resolution, custom orderbook URLs), do we write that logic locally in +`nexum-engine` and tidy it up upstream later, or do we open the cow-rs +PR first and only land the engine wiring afterwards? + +mfw78's review of cow-rs PR #5 named the failure mode explicitly: +duplicating work that an existing crate could do is the AI-coding +anti-pattern most likely to land in a Bleu PR. The same risk applies to +any engine-side reimplementation of protocol logic. + +## Decision + +Protocol-level CoW logic — anything that an indexer, a bot, or a +non-`nexum` Rust consumer of CoW Protocol would also need — lands in +`bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` +via the existing `[patch.crates-io]` rev bump (ADR-0002). The engine +never writes throwaway local copies of the same logic with the intent +to "port later". + +The concrete set of primitives we know we need is, in priority order: + +1. `cowprotocol::composable::poll_and_build_order(provider, owner, + params, proof) -> Result` — eth_call against + `ComposableCoW.getTradeableOrderWithSignature`, decode return, + rebuild `OrderCreation`. Backs `twap.poll-and-submit`. +2. `cowprotocol::eth_flow::decode_placement(log) -> + Result` — decode `OrderPlacement` event log, + reconstruct `OrderCreation` and `OrderUid`. Backs + `ethflow.submit-from-log`. +3. `cowprotocol::app_data::OrderBookAppDataResolver` — `AppDataResolver` + trait + cached implementation around `OrderBookApi::app_data(hash)`, + with `EMPTY_APP_DATA_HASH` fast-path. Used by twap, ethflow, and any + future caller that needs to materialise an app-data document. +4. `cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)` — + custom-URL constructor for barn / staging / forked deployments. +5. `cowprotocol` `wasm32` compatibility — feature-gate the `reqwest` + dependency so guest modules can use the pure types + (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, + `eth_flow::decode_*`) without dragging in an HTTP client. + +Lower-priority follow-ons (richer `OrderBookApiError` variants, +`OrderUid::from_slice`, retry middleware, `OrderCreation::from_gpv2`) +are good-to-have but are not blocking for the M2 host scope. + +## Considered options + +- **Implement locally, refactor upstream later.** Faster short term but + predictably leaves an indeterminate amount of duplicated logic in the + engine, contradicts mfw78's stated conventions, and grows technical + debt every time cow-rs evolves the underlying types. Rejected. +- **Wait for cow-rs upstream maintainers to add these on their own.** + No evidence anyone else is doing this work; the grant timeline does + not permit waiting. +- **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all + worlds: blocks neither the engine nor cow-rs from drifting, and + forces every other CoW consumer to re-derive the same primitives. + +## Consequences + +- Every M2 engine issue that consumes one of the five primitives above + is blocked on its cow-rs PR merging. We sequence issues so that + upstream PRs and engine adoption can land in parallel where possible + (e.g., open all three protocol-helper PRs against `bleu/cow-rs` + simultaneously rather than serially). +- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0002) is + bumped after each cow-rs merge; the bump is the engine's signal that a + new primitive is consumable. +- PRs in `bleu/cow-rs` follow the existing mfw78 conventions established + by cow-rs PR #5: severity-tagged reviews, alloy reuse over local + reimplementation, GPL-3.0, edition 2024, terse rustdoc. +- After acceptance in `bleu/cow-rs`, each primitive is also surfaced as + a PR (or backport) against `cowdao-grants/cow-rs` so the wider + ecosystem benefits and the bleu fork narrows over time. +- The engine repo stays small: `nexum-engine` contains WIT, host + wiring, supervisor, redb store, alloy provider pool, and `engine.toml` + schema — nothing about CoW Protocol semantics. From 3f1dbf835b5664f04b004be525b6197ffd85cb63 Mon Sep 17 00:00:00 2001 From: brunota20 Date: Tue, 2 Jun 2026 17:18:11 -0300 Subject: [PATCH 2/5] docs(adr): unwrap hard-wrapped paragraphs to single line each --- .../adr/0001-cow-twap-ethflow-host-helpers.md | 120 ++++-------------- .../0002-patch-cowprotocol-to-bleu-cow-rs.md | 45 ++----- docs/adr/0003-local-store-namespacing.md | 44 ++----- .../0004-cow-api-via-cached-orderbookapi.md | 58 ++------- .../0005-provider-pool-transport-by-scheme.md | 51 ++------ ...06-engine-toml-separate-from-nexum-toml.md | 55 ++------ .../0007-upstream-protocol-logic-to-cow-rs.md | 82 +++--------- 7 files changed, 98 insertions(+), 357 deletions(-) diff --git a/docs/adr/0001-cow-twap-ethflow-host-helpers.md b/docs/adr/0001-cow-twap-ethflow-host-helpers.md index 8daefce..384e368 100644 --- a/docs/adr/0001-cow-twap-ethflow-host-helpers.md +++ b/docs/adr/0001-cow-twap-ethflow-host-helpers.md @@ -6,23 +6,9 @@ status: proposed ## Context -The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook -access (REST passthrough + `submit-order`). Two further CoW workflows show up -in every non-trivial module: ComposableCoW conditional orders (TWAP being the -canonical example) and EthFlow native-ETH orders. Both share a tight pattern -— observe an on-chain event, derive a signed `OrderCreation`, submit it to -the orderbook — but the derivation has enough protocol detail (digest, -signature scheme, app-data resolution, `getTradeableOrderWithSignature` -eth_call against ComposableCoW) that a guest module would either ship that -logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or -make ten round-trips to the host through generic `chain`/`cow-api` calls. - -The protocol logic itself — TWAP polling, EthFlow log decoding, app-data -resolution — is not engine-specific. Every Rust consumer of CoW Protocol -(indexers, bots, this engine) needs the same primitives. Per ADR-0007, those -primitives belong in the `cowprotocol` crate, not in `nexum-engine`. This -ADR consequently scopes the engine-side helpers to the WIT surface and the -glue that wires the upstream primitives into the host call boundary. +The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both share a tight pattern — observe an on-chain event, derive a signed `OrderCreation`, submit it to the orderbook — but the derivation has enough protocol detail (digest, signature scheme, app-data resolution, `getTradeableOrderWithSignature` eth_call against ComposableCoW) that a guest module would either ship that logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or make ten round-trips to the host through generic `chain`/`cow-api` calls. + +The protocol logic itself — TWAP polling, EthFlow log decoding, app-data resolution — is not engine-specific. Every Rust consumer of CoW Protocol (indexers, bots, this engine) needs the same primitives. Per ADR-0007, those primitives belong in the `cowprotocol` crate, not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. ## Decision @@ -48,87 +34,31 @@ interface ethflow { } ``` -Both interfaces ship in the existing `shepherd` world alongside `cow-api`. -`order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, -validated host-side) and reused by all three interfaces; `cow-api/submit-order` -keeps returning it instead of `string`. Capability names `"twap"` and -`"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare -them under `[capabilities].required`. - -Host implementations are thin wrappers (~20–30 LOC each) over three -upstream primitives that land in `cowprotocol` first (see ADR-0007): - -- `cowprotocol::composable::poll_and_build_order(provider, owner, params, - proof)` — returns `Ready(OrderCreation, signature)` or `NotReady` on - contract revert. Backs `twap.poll-and-submit`. -- `cowprotocol::eth_flow::decode_placement(log)` — returns - `(owner, OrderCreation, OrderUid)` from an `OrderPlacement` event log. - Backs `ethflow.submit-from-log`. -- `cowprotocol::app_data::OrderBookAppDataResolver` — given a chain id and - a `bytes32` hash, returns the JSON document (with `EMPTY_APP_DATA_HASH` - fast-path and LRU cache built in). Used by both helpers and any future - module-facing path. - -The engine wires these primitives into HostState and maps their errors to -`host-error` kinds; no protocol logic lives in `nexum-engine`. Modules -continue to declare their own log subscriptions via `[[subscription]]` in -`nexum.toml`; the helpers only decode and submit, they do not -auto-subscribe. +Both interfaces ship in the existing `shepherd` world alongside `cow-api`. `order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, validated host-side) and reused by all three interfaces; `cow-api/submit-order` keeps returning it instead of `string`. Capability names `"twap"` and `"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare them under `[capabilities].required`. + +Host implementations are thin wrappers (~20–30 LOC each) over three upstream primitives that land in `cowprotocol` first (see ADR-0007): + +- `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof)` — returns `Ready(OrderCreation, signature)` or `NotReady` on contract revert. Backs `twap.poll-and-submit`. +- `cowprotocol::eth_flow::decode_placement(log)` — returns `(owner, OrderCreation, OrderUid)` from an `OrderPlacement` event log. Backs `ethflow.submit-from-log`. +- `cowprotocol::app_data::OrderBookAppDataResolver` — given a chain id and a `bytes32` hash, returns the JSON document (with `EMPTY_APP_DATA_HASH` fast-path and LRU cache built in). Used by both helpers and any future module-facing path. + +The engine wires these primitives into HostState and maps their errors to `host-error` kinds; no protocol logic lives in `nexum-engine`. Modules continue to declare their own log subscriptions via `[[subscription]]` in `nexum.toml`; the helpers only decode and submit, they do not auto-subscribe. ## Considered options -- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, - `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, - but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW - glue. mfw78's "reuse over reimplement" applied: that derivation already - lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and - should not be re-shipped in every WASM artifact. -- **Implement the protocol glue inside `nexum-engine` host code, port - upstream later.** Rejected per ADR-0007: every line of TWAP polling or - EthFlow decoding that lives in the engine is a line that future Rust - consumers cannot reuse, and a line that diverges as cow-rs evolves. -- **Single combined interface** `shepherd:cow/orders` with both helpers. - Cheaper world surface but harder to gate per-capability — a module that - only watches EthFlow shouldn't have to import TWAP and vice versa. - Splitting keeps `[capabilities].required` honest. -- **Symmetric `result, host-error>` for both.** TWAP and - EthFlow are genuinely asymmetric: TWAP is poll-driven and a `None` ("not - tradeable yet") is the normal steady-state; EthFlow is event-driven and - every accepted log produces exactly one UID. Forcing symmetry obscures - semantics for callers. -- **`log-json: list` payload** instead of the typed `nexum:host/types.log` - record. The record already exists and the engine's event dispatch already - projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both - ergonomics and "no duplicate decoders". -- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper - only handles `ComposableCoW.create()` (empty proof, single conditional - order). `setRoot` polling requires off-chain proof derivation that itself - warrants a separate helper (`twap.poll-and-submit-with-proof`) once a - module actually needs it. -- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding - imports to an existing world is additive under WIT subsumption rules. - Modules compiled against the current 0.2.0 surface continue to build. +- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW glue. mfw78's "reuse over reimplement" applied: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. +- **Implement the protocol glue inside `nexum-engine` host code, port upstream later.** Rejected per ADR-0007: every line of TWAP polling or EthFlow decoding that lives in the engine is a line that future Rust consumers cannot reuse, and a line that diverges as cow-rs evolves. +- **Single combined interface** `shepherd:cow/orders` with both helpers. Cheaper world surface but harder to gate per-capability — a module that only watches EthFlow shouldn't have to import TWAP and vice versa. Splitting keeps `[capabilities].required` honest. +- **Symmetric `result, host-error>` for both.** TWAP and EthFlow are genuinely asymmetric: TWAP is poll-driven and a `None` ("not tradeable yet") is the normal steady-state; EthFlow is event-driven and every accepted log produces exactly one UID. Forcing symmetry obscures semantics for callers. +- **`log-json: list` payload** instead of the typed `nexum:host/types.log` record. The record already exists and the engine's event dispatch already projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both ergonomics and "no duplicate decoders". +- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper only handles `ComposableCoW.create()` (empty proof, single conditional order). `setRoot` polling requires off-chain proof derivation that itself warrants a separate helper (`twap.poll-and-submit-with-proof`) once a module actually needs it. +- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding imports to an existing world is additive under WIT subsumption rules. Modules compiled against the current 0.2.0 surface continue to build. ## Consequences -- `cow-api/submit-order` return type changes from `string` to `order-uid`. - No external consumers today (0.2 is unreleased), so this is internal. -- Host helpers require a chain to be configured in `[chains.]` — - uncovered chains return `host-error.unsupported`. Same posture as - `cow-api`. -- Orderbook idempotency (same UID on duplicate submit) is preserved but - invisible to the module. Modules that need dedup must record UIDs in - `local-store` themselves. -- App-data resolution adds a GET to `api.cow.fi/{chain}/api/v1/app_data/{hash}` - on the first sighting of a non-empty hash. The LRU cache and the GET - itself live in `cowprotocol::app_data::OrderBookAppDataResolver` - (ADR-0007 item 3); cache miss + orderbook miss surfaces as - `host-error.unavailable`. -- Implementation order: the three `cowprotocol` primitives (`composable:: - poll_and_build_order`, `eth_flow::decode_placement`, - `app_data::OrderBookAppDataResolver`) land in `bleu/cow-rs` first; - `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump - (ADR-0002). Host-side issues stay blocked on upstream merges. -- Failure modes map onto existing `host-error-kind` variants - (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, - `unsupported`, `internal`). No new error taxonomy. +- `cow-api/submit-order` return type changes from `string` to `order-uid`. No external consumers today (0.2 is unreleased), so this is internal. +- Host helpers require a chain to be configured in `[chains.]` — uncovered chains return `host-error.unsupported`. Same posture as `cow-api`. +- Orderbook idempotency (same UID on duplicate submit) is preserved but invisible to the module. Modules that need dedup must record UIDs in `local-store` themselves. +- App-data resolution adds a GET to `api.cow.fi/{chain}/api/v1/app_data/{hash}` on the first sighting of a non-empty hash. The LRU cache and the GET itself live in `cowprotocol::app_data::OrderBookAppDataResolver` (ADR-0007 item 3); cache miss + orderbook miss surfaces as `host-error.unavailable`. +- Implementation order: the three `cowprotocol` primitives (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `app_data::OrderBookAppDataResolver`) land in `bleu/cow-rs` first; `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump (ADR-0002). Host-side issues stay blocked on upstream merges. +- Failure modes map onto existing `host-error-kind` variants (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, `unsupported`, `internal`). No new error taxonomy. diff --git a/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md b/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md index ed73ccb..380b632 100644 --- a/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md +++ b/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md @@ -7,54 +7,29 @@ implemented-in: nullislabs/shepherd#10 ## Context -`cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from -`cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. The published artifact -predates 18 follow-up commits on `bleu/cow-rs` main that the engine -materially depends on, in particular: +`cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from `cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. The published artifact predates 18 follow-up commits on `bleu/cow-rs` main that the engine materially depends on, in particular: - `composable::Proof` byte-width fix (consumed by the TWAP poll path); -- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding - from mfw78's review of PR #5); -- `order_book` / `composable` submodule splits (cleaner imports on the - engine side, no more `cowprotocol::order_book::*` re-export gymnastics). +- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding from mfw78's review of PR #5); +- `order_book` / `composable` submodule splits (cleaner imports on the engine side, no more `cowprotocol::order_book::*` re-export gymnastics). -ADR-0007 additionally commits us to pushing TWAP / EthFlow / app-data -protocol logic upstream into `cowprotocol` first and consuming it via the -same patched dependency, so the patch surface will continue growing -through M2. +ADR-0007 additionally commits us to pushing TWAP / EthFlow / app-data protocol logic upstream into `cowprotocol` first and consuming it via the same patched dependency, so the patch surface will continue growing through M2. There is no published `alpha.4` and no scheduled date for one. ## Decision -Add a workspace-level `[patch.crates-io]` redirecting `cowprotocol` to -`https://github.com/bleu/cow-rs` at commit `c012404`. Every crate that -declares `cowprotocol = "1.0.0-alpha.3"` (engine, modules, future SDK) -silently picks up the patched build with no `Cargo.toml` change at the -dependent site. +Add a workspace-level `[patch.crates-io]` redirecting `cowprotocol` to `https://github.com/bleu/cow-rs` at commit `c012404`. Every crate that declares `cowprotocol = "1.0.0-alpha.3"` (engine, modules, future SDK) silently picks up the patched build with no `Cargo.toml` change at the dependent site. ## Considered options -- **Vendor the missing types locally.** Rejected: re-implementing - `composable::Proof`, `OrderCreation`, etc. in the engine repo is exactly - the AI-duplication anti-pattern mfw78 flagged in cow-rs PR #5. Reuse - over reimplement applies. -- **Pin every dependent to `cow-rs` git directly.** Works but every new - workspace member has to remember the git source. `[patch.crates-io]` - centralises the override. -- **Wait for `alpha.4` to publish.** No ETA; the TWAP/EthFlow milestone - cannot land without `composable::Proof` correct. +- **Vendor the missing types locally.** Rejected: re-implementing `composable::Proof`, `OrderCreation`, etc. in the engine repo is exactly the AI-duplication anti-pattern mfw78 flagged in cow-rs PR #5. Reuse over reimplement applies. +- **Pin every dependent to `cow-rs` git directly.** Works but every new workspace member has to remember the git source. `[patch.crates-io]` centralises the override. +- **Wait for `alpha.4` to publish.** No ETA; the TWAP/EthFlow milestone cannot land without `composable::Proof` correct. ## Consequences - `cargo update` will re-resolve to the same `rev` — the lock pins it. - Bumping the rev is a single-line workspace edit; reviewers see one diff. -- Drop the patch entirely once a published `cowprotocol` release contains - both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions - (`composable::poll_and_build_order`, `eth_flow::decode_placement`, - `app_data::OrderBookAppDataResolver`). Until then, expect the patch - rev to advance with every cow-rs merge that the engine consumes. -- Modules built against this workspace inherit the patch transitively; - modules built standalone against crates.io will see `alpha.3` and may - hit the very bugs the patch closes — flag in the SDK README when M3 - lands. +- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `app_data::OrderBookAppDataResolver`). Until then, expect the patch rev to advance with every cow-rs merge that the engine consumes. +- Modules built against this workspace inherit the patch transitively; modules built standalone against crates.io will see `alpha.3` and may hit the very bugs the patch closes — flag in the SDK README when M3 lands. diff --git a/docs/adr/0003-local-store-namespacing.md b/docs/adr/0003-local-store-namespacing.md index ee5be1e..f265137 100644 --- a/docs/adr/0003-local-store-namespacing.md +++ b/docs/adr/0003-local-store-namespacing.md @@ -7,51 +7,27 @@ implemented-in: nullislabs/shepherd#8 ## Context -`nexum:host/local-store` is a key-value store shared across all modules -the engine runs. Two modules using the same key string (e.g. -`"last-block"`) must see disjoint values; one module must never read or -overwrite another's data. The engine knows each module's name at -instantiation time, so namespacing is a host-side concern. +`nexum:host/local-store` is a key-value store shared across all modules the engine runs. Two modules using the same key string (e.g. `"last-block"`) must see disjoint values; one module must never read or overwrite another's data. The engine knows each module's name at instantiation time, so namespacing is a host-side concern. ## Decision -Single redb database file at `EngineConfig.engine.state_dir`, single -shared table `nexum:local-store`. Every key handed to redb is composed -host-side as: +Single redb database file at `EngineConfig.engine.state_dir`, single shared table `nexum:local-store`. Every key handed to redb is composed host-side as: ``` [len: u8] [module_name: len bytes] [raw key: rest of the bytes] ``` -Module names longer than 255 bytes are rejected at `LocalStore` -construction (matches the one-byte length prefix). Modules see plain -key strings on both the read and write paths; the prefix is invisible -to the WIT-facing API. +Module names longer than 255 bytes are rejected at `LocalStore` construction (matches the one-byte length prefix). Modules see plain key strings on both the read and write paths; the prefix is invisible to the WIT-facing API. ## Considered options -- **Separator string** (`{module}:{key}`). Rejected: any module name - containing `:` collides with another module's `:`-bearing key. Length - prefix is unambiguous regardless of payload bytes. -- **One redb database file per module.** Rejected: multiplies open - file handles linearly in modules, blocks any future cross-module - atomic operations (not currently planned but cheap to keep on the - table), and complicates backup tooling (N files vs 1). -- **One redb *table* per module within a single file.** Rejected: redb - `TableDefinition` lifetimes are `'static`, so table names must be - known at compile time. Dynamic table opening per module would force - string-leak workarounds and exposes the same name-collision question - as separator-based keys. +- **Separator string** (`{module}:{key}`). Rejected: any module name containing `:` collides with another module's `:`-bearing key. Length prefix is unambiguous regardless of payload bytes. +- **One redb database file per module.** Rejected: multiplies open file handles linearly in modules, blocks any future cross-module atomic operations (not currently planned but cheap to keep on the table), and complicates backup tooling (N files vs 1). +- **One redb *table* per module within a single file.** Rejected: redb `TableDefinition` lifetimes are `'static`, so table names must be known at compile time. Dynamic table opening per module would force string-leak workarounds and exposes the same name-collision question as separator-based keys. ## Consequences -- Module data is physically interleaved in the redb tree (range scans - for one module's keys are O(log n + module-key-count) — fine for our - workload). -- Migrations changing the namespacing layout break every existing - module's persisted state. The format must stay stable through 0.x. -- A module's `list-keys` (when added) iterates over the namespace - range; the host strips the prefix before returning to the guest. -- 255-byte module-name limit is enforced loudly at construction, so - configuration errors surface at boot rather than silently corrupting - data at first write. +- Module data is physically interleaved in the redb tree (range scans for one module's keys are O(log n + module-key-count) — fine for our workload). +- Migrations changing the namespacing layout break every existing module's persisted state. The format must stay stable through 0.x. +- A module's `list-keys` (when added) iterates over the namespace range; the host strips the prefix before returning to the guest. +- 255-byte module-name limit is enforced loudly at construction, so configuration errors surface at boot rather than silently corrupting data at first write. diff --git a/docs/adr/0004-cow-api-via-cached-orderbookapi.md b/docs/adr/0004-cow-api-via-cached-orderbookapi.md index bf4fd1a..52d5b8f 100644 --- a/docs/adr/0004-cow-api-via-cached-orderbookapi.md +++ b/docs/adr/0004-cow-api-via-cached-orderbookapi.md @@ -7,59 +7,27 @@ implemented-in: nullislabs/shepherd#8 ## Context -`shepherd:cow/cow-api` exposes two operations: a generic REST passthrough -(`request`) and a typed order submission (`submit-order`). Either could -be implemented with raw `reqwest` against `api.cow.fi/{slug}/api/v1`, -but the published `cowprotocol` crate already ships an `OrderBookApi` -client that knows the chain-specific base URL, the canonical paths, and -the `post_order` codec. +`shepherd:cow/cow-api` exposes two operations: a generic REST passthrough (`request`) and a typed order submission (`submit-order`). Either could be implemented with raw `reqwest` against `api.cow.fi/{slug}/api/v1`, but the published `cowprotocol` crate already ships an `OrderBookApi` client that knows the chain-specific base URL, the canonical paths, and the `post_order` codec. ## Decision -At engine boot, construct one `cowprotocol::OrderBookApi` per -`cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, -ArbitrumOne, Base) into a `BTreeMap` keyed by EVM -chain id. Both `cow-api` operations consult this pool: +At engine boot, construct one `cowprotocol::OrderBookApi` per `cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, ArbitrumOne, Base) into a `BTreeMap` keyed by EVM chain id. Both `cow-api` operations consult this pool: -- `request` resolves the chain's `OrderBookApi`, reads - `api.base_url()` for the prefix, joins the module-supplied path, - and dispatches via a shared `reqwest::Client`. -- `submit-order` deserialises the JSON `OrderCreation` and calls - `OrderBookApi::post_order` directly. The crate handles signing-scheme - encoding, error mapping, and `OrderUid` extraction. +- `request` resolves the chain's `OrderBookApi`, reads `api.base_url()` for the prefix, joins the module-supplied path, and dispatches via a shared `reqwest::Client`. +- `submit-order` deserialises the JSON `OrderCreation` and calls `OrderBookApi::post_order` directly. The crate handles signing-scheme encoding, error mapping, and `OrderUid` extraction. -Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` -at the host call boundary. +Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` at the host call boundary. ## Considered options -- **Raw `reqwest` for both.** Rejected: forces us to maintain the - chain → base-URL table (drifts whenever cowprotocol adds a chain) and - reimplement `post_order`'s body codec and error mapping — the exact - duplication mfw78 called out in cow-rs PR #5. -- **`OrderBookApi` for `submit-order`, raw `reqwest` for `request`.** - Tempting (request is opaque to the crate) but means two separate - chain-resolution paths, two HTTP clients, and a second place to keep - the chain set in sync. -- **Build `OrderBookApi` lazily on first call per chain.** Rejected: - hides config errors at runtime. Up-front boot construction surfaces - unknown chains immediately and amortises away the per-call cost. +- **Raw `reqwest` for both.** Rejected: forces us to maintain the chain → base-URL table (drifts whenever cowprotocol adds a chain) and reimplement `post_order`'s body codec and error mapping — the exact duplication mfw78 called out in cow-rs PR #5. +- **`OrderBookApi` for `submit-order`, raw `reqwest` for `request`.** Tempting (request is opaque to the crate) but means two separate chain-resolution paths, two HTTP clients, and a second place to keep the chain set in sync. +- **Build `OrderBookApi` lazily on first call per chain.** Rejected: hides config errors at runtime. Up-front boot construction surfaces unknown chains immediately and amortises away the per-call cost. ## Consequences -- Operator-supplied custom orderbook URLs (barn, staging, forked - deployments) are out of scope for the default constructor and require - a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` - constructor in the cow-rs crate (ADR-0007, upstream item 4 — not - vendored locally). -- App-data resolution moves out of the engine entirely once ADR-0007 - item 3 lands: `OrderBookPool` exposes an `AppDataResolver` constructed - from the same per-chain `OrderBookApi` clients, and both `cow-api` - call sites and the new twap/ethflow helpers (ADR-0001) consume that - shared resolver. No engine-side LRU. -- Adding a chain means a `cowprotocol::Chain` variant lands in cow-rs - first; the engine inherits it on the next patched rev bump. -- The shared `reqwest::Client` enables connection pooling across both - `request` and `submit-order` paths. -- TWAP and EthFlow helpers (ADR-0001) reuse the same pool — no - duplicated client construction in those host wrappers. +- Operator-supplied custom orderbook URLs (barn, staging, forked deployments) are out of scope for the default constructor and require a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` constructor in the cow-rs crate (ADR-0007, upstream item 4 — not vendored locally). +- App-data resolution moves out of the engine entirely once ADR-0007 item 3 lands: `OrderBookPool` exposes an `AppDataResolver` constructed from the same per-chain `OrderBookApi` clients, and both `cow-api` call sites and the new twap/ethflow helpers (ADR-0001) consume that shared resolver. No engine-side LRU. +- Adding a chain means a `cowprotocol::Chain` variant lands in cow-rs first; the engine inherits it on the next patched rev bump. +- The shared `reqwest::Client` enables connection pooling across both `request` and `submit-order` paths. +- TWAP and EthFlow helpers (ADR-0001) reuse the same pool — no duplicated client construction in those host wrappers. diff --git a/docs/adr/0005-provider-pool-transport-by-scheme.md b/docs/adr/0005-provider-pool-transport-by-scheme.md index aba0a72..f027480 100644 --- a/docs/adr/0005-provider-pool-transport-by-scheme.md +++ b/docs/adr/0005-provider-pool-transport-by-scheme.md @@ -7,53 +7,26 @@ implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 ## Context -`nexum:host/chain` covers both generic JSON-RPC dispatch (`request`) -and event subscriptions (`subscribe-blocks`, `subscribe-logs`). -Subscriptions require a duplex transport (`eth_subscribe` is push-only -over a long-lived connection); request/response works on either HTTP -or WebSocket. The operator configures one RPC endpoint per chain in -`engine.toml`; the engine has to decide which alloy transport to use. +`nexum:host/chain` covers both generic JSON-RPC dispatch (`request`) and event subscriptions (`subscribe-blocks`, `subscribe-logs`). Subscriptions require a duplex transport (`eth_subscribe` is push-only over a long-lived connection); request/response works on either HTTP or WebSocket. The operator configures one RPC endpoint per chain in `engine.toml`; the engine has to decide which alloy transport to use. ## Decision -The `ProviderPool::from_config` constructor reads each chain's -`rpc_url` and switches by URL scheme prefix: +The `ProviderPool::from_config` constructor reads each chain's `rpc_url` and switches by URL scheme prefix: -- `ws://` or `wss://` → `ProviderBuilder::new().connect_ws(WsConnect::new(url))`. - Pubsub transport. Subscriptions and request/response both work. -- `http://` or `https://` → `ProviderBuilder::new().connect_http(parsed)`. - HTTP transport. Request/response only; `subscribe-blocks` and - `subscribe-logs` surface as a host error to the guest. +- `ws://` or `wss://` → `ProviderBuilder::new().connect_ws(WsConnect::new(url))`. Pubsub transport. Subscriptions and request/response both work. +- `http://` or `https://` → `ProviderBuilder::new().connect_http(parsed)`. HTTP transport. Request/response only; `subscribe-blocks` and `subscribe-logs` surface as a host error to the guest. -Both transports erase to `DynProvider` so the rest of the engine is -transport-agnostic. +Both transports erase to `DynProvider` so the rest of the engine is transport-agnostic. ## Considered options -- **Force WSS everywhere.** Rejected: many providers (Alchemy, Infura, - self-hosted RPC) expose HTTP-only on free tiers, and modules that - only need `request` (no subscriptions) shouldn't be blocked by a - WSS requirement. -- **Explicit `transport = "ws" | "http"` field per chain in - `engine.toml`.** Rejected for 0.2: redundant with the URL scheme, - and operators already distinguish `wss://` from `https://` - endpoints when copying them from their RPC provider's dashboard. - Revisit if we add IPC (`/path/to/geth.ipc`) — scheme alone won't - carry that. -- **Open both an HTTP and a WSS connection per chain.** Rejected: doubles - connection count for the common case where one endpoint serves - both, and forces operators to provide two URLs even when their - provider returns identical data on both. +- **Force WSS everywhere.** Rejected: many providers (Alchemy, Infura, self-hosted RPC) expose HTTP-only on free tiers, and modules that only need `request` (no subscriptions) shouldn't be blocked by a WSS requirement. +- **Explicit `transport = "ws" | "http"` field per chain in `engine.toml`.** Rejected for 0.2: redundant with the URL scheme, and operators already distinguish `wss://` from `https://` endpoints when copying them from their RPC provider's dashboard. Revisit if we add IPC (`/path/to/geth.ipc`) — scheme alone won't carry that. +- **Open both an HTTP and a WSS connection per chain.** Rejected: doubles connection count for the common case where one endpoint serves both, and forces operators to provide two URLs even when their provider returns identical data on both. ## Consequences -- Operators that need subscriptions must supply WSS URLs; HTTP-only - chains downgrade to request-only mode at the host call boundary. -- Connection failures at boot are fatal (the engine refuses to start - with a broken chain). This is intentional — silent fall-back to a - half-functioning state masks misconfiguration that a module then - rediscovers at first event. -- Adding IPC support is additive: extend the scheme match with - `/` / `file://` and call `connect_ipc`. -- The `DynProvider` erasure costs a virtual dispatch per call — a - measurable concern at scale, deferred to M4 if profiling shows it. +- Operators that need subscriptions must supply WSS URLs; HTTP-only chains downgrade to request-only mode at the host call boundary. +- Connection failures at boot are fatal (the engine refuses to start with a broken chain). This is intentional — silent fall-back to a half-functioning state masks misconfiguration that a module then rediscovers at first event. +- Adding IPC support is additive: extend the scheme match with `/` / `file://` and call `connect_ipc`. +- The `DynProvider` erasure costs a virtual dispatch per call — a measurable concern at scale, deferred to M4 if profiling shows it. diff --git a/docs/adr/0006-engine-toml-separate-from-nexum-toml.md b/docs/adr/0006-engine-toml-separate-from-nexum-toml.md index 57f0dd7..fd77ac3 100644 --- a/docs/adr/0006-engine-toml-separate-from-nexum-toml.md +++ b/docs/adr/0006-engine-toml-separate-from-nexum-toml.md @@ -7,59 +7,26 @@ implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 ## Context -The engine needs two distinct kinds of configuration: what the -**operator** decides at deployment time (which chains to connect to, -where the local-store database lives, which modules to boot) and -what the **module developer** declares at build time (required and -optional capabilities, HTTP allowlist, module-specific config keys). -These have different reviewers, different threat models, and change -on different cadences. +The engine needs two distinct kinds of configuration: what the **operator** decides at deployment time (which chains to connect to, where the local-store database lives, which modules to boot) and what the **module developer** declares at build time (required and optional capabilities, HTTP allowlist, module-specific config keys). These have different reviewers, different threat models, and change on different cadences. ## Decision Two distinct files, distinct schemas, distinct loaders: -- **`engine.toml`** — operator-owned, lives next to the engine binary - or pointed to by `--engine-config`. Defines `[engine]` (state_dir, - log_level), `[chains.]` (rpc_url), and `[[modules]]` (path, - manifest). Loaded by `engine_config::EngineConfig::load`. -- **`nexum.toml`** — module-developer-owned, ships in the module's - bundle alongside its `.wasm` component. Defines `[module]`, - `[capabilities]` (required, optional, http allowlist), `[config]`. - Loaded by `manifest::load`. +- **`engine.toml`** — operator-owned, lives next to the engine binary or pointed to by `--engine-config`. Defines `[engine]` (state_dir, log_level), `[chains.]` (rpc_url), and `[[modules]]` (path, manifest). Loaded by `engine_config::EngineConfig::load`. +- **`nexum.toml`** — module-developer-owned, ships in the module's bundle alongside its `.wasm` component. Defines `[module]`, `[capabilities]` (required, optional, http allowlist), `[config]`. Loaded by `manifest::load`. -The engine config carries the path to each module's manifest; the -two never collapse into one file. +The engine config carries the path to each module's manifest; the two never collapse into one file. ## Considered options -- **Single `shepherd.toml` with `[engine]`, `[chains]`, `[[modules]]` - *and* nested `[modules..capabilities]` per module.** Rejected: - conflates operator and developer concerns. A module's capability - declaration is a property of the build, not the deployment — it - belongs in the artifact, not in the operator's local file. Auditing - a module's capabilities also becomes a per-deployment exercise - instead of a property visible in the published bundle. -- **`nexum.toml` inside the engine config (module entries embed it - inline).** Rejected for the same reason; also bloats `engine.toml`. -- **Drop `engine.toml` entirely; pass everything as CLI flags or - env vars.** Rejected: per-chain RPC URLs and module lists are - awkward as flags, and `RUST_LOG` already covers the only thing - that env vars naturally express. +- **Single `shepherd.toml` with `[engine]`, `[chains]`, `[[modules]]` *and* nested `[modules..capabilities]` per module.** Rejected: conflates operator and developer concerns. A module's capability declaration is a property of the build, not the deployment — it belongs in the artifact, not in the operator's local file. Auditing a module's capabilities also becomes a per-deployment exercise instead of a property visible in the published bundle. +- **`nexum.toml` inside the engine config (module entries embed it inline).** Rejected for the same reason; also bloats `engine.toml`. +- **Drop `engine.toml` entirely; pass everything as CLI flags or env vars.** Rejected: per-chain RPC URLs and module lists are awkward as flags, and `RUST_LOG` already covers the only thing that env vars naturally express. ## Consequences -- A deployment needs both files. A missing `engine.toml` falls back - to "no chains, default state_dir" — the example logging module - still runs; cow-api / chain backends report `unsupported`. -- A missing `nexum.toml` triggers the 0.1-compat deprecation warning - in `manifest::fallback_manifest()` (defined in - `crates/nexum-engine/src/manifest.rs`) and treats every linked - capability as required. This fallback is scheduled for removal in - 0.3 per `docs/migration/0.1-to-0.2.md`. -- Module-bundle redistribution carries `nexum.toml` with the - artifact; engines do not need to ship templates. -- Future content-addressed module distribution (0.3) embeds - `nexum.toml` in the bundle hash; `engine.toml` references modules - by content address rather than filesystem path. The split survives - that migration unchanged. +- A deployment needs both files. A missing `engine.toml` falls back to "no chains, default state_dir" — the example logging module still runs; cow-api / chain backends report `unsupported`. +- A missing `nexum.toml` triggers the 0.1-compat deprecation warning in `manifest::fallback_manifest()` (defined in `crates/nexum-engine/src/manifest.rs`) and treats every linked capability as required. This fallback is scheduled for removal in 0.3 per `docs/migration/0.1-to-0.2.md`. +- Module-bundle redistribution carries `nexum.toml` with the artifact; engines do not need to ship templates. +- Future content-addressed module distribution (0.3) embeds `nexum.toml` in the bundle hash; `engine.toml` references modules by content address rather than filesystem path. The split survives that migration unchanged. diff --git a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md index e60c895..6ed2a36 100644 --- a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md +++ b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md @@ -6,82 +6,34 @@ status: proposed ## Context -Implementing ADR-0001 (twap + ethflow host helpers) and ADR-0004 (cow-api -backend) surfaces a recurring question: when the engine needs a piece of -CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose -(TWAP polling glue, EthFlow log decoding, app-data hash-to-document -resolution, custom orderbook URLs), do we write that logic locally in -`nexum-engine` and tidy it up upstream later, or do we open the cow-rs -PR first and only land the engine wiring afterwards? +Implementing ADR-0001 (twap + ethflow host helpers) and ADR-0004 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, app-data hash-to-document resolution, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we open the cow-rs PR first and only land the engine wiring afterwards? -mfw78's review of cow-rs PR #5 named the failure mode explicitly: -duplicating work that an existing crate could do is the AI-coding -anti-pattern most likely to land in a Bleu PR. The same risk applies to -any engine-side reimplementation of protocol logic. +mfw78's review of cow-rs PR #5 named the failure mode explicitly: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a Bleu PR. The same risk applies to any engine-side reimplementation of protocol logic. ## Decision -Protocol-level CoW logic — anything that an indexer, a bot, or a -non-`nexum` Rust consumer of CoW Protocol would also need — lands in -`bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` -via the existing `[patch.crates-io]` rev bump (ADR-0002). The engine -never writes throwaway local copies of the same logic with the intent -to "port later". +Protocol-level CoW logic — anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need — lands in `bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` via the existing `[patch.crates-io]` rev bump (ADR-0002). The engine never writes throwaway local copies of the same logic with the intent to "port later". The concrete set of primitives we know we need is, in priority order: -1. `cowprotocol::composable::poll_and_build_order(provider, owner, - params, proof) -> Result` — eth_call against - `ComposableCoW.getTradeableOrderWithSignature`, decode return, - rebuild `OrderCreation`. Backs `twap.poll-and-submit`. -2. `cowprotocol::eth_flow::decode_placement(log) -> - Result` — decode `OrderPlacement` event log, - reconstruct `OrderCreation` and `OrderUid`. Backs - `ethflow.submit-from-log`. -3. `cowprotocol::app_data::OrderBookAppDataResolver` — `AppDataResolver` - trait + cached implementation around `OrderBookApi::app_data(hash)`, - with `EMPTY_APP_DATA_HASH` fast-path. Used by twap, ethflow, and any - future caller that needs to materialise an app-data document. -4. `cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)` — - custom-URL constructor for barn / staging / forked deployments. -5. `cowprotocol` `wasm32` compatibility — feature-gate the `reqwest` - dependency so guest modules can use the pure types - (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, - `eth_flow::decode_*`) without dragging in an HTTP client. +1. `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> Result` — eth_call against `ComposableCoW.getTradeableOrderWithSignature`, decode return, rebuild `OrderCreation`. Backs `twap.poll-and-submit`. +2. `cowprotocol::eth_flow::decode_placement(log) -> Result` — decode `OrderPlacement` event log, reconstruct `OrderCreation` and `OrderUid`. Backs `ethflow.submit-from-log`. +3. `cowprotocol::app_data::OrderBookAppDataResolver` — `AppDataResolver` trait + cached implementation around `OrderBookApi::app_data(hash)`, with `EMPTY_APP_DATA_HASH` fast-path. Used by twap, ethflow, and any future caller that needs to materialise an app-data document. +4. `cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)` — custom-URL constructor for barn / staging / forked deployments. +5. `cowprotocol` `wasm32` compatibility — feature-gate the `reqwest` dependency so guest modules can use the pure types (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, `eth_flow::decode_*`) without dragging in an HTTP client. -Lower-priority follow-ons (richer `OrderBookApiError` variants, -`OrderUid::from_slice`, retry middleware, `OrderCreation::from_gpv2`) -are good-to-have but are not blocking for the M2 host scope. +Lower-priority follow-ons (richer `OrderBookApiError` variants, `OrderUid::from_slice`, retry middleware, `OrderCreation::from_gpv2`) are good-to-have but are not blocking for the M2 host scope. ## Considered options -- **Implement locally, refactor upstream later.** Faster short term but - predictably leaves an indeterminate amount of duplicated logic in the - engine, contradicts mfw78's stated conventions, and grows technical - debt every time cow-rs evolves the underlying types. Rejected. -- **Wait for cow-rs upstream maintainers to add these on their own.** - No evidence anyone else is doing this work; the grant timeline does - not permit waiting. -- **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all - worlds: blocks neither the engine nor cow-rs from drifting, and - forces every other CoW consumer to re-derive the same primitives. +- **Implement locally, refactor upstream later.** Faster short term but predictably leaves an indeterminate amount of duplicated logic in the engine, contradicts mfw78's stated conventions, and grows technical debt every time cow-rs evolves the underlying types. Rejected. +- **Wait for cow-rs upstream maintainers to add these on their own.** No evidence anyone else is doing this work; the grant timeline does not permit waiting. +- **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all worlds: blocks neither the engine nor cow-rs from drifting, and forces every other CoW consumer to re-derive the same primitives. ## Consequences -- Every M2 engine issue that consumes one of the five primitives above - is blocked on its cow-rs PR merging. We sequence issues so that - upstream PRs and engine adoption can land in parallel where possible - (e.g., open all three protocol-helper PRs against `bleu/cow-rs` - simultaneously rather than serially). -- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0002) is - bumped after each cow-rs merge; the bump is the engine's signal that a - new primitive is consumable. -- PRs in `bleu/cow-rs` follow the existing mfw78 conventions established - by cow-rs PR #5: severity-tagged reviews, alloy reuse over local - reimplementation, GPL-3.0, edition 2024, terse rustdoc. -- After acceptance in `bleu/cow-rs`, each primitive is also surfaced as - a PR (or backport) against `cowdao-grants/cow-rs` so the wider - ecosystem benefits and the bleu fork narrows over time. -- The engine repo stays small: `nexum-engine` contains WIT, host - wiring, supervisor, redb store, alloy provider pool, and `engine.toml` - schema — nothing about CoW Protocol semantics. +- Every M2 engine issue that consumes one of the five primitives above is blocked on its cow-rs PR merging. We sequence issues so that upstream PRs and engine adoption can land in parallel where possible (e.g., open all three protocol-helper PRs against `bleu/cow-rs` simultaneously rather than serially). +- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0002) is bumped after each cow-rs merge; the bump is the engine's signal that a new primitive is consumable. +- PRs in `bleu/cow-rs` follow the existing mfw78 conventions established by cow-rs PR #5: severity-tagged reviews, alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. +- After acceptance in `bleu/cow-rs`, each primitive is also surfaced as a PR (or backport) against `cowdao-grants/cow-rs` so the wider ecosystem benefits and the bleu fork narrows over time. +- The engine repo stays small: `nexum-engine` contains WIT, host wiring, supervisor, redb store, alloy provider pool, and `engine.toml` schema — nothing about CoW Protocol semantics. From 7e05190a79cd5c0ee842bab0eaeecc9fc359c453 Mon Sep 17 00:00:00 2001 From: brunota20 Date: Wed, 3 Jun 2026 15:36:59 -0300 Subject: [PATCH 3/5] docs(adr): revise CoW design and reorder ADRs (0001-0008) --- .../adr/0001-cow-twap-ethflow-host-helpers.md | 64 -------- ...1-engine-toml-separate-from-nexum-toml.md} | 0 ...0002-provider-pool-transport-by-scheme.md} | 0 ... 0004-patch-cowprotocol-to-bleu-cow-rs.md} | 2 +- ...> 0005-cow-api-via-cached-orderbookapi.md} | 5 +- .../adr/0006-cow-twap-ethflow-host-helpers.md | 84 +++++++++++ .../0007-upstream-protocol-logic-to-cow-rs.md | 29 ++-- .../0008-factory-subscriptions-in-manifest.md | 140 ++++++++++++++++++ 8 files changed, 246 insertions(+), 78 deletions(-) delete mode 100644 docs/adr/0001-cow-twap-ethflow-host-helpers.md rename docs/adr/{0006-engine-toml-separate-from-nexum-toml.md => 0001-engine-toml-separate-from-nexum-toml.md} (100%) rename docs/adr/{0005-provider-pool-transport-by-scheme.md => 0002-provider-pool-transport-by-scheme.md} (100%) rename docs/adr/{0002-patch-cowprotocol-to-bleu-cow-rs.md => 0004-patch-cowprotocol-to-bleu-cow-rs.md} (94%) rename docs/adr/{0004-cow-api-via-cached-orderbookapi.md => 0005-cow-api-via-cached-orderbookapi.md} (84%) create mode 100644 docs/adr/0006-cow-twap-ethflow-host-helpers.md create mode 100644 docs/adr/0008-factory-subscriptions-in-manifest.md diff --git a/docs/adr/0001-cow-twap-ethflow-host-helpers.md b/docs/adr/0001-cow-twap-ethflow-host-helpers.md deleted file mode 100644 index 384e368..0000000 --- a/docs/adr/0001-cow-twap-ethflow-host-helpers.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -status: proposed ---- - -# TWAP and EthFlow as intent helpers in `shepherd:cow@0.2.0` - -## Context - -The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both share a tight pattern — observe an on-chain event, derive a signed `OrderCreation`, submit it to the orderbook — but the derivation has enough protocol detail (digest, signature scheme, app-data resolution, `getTradeableOrderWithSignature` eth_call against ComposableCoW) that a guest module would either ship that logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or make ten round-trips to the host through generic `chain`/`cow-api` calls. - -The protocol logic itself — TWAP polling, EthFlow log decoding, app-data resolution — is not engine-specific. Every Rust consumer of CoW Protocol (indexers, bots, this engine) needs the same primitives. Per ADR-0007, those primitives belong in the `cowprotocol` crate, not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. - -## Decision - -Add two new interfaces to package `shepherd:cow@0.2.0`: - -```wit -interface twap { - use nexum:host/types@0.2.0.{chain-id, log, host-error}; - use cow-api.{order-uid}; - poll-and-submit: func( - chain-id: chain-id, - registration: log, - ) -> result, host-error>; -} - -interface ethflow { - use nexum:host/types@0.2.0.{chain-id, log, host-error}; - use cow-api.{order-uid}; - submit-from-log: func( - chain-id: chain-id, - placement: log, - ) -> result; -} -``` - -Both interfaces ship in the existing `shepherd` world alongside `cow-api`. `order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, validated host-side) and reused by all three interfaces; `cow-api/submit-order` keeps returning it instead of `string`. Capability names `"twap"` and `"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare them under `[capabilities].required`. - -Host implementations are thin wrappers (~20–30 LOC each) over three upstream primitives that land in `cowprotocol` first (see ADR-0007): - -- `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof)` — returns `Ready(OrderCreation, signature)` or `NotReady` on contract revert. Backs `twap.poll-and-submit`. -- `cowprotocol::eth_flow::decode_placement(log)` — returns `(owner, OrderCreation, OrderUid)` from an `OrderPlacement` event log. Backs `ethflow.submit-from-log`. -- `cowprotocol::app_data::OrderBookAppDataResolver` — given a chain id and a `bytes32` hash, returns the JSON document (with `EMPTY_APP_DATA_HASH` fast-path and LRU cache built in). Used by both helpers and any future module-facing path. - -The engine wires these primitives into HostState and maps their errors to `host-error` kinds; no protocol logic lives in `nexum-engine`. Modules continue to declare their own log subscriptions via `[[subscription]]` in `nexum.toml`; the helpers only decode and submit, they do not auto-subscribe. - -## Considered options - -- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW glue. mfw78's "reuse over reimplement" applied: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. -- **Implement the protocol glue inside `nexum-engine` host code, port upstream later.** Rejected per ADR-0007: every line of TWAP polling or EthFlow decoding that lives in the engine is a line that future Rust consumers cannot reuse, and a line that diverges as cow-rs evolves. -- **Single combined interface** `shepherd:cow/orders` with both helpers. Cheaper world surface but harder to gate per-capability — a module that only watches EthFlow shouldn't have to import TWAP and vice versa. Splitting keeps `[capabilities].required` honest. -- **Symmetric `result, host-error>` for both.** TWAP and EthFlow are genuinely asymmetric: TWAP is poll-driven and a `None` ("not tradeable yet") is the normal steady-state; EthFlow is event-driven and every accepted log produces exactly one UID. Forcing symmetry obscures semantics for callers. -- **`log-json: list` payload** instead of the typed `nexum:host/types.log` record. The record already exists and the engine's event dispatch already projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both ergonomics and "no duplicate decoders". -- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper only handles `ComposableCoW.create()` (empty proof, single conditional order). `setRoot` polling requires off-chain proof derivation that itself warrants a separate helper (`twap.poll-and-submit-with-proof`) once a module actually needs it. -- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding imports to an existing world is additive under WIT subsumption rules. Modules compiled against the current 0.2.0 surface continue to build. - -## Consequences - -- `cow-api/submit-order` return type changes from `string` to `order-uid`. No external consumers today (0.2 is unreleased), so this is internal. -- Host helpers require a chain to be configured in `[chains.]` — uncovered chains return `host-error.unsupported`. Same posture as `cow-api`. -- Orderbook idempotency (same UID on duplicate submit) is preserved but invisible to the module. Modules that need dedup must record UIDs in `local-store` themselves. -- App-data resolution adds a GET to `api.cow.fi/{chain}/api/v1/app_data/{hash}` on the first sighting of a non-empty hash. The LRU cache and the GET itself live in `cowprotocol::app_data::OrderBookAppDataResolver` (ADR-0007 item 3); cache miss + orderbook miss surfaces as `host-error.unavailable`. -- Implementation order: the three `cowprotocol` primitives (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `app_data::OrderBookAppDataResolver`) land in `bleu/cow-rs` first; `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump (ADR-0002). Host-side issues stay blocked on upstream merges. -- Failure modes map onto existing `host-error-kind` variants (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, `unsupported`, `internal`). No new error taxonomy. diff --git a/docs/adr/0006-engine-toml-separate-from-nexum-toml.md b/docs/adr/0001-engine-toml-separate-from-nexum-toml.md similarity index 100% rename from docs/adr/0006-engine-toml-separate-from-nexum-toml.md rename to docs/adr/0001-engine-toml-separate-from-nexum-toml.md diff --git a/docs/adr/0005-provider-pool-transport-by-scheme.md b/docs/adr/0002-provider-pool-transport-by-scheme.md similarity index 100% rename from docs/adr/0005-provider-pool-transport-by-scheme.md rename to docs/adr/0002-provider-pool-transport-by-scheme.md diff --git a/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md similarity index 94% rename from docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md rename to docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md index 380b632..4564401 100644 --- a/docs/adr/0002-patch-cowprotocol-to-bleu-cow-rs.md +++ b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md @@ -31,5 +31,5 @@ Add a workspace-level `[patch.crates-io]` redirecting `cowprotocol` to `https:// - `cargo update` will re-resolve to the same `rev` — the lock pins it. - Bumping the rev is a single-line workspace edit; reviewers see one diff. -- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `app_data::OrderBookAppDataResolver`). Until then, expect the patch rev to advance with every cow-rs merge that the engine consumes. +- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `OrderPostError` rich variants). Until then, expect the patch rev to advance with every cow-rs merge that the engine consumes. - Modules built against this workspace inherit the patch transitively; modules built standalone against crates.io will see `alpha.3` and may hit the very bugs the patch closes — flag in the SDK README when M3 lands. diff --git a/docs/adr/0004-cow-api-via-cached-orderbookapi.md b/docs/adr/0005-cow-api-via-cached-orderbookapi.md similarity index 84% rename from docs/adr/0004-cow-api-via-cached-orderbookapi.md rename to docs/adr/0005-cow-api-via-cached-orderbookapi.md index 52d5b8f..ae9c6b5 100644 --- a/docs/adr/0004-cow-api-via-cached-orderbookapi.md +++ b/docs/adr/0005-cow-api-via-cached-orderbookapi.md @@ -26,8 +26,7 @@ Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` at t ## Consequences -- Operator-supplied custom orderbook URLs (barn, staging, forked deployments) are out of scope for the default constructor and require a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` constructor in the cow-rs crate (ADR-0007, upstream item 4 — not vendored locally). -- App-data resolution moves out of the engine entirely once ADR-0007 item 3 lands: `OrderBookPool` exposes an `AppDataResolver` constructed from the same per-chain `OrderBookApi` clients, and both `cow-api` call sites and the new twap/ethflow helpers (ADR-0001) consume that shared resolver. No engine-side LRU. +- Operator-supplied custom orderbook URLs (barn, staging, forked deployments) are out of scope for the default constructor and require a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` constructor in the cow-rs crate (ADR-0007 item 4 — not vendored locally). - Adding a chain means a `cowprotocol::Chain` variant lands in cow-rs first; the engine inherits it on the next patched rev bump. - The shared `reqwest::Client` enables connection pooling across both `request` and `submit-order` paths. -- TWAP and EthFlow helpers (ADR-0001) reuse the same pool — no duplicated client construction in those host wrappers. +- TWAP and EthFlow helpers (ADR-0006) reuse the same pool — no duplicated client construction in those host wrappers. diff --git a/docs/adr/0006-cow-twap-ethflow-host-helpers.md b/docs/adr/0006-cow-twap-ethflow-host-helpers.md new file mode 100644 index 0000000..8870d3d --- /dev/null +++ b/docs/adr/0006-cow-twap-ethflow-host-helpers.md @@ -0,0 +1,84 @@ +--- +status: proposed +--- + +# TWAP and EthFlow as intent helpers in `shepherd:cow@0.2.0` + +## Context + +The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both follow the same external-indexer/relayer pattern that CoW's own infrastructure has been progressively extracting from the monolithic `cowprotocol/services` repository: + +- **TWAP / ComposableCoW** — extracted as the standalone `cowprotocol/watch-tower` (TypeScript). Listens to `ConditionalOrderCreated`, polls `getTradeableOrderWithSignature` on each block, posts to the orderbook when an order becomes tradeable. +- **EthFlow indexer** — still inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Listens to `OrderPlacement` / `OrderInvalidation` / `OrderRefund`, inserts into the `ethflow_orders` table. CoW's architectural direction is to extract this into a standalone service, mirroring how `watch-tower` and the `refunder` crate were already extracted. The Shepherd `ethflow-watcher` module is the natural Rust home for that extraction. + +Both flows share the same pattern: observe an on-chain event, derive a signed `OrderCreation`, submit it to the orderbook. The derivation has enough protocol detail (signing scheme, ComposableCoW eth_call, EthFlow EIP-1271 contract signature, log decoding) that a guest module would either ship that logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or make ten round-trips to the host through generic `chain`/`cow-api` calls. + +Per ADR-0007, the protocol logic itself lives in the `cowprotocol` crate — not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. + +## Decision + +Add two new interfaces to package `shepherd:cow@0.2.0`: + +```wit +interface twap { + use nexum:host/types@0.2.0.{chain-id, log, host-error}; + use cow-api.{order-uid}; + + /// Discriminated outcome of a single poll attempt against + /// ComposableCoW. Mirrors watchtower's PollResultCode so modules + /// avoid spamming RPC/orderbook when an order is known-not-ready. + variant poll-outcome { + submitted(order-uid), + try-at-epoch(u64), // unix seconds; module skips polls until then + try-on-block(u64), // specific block number + try-next-block, // default retry + dont-try-again, // terminal: TWAP completed or cancelled + } + + poll-and-submit: func( + chain-id: chain-id, + registration: log, + ) -> result; +} + +interface ethflow { + use nexum:host/types@0.2.0.{chain-id, log, host-error}; + use cow-api.{order-uid}; + + submit-from-log: func( + chain-id: chain-id, + placement: log, + ) -> result; +} +``` + +Both interfaces ship in the existing `shepherd` world alongside `cow-api`. `order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, validated host-side) and reused by all three interfaces; `cow-api/submit-order` keeps returning it instead of `string`. Capability names `"twap"` and `"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare them under `[capabilities].required`. + +Host implementations are thin wrappers (~20–30 LOC each) over three upstream primitives that land in `cowprotocol` first (see ADR-0007): + +- `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> PollOutcome` — returns the same discriminated outcome (`Submitted`, `TryAtEpoch`, `TryOnBlock`, `TryNextBlock`, `DontTryAgain`). Backs `twap.poll-and-submit`. +- `cowprotocol::eth_flow::decode_placement(log)` — decodes `OrderPlacement` into `(owner, OrderCreation, OrderUid)` with the EIP-1271 signing scheme pointing at the EthFlow contract. Backs `ethflow.submit-from-log`. +- `cowprotocol::OrderPostError` (rich variants + `retry_hint()`) — typed orderbook submission errors with backoff/drop classification. Modules consume the hints to react to transient vs permanent failures without spamming. + +The engine wires these primitives into HostState and maps their errors to `host-error` kinds; no protocol logic lives in `nexum-engine`. Modules continue to declare their own log subscriptions via `[[subscription]]` in `nexum.toml`; the helpers only decode and submit, they do not auto-subscribe. + +## Considered options + +- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW / EthFlow glue. mfw78's "reuse over reimplement" applied: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. +- **Implement the protocol glue inside `nexum-engine` host code, port upstream later.** Rejected per ADR-0007: every line of TWAP polling or EthFlow decoding that lives in the engine is a line that future Rust consumers cannot reuse, and a line that diverges as cow-rs evolves. +- **EthFlow as pure passive observer (no `submit-from-log`).** Briefly considered after reading "watcher" / "monitor" in mfw78's docs/00 and docs/04 as "no submission". Rejected after verifying that CoW's own autopilot DOES post equivalent (insert into `ethflow_orders` table); the Shepherd module is intended to externalize that role, not replace it with passive observation. The `pending_orders` state mentioned in docs/04 is a side-effect of the relay (local accounting of what's been observed), not the goal. +- **Simple `option` return on twap instead of `poll-outcome` variant.** A 1-hour-spaced TWAP polled every block would spam ~300 RPC calls per part with `None` returns. The richer outcome (`try-at-epoch`, etc.) matches watchtower's existing `PollResult` and lets modules skip polls until the contract says it's worth retrying. Production-critical. +- **Single combined interface** `shepherd:cow/orders` with both helpers. Cheaper world surface but harder to gate per-capability — a module that only watches EthFlow shouldn't have to import TWAP and vice versa. Splitting keeps `[capabilities].required` honest. +- **`log-json: list` payload** instead of the typed `nexum:host/types.log` record. The record already exists and the engine's event dispatch already projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both ergonomics and "no duplicate decoders". +- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper only handles `ComposableCoW.create()` (empty proof, single conditional order). `setRoot` polling requires off-chain proof derivation that itself warrants a separate helper (`twap.poll-and-submit-with-proof`) once a module actually needs it. +- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding imports to an existing world is additive under WIT subsumption rules. Modules compiled against the current 0.2.0 surface continue to build. + +## Consequences + +- `cow-api/submit-order` return type changes from `string` to `order-uid`. No external consumers today (0.2 is unreleased), so this is internal. +- Host helpers require a chain to be configured in `[chains.]` — uncovered chains return `host-error.unsupported`. Same posture as `cow-api`. +- Orderbook idempotency (same UID on duplicate submit) is preserved but invisible to the module. Modules that need dedup must record UIDs in `local-store` themselves. +- TWAP modules must implement the `poll-outcome` state machine: persist `next_attempt` hints (epoch or block number) in local-store, skip polls until trigger, remove watches on `dont-try-again`. Without this, the poll loop becomes O(blocks × twaps) with most calls wasted. The M3 SDK is expected to ship a helper that encapsulates the state machine. +- Orderbook errors return as `host-error` with the original CoW error code in `code`. Modules use `OrderPostError::try_from(host_error)` plus `retry_hint()` (ADR-0007 item 3) to map to next-block / backoff / drop. Without this layered approach, modules spam the orderbook with permanently-broken orders. +- Implementation order: the three `cowprotocol` primitives (`composable::poll_and_build_order` with rich `PollOutcome`, `eth_flow::decode_placement`, `OrderPostError` rich + `retry_hint`) land in `bleu/cow-rs` first; `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump (ADR-0004). Host-side issues stay blocked on upstream merges. +- Failure modes map onto existing `host-error-kind` variants (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, `unsupported`, `internal`). No new error taxonomy. diff --git a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md index 6ed2a36..dac09ea 100644 --- a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md +++ b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md @@ -6,34 +6,43 @@ status: proposed ## Context -Implementing ADR-0001 (twap + ethflow host helpers) and ADR-0004 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, app-data hash-to-document resolution, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we open the cow-rs PR first and only land the engine wiring afterwards? +Implementing ADR-0006 (twap + ethflow host helpers) and ADR-0005 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, rich orderbook error variants, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we open the cow-rs PR first and only land the engine wiring afterwards? mfw78's review of cow-rs PR #5 named the failure mode explicitly: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a Bleu PR. The same risk applies to any engine-side reimplementation of protocol logic. +CoW's broader architecture has been moving the same direction: `watch-tower` extracted from `cowprotocol/services` autopilot, the `refunder` crate likewise, with the `ethflow_events` indexer (`crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`) identified as the next extraction target. The Rust-side equivalent of those extractions is the right home for protocol primitives — `bleu/cow-rs` (then upstream into `cowdao-grants/cow-rs`), not the engine. + ## Decision -Protocol-level CoW logic — anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need — lands in `bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` via the existing `[patch.crates-io]` rev bump (ADR-0002). The engine never writes throwaway local copies of the same logic with the intent to "port later". +Protocol-level CoW logic — anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need — lands in `bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` via the existing `[patch.crates-io]` rev bump (ADR-0004). The engine never writes throwaway local copies of the same logic with the intent to "port later". The concrete set of primitives we know we need is, in priority order: -1. `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> Result` — eth_call against `ComposableCoW.getTradeableOrderWithSignature`, decode return, rebuild `OrderCreation`. Backs `twap.poll-and-submit`. -2. `cowprotocol::eth_flow::decode_placement(log) -> Result` — decode `OrderPlacement` event log, reconstruct `OrderCreation` and `OrderUid`. Backs `ethflow.submit-from-log`. -3. `cowprotocol::app_data::OrderBookAppDataResolver` — `AppDataResolver` trait + cached implementation around `OrderBookApi::app_data(hash)`, with `EMPTY_APP_DATA_HASH` fast-path. Used by twap, ethflow, and any future caller that needs to materialise an app-data document. -4. `cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)` — custom-URL constructor for barn / staging / forked deployments. -5. `cowprotocol` `wasm32` compatibility — feature-gate the `reqwest` dependency so guest modules can use the pure types (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, `eth_flow::decode_*`) without dragging in an HTTP client. +1. **`cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> Result`** — eth_call against `ComposableCoW.getTradeableOrderWithSignature`, decode return, rebuild `OrderCreation`. `PollOutcome` mirrors watchtower's `PollResultCode` (TS): `Submitted(OrderCreation, Vec)`, `TryAtEpoch(u64)`, `TryOnBlock(u64)`, `TryNextBlock`, `DontTryAgain`. Backs `twap.poll-and-submit` (ADR-0006). + +2. **`cowprotocol::eth_flow::decode_placement(log) -> Result`** — decode `OrderPlacement` event log, reconstruct `OrderCreation` with the EIP-1271 signing scheme pointing at the `CoWSwapEthFlow` contract, compute `OrderUid`. Replicates the indexing logic currently inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Backs `ethflow.submit-from-log` (ADR-0006). + +3. **`cowprotocol::OrderPostError` rich variants + `retry_hint(&self) -> RetryHint`** — typed orderbook submission errors (`QuoteNotFound`, `InvalidQuote`, `InsufficientAllowance`, `InsufficientBalance`, `TooManyLimitOrders`, `InvalidAppData`, `AppDataFromMismatch`, `SellAmountOverflow`, `ZeroAmount`, `TransferSimulationFailed`, `ExcessiveValidTo`, …) with a `retry_hint()` helper classifying each into `TryNextBlock`, `BackoffSeconds(u64)`, or `Drop`. Mirrors watchtower's `API_ERRORS_TRY_NEXT_BLOCK` / `API_ERRORS_BACKOFF` / `API_ERRORS_DROP` tables. Without this, every Rust consumer of CoW reinvents the same mapping, and modules spam the orderbook with permanently-broken orders. **Critical-path, not optional.** + +4. **`cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)`** — custom-URL constructor for barn / staging / forked deployments. Unblocks per-chain orderbook URL overrides in `engine.toml` (ADR-0005). + +5. **`cowprotocol` `wasm32` compatibility** — feature-gate the `reqwest` dependency so guest modules can use the pure types (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, `eth_flow::decode_*`) without dragging in an HTTP client. Unblocks M3 SDK guest modules consuming `cowprotocol` directly. -Lower-priority follow-ons (richer `OrderBookApiError` variants, `OrderUid::from_slice`, retry middleware, `OrderCreation::from_gpv2`) are good-to-have but are not blocking for the M2 host scope. +Lower-priority follow-ons (`OrderUid::from_slice`, retry middleware on `OrderBookApi`, `OrderCreation::from_gpv2`) are good-to-have but are not blocking for the M2 host scope. ## Considered options - **Implement locally, refactor upstream later.** Faster short term but predictably leaves an indeterminate amount of duplicated logic in the engine, contradicts mfw78's stated conventions, and grows technical debt every time cow-rs evolves the underlying types. Rejected. - **Wait for cow-rs upstream maintainers to add these on their own.** No evidence anyone else is doing this work; the grant timeline does not permit waiting. - **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all worlds: blocks neither the engine nor cow-rs from drifting, and forces every other CoW consumer to re-derive the same primitives. +- **Simple `Ready/NotReady` PollOutcome on item 1.** Rejected: doesn't capture watchtower's `TRY_AT_EPOCH(t)` hint, which is what prevents the polling loop from RPC-spamming during the 1-hour gap between TWAP parts. ## Consequences -- Every M2 engine issue that consumes one of the five primitives above is blocked on its cow-rs PR merging. We sequence issues so that upstream PRs and engine adoption can land in parallel where possible (e.g., open all three protocol-helper PRs against `bleu/cow-rs` simultaneously rather than serially). -- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0002) is bumped after each cow-rs merge; the bump is the engine's signal that a new primitive is consumable. +- Every M2 engine issue that consumes one of the five primitives above is blocked on its cow-rs PR merging. We sequence issues so that upstream PRs and engine adoption can land in parallel where possible (e.g., open items 1, 2, 3 against `bleu/cow-rs` simultaneously rather than serially). +- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0004) is bumped after each cow-rs merge; the bump is the engine's signal that a new primitive is consumable. - PRs in `bleu/cow-rs` follow the existing mfw78 conventions established by cow-rs PR #5: severity-tagged reviews, alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. - After acceptance in `bleu/cow-rs`, each primitive is also surfaced as a PR (or backport) against `cowdao-grants/cow-rs` so the wider ecosystem benefits and the bleu fork narrows over time. - The engine repo stays small: `nexum-engine` contains WIT, host wiring, supervisor, redb store, alloy provider pool, and `engine.toml` schema — nothing about CoW Protocol semantics. +- The rich `PollOutcome` (item 1) + `OrderPostError` + `retry_hint` (item 3) design naturally leads to tighter M3 SDK helpers: `WatchSet`, `PollLoop`, `BackoffLedger` patterns that any module re-using `shepherd-sdk` gets for free. +- A follow-on Bleu module — the Rust-side equivalent of `cowprotocol/refunder` (permissionless `invalidateOrder` triggering for expired EthFlow orders) — becomes natural to ship once `ethflow.submit-from-log` lands. Out of scope for M2 but explicitly enabled by the same primitives. diff --git a/docs/adr/0008-factory-subscriptions-in-manifest.md b/docs/adr/0008-factory-subscriptions-in-manifest.md new file mode 100644 index 0000000..af6c6f1 --- /dev/null +++ b/docs/adr/0008-factory-subscriptions-in-manifest.md @@ -0,0 +1,140 @@ +--- +status: proposed +--- + +# Dynamic address registration for log subscriptions (Envio HyperIndex-style) + +## Context + +Some module archetypes need to track contracts deployed dynamically by a factory — Uniswap V3 pools (deployed by `UniswapV3Factory`), Aave V3 reserves (registered via `PoolAddressesProvider`), lending market deployments, NFT marketplace collections. Static `[[subscription]]` declarations in `nexum.toml` cannot express this: the child addresses are not known when the module's manifest is authored. + +Neither TWAP nor EthFlow (the M2 grant deliverables) needs this — both subscribe to a single well-known contract per chain (`ComposableCoW`, `CoWSwapEthFlow`). This ADR is forward-looking: 0.2 is the breaking-change window per `docs/migration/0.1-to-0.2.md` §522, with contracts stable from 0.2.0 onwards. Adding factory support after 0.2 would require another major version bump. + +Two production EVM indexer frameworks define the design space: + +- **Ponder** (`ponder.config.ts`) is fully declarative: the user describes the factory contract, the factory event, and which event parameter holds the child address. Ponder extracts the address itself and indexes children automatically. The framework does ABI-aware extraction; the user writes no factory handler. +- **Envio HyperIndex** (`envio.yaml` + handler code) is a hybrid: the user declares the **template** (ABI, event topics) without an address, then calls `context..register(address)` inside the factory event handler. Topics are static; the watched address set grows at runtime. + +The Envio model decouples "what topics the engine listens for" (static, in the manifest) from "which addresses are interesting" (dynamic, driven by module code). The engine maintains a single aggregated subscription per template; the address set is mutated as the module learns of new contracts. + +## Decision + +Adopt the Envio model. Two pieces: + +**1. Manifest schema gains `[[subscription.template]]`** — a topic-only log subscription whose address set is populated at runtime: + +```toml +[[subscription.template]] +chain_id = 1 +name = "uniswap_v3_pool" +event_topics = [ + "0xc42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67", # Swap + "0x7a53080ba414158be7ec69b987b5fb7d07dee101fe85488f0853ae16239d0bde", # Mint +] +# Optional: pre-register a set of addresses at boot (before init runs). +# Useful for protocols where some addresses are known statically. +initial_addresses = [] +``` + +Existing `[[subscription]]` blocks with concrete `address` are unchanged. A module typically declares one static `[[subscription]]` for the factory event itself, plus one `[[subscription.template]]` per child contract type. + +**2. `nexum:host/chain` gains two host functions** for the module to manage the address set: + +```wit +interface chain { + // ... existing request, request-batch, subscribe-blocks, subscribe-logs ... + + /// Add an address to the watch set for `template-name` on `chain-id`. + /// If `from-block` is set and precedes the current head, the engine + /// runs paginated `eth_getLogs` over the template's topics on this + /// address from `from-block` to head before going live. Registration + /// is idempotent — calling twice with the same arguments is a no-op. + register-address: func( + chain-id: chain-id, + template-name: string, + address: list, // 20 bytes + from-block: option, + ) -> result<_, host-error>; + + /// Remove an address from the watch set. Subsequent events on that + /// address are dropped. Idempotent — unregistering an unknown address + /// returns Ok. + unregister-address: func( + chain-id: chain-id, + template-name: string, + address: list, + ) -> result<_, host-error>; +} +``` + +**3. `log-source` variant in `nexum:host/event-module`** gains a `template` case so modules can route events: + +```wit +variant log-source { + static(u32), // existing — index into [[subscription]] + template(string), // new — name of the [[subscription.template]] +} +``` + +Module code (Rust, Uniswap V3 indexer): + +```rust +fn init(config: Vec<(String, String)>) -> Result<(), HostError> { + // Resume: re-register every pool we already discovered. Each pool's + // creation block is persisted; backfill resumes from where we left off. + for key in local_store::list_keys("pool:")? { + let pool = parse_addr(&key); + let from_block = u64::from_le_bytes(local_store::get(&key)?.unwrap()); + chain::register_address(1, "uniswap_v3_pool", &pool, Some(from_block))?; + } + Ok(()) +} + +fn on_event(event: Event) -> Result<(), HostError> { + match event { + // Factory event — declared as a static [[subscription]] for the factory. + Event::Log(LogEvent { log, source: LogSource::Static(0) }) => { + let pool = decode_pool_created(&log)?; + chain::register_address(1, "uniswap_v3_pool", &pool, Some(log.block_number))?; + local_store::set(&format!("pool:{}", hex(&pool)), &log.block_number.to_le_bytes())?; + } + // Pool event — dispatched through the template. + Event::Log(LogEvent { log, source: LogSource::Template(name) }) + if name == "uniswap_v3_pool" => + { + process_pool_event(log)?; + } + _ => {} + } + Ok(()) +} +``` + +Engine internals: + +- **Boot**: read all `[[subscription.template]]` blocks across loaded modules. Initialise per-template address sets from `initial_addresses` plus the reserved key `__nexum:template:{name}:addresses` in the module's `local-store` namespace. +- **Live**: one `eth_subscribe logs` per chain per template, filter = `(topic in event_topics) ∧ (address in current_set)`. When `register-address` mutates the set, the engine re-subscribes (or shards the filter when the set exceeds the provider's address-limit threshold). +- **Backfill on register**: if `from-block` < current head, run paginated `eth_getLogs(topic, address, from-block, head)` synchronously before joining the live stream. Events from backfill are dispatched through the same `on_event` callback as live events. +- **Persistence**: engine writes `__nexum:template:{name}:addresses` (one entry per registered address) and `__nexum:template:{name}:cursor:{address}` (last block dispatched per address) in the module's reserved namespace. Resume is automatic if the module re-calls `register-address` for each persisted address; engine deduplicates via the persisted cursor. + +## Considered options + +- **Ponder full-declarative** (factory address + event + parameter declared in manifest, engine extracts child). Rejected: schema must express ABI-aware extraction (`child = { source = "topic", index = 1 }` or `{ source = "data", offset = 32, length = 20 }`), and grows with every exotic factory shape (nested factories, multi-child events, address computed from multiple fields). The Envio model pushes that complexity into module Rust code — where it belongs, given the module already decodes events with `alloy_sol_types`. +- **Pure imperative `chain.open-log-stream(filter) -> stream-handle`.** Rejected: each call opens a new subscription, so N pools = N WSS connections. Doesn't scale to indexers with 10k+ tracked addresses. The Envio model keeps one subscription per template and mutates its address set — engine batches naturally. +- **Wildcard manifest** (`address = "*"` with topic-only filter, module client-side filters). Rejected: mainnet has ~10k contracts emitting `Transfer` / `Swap` per day. The engine would deliver every matching event to every wildcard subscriber; modules pay fuel and bandwidth to discard 99% of them. +- **Defer factory pattern entirely to 0.3.** Rejected: 0.2 is the breaking-change window per migration:522. Adding either `[[subscription.template]]` or `register-address` after 0.2 requires another major bump. Better to land the small surface now than break later. +- **Templates declared inside `[[subscription]]` with optional `address` (one block, two modes).** Rejected: conflates two semantically distinct cases — modules looking at `[[subscription]]` would have to inspect for the presence of `address` to know whether they need to call `register-address`. Separate block name is clearer. +- **Engine extracts the child address from the static factory `[[subscription]]` (best of both).** Rejected: would require the manifest to identify a relationship between the static subscription and a template, plus the ABI extraction rules. Reintroduces the Ponder schema complexity we just rejected. + +## Consequences + +- `nexum.toml` schema gains `[[subscription.template]]` with `chain_id`, `name`, `event_topics`, optional `initial_addresses`. mfw78 approval needed for the schema extension (his spec). +- `nexum:host/chain` gains `register-address` and `unregister-address` functions; `nexum:host/event-module`'s `log-source` variant gains `template(string)`. mfw78 approval needed for the WIT change (his namespace). These are the only WIT additions in this ADR — small, focused, with no implicit dependencies on other interfaces. +- Reserved key namespace `__nexum:template:*` in each module's `local-store` namespace. Modules MUST NOT write to keys with this prefix; engine reserves them. +- Module boilerplate per factory ≈ 5–10 lines (decode the factory event, call `register-address`, persist for resume). The M3 SDK is expected to ship a helper that encapsulates this — something like `Factory::::on_event(register_template("uniswap_v3_pool"))` — but the host surface is intentionally simple enough that no SDK is required to use it. +- Engine can register addresses sourced from anywhere — factory events, HTTP API responses, governance votes, operator-supplied lists. Composability is a deliberate feature; the engine treats every registration the same way regardless of provenance. +- Nested factories (a child contract that is itself a factory) work without schema changes: the child's event handler decodes its own creation events and calls `register-address` on the grandchild template. Engine has no concept of nesting; it just multiplexes addresses per template. +- Conditional registration ("only register pools with fee = 3000") works without schema changes: the module's factory-event handler inspects the event payload and decides whether to call `register-address`. +- Backfill cost: a module registering 10k addresses with `from-block` deep in history triggers 10k paginated `eth_getLogs` runs, sequentially per address (the engine cannot batch across addresses with different `from-block` cursors without state-machine work that's not in scope for 0.2). Operators should set sensible `start_block` boundaries; the M3 SDK is expected to ship a `BulkBackfill` helper that groups same-cursor addresses into combined filter queries. +- The address set per template is bounded only by `local-store` quota. The engine enforces a soft cap (default 50k addresses per template) configurable in `engine.toml` to prevent a runaway module from saturating the provider's filter limits; exceeding the cap returns `host-error.denied` from `register-address`. +- A module that never calls `register-address` for a declared template receives no events from it — equivalent to declaring an unused subscription. Engine logs a warning on boot if a template is declared with `initial_addresses = []` and the module has no registrations after `init` returns. From 67a0be75eeb12a4218261c7fef2ce5344fcf3aef Mon Sep 17 00:00:00 2001 From: brunota20 Date: Wed, 3 Jun 2026 19:26:04 -0300 Subject: [PATCH 4/5] fix(docs): reviewed ADRs by bleu --- .../0004-patch-cowprotocol-to-bleu-cow-rs.md | 27 +++--- .../0005-cow-api-via-cached-orderbookapi.md | 6 +- .../adr/0006-cow-twap-ethflow-host-helpers.md | 14 +-- .../0007-upstream-protocol-logic-to-cow-rs.md | 23 +++-- .../0008-factory-subscriptions-in-manifest.md | 89 ++++++++----------- 5 files changed, 76 insertions(+), 83 deletions(-) diff --git a/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md index 4564401..8dfb931 100644 --- a/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md +++ b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md @@ -3,33 +3,36 @@ status: proposed implemented-in: nullislabs/shepherd#10 --- -# Patch `cowprotocol` crate to `bleu/cow-rs` main +# Patch `cowprotocol` crate to the head of upstream PR #5 ## Context -`cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from `cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. The published artifact predates 18 follow-up commits on `bleu/cow-rs` main that the engine materially depends on, in particular: +`cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from an early snapshot of `cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. That PR is still open and is the canonical upstream channel for landing additions to the Rust SDK. Its head branch is `bleu/cow-rs:main`, currently at commit `c012404`, carrying 18 follow-up commits the engine materially depends on: -- `composable::Proof` byte-width fix (consumed by the TWAP poll path); -- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding from mfw78's review of PR #5); -- `order_book` / `composable` submodule splits (cleaner imports on the engine side, no more `cowprotocol::order_book::*` re-export gymnastics). +- `composable::Proof` byte-width fix (consumed by the TWAP poll path). +- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding from the PR #5 review). +- `order_book` / `composable` submodule splits (cleaner imports on the engine side). -ADR-0007 additionally commits us to pushing TWAP / EthFlow / app-data protocol logic upstream into `cowprotocol` first and consuming it via the same patched dependency, so the patch surface will continue growing through M2. +ADR-0007 commits us to landing TWAP, EthFlow, and `OrderPostError` primitives into PR #5 directly, by pushing additional commits to its head branch. Each commit advances both PR #5 and the patch rev consumed here. -There is no published `alpha.4` and no scheduled date for one. +There is no published `alpha.4` and no scheduled date for one; the engine cannot wait. ## Decision Add a workspace-level `[patch.crates-io]` redirecting `cowprotocol` to `https://github.com/bleu/cow-rs` at commit `c012404`. Every crate that declares `cowprotocol = "1.0.0-alpha.3"` (engine, modules, future SDK) silently picks up the patched build with no `Cargo.toml` change at the dependent site. +This is not a parallel fork. `bleu/cow-rs:main` IS the head branch of upstream PR #5. Pushing to it updates PR #5; the patch rev advances by bumping a single workspace line. + ## Considered options -- **Vendor the missing types locally.** Rejected: re-implementing `composable::Proof`, `OrderCreation`, etc. in the engine repo is exactly the AI-duplication anti-pattern mfw78 flagged in cow-rs PR #5. Reuse over reimplement applies. +- **Vendor the missing types locally.** Rejected: re-implementing `composable::Proof`, `OrderCreation`, etc. in the engine repo is the AI-duplication anti-pattern flagged by reviewers on cow-rs PR #5. Reuse over reimplement applies. - **Pin every dependent to `cow-rs` git directly.** Works but every new workspace member has to remember the git source. `[patch.crates-io]` centralises the override. +- **Open a separate PR per primitive against `cowdao-grants/cow-rs`.** Rejected: fragments review across multiple PRs when one already exists at the appropriate granularity. Stacking commits on PR #5 keeps the review thread coherent and lets reviewers track the cumulative change. - **Wait for `alpha.4` to publish.** No ETA; the TWAP/EthFlow milestone cannot land without `composable::Proof` correct. ## Consequences -- `cargo update` will re-resolve to the same `rev` — the lock pins it. -- Bumping the rev is a single-line workspace edit; reviewers see one diff. -- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `OrderPostError` rich variants). Until then, expect the patch rev to advance with every cow-rs merge that the engine consumes. -- Modules built against this workspace inherit the patch transitively; modules built standalone against crates.io will see `alpha.3` and may hit the very bugs the patch closes — flag in the SDK README when M3 lands. +- `cargo update` will re-resolve to the same `rev`; the lock pins it. +- Bumping the rev is a single-line workspace edit; reviewers see one diff per primitive added to PR #5. +- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `OrderPostError` rich variants). Until then, expect the patch rev to advance with every push to PR #5. +- Modules built against this workspace inherit the patch transitively; modules built standalone against crates.io will see `alpha.3` and may hit the very bugs the patch closes. Flag this in the SDK README when M3 lands. diff --git a/docs/adr/0005-cow-api-via-cached-orderbookapi.md b/docs/adr/0005-cow-api-via-cached-orderbookapi.md index ae9c6b5..5b37019 100644 --- a/docs/adr/0005-cow-api-via-cached-orderbookapi.md +++ b/docs/adr/0005-cow-api-via-cached-orderbookapi.md @@ -11,7 +11,9 @@ implemented-in: nullislabs/shepherd#8 ## Decision -At engine boot, construct one `cowprotocol::OrderBookApi` per `cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, ArbitrumOne, Base) into a `BTreeMap` keyed by EVM chain id. Both `cow-api` operations consult this pool: +At engine boot, construct one `cowprotocol::OrderBookApi` per `cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, ArbitrumOne, Base) into a `BTreeMap` keyed by EVM chain id. "Cached" here means built once during boot and reused for the engine's lifetime; clients are not lazy-constructed on each call nor LRU-evicted. The map is created in `OrderBookPool::with_default_chains()` and never mutated after. + +Both `cow-api` operations consult this pool: - `request` resolves the chain's `OrderBookApi`, reads `api.base_url()` for the prefix, joins the module-supplied path, and dispatches via a shared `reqwest::Client`. - `submit-order` deserialises the JSON `OrderCreation` and calls `OrderBookApi::post_order` directly. The crate handles signing-scheme encoding, error mapping, and `OrderUid` extraction. @@ -20,7 +22,7 @@ Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` at t ## Considered options -- **Raw `reqwest` for both.** Rejected: forces us to maintain the chain → base-URL table (drifts whenever cowprotocol adds a chain) and reimplement `post_order`'s body codec and error mapping — the exact duplication mfw78 called out in cow-rs PR #5. +- **Raw `reqwest` for both.** Rejected: forces us to maintain the chain → base-URL table (drifts whenever cowprotocol adds a chain) and reimplement `post_order`'s body codec and error mapping, the exact duplication flagged in cow-rs PR #5 review. - **`OrderBookApi` for `submit-order`, raw `reqwest` for `request`.** Tempting (request is opaque to the crate) but means two separate chain-resolution paths, two HTTP clients, and a second place to keep the chain set in sync. - **Build `OrderBookApi` lazily on first call per chain.** Rejected: hides config errors at runtime. Up-front boot construction surfaces unknown chains immediately and amortises away the per-call cost. diff --git a/docs/adr/0006-cow-twap-ethflow-host-helpers.md b/docs/adr/0006-cow-twap-ethflow-host-helpers.md index 8870d3d..300709a 100644 --- a/docs/adr/0006-cow-twap-ethflow-host-helpers.md +++ b/docs/adr/0006-cow-twap-ethflow-host-helpers.md @@ -6,14 +6,16 @@ status: proposed ## Context -The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both follow the same external-indexer/relayer pattern that CoW's own infrastructure has been progressively extracting from the monolithic `cowprotocol/services` repository: +The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both follow the same external-indexer/relayer pattern that CoW maintainers have signalled intent to extract from the monolithic `cowprotocol/services` repository: -- **TWAP / ComposableCoW** — extracted as the standalone `cowprotocol/watch-tower` (TypeScript). Listens to `ConditionalOrderCreated`, polls `getTradeableOrderWithSignature` on each block, posts to the orderbook when an order becomes tradeable. -- **EthFlow indexer** — still inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Listens to `OrderPlacement` / `OrderInvalidation` / `OrderRefund`, inserts into the `ethflow_orders` table. CoW's architectural direction is to extract this into a standalone service, mirroring how `watch-tower` and the `refunder` crate were already extracted. The Shepherd `ethflow-watcher` module is the natural Rust home for that extraction. +- **TWAP / ComposableCoW** is already extracted as the standalone `cowprotocol/watch-tower` (TypeScript). Listens to `ConditionalOrderCreated`, polls `getTradeableOrderWithSignature` on each block, posts to the orderbook when an order becomes tradeable. +- **EthFlow indexer** still lives inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Listens to `OrderPlacement` / `OrderInvalidation` / `OrderRefund`, inserts into the `ethflow_orders` table. The intent is to extract it into a standalone service following the same path `watch-tower` and the `refunder` crate already took. The Shepherd `ethflow-watcher` module is positioned as that extraction. Both flows share the same pattern: observe an on-chain event, derive a signed `OrderCreation`, submit it to the orderbook. The derivation has enough protocol detail (signing scheme, ComposableCoW eth_call, EthFlow EIP-1271 contract signature, log decoding) that a guest module would either ship that logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or make ten round-trips to the host through generic `chain`/`cow-api` calls. -Per ADR-0007, the protocol logic itself lives in the `cowprotocol` crate — not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. +Per ADR-0007, the protocol logic itself lives in the `cowprotocol` crate, not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. + +The newer ComposableCoW iteration in development simplifies polling versus the watch-tower TypeScript implementation: less of the SDK's discriminated `PollResultCode` mapping may need to be replicated in `cowprotocol::composable` for `twap.poll-and-submit` to work. The rich `PollOutcome` variants described below remain the target API surface; the upstream implementation may end up simpler than the watch-tower mirror suggests. ## Decision @@ -64,9 +66,9 @@ The engine wires these primitives into HostState and maps their errors to `host- ## Considered options -- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW / EthFlow glue. mfw78's "reuse over reimplement" applied: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. +- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW / EthFlow glue. "Reuse over reimplement" applies: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. - **Implement the protocol glue inside `nexum-engine` host code, port upstream later.** Rejected per ADR-0007: every line of TWAP polling or EthFlow decoding that lives in the engine is a line that future Rust consumers cannot reuse, and a line that diverges as cow-rs evolves. -- **EthFlow as pure passive observer (no `submit-from-log`).** Briefly considered after reading "watcher" / "monitor" in mfw78's docs/00 and docs/04 as "no submission". Rejected after verifying that CoW's own autopilot DOES post equivalent (insert into `ethflow_orders` table); the Shepherd module is intended to externalize that role, not replace it with passive observation. The `pending_orders` state mentioned in docs/04 is a side-effect of the relay (local accounting of what's been observed), not the goal. +- **EthFlow as pure passive observer (no `submit-from-log`).** Briefly considered after reading "watcher" / "monitor" in docs/00 and docs/04 as "no submission". Rejected after verifying that CoW's own autopilot DOES post equivalent (insert into `ethflow_orders` table); the Shepherd module is intended to externalize that role, not replace it with passive observation. The `pending_orders` state mentioned in docs/04 is a side-effect of the relay (local accounting of what's been observed), not the goal. - **Simple `option` return on twap instead of `poll-outcome` variant.** A 1-hour-spaced TWAP polled every block would spam ~300 RPC calls per part with `None` returns. The richer outcome (`try-at-epoch`, etc.) matches watchtower's existing `PollResult` and lets modules skip polls until the contract says it's worth retrying. Production-critical. - **Single combined interface** `shepherd:cow/orders` with both helpers. Cheaper world surface but harder to gate per-capability — a module that only watches EthFlow shouldn't have to import TWAP and vice versa. Splitting keeps `[capabilities].required` honest. - **`log-json: list` payload** instead of the typed `nexum:host/types.log` record. The record already exists and the engine's event dispatch already projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both ergonomics and "no duplicate decoders". diff --git a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md index dac09ea..b6aeca6 100644 --- a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md +++ b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md @@ -6,15 +6,15 @@ status: proposed ## Context -Implementing ADR-0006 (twap + ethflow host helpers) and ADR-0005 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, rich orderbook error variants, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we open the cow-rs PR first and only land the engine wiring afterwards? +Implementing ADR-0006 (twap + ethflow host helpers) and ADR-0005 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, rich orderbook error variants, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we add it to the open upstream PR first and only land the engine wiring afterwards? -mfw78's review of cow-rs PR #5 named the failure mode explicitly: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a Bleu PR. The same risk applies to any engine-side reimplementation of protocol logic. +Review feedback on cow-rs PR #5 named the failure mode explicitly: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a contribution. The same risk applies to any engine-side reimplementation of protocol logic. -CoW's broader architecture has been moving the same direction: `watch-tower` extracted from `cowprotocol/services` autopilot, the `refunder` crate likewise, with the `ethflow_events` indexer (`crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`) identified as the next extraction target. The Rust-side equivalent of those extractions is the right home for protocol primitives — `bleu/cow-rs` (then upstream into `cowdao-grants/cow-rs`), not the engine. +CoW maintainers have signalled intent to keep extracting services from the `cowprotocol/services` monolith: `watch-tower` is already extracted, the `refunder` crate likewise, and the `ethflow_events` indexer (`crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`) is the next extraction target. The Rust SDK that Bleu is delivering through PR #5 is the natural home for the protocol primitives those extractions need. ## Decision -Protocol-level CoW logic — anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need — lands in `bleu/cow-rs` first as an upstream PR, and is consumed by `nexum-engine` via the existing `[patch.crates-io]` rev bump (ADR-0004). The engine never writes throwaway local copies of the same logic with the intent to "port later". +Protocol-level CoW logic, meaning anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need, lands as additional commits on `cowdao-grants/cow-rs` PR #5 first (head branch `bleu/cow-rs:main`), and is consumed by `nexum-engine` via the `[patch.crates-io]` rev bump (ADR-0004). The engine never writes throwaway local copies of the same logic with the intent to "port later". The concrete set of primitives we know we need is, in priority order: @@ -32,17 +32,16 @@ Lower-priority follow-ons (`OrderUid::from_slice`, retry middleware on `OrderBoo ## Considered options -- **Implement locally, refactor upstream later.** Faster short term but predictably leaves an indeterminate amount of duplicated logic in the engine, contradicts mfw78's stated conventions, and grows technical debt every time cow-rs evolves the underlying types. Rejected. +- **Implement locally, refactor upstream later.** Faster short term but predictably leaves an indeterminate amount of duplicated logic in the engine, contradicts the conventions established on cow-rs PR #5, and grows technical debt every time cow-rs evolves the underlying types. Rejected. - **Wait for cow-rs upstream maintainers to add these on their own.** No evidence anyone else is doing this work; the grant timeline does not permit waiting. - **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all worlds: blocks neither the engine nor cow-rs from drifting, and forces every other CoW consumer to re-derive the same primitives. - **Simple `Ready/NotReady` PollOutcome on item 1.** Rejected: doesn't capture watchtower's `TRY_AT_EPOCH(t)` hint, which is what prevents the polling loop from RPC-spamming during the 1-hour gap between TWAP parts. ## Consequences -- Every M2 engine issue that consumes one of the five primitives above is blocked on its cow-rs PR merging. We sequence issues so that upstream PRs and engine adoption can land in parallel where possible (e.g., open items 1, 2, 3 against `bleu/cow-rs` simultaneously rather than serially). -- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0004) is bumped after each cow-rs merge; the bump is the engine's signal that a new primitive is consumable. -- PRs in `bleu/cow-rs` follow the existing mfw78 conventions established by cow-rs PR #5: severity-tagged reviews, alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. -- After acceptance in `bleu/cow-rs`, each primitive is also surfaced as a PR (or backport) against `cowdao-grants/cow-rs` so the wider ecosystem benefits and the bleu fork narrows over time. -- The engine repo stays small: `nexum-engine` contains WIT, host wiring, supervisor, redb store, alloy provider pool, and `engine.toml` schema — nothing about CoW Protocol semantics. -- The rich `PollOutcome` (item 1) + `OrderPostError` + `retry_hint` (item 3) design naturally leads to tighter M3 SDK helpers: `WatchSet`, `PollLoop`, `BackoffLedger` patterns that any module re-using `shepherd-sdk` gets for free. -- A follow-on Bleu module — the Rust-side equivalent of `cowprotocol/refunder` (permissionless `invalidateOrder` triggering for expired EthFlow orders) — becomes natural to ship once `ethflow.submit-from-log` lands. Out of scope for M2 but explicitly enabled by the same primitives. +- Every M2 engine issue that consumes one of the five primitives above is blocked on the corresponding commit landing in PR #5's head branch. Items 1, 2, 3 can be authored as independent commits and pushed in parallel rather than serially. +- `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0004) is bumped after each push to PR #5; the bump is the engine's signal that a new primitive is consumable. +- Commits added to PR #5 follow the conventions established by its review thread: severity-tagged review notes, alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. +- The engine repo stays small: `nexum-engine` contains WIT, host wiring, supervisor, redb store, alloy provider pool, and `engine.toml` schema, with nothing about CoW Protocol semantics. +- The rich `PollOutcome` (item 1) plus `OrderPostError` and `retry_hint` (item 3) design naturally leads to tighter M3 SDK helpers: `WatchSet`, `PollLoop`, `BackoffLedger` patterns that any module re-using `shepherd-sdk` gets for free. +- A follow-on Bleu module, the Rust-side equivalent of `cowprotocol/refunder` (permissionless `invalidateOrder` triggering for expired EthFlow orders), becomes natural to ship once `ethflow.submit-from-log` lands. Out of scope for M2 but explicitly enabled by the same primitives. diff --git a/docs/adr/0008-factory-subscriptions-in-manifest.md b/docs/adr/0008-factory-subscriptions-in-manifest.md index af6c6f1..fead3a9 100644 --- a/docs/adr/0008-factory-subscriptions-in-manifest.md +++ b/docs/adr/0008-factory-subscriptions-in-manifest.md @@ -2,26 +2,23 @@ status: proposed --- -# Dynamic address registration for log subscriptions (Envio HyperIndex-style) +# Dynamic address registration for log subscriptions ## Context -Some module archetypes need to track contracts deployed dynamically by a factory — Uniswap V3 pools (deployed by `UniswapV3Factory`), Aave V3 reserves (registered via `PoolAddressesProvider`), lending market deployments, NFT marketplace collections. Static `[[subscription]]` declarations in `nexum.toml` cannot express this: the child addresses are not known when the module's manifest is authored. +Some module archetypes need to track contracts deployed dynamically by a factory, for example Uniswap V3 pools (deployed by `UniswapV3Factory`). Static `[[subscription]]` declarations in `nexum.toml` cannot express this: the child addresses are not known when the module's manifest is authored. -Neither TWAP nor EthFlow (the M2 grant deliverables) needs this — both subscribe to a single well-known contract per chain (`ComposableCoW`, `CoWSwapEthFlow`). This ADR is forward-looking: 0.2 is the breaking-change window per `docs/migration/0.1-to-0.2.md` §522, with contracts stable from 0.2.0 onwards. Adding factory support after 0.2 would require another major version bump. +Neither TWAP nor EthFlow (the M2 grant deliverables) needs this. Both subscribe to a single well-known contract per chain. This ADR is forward-looking, motivated by `docs/migration/0.1-to-0.2.md` §522 declaring 0.2 the breaking-change window; adding factory support after 0.2 would require another major version bump. -Two production EVM indexer frameworks define the design space: +Envio HyperIndex uses a hybrid pattern that fits Shepherd's design: topics are declared statically in the manifest, and the watched address set is mutated at runtime via a `register()` host call. The engine maintains a single aggregated log subscription per template; the address set grows as the module learns of new contracts. -- **Ponder** (`ponder.config.ts`) is fully declarative: the user describes the factory contract, the factory event, and which event parameter holds the child address. Ponder extracts the address itself and indexes children automatically. The framework does ABI-aware extraction; the user writes no factory handler. -- **Envio HyperIndex** (`envio.yaml` + handler code) is a hybrid: the user declares the **template** (ABI, event topics) without an address, then calls `context..register(address)` inside the factory event handler. Topics are static; the watched address set grows at runtime. - -The Envio model decouples "what topics the engine listens for" (static, in the manifest) from "which addresses are interesting" (dynamic, driven by module code). The engine maintains a single aggregated subscription per template; the address set is mutated as the module learns of new contracts. +Whether the engine should also handle historical backfill on register (the module passes `from-block`, engine paginates `eth_getLogs` from there to head before going live) is a separate decision flagged for upstream review. This ADR keeps the engine surface minimal and defers historical replay to the existing module-driven catch-up pattern documented in `docs/02:260`. ## Decision -Adopt the Envio model. Two pieces: +Two pieces: -**1. Manifest schema gains `[[subscription.template]]`** — a topic-only log subscription whose address set is populated at runtime: +**1. Manifest schema gains `[[subscription.template]]`**, a topic-only log subscription whose address set is populated at runtime: ```toml [[subscription.template]] @@ -31,9 +28,6 @@ event_topics = [ "0xc42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67", # Swap "0x7a53080ba414158be7ec69b987b5fb7d07dee101fe85488f0853ae16239d0bde", # Mint ] -# Optional: pre-register a set of addresses at boot (before init runs). -# Useful for protocols where some addresses are known statically. -initial_addresses = [] ``` Existing `[[subscription]]` blocks with concrete `address` are unchanged. A module typically declares one static `[[subscription]]` for the factory event itself, plus one `[[subscription.template]]` per child contract type. @@ -42,23 +36,18 @@ Existing `[[subscription]]` blocks with concrete `address` are unchanged. A modu ```wit interface chain { - // ... existing request, request-batch, subscribe-blocks, subscribe-logs ... + // existing request, request-batch, subscribe-blocks, subscribe-logs ... /// Add an address to the watch set for `template-name` on `chain-id`. - /// If `from-block` is set and precedes the current head, the engine - /// runs paginated `eth_getLogs` over the template's topics on this - /// address from `from-block` to head before going live. Registration - /// is idempotent — calling twice with the same arguments is a no-op. + /// Idempotent: calling twice with the same arguments is a no-op. register-address: func( chain-id: chain-id, template-name: string, address: list, // 20 bytes - from-block: option, ) -> result<_, host-error>; /// Remove an address from the watch set. Subsequent events on that - /// address are dropped. Idempotent — unregistering an unknown address - /// returns Ok. + /// address are dropped. Idempotent. unregister-address: func( chain-id: chain-id, template-name: string, @@ -71,8 +60,8 @@ interface chain { ```wit variant log-source { - static(u32), // existing — index into [[subscription]] - template(string), // new — name of the [[subscription.template]] + static(u32), // existing: index into [[subscription]] + template(string), // new: name of the [[subscription.template]] } ``` @@ -80,25 +69,23 @@ Module code (Rust, Uniswap V3 indexer): ```rust fn init(config: Vec<(String, String)>) -> Result<(), HostError> { - // Resume: re-register every pool we already discovered. Each pool's - // creation block is persisted; backfill resumes from where we left off. + // Resume: re-register every pool we already discovered. for key in local_store::list_keys("pool:")? { let pool = parse_addr(&key); - let from_block = u64::from_le_bytes(local_store::get(&key)?.unwrap()); - chain::register_address(1, "uniswap_v3_pool", &pool, Some(from_block))?; + chain::register_address(1, "uniswap_v3_pool", &pool)?; } Ok(()) } fn on_event(event: Event) -> Result<(), HostError> { match event { - // Factory event — declared as a static [[subscription]] for the factory. + // Factory event, declared as a static [[subscription]] for the factory. Event::Log(LogEvent { log, source: LogSource::Static(0) }) => { let pool = decode_pool_created(&log)?; - chain::register_address(1, "uniswap_v3_pool", &pool, Some(log.block_number))?; - local_store::set(&format!("pool:{}", hex(&pool)), &log.block_number.to_le_bytes())?; + chain::register_address(1, "uniswap_v3_pool", &pool)?; + local_store::set(&format!("pool:{}", hex(&pool)), b"")?; } - // Pool event — dispatched through the template. + // Pool event, dispatched through the template. Event::Log(LogEvent { log, source: LogSource::Template(name) }) if name == "uniswap_v3_pool" => { @@ -112,29 +99,29 @@ fn on_event(event: Event) -> Result<(), HostError> { Engine internals: -- **Boot**: read all `[[subscription.template]]` blocks across loaded modules. Initialise per-template address sets from `initial_addresses` plus the reserved key `__nexum:template:{name}:addresses` in the module's `local-store` namespace. -- **Live**: one `eth_subscribe logs` per chain per template, filter = `(topic in event_topics) ∧ (address in current_set)`. When `register-address` mutates the set, the engine re-subscribes (or shards the filter when the set exceeds the provider's address-limit threshold). -- **Backfill on register**: if `from-block` < current head, run paginated `eth_getLogs(topic, address, from-block, head)` synchronously before joining the live stream. Events from backfill are dispatched through the same `on_event` callback as live events. -- **Persistence**: engine writes `__nexum:template:{name}:addresses` (one entry per registered address) and `__nexum:template:{name}:cursor:{address}` (last block dispatched per address) in the module's reserved namespace. Resume is automatic if the module re-calls `register-address` for each persisted address; engine deduplicates via the persisted cursor. +- **Boot**: read all `[[subscription.template]]` blocks. Initialise per-template address sets from the reserved key `__nexum:template:{name}:addresses` in the module's `local-store` namespace if present from a prior run. +- **Live**: one `eth_subscribe logs` per chain per template with filter `(topic in event_topics) AND (address in current_set)`. When `register-address` mutates the set, the engine re-subscribes. +- **Persistence**: engine writes `__nexum:template:{name}:addresses` whenever the set changes. Resume after restart is automatic if the module re-calls `register-address` in `init`. + +Historical backfill is the module's responsibility, consistent with the catch-up pattern documented in `docs/02:260`. The module calls `chain.request("eth_getLogs", ...)` during `init` to replay history before going live. The engine does not backfill on `register-address`. ## Considered options -- **Ponder full-declarative** (factory address + event + parameter declared in manifest, engine extracts child). Rejected: schema must express ABI-aware extraction (`child = { source = "topic", index = 1 }` or `{ source = "data", offset = 32, length = 20 }`), and grows with every exotic factory shape (nested factories, multi-child events, address computed from multiple fields). The Envio model pushes that complexity into module Rust code — where it belongs, given the module already decodes events with `alloy_sol_types`. -- **Pure imperative `chain.open-log-stream(filter) -> stream-handle`.** Rejected: each call opens a new subscription, so N pools = N WSS connections. Doesn't scale to indexers with 10k+ tracked addresses. The Envio model keeps one subscription per template and mutates its address set — engine batches naturally. -- **Wildcard manifest** (`address = "*"` with topic-only filter, module client-side filters). Rejected: mainnet has ~10k contracts emitting `Transfer` / `Swap` per day. The engine would deliver every matching event to every wildcard subscriber; modules pay fuel and bandwidth to discard 99% of them. -- **Defer factory pattern entirely to 0.3.** Rejected: 0.2 is the breaking-change window per migration:522. Adding either `[[subscription.template]]` or `register-address` after 0.2 requires another major bump. Better to land the small surface now than break later. -- **Templates declared inside `[[subscription]]` with optional `address` (one block, two modes).** Rejected: conflates two semantically distinct cases — modules looking at `[[subscription]]` would have to inspect for the presence of `address` to know whether they need to call `register-address`. Separate block name is clearer. -- **Engine extracts the child address from the static factory `[[subscription]]` (best of both).** Rejected: would require the manifest to identify a relationship between the static subscription and a template, plus the ABI extraction rules. Reintroduces the Ponder schema complexity we just rejected. +- **Ponder full-declarative** (factory address, event, parameter declared in manifest; engine extracts child). Rejected: schema must express ABI-aware extraction (`child = { source = "topic", index = 1 }` or similar), and grows with every exotic factory shape (nested factories, multi-child events, address computed from multiple fields). The Envio model pushes that complexity into module Rust code, where it belongs given the module already decodes events with `alloy_sol_types`. +- **Pure imperative `chain.open-log-stream(filter) -> stream-handle`.** Rejected: each call opens a new subscription, so N pools means N WSS connections. Doesn't scale to indexers with 10k+ tracked addresses. The Envio model keeps one subscription per template and mutates its address set; engine batches naturally. +- **Engine-driven historical backfill on register** (with `from-block` parameter). Rejected after PR review flagged the added complexity. Module-driven catch-up via `init` + `eth_getLogs` already exists in mfw's design (`docs/02:260`) and covers the same use case without adding engine state (per-address cursor, paginated `eth_getLogs` orchestration). M3 SDK can ship a helper that wraps the pattern. +- **Wildcard manifest** (`address = "*"` with topic-only filter, module client-side filters). Rejected: mainnet has ~10k contracts emitting `Transfer` or `Swap` per day. The engine would deliver every matching event to every wildcard subscriber; modules pay fuel and bandwidth to discard 99% of them. +- **Defer factory pattern entirely to 0.3.** Rejected: 0.2 is the breaking-change window per migration:522. Adding either `[[subscription.template]]` or `register-address` after 0.2 requires another major bump. +- **Templates declared inside `[[subscription]]` with optional `address` (one block, two modes).** Rejected: conflates two semantically distinct cases. Modules looking at `[[subscription]]` would have to inspect for the presence of `address` to know whether they need to call `register-address`. Separate block name is clearer. ## Consequences -- `nexum.toml` schema gains `[[subscription.template]]` with `chain_id`, `name`, `event_topics`, optional `initial_addresses`. mfw78 approval needed for the schema extension (his spec). -- `nexum:host/chain` gains `register-address` and `unregister-address` functions; `nexum:host/event-module`'s `log-source` variant gains `template(string)`. mfw78 approval needed for the WIT change (his namespace). These are the only WIT additions in this ADR — small, focused, with no implicit dependencies on other interfaces. -- Reserved key namespace `__nexum:template:*` in each module's `local-store` namespace. Modules MUST NOT write to keys with this prefix; engine reserves them. -- Module boilerplate per factory ≈ 5–10 lines (decode the factory event, call `register-address`, persist for resume). The M3 SDK is expected to ship a helper that encapsulates this — something like `Factory::::on_event(register_template("uniswap_v3_pool"))` — but the host surface is intentionally simple enough that no SDK is required to use it. -- Engine can register addresses sourced from anywhere — factory events, HTTP API responses, governance votes, operator-supplied lists. Composability is a deliberate feature; the engine treats every registration the same way regardless of provenance. -- Nested factories (a child contract that is itself a factory) work without schema changes: the child's event handler decodes its own creation events and calls `register-address` on the grandchild template. Engine has no concept of nesting; it just multiplexes addresses per template. -- Conditional registration ("only register pools with fee = 3000") works without schema changes: the module's factory-event handler inspects the event payload and decides whether to call `register-address`. -- Backfill cost: a module registering 10k addresses with `from-block` deep in history triggers 10k paginated `eth_getLogs` runs, sequentially per address (the engine cannot batch across addresses with different `from-block` cursors without state-machine work that's not in scope for 0.2). Operators should set sensible `start_block` boundaries; the M3 SDK is expected to ship a `BulkBackfill` helper that groups same-cursor addresses into combined filter queries. -- The address set per template is bounded only by `local-store` quota. The engine enforces a soft cap (default 50k addresses per template) configurable in `engine.toml` to prevent a runaway module from saturating the provider's filter limits; exceeding the cap returns `host-error.denied` from `register-address`. -- A module that never calls `register-address` for a declared template receives no events from it — equivalent to declaring an unused subscription. Engine logs a warning on boot if a template is declared with `initial_addresses = []` and the module has no registrations after `init` returns. +- `nexum.toml` schema gains `[[subscription.template]]` with `chain_id`, `name`, `event_topics`. Schema extension needs upstream approval. +- `nexum:host/chain` gains `register-address` and `unregister-address`; `nexum:host/event-module`'s `log-source` variant gains `template(string)`. WIT change needs upstream approval. +- Reserved key namespace `__nexum:template:*` in each module's `local-store` namespace. Modules MUST NOT write to keys with this prefix. +- Module boilerplate per factory is roughly 5 lines (decode the factory event, call `register-address`, persist for resume). The M3 SDK can ship a helper that wraps it. +- Register sources are not limited to factory events. A module can register addresses from any signal: HTTP API responses, governance votes, operator-supplied lists. Composability is a deliberate feature. +- Nested factories (a child contract that is itself a factory) work without schema changes. The child's event handler calls `register-address` on the grandchild template. +- Conditional registration ("only register pools with fee = 3000") works without schema changes. The module's factory-event handler decides. +- The address set per template is bounded only by `local-store` quota. The engine enforces a soft cap (default 50k addresses per template) configurable in `engine.toml`; exceeding the cap returns `host-error.denied` from `register-address`. +- Open follow-up: whether to support `from-block` historical backfill on register is left for upstream discussion. The minimal surface here can be extended additively if needed. From e5579a3f9ec7632e64bfbeb500a9823d816486ea Mon Sep 17 00:00:00 2001 From: brunota20 Date: Mon, 8 Jun 2026 14:39:17 -0300 Subject: [PATCH 5/5] fix(docs): revised ADRs and diagrams --- ...01-engine-toml-separate-from-nexum-toml.md | 18 +- .../0002-provider-pool-transport-by-scheme.md | 11 +- docs/adr/0003-local-store-namespacing.md | 34 +- .../0004-patch-cowprotocol-to-bleu-cow-rs.md | 10 +- .../0005-cow-api-via-cached-orderbookapi.md | 8 +- .../adr/0006-cow-twap-ethflow-host-helpers.md | 91 +--- .../0007-upstream-protocol-logic-to-cow-rs.md | 37 +- .../0008-factory-subscriptions-in-manifest.md | 171 ++----- docs/diagrams/README.md | 31 ++ docs/diagrams/architecture.mmd | 69 +++ docs/diagrams/diagrams.md | 472 ++++++++++++++++++ docs/diagrams/engine-boot.mmd | 59 +++ docs/diagrams/module-lifecycle.mmd | 39 ++ docs/diagrams/sequence-ethflow.mmd | 39 ++ docs/diagrams/sequence-twap.mmd | 56 +++ docs/diagrams/subscription-dispatch.mmd | 61 +++ docs/diagrams/wit-call-path.mmd | 34 ++ 17 files changed, 1009 insertions(+), 231 deletions(-) create mode 100644 docs/diagrams/README.md create mode 100644 docs/diagrams/architecture.mmd create mode 100644 docs/diagrams/diagrams.md create mode 100644 docs/diagrams/engine-boot.mmd create mode 100644 docs/diagrams/module-lifecycle.mmd create mode 100644 docs/diagrams/sequence-ethflow.mmd create mode 100644 docs/diagrams/sequence-twap.mmd create mode 100644 docs/diagrams/subscription-dispatch.mmd create mode 100644 docs/diagrams/wit-call-path.mmd diff --git a/docs/adr/0001-engine-toml-separate-from-nexum-toml.md b/docs/adr/0001-engine-toml-separate-from-nexum-toml.md index fd77ac3..ab6c1f4 100644 --- a/docs/adr/0001-engine-toml-separate-from-nexum-toml.md +++ b/docs/adr/0001-engine-toml-separate-from-nexum-toml.md @@ -3,30 +3,34 @@ status: proposed implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 --- -# Operator config (`engine.toml`) is separate from module manifest (`nexum.toml`) +# Operator config (`engine.toml`) is separate from module manifest (`module.toml`) ## Context The engine needs two distinct kinds of configuration: what the **operator** decides at deployment time (which chains to connect to, where the local-store database lives, which modules to boot) and what the **module developer** declares at build time (required and optional capabilities, HTTP allowlist, module-specific config keys). These have different reviewers, different threat models, and change on different cadences. +The filenames need to signal who owns each file directly. An operator opening a config file should know without prior context whether the file is their concern or the module developer's. A name like `nexum.toml` requires the reader to know that "nexum" refers to the runtime that hosts the module, which is one indirection too many; `module.toml` reads as "the module's manifest" with no prior context. + ## Decision Two distinct files, distinct schemas, distinct loaders: - **`engine.toml`** — operator-owned, lives next to the engine binary or pointed to by `--engine-config`. Defines `[engine]` (state_dir, log_level), `[chains.]` (rpc_url), and `[[modules]]` (path, manifest). Loaded by `engine_config::EngineConfig::load`. -- **`nexum.toml`** — module-developer-owned, ships in the module's bundle alongside its `.wasm` component. Defines `[module]`, `[capabilities]` (required, optional, http allowlist), `[config]`. Loaded by `manifest::load`. +- **`module.toml`** — module-developer-owned, ships in the module's bundle alongside its `.wasm` component. Defines `[module]`, `[capabilities]` (required, optional, http allowlist), `[config]`. Loaded by `manifest::load`. -The engine config carries the path to each module's manifest; the two never collapse into one file. +The engine config carries the path to each module's manifest; the two never collapse into one file. The names `engine.toml` and `module.toml` map directly onto the two distinct roles, so a reader reaching either file knows whose concerns it covers. ## Considered options - **Single `shepherd.toml` with `[engine]`, `[chains]`, `[[modules]]` *and* nested `[modules..capabilities]` per module.** Rejected: conflates operator and developer concerns. A module's capability declaration is a property of the build, not the deployment — it belongs in the artifact, not in the operator's local file. Auditing a module's capabilities also becomes a per-deployment exercise instead of a property visible in the published bundle. -- **`nexum.toml` inside the engine config (module entries embed it inline).** Rejected for the same reason; also bloats `engine.toml`. +- **Keep the `nexum.toml` filename for the module manifest.** Rejected: the name does not signal who owns the file (engine vs module). `module.toml` reads as "the module's manifest" without prior context. +- **`module.toml` inside the engine config (module entries embed it inline).** Rejected for the same reason as the single-file proposal; also bloats `engine.toml`. - **Drop `engine.toml` entirely; pass everything as CLI flags or env vars.** Rejected: per-chain RPC URLs and module lists are awkward as flags, and `RUST_LOG` already covers the only thing that env vars naturally express. ## Consequences - A deployment needs both files. A missing `engine.toml` falls back to "no chains, default state_dir" — the example logging module still runs; cow-api / chain backends report `unsupported`. -- A missing `nexum.toml` triggers the 0.1-compat deprecation warning in `manifest::fallback_manifest()` (defined in `crates/nexum-engine/src/manifest.rs`) and treats every linked capability as required. This fallback is scheduled for removal in 0.3 per `docs/migration/0.1-to-0.2.md`. -- Module-bundle redistribution carries `nexum.toml` with the artifact; engines do not need to ship templates. -- Future content-addressed module distribution (0.3) embeds `nexum.toml` in the bundle hash; `engine.toml` references modules by content address rather than filesystem path. The split survives that migration unchanged. +- A missing `module.toml` triggers the 0.1-compat deprecation warning in `manifest::fallback_manifest()` (defined in `crates/nexum-engine/src/manifest.rs`) and treats every linked capability as required. This fallback is scheduled for removal in 0.3 per `docs/migration/0.1-to-0.2.md`. +- Module-bundle redistribution carries `module.toml` with the artifact; engines do not need to ship templates. +- Future content-addressed module distribution (0.3) embeds `module.toml` in the bundle hash; `engine.toml` references modules by content address rather than filesystem path. The split survives that migration unchanged. +- Implementation impact: `crates/nexum-engine/src/manifest.rs` and `engine_config.rs` need to update the filename lookup from `nexum.toml` to `module.toml`. The 0.1-compat fallback in `manifest::fallback_manifest()` should accept both names during the transition; after 0.3 only `module.toml` is recognised. diff --git a/docs/adr/0002-provider-pool-transport-by-scheme.md b/docs/adr/0002-provider-pool-transport-by-scheme.md index f027480..c8e8fab 100644 --- a/docs/adr/0002-provider-pool-transport-by-scheme.md +++ b/docs/adr/0002-provider-pool-transport-by-scheme.md @@ -13,11 +13,18 @@ implemented-in: nullislabs/shepherd#8, nullislabs/shepherd#9 The `ProviderPool::from_config` constructor reads each chain's `rpc_url` and switches by URL scheme prefix: -- `ws://` or `wss://` → `ProviderBuilder::new().connect_ws(WsConnect::new(url))`. Pubsub transport. Subscriptions and request/response both work. -- `http://` or `https://` → `ProviderBuilder::new().connect_http(parsed)`. HTTP transport. Request/response only; `subscribe-blocks` and `subscribe-logs` surface as a host error to the guest. +- `ws://` or `wss://` → `ProviderBuilder::new().connect_ws(WsConnect::new(url))`. Pubsub transport. Subscriptions and request/response both work. **This is the recommended configuration for any chain a module subscribes to.** +- `http://` or `https://` → `ProviderBuilder::new().connect_http(parsed)`. HTTP transport. Request/response only; `subscribe-blocks` and `subscribe-logs` surface as `host-error.unsupported` to the guest. Both transports erase to `DynProvider` so the rest of the engine is transport-agnostic. +Alloy is capable of emulating `eth_subscribe` on HTTP via polling, but this is intentionally **not** enabled. The engine takes an opinionated stance favouring WebSockets for subscriptions; operators who want push-based events configure WSS endpoints. HTTP-only chains are supported for `request` traffic but not for subscriptions. + +## Non-goals + +- **RPC failover, load balancing, and retry policies are explicitly out of scope for the engine.** This logic lives in upstream crates (alloy ships tower-style middleware for timeout / retry / rate-limit / fallback endpoint). The engine does not roll its own. Operators wanting failover configure it via alloy provider builders before passing them through, or rely on the provider's own fallback (Alchemy, Infura, etc. handle it server-side). +- Re-routing requests across chains, rebalancing across pools within a chain, and similar provider-management concerns are likewise alloy's responsibility. + ## Considered options - **Force WSS everywhere.** Rejected: many providers (Alchemy, Infura, self-hosted RPC) expose HTTP-only on free tiers, and modules that only need `request` (no subscriptions) shouldn't be blocked by a WSS requirement. diff --git a/docs/adr/0003-local-store-namespacing.md b/docs/adr/0003-local-store-namespacing.md index f265137..47d5378 100644 --- a/docs/adr/0003-local-store-namespacing.md +++ b/docs/adr/0003-local-store-namespacing.md @@ -3,31 +3,47 @@ status: proposed implemented-in: nullislabs/shepherd#8 --- -# Per-module namespacing in `local-store` via `[len:u8][module][key]` prefix +# Per-module namespacing in `local-store` via 32-byte deterministic hash prefix ## Context -`nexum:host/local-store` is a key-value store shared across all modules the engine runs. Two modules using the same key string (e.g. `"last-block"`) must see disjoint values; one module must never read or overwrite another's data. The engine knows each module's name at instantiation time, so namespacing is a host-side concern. +`nexum:host/local-store` is a key-value store shared across all modules the engine runs. Two modules using the same key string (e.g. `"last-block"`) must see disjoint values; one module must never read or overwrite another's data. The engine knows each module's identity at instantiation time, so namespacing is a host-side concern. + +Two properties matter for the namespace prefix: + +1. **Deterministic and unspoofable.** An arbitrary `module_name` string read out of `module.toml` lets a malicious or careless operator give two modules the same name and have one read the other's state. A fixed-size hash derived from the module's canonical identity is harder to collide and removes the operator-supplied-text attack surface. +2. **Composes with ENS-based module discovery** (per `docs/03-module-discovery.md`): when a module is identified by an ENS name (e.g. `twap-monitor.shepherd.eth`), the ENS namehash is a natural prefix. ENS TXT records pinning the `.wasm` content hash provide a separate verification path against the loaded bundle. ## Decision Single redb database file at `EngineConfig.engine.state_dir`, single shared table `nexum:local-store`. Every key handed to redb is composed host-side as: ``` -[len: u8] [module_name: len bytes] [raw key: rest of the bytes] +[32-byte namespace prefix][raw key bytes] ``` -Module names longer than 255 bytes are rejected at `LocalStore` construction (matches the one-byte length prefix). Modules see plain key strings on both the read and write paths; the prefix is invisible to the WIT-facing API. +The 32-byte prefix is computed deterministically from the module's canonical identity: + +- **ENS-identified modules** (M3+, per `docs/03`): prefix is `ens_namehash(name)` (EIP-137), e.g. `namehash("twap-monitor.shepherd.eth")`. +- **Locally-loaded modules** (current 0.2 scope, no ENS): prefix is `keccak256(module_name)` where `module_name` comes from `module.toml`'s `[module].name` field. + +Both produce a 32-byte digest with the same domain, so a module loaded locally during development and later published under an ENS name can keep its existing state by registering an alias (`alias = keccak256(name)`) the engine recognises during the migration window. The exact alias mechanism is out of scope for this ADR. + +Modules see plain key strings on both the read and write paths; the prefix is invisible to the WIT-facing API. ## Considered options -- **Separator string** (`{module}:{key}`). Rejected: any module name containing `:` collides with another module's `:`-bearing key. Length prefix is unambiguous regardless of payload bytes. +- **Separator string** (`{module}:{key}`). Rejected: any module name containing `:` collides with another module's `:`-bearing key. A fixed-size hash is unambiguous regardless of payload bytes. +- **`[len:u8][module_name][key]` length-prefixed string.** Rejected: spoofable (the name is operator-supplied text), and does not align with the ENS-based discovery path that 0.3 will introduce. The 32-byte hash is deterministic and namespace-uniform. - **One redb database file per module.** Rejected: multiplies open file handles linearly in modules, blocks any future cross-module atomic operations (not currently planned but cheap to keep on the table), and complicates backup tooling (N files vs 1). - **One redb *table* per module within a single file.** Rejected: redb `TableDefinition` lifetimes are `'static`, so table names must be known at compile time. Dynamic table opening per module would force string-leak workarounds and exposes the same name-collision question as separator-based keys. +- **Engine-allocated incrementing module id.** Rejected: stable across reboots only if the engine persists the allocation table, which adds a chicken-and-egg dependency on the local-store itself. Determinism from the name avoids the dependency entirely. ## Consequences -- Module data is physically interleaved in the redb tree (range scans for one module's keys are O(log n + module-key-count) — fine for our workload). -- Migrations changing the namespacing layout break every existing module's persisted state. The format must stay stable through 0.x. -- A module's `list-keys` (when added) iterates over the namespace range; the host strips the prefix before returning to the guest. -- 255-byte module-name limit is enforced loudly at construction, so configuration errors surface at boot rather than silently corrupting data at first write. +- The prefix is fixed-size (32 bytes) and independent of module name length. Range scans over a single module's keys are O(log n + module-key-count) — fine for our workload. +- Migrations changing the prefix derivation (e.g., switching the local-mode hash function or the ENS resolver) would orphan every existing module's persisted state. The derivation must stay stable through 0.x; ENS-mode introduction in 0.3 happens additively via the alias mechanism, not by changing existing prefixes. +- A module's `list-keys` iterates over the namespace range (32-byte prefix scan); the host strips the prefix before returning to the guest. +- Module data versioning (schema migrations across module versions) is the module's responsibility. The local-store does not version values; modules MAY embed a `schema_version` byte in their stored payloads and migrate on `init` when the read value's version differs from the current code's expectation. +- ENS-based discovery (per docs/03) integrates without a prefix-format change: when a module is loaded by ENS name, the prefix is `namehash(name)`. The corresponding `.wasm` content hash is verified via ENS TXT records before loading, separately from the local-store prefix derivation. +- Spoofing protection: an operator cannot make module A read module B's state by renaming, because the prefix is the hash of the canonical name. Renaming a module to match another's name produces a name conflict the engine refuses at boot, rather than silent state takeover. diff --git a/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md index 8dfb931..c8ba48b 100644 --- a/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md +++ b/docs/adr/0004-patch-cowprotocol-to-bleu-cow-rs.md @@ -10,10 +10,10 @@ implemented-in: nullislabs/shepherd#10 `cowprotocol` v1.0.0-alpha.3 (the version on crates.io) was cut from an early snapshot of `cowdao-grants/cow-rs` PR #5 at commit `1742ffa`. That PR is still open and is the canonical upstream channel for landing additions to the Rust SDK. Its head branch is `bleu/cow-rs:main`, currently at commit `c012404`, carrying 18 follow-up commits the engine materially depends on: - `composable::Proof` byte-width fix (consumed by the TWAP poll path). -- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding from the PR #5 review). +- `OrderCreation` zero-`from` fast-fail (closes a MEDIUM severity finding in PR #5). - `order_book` / `composable` submodule splits (cleaner imports on the engine side). -ADR-0007 commits us to landing TWAP, EthFlow, and `OrderPostError` primitives into PR #5 directly, by pushing additional commits to its head branch. Each commit advances both PR #5 and the patch rev consumed here. +ADR-0007 commits us to landing three protocol-level primitives into PR #5 directly (`OrderPostError` rich variants + `retry_hint`, `OrderBookApi::with_base_url`, and `wasm32` feature-gating) by pushing additional commits to its head branch. Each commit advances both PR #5 and the patch rev consumed here. There is no published `alpha.4` and no scheduled date for one; the engine cannot wait. @@ -25,14 +25,14 @@ This is not a parallel fork. `bleu/cow-rs:main` IS the head branch of upstream P ## Considered options -- **Vendor the missing types locally.** Rejected: re-implementing `composable::Proof`, `OrderCreation`, etc. in the engine repo is the AI-duplication anti-pattern flagged by reviewers on cow-rs PR #5. Reuse over reimplement applies. +- **Vendor the missing types locally.** Rejected: re-implementing `composable::Proof`, `OrderCreation`, etc. in the engine repo is the AI-duplication anti-pattern that the cow-rs SDK already solves. Reuse over reimplement applies. - **Pin every dependent to `cow-rs` git directly.** Works but every new workspace member has to remember the git source. `[patch.crates-io]` centralises the override. -- **Open a separate PR per primitive against `cowdao-grants/cow-rs`.** Rejected: fragments review across multiple PRs when one already exists at the appropriate granularity. Stacking commits on PR #5 keeps the review thread coherent and lets reviewers track the cumulative change. +- **Open a separate PR per primitive against `cowdao-grants/cow-rs`.** Rejected: fragments the change across multiple PRs when one already exists at the appropriate granularity. Stacking commits on PR #5 keeps the change coherent and lets the cumulative diff be tracked in one place. - **Wait for `alpha.4` to publish.** No ETA; the TWAP/EthFlow milestone cannot land without `composable::Proof` correct. ## Consequences - `cargo update` will re-resolve to the same `rev`; the lock pins it. - Bumping the rev is a single-line workspace edit; reviewers see one diff per primitive added to PR #5. -- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-helper additions (`composable::poll_and_build_order`, `eth_flow::decode_placement`, `OrderPostError` rich variants). Until then, expect the patch rev to advance with every push to PR #5. +- Drop the patch entirely once a published `cowprotocol` release contains both the alpha.3 follow-ups and the ADR-0007 protocol-primitive additions (`OrderPostError` rich variants + `retry_hint`, `OrderBookApi::with_base_url`, `wasm32` feature-gate). Until then, expect the patch rev to advance with every push to PR #5. - Modules built against this workspace inherit the patch transitively; modules built standalone against crates.io will see `alpha.3` and may hit the very bugs the patch closes. Flag this in the SDK README when M3 lands. diff --git a/docs/adr/0005-cow-api-via-cached-orderbookapi.md b/docs/adr/0005-cow-api-via-cached-orderbookapi.md index 5b37019..0862d54 100644 --- a/docs/adr/0005-cow-api-via-cached-orderbookapi.md +++ b/docs/adr/0005-cow-api-via-cached-orderbookapi.md @@ -11,7 +11,7 @@ implemented-in: nullislabs/shepherd#8 ## Decision -At engine boot, construct one `cowprotocol::OrderBookApi` per `cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, ArbitrumOne, Base) into a `BTreeMap` keyed by EVM chain id. "Cached" here means built once during boot and reused for the engine's lifetime; clients are not lazy-constructed on each call nor LRU-evicted. The map is created in `OrderBookPool::with_default_chains()` and never mutated after. +At engine boot, construct one `cowprotocol::OrderBookApi` per `cowprotocol::Chain` variant (currently Mainnet, Gnosis, Sepolia, ArbitrumOne, Base) into a `BTreeMap` keyed by EVM chain id. "Cached" here means built once during boot and reused for the engine's lifetime; clients are not lazy-constructed on each call nor LRU-evicted. The pool implements `Default` so callers instantiate it as `OrderBookPool::default()`; the trait impl populates the map with one entry per `cowprotocol::Chain` variant. Both `cow-api` operations consult this pool: @@ -22,13 +22,13 @@ Chains not in `cowprotocol::Chain` return `HostError { kind: unsupported }` at t ## Considered options -- **Raw `reqwest` for both.** Rejected: forces us to maintain the chain → base-URL table (drifts whenever cowprotocol adds a chain) and reimplement `post_order`'s body codec and error mapping, the exact duplication flagged in cow-rs PR #5 review. +- **Raw `reqwest` for both.** Rejected: forces us to maintain the chain → base-URL table (drifts whenever cowprotocol adds a chain) and reimplement `post_order`'s body codec and error mapping, the exact duplication the cow-rs SDK already eliminates. - **`OrderBookApi` for `submit-order`, raw `reqwest` for `request`.** Tempting (request is opaque to the crate) but means two separate chain-resolution paths, two HTTP clients, and a second place to keep the chain set in sync. - **Build `OrderBookApi` lazily on first call per chain.** Rejected: hides config errors at runtime. Up-front boot construction surfaces unknown chains immediately and amortises away the per-call cost. ## Consequences -- Operator-supplied custom orderbook URLs (barn, staging, forked deployments) are out of scope for the default constructor and require a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` constructor in the cow-rs crate (ADR-0007 item 4 — not vendored locally). +- Operator-supplied custom orderbook URLs (barn, staging, forked deployments) are out of scope for the default constructor and require a follow-on `OrderBookApi::with_base_url(chain_id, base_url)` constructor in the cow-rs crate (ADR-0007 item 2, not vendored locally). - Adding a chain means a `cowprotocol::Chain` variant lands in cow-rs first; the engine inherits it on the next patched rev bump. - The shared `reqwest::Client` enables connection pooling across both `request` and `submit-order` paths. -- TWAP and EthFlow helpers (ADR-0006) reuse the same pool — no duplicated client construction in those host wrappers. +- Guest-side TWAP and EthFlow modules (ADR-0006) submit orders through this `cow-api` interface; no specialised host helpers wrap it. diff --git a/docs/adr/0006-cow-twap-ethflow-host-helpers.md b/docs/adr/0006-cow-twap-ethflow-host-helpers.md index 300709a..0e9e776 100644 --- a/docs/adr/0006-cow-twap-ethflow-host-helpers.md +++ b/docs/adr/0006-cow-twap-ethflow-host-helpers.md @@ -2,85 +2,48 @@ status: proposed --- -# TWAP and EthFlow as intent helpers in `shepherd:cow@0.2.0` +# TWAP and EthFlow run as guest modules using low-level host primitives (no specialised `shepherd:cow` interfaces) ## Context -The reference engine already exposes `shepherd:cow/cow-api` for raw orderbook access (REST passthrough + `submit-order`). Two further CoW workflows show up in every non-trivial module: ComposableCoW conditional orders (TWAP being the canonical example) and EthFlow native-ETH orders. Both follow the same external-indexer/relayer pattern that CoW maintainers have signalled intent to extract from the monolithic `cowprotocol/services` repository: +TWAP (over ComposableCoW) and EthFlow are the two CoW workflows the M2 grant ships modules for. The natural-seeming approach is to add `shepherd:cow/twap` and `shepherd:cow/ethflow` WIT interfaces that the host implements on top of `cowprotocol` crate primitives, so modules would call `twap.poll-and-submit(...)` and `ethflow.submit-from-log(...)` as host functions. This ADR rejects that direction. -- **TWAP / ComposableCoW** is already extracted as the standalone `cowprotocol/watch-tower` (TypeScript). Listens to `ConditionalOrderCreated`, polls `getTradeableOrderWithSignature` on each block, posts to the orderbook when an order becomes tradeable. -- **EthFlow indexer** still lives inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Listens to `OrderPlacement` / `OrderInvalidation` / `OrderRefund`, inserts into the `ethflow_orders` table. The intent is to extract it into a standalone service following the same path `watch-tower` and the `refunder` crate already took. The Shepherd `ethflow-watcher` module is positioned as that extraction. +The dividing line is protocol vs implementation. CoW Protocol primitives — order types, signing schemes, the orderbook REST surface — are protocol concerns and belong in shared layers (`cowprotocol` crate, `shepherd:cow/cow-api` interface). TWAP is one of many strategies built _on top of_ those primitives; ComposableCoW is the contract surface a TWAP module observes, but the act of polling, deciding when to submit, and reacting to orderbook errors is application logic. Putting that application logic in the host or in `cowprotocol` couples every consumer to one implementation and one error-handling policy. -Both flows share the same pattern: observe an on-chain event, derive a signed `OrderCreation`, submit it to the orderbook. The derivation has enough protocol detail (signing scheme, ComposableCoW eth_call, EthFlow EIP-1271 contract signature, log decoding) that a guest module would either ship that logic itself (large WASM, duplicates work in the `cowprotocol` Rust SDK) or make ten round-trips to the host through generic `chain`/`cow-api` calls. - -Per ADR-0007, the protocol logic itself lives in the `cowprotocol` crate, not in `nexum-engine`. This ADR consequently scopes the engine-side helpers to the WIT surface and the glue that wires the upstream primitives into the host call boundary. - -The newer ComposableCoW iteration in development simplifies polling versus the watch-tower TypeScript implementation: less of the SDK's discriminated `PollResultCode` mapping may need to be replicated in `cowprotocol::composable` for `twap.poll-and-submit` to work. The rich `PollOutcome` variants described below remain the target API surface; the upstream implementation may end up simpler than the watch-tower mirror suggests. +Embedding a concrete TWAP implementation in an SDK is an architectural smell the grant explicitly seeks to alleviate. The grant seeks to enable Shepherd as the runtime where many independent strategy implementations coexist, each compiled to its own WASM module. A specialised `twap` interface in the host would defeat that goal: every Shepherd deployment would have to use the same polling implementation, the same error-mapping, the same retry hints, with no room for different strategies to differ on those choices. ## Decision -Add two new interfaces to package `shepherd:cow@0.2.0`: - -```wit -interface twap { - use nexum:host/types@0.2.0.{chain-id, log, host-error}; - use cow-api.{order-uid}; - - /// Discriminated outcome of a single poll attempt against - /// ComposableCoW. Mirrors watchtower's PollResultCode so modules - /// avoid spamming RPC/orderbook when an order is known-not-ready. - variant poll-outcome { - submitted(order-uid), - try-at-epoch(u64), // unix seconds; module skips polls until then - try-on-block(u64), // specific block number - try-next-block, // default retry - dont-try-again, // terminal: TWAP completed or cancelled - } - - poll-and-submit: func( - chain-id: chain-id, - registration: log, - ) -> result; -} - -interface ethflow { - use nexum:host/types@0.2.0.{chain-id, log, host-error}; - use cow-api.{order-uid}; - - submit-from-log: func( - chain-id: chain-id, - placement: log, - ) -> result; -} -``` +The `shepherd:cow` WIT package contains only the existing `cow-api` interface (REST passthrough + `submit-order`), which is protocol-level. No `twap` interface, no `ethflow` interface, no host-side helpers specific to either workflow. -Both interfaces ship in the existing `shepherd` world alongside `cow-api`. `order-uid` is added to `cow-api` as `type order-uid = list` (56 bytes, validated host-side) and reused by all three interfaces; `cow-api/submit-order` keeps returning it instead of `string`. Capability names `"twap"` and `"ethflow"` are appended to `KNOWN_CAPABILITIES` so manifests can declare them under `[capabilities].required`. +TWAP and EthFlow modules implement their logic in Rust guest code using: -Host implementations are thin wrappers (~20–30 LOC each) over three upstream primitives that land in `cowprotocol` first (see ADR-0007): +- **`nexum:host/chain`** — `request` (for `eth_call`, `eth_getLogs`, etc.), `subscribe-blocks`, `subscribe-logs`. +- **`nexum:host/local-store`** — for watch lists, cursors, and backoff state. +- **`nexum:host/logging`** — for structured logs. +- **`shepherd:cow/cow-api`** — `submit-order` for orderbook submission. +- **`cowprotocol` crate** (consumed directly by the module, gated on the wasm32 feature work in ADR-0007) — for protocol types: `Order`, `OrderCreation`, `OrderUid`, signing schemes, `OrderPostError`, etc. +- **`alloy_sol_types`** (or equivalent) — for ABI-aware decoding of `ConditionalOrderCreated`, `OrderPlacement`, `getTradeableOrderWithSignature` return values, and similar Solidity-typed payloads. -- `cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> PollOutcome` — returns the same discriminated outcome (`Submitted`, `TryAtEpoch`, `TryOnBlock`, `TryNextBlock`, `DontTryAgain`). Backs `twap.poll-and-submit`. -- `cowprotocol::eth_flow::decode_placement(log)` — decodes `OrderPlacement` into `(owner, OrderCreation, OrderUid)` with the EIP-1271 signing scheme pointing at the EthFlow contract. Backs `ethflow.submit-from-log`. -- `cowprotocol::OrderPostError` (rich variants + `retry_hint()`) — typed orderbook submission errors with backoff/drop classification. Modules consume the hints to react to transient vs permanent failures without spamming. +Concretely, a TWAP module's `on_event(block)` handler iterates the local-store watch set, makes an `eth_call` to `ComposableCoW.getTradeableOrderWithSignature(owner, params, "", [])` via `chain.request`, decodes the return (or revert reason) with `alloy_sol_types`, constructs an `OrderCreation` with `cowprotocol` types, and submits via `cow-api/submit-order`. Orderbook errors are interpreted via `OrderPostError::retry_hint()` (ADR-0007). Backoff state is persisted to `local-store`. All of this lives in module Rust source, not in the engine. -The engine wires these primitives into HostState and maps their errors to `host-error` kinds; no protocol logic lives in `nexum-engine`. Modules continue to declare their own log subscriptions via `[[subscription]]` in `nexum.toml`; the helpers only decode and submit, they do not auto-subscribe. +An EthFlow module's `on_event(log)` handler decodes the `OrderPlacement` event with `alloy_sol_types`, constructs the `OrderCreation` (with the EIP-1271 signing scheme pointing at the `CoWSwapEthFlow` contract), and submits the same way. Module-side, no host helper required. ## Considered options -- **Low-level primitives only** (`chain.eth-call`, `chain.keccak256`, `chain.sign-digest`, raw `cow-api/submit-order`). Maximally orthogonal, but every guest module re-derives the same EIP-712 / GPv2 / ComposableCoW / EthFlow glue. "Reuse over reimplement" applies: that derivation already lives in `cowprotocol::{Order, OrderBookApi, eth_flow, composable}` and should not be re-shipped in every WASM artifact. -- **Implement the protocol glue inside `nexum-engine` host code, port upstream later.** Rejected per ADR-0007: every line of TWAP polling or EthFlow decoding that lives in the engine is a line that future Rust consumers cannot reuse, and a line that diverges as cow-rs evolves. -- **EthFlow as pure passive observer (no `submit-from-log`).** Briefly considered after reading "watcher" / "monitor" in docs/00 and docs/04 as "no submission". Rejected after verifying that CoW's own autopilot DOES post equivalent (insert into `ethflow_orders` table); the Shepherd module is intended to externalize that role, not replace it with passive observation. The `pending_orders` state mentioned in docs/04 is a side-effect of the relay (local accounting of what's been observed), not the goal. -- **Simple `option` return on twap instead of `poll-outcome` variant.** A 1-hour-spaced TWAP polled every block would spam ~300 RPC calls per part with `None` returns. The richer outcome (`try-at-epoch`, etc.) matches watchtower's existing `PollResult` and lets modules skip polls until the contract says it's worth retrying. Production-critical. -- **Single combined interface** `shepherd:cow/orders` with both helpers. Cheaper world surface but harder to gate per-capability — a module that only watches EthFlow shouldn't have to import TWAP and vice versa. Splitting keeps `[capabilities].required` honest. -- **`log-json: list` payload** instead of the typed `nexum:host/types.log` record. The record already exists and the engine's event dispatch already projects `alloy_rpc_types_eth::Log` into it, so reuse wins on both ergonomics and "no duplicate decoders". -- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 helper only handles `ComposableCoW.create()` (empty proof, single conditional order). `setRoot` polling requires off-chain proof derivation that itself warrants a separate helper (`twap.poll-and-submit-with-proof`) once a module actually needs it. -- **Bumping the package to `shepherd:cow@0.3.0`.** Not needed: adding imports to an existing world is additive under WIT subsumption rules. Modules compiled against the current 0.2.0 surface continue to build. +- **Specialised `shepherd:cow/twap` and `shepherd:cow/ethflow` interfaces** with rich `PollOutcome` variants and per-event host helpers, backed by `composable::poll_and_build_order` and `eth_flow::decode_placement` primitives in the `cowprotocol` crate. Rejected: this puts a single concrete TWAP / EthFlow implementation behind a WIT boundary, forcing every Shepherd deployment to use the same polling policy, the same error-mapping, the same retry hints. It also blurs the protocol-vs-implementation boundary the grant is meant to clarify. Multiple TWAP implementations (different polling cadences, different error tolerances, different cancel-on-loss thresholds) must be able to coexist as separate modules without changing the host or the SDK. +- **Move TWAP / EthFlow primitives into `cowprotocol` crate but skip the WIT interfaces**, leaving modules to call `composable::poll_and_build_order` from guest code. Rejected for the same reason: `cowprotocol` is the protocol SDK, not the strategy SDK. Putting TWAP logic there embeds an implementation in the shared layer, which is the smell the grant seeks to fix. +- **Ship a thin `shepherd-sdk` helper crate** that wraps the low-level primitive calls (eth_call, decode, submit) into a convenient `Twap::poll(...)` interface for guest modules. **Acceptable for M3** because the helper would live in guest-callable code, not behind a WIT boundary — a module that wants different polling policy just doesn't use the SDK helper. The host stays neutral. +- **EthFlow as pure passive observer (no submission)**. Rejected on closer read of `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`: the canonical CoW flow expects the event to be relayed into the orderbook, which is what autopilot currently does internally. Shepherd's `ethflow-watcher` externalises that role, so the module does submit; just from guest code, not via a specialised host interface. +- **TWAP merkle-proof / `setRoot` support in v1.** Deferred. The 0.2 module only handles `ComposableCoW.create()` (empty proof, single conditional order). `setRoot` polling requires off-chain proof derivation; when a real module needs it, it will be implemented in guest code using the same low-level primitives, possibly with an SDK helper to encapsulate the proof bookkeeping. ## Consequences -- `cow-api/submit-order` return type changes from `string` to `order-uid`. No external consumers today (0.2 is unreleased), so this is internal. -- Host helpers require a chain to be configured in `[chains.]` — uncovered chains return `host-error.unsupported`. Same posture as `cow-api`. -- Orderbook idempotency (same UID on duplicate submit) is preserved but invisible to the module. Modules that need dedup must record UIDs in `local-store` themselves. -- TWAP modules must implement the `poll-outcome` state machine: persist `next_attempt` hints (epoch or block number) in local-store, skip polls until trigger, remove watches on `dont-try-again`. Without this, the poll loop becomes O(blocks × twaps) with most calls wasted. The M3 SDK is expected to ship a helper that encapsulates the state machine. -- Orderbook errors return as `host-error` with the original CoW error code in `code`. Modules use `OrderPostError::try_from(host_error)` plus `retry_hint()` (ADR-0007 item 3) to map to next-block / backoff / drop. Without this layered approach, modules spam the orderbook with permanently-broken orders. -- Implementation order: the three `cowprotocol` primitives (`composable::poll_and_build_order` with rich `PollOutcome`, `eth_flow::decode_placement`, `OrderPostError` rich + `retry_hint`) land in `bleu/cow-rs` first; `nullis-shepherd` adopts via the existing `[patch.crates-io]` rev bump (ADR-0004). Host-side issues stay blocked on upstream merges. -- Failure modes map onto existing `host-error-kind` variants (`invalid-input`, `denied`, `rate-limited`, `timeout`, `unavailable`, `unsupported`, `internal`). No new error taxonomy. +- `shepherd:cow@0.2.0` keeps `cow-api` as its only interface. No new WIT files in this ADR. +- `KNOWN_CAPABILITIES` in `crates/nexum-engine/src/manifest.rs` does **not** gain `"twap"` or `"ethflow"` entries. Modules declare the universal capabilities they actually use: `chain`, `local-store`, `logging`, `cow-api`. +- Modules ship larger (~150 LOC each estimated, up from the ~30 LOC the host-helper design implied), because event decoding, eth_call orchestration, OrderCreation construction, and error-hint interpretation now live in guest code. This is the explicit trade-off: more code per module, less coupling, more freedom for different strategies to coexist. +- Different TWAP polling strategies can coexist as different modules. Operators choose which to load via `engine.toml`'s `[[modules]]` array. +- The watch-tower TypeScript implementation remains the closest reference for what a TWAP module's logic looks like, but it is reference material, not a template the Rust module mirrors verbatim. A newer ComposableCoW iteration in development may simplify the polling surface significantly; the relevant decisions live in the module, not the host. +- `OrderPostError` rich variants + `retry_hint()` (ADR-0007 item 1, formerly item 3) become the primary protocol-level contract between the orderbook and any module submitting orders. Modules `match` on the typed error and apply the `RetryHint` (try-next-block / backoff-seconds / drop). This logic is generic across TWAP, EthFlow, stop-loss, and any future strategy. +- The M3 SDK (`shepherd-sdk` crate) is the natural home for ergonomic guest-side helpers: `WatchSet`, `PollLoop`, `BackoffLedger`, decode-and-submit utilities. The SDK is opt-in for module authors and lives entirely on the guest side; the host remains protocol-neutral. +- The architecture and sequence diagrams in `docs/diagrams/` that depict `twap.poll-and-submit` and `ethflow.submit-from-log` host calls reflect the rejected design and must be updated to show modules calling low-level primitives directly. diff --git a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md index b6aeca6..e8e949c 100644 --- a/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md +++ b/docs/adr/0007-upstream-protocol-logic-to-cow-rs.md @@ -2,46 +2,45 @@ status: proposed --- -# Push CoW Protocol logic to `cow-rs` first, adopt in `nexum-engine` second +# Push CoW Protocol primitives to `cow-rs` first, adopt in `nexum-engine` second ## Context -Implementing ADR-0006 (twap + ethflow host helpers) and ADR-0005 (cow-api backend) surfaces a recurring question: when the engine needs a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (TWAP polling glue, EthFlow log decoding, rich orderbook error variants, custom orderbook URLs), do we write that logic locally in `nexum-engine` and tidy it up upstream later, or do we add it to the open upstream PR first and only land the engine wiring afterwards? +Implementing ADR-0005 (cow-api backend) and supporting guest-side TWAP / EthFlow modules per ADR-0006 surfaces a recurring question: when the engine or its modules need a piece of CoW Protocol logic that the `cowprotocol` Rust SDK does not yet expose (rich orderbook error variants, custom orderbook URLs, wasm32 compatibility), do we write that logic locally and tidy it up upstream later, or do we add it to the open upstream PR first and only land the engine wiring afterwards? -Review feedback on cow-rs PR #5 named the failure mode explicitly: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a contribution. The same risk applies to any engine-side reimplementation of protocol logic. +The failure mode is well-known: duplicating work that an existing crate could do is the AI-coding anti-pattern most likely to land in a contribution. The same risk applies to any engine-side reimplementation of protocol logic. -CoW maintainers have signalled intent to keep extracting services from the `cowprotocol/services` monolith: `watch-tower` is already extracted, the `refunder` crate likewise, and the `ethflow_events` indexer (`crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`) is the next extraction target. The Rust SDK that Bleu is delivering through PR #5 is the natural home for the protocol primitives those extractions need. +The line between **protocol primitives** (which belong in `cowprotocol`) and **strategy implementations** (which belong in guest modules, per ADR-0006) is the operating principle. This ADR covers only the protocol-primitive additions; TWAP polling and EthFlow event decoding stay in guest modules and are explicitly **not** primitives we push to `cowprotocol`. ## Decision -Protocol-level CoW logic, meaning anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need, lands as additional commits on `cowdao-grants/cow-rs` PR #5 first (head branch `bleu/cow-rs:main`), and is consumed by `nexum-engine` via the `[patch.crates-io]` rev bump (ADR-0004). The engine never writes throwaway local copies of the same logic with the intent to "port later". +Protocol-level CoW logic — anything that an indexer, a bot, or a non-`nexum` Rust consumer of CoW Protocol would also need to interact with the protocol — lands as additional commits on `cowdao-grants/cow-rs` PR #5 first (head branch `bleu/cow-rs:main`), and is consumed by `nexum-engine` and by guest modules via the `[patch.crates-io]` rev bump (ADR-0004). The engine and the modules never write throwaway local copies of the same logic with the intent to "port later". -The concrete set of primitives we know we need is, in priority order: +The concrete set of primitives this ADR commits to upstream, in priority order: -1. **`cowprotocol::composable::poll_and_build_order(provider, owner, params, proof) -> Result`** — eth_call against `ComposableCoW.getTradeableOrderWithSignature`, decode return, rebuild `OrderCreation`. `PollOutcome` mirrors watchtower's `PollResultCode` (TS): `Submitted(OrderCreation, Vec)`, `TryAtEpoch(u64)`, `TryOnBlock(u64)`, `TryNextBlock`, `DontTryAgain`. Backs `twap.poll-and-submit` (ADR-0006). +1. **`cowprotocol::OrderPostError` rich variants + `retry_hint(&self) -> RetryHint`** — typed orderbook submission errors (`QuoteNotFound`, `InvalidQuote`, `InsufficientAllowance`, `InsufficientBalance`, `TooManyLimitOrders`, `InvalidAppData`, `AppDataFromMismatch`, `SellAmountOverflow`, `ZeroAmount`, `TransferSimulationFailed`, `ExcessiveValidTo`, …) with a `retry_hint()` helper classifying each into `TryNextBlock`, `BackoffSeconds(u64)`, or `Drop`. Mirrors watch-tower's `API_ERRORS_TRY_NEXT_BLOCK` / `API_ERRORS_BACKOFF` / `API_ERRORS_DROP` tables. Without this, every Rust consumer of CoW reinvents the same mapping, and modules spam the orderbook with permanently-broken orders. **Critical-path, not optional.** -2. **`cowprotocol::eth_flow::decode_placement(log) -> Result`** — decode `OrderPlacement` event log, reconstruct `OrderCreation` with the EIP-1271 signing scheme pointing at the `CoWSwapEthFlow` contract, compute `OrderUid`. Replicates the indexing logic currently inside `cowprotocol/services/crates/autopilot/src/database/onchain_order_events/ethflow_events.rs`. Backs `ethflow.submit-from-log` (ADR-0006). +2. **`cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)`** — custom-URL constructor for barn / staging / forked deployments. Unblocks per-chain orderbook URL overrides in `engine.toml` (ADR-0005). -3. **`cowprotocol::OrderPostError` rich variants + `retry_hint(&self) -> RetryHint`** — typed orderbook submission errors (`QuoteNotFound`, `InvalidQuote`, `InsufficientAllowance`, `InsufficientBalance`, `TooManyLimitOrders`, `InvalidAppData`, `AppDataFromMismatch`, `SellAmountOverflow`, `ZeroAmount`, `TransferSimulationFailed`, `ExcessiveValidTo`, …) with a `retry_hint()` helper classifying each into `TryNextBlock`, `BackoffSeconds(u64)`, or `Drop`. Mirrors watchtower's `API_ERRORS_TRY_NEXT_BLOCK` / `API_ERRORS_BACKOFF` / `API_ERRORS_DROP` tables. Without this, every Rust consumer of CoW reinvents the same mapping, and modules spam the orderbook with permanently-broken orders. **Critical-path, not optional.** +3. **`cowprotocol` `wasm32` compatibility** — feature-gate the `reqwest` dependency so guest modules can use the pure types (`Order`, `OrderCreation`, `OrderUid`, signing schemes, error variants) without dragging in an HTTP client. **Critical for ADR-0006**: modules implement TWAP and EthFlow logic in guest code and need `cowprotocol` types compiled to wasm32. Without this, guest modules fall back to duplicating type definitions. -4. **`cowprotocol::OrderBookApi::with_base_url(chain_id, base_url)`** — custom-URL constructor for barn / staging / forked deployments. Unblocks per-chain orderbook URL overrides in `engine.toml` (ADR-0005). - -5. **`cowprotocol` `wasm32` compatibility** — feature-gate the `reqwest` dependency so guest modules can use the pure types (`Order`, `OrderCreation`, `OrderUid`, `composable::*`, `eth_flow::decode_*`) without dragging in an HTTP client. Unblocks M3 SDK guest modules consuming `cowprotocol` directly. - -Lower-priority follow-ons (`OrderUid::from_slice`, retry middleware on `OrderBookApi`, `OrderCreation::from_gpv2`) are good-to-have but are not blocking for the M2 host scope. +Lower-priority follow-ons (`OrderUid::from_slice`, retry middleware on `OrderBookApi`, `OrderCreation::from_gpv2`) are good-to-have but are not blocking for the M2 host or module scope. ## Considered options - **Implement locally, refactor upstream later.** Faster short term but predictably leaves an indeterminate amount of duplicated logic in the engine, contradicts the conventions established on cow-rs PR #5, and grows technical debt every time cow-rs evolves the underlying types. Rejected. +- **Push TWAP / ComposableCoW primitives** (`composable::poll_and_build_order`) into `cowprotocol`. Rejected: TWAP is a concrete strategy on top of the protocol, not part of the protocol. Putting it in the SDK forces every consumer to use one polling implementation and one error-mapping policy. Per ADR-0006, TWAP polling lives in guest module code, not in shared layers. +- **Push EthFlow log-decoding primitives** (`eth_flow::decode_placement`) into `cowprotocol`. **Rejected for the same reason**: EthFlow event decoding is an implementation detail of how a particular module relays orders into the orderbook. The protocol layer defines the order types and the orderbook submission endpoint; the act of decoding an on-chain event into an `OrderCreation` is module-side logic. Modules decode `OrderPlacement` directly with `alloy_sol_types` and construct the `OrderCreation` with the EIP-1271 signing scheme. - **Wait for cow-rs upstream maintainers to add these on their own.** No evidence anyone else is doing this work; the grant timeline does not permit waiting. - **Vendor a fork of cow-rs inside `nullislabs/shepherd`.** Worst of all worlds: blocks neither the engine nor cow-rs from drifting, and forces every other CoW consumer to re-derive the same primitives. -- **Simple `Ready/NotReady` PollOutcome on item 1.** Rejected: doesn't capture watchtower's `TRY_AT_EPOCH(t)` hint, which is what prevents the polling loop from RPC-spamming during the 1-hour gap between TWAP parts. +- **Host-side `AppDataResolver` (LRU cache + GET against `/api/v1/app_data/{hash}`).** Rejected after verifying watch-tower's behavior: it never fetches app-data. The trader uploads the JSON to the orderbook via `PUT /api/v1/app_data/{hash}` separately; the relayer module just submits and reacts to `INVALID_APP_DATA` (backoff 1 min) / `APPDATA_FROM_MISMATCH` (drop) via the error map in item 1 above. ## Consequences -- Every M2 engine issue that consumes one of the five primitives above is blocked on the corresponding commit landing in PR #5's head branch. Items 1, 2, 3 can be authored as independent commits and pushed in parallel rather than serially. +- Every M2 engine or module issue that consumes one of the three primitives above is blocked on the corresponding commit landing in PR #5's head branch. Items 1, 2, 3 can be authored as independent commits and pushed in parallel rather than serially. - `[patch.crates-io]` rev in the workspace `Cargo.toml` (ADR-0004) is bumped after each push to PR #5; the bump is the engine's signal that a new primitive is consumable. -- Commits added to PR #5 follow the conventions established by its review thread: severity-tagged review notes, alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. +- Commits added to PR #5 follow its established conventions: alloy reuse over local reimplementation, GPL-3.0, edition 2024, terse rustdoc. - The engine repo stays small: `nexum-engine` contains WIT, host wiring, supervisor, redb store, alloy provider pool, and `engine.toml` schema, with nothing about CoW Protocol semantics. -- The rich `PollOutcome` (item 1) plus `OrderPostError` and `retry_hint` (item 3) design naturally leads to tighter M3 SDK helpers: `WatchSet`, `PollLoop`, `BackoffLedger` patterns that any module re-using `shepherd-sdk` gets for free. -- A follow-on Bleu module, the Rust-side equivalent of `cowprotocol/refunder` (permissionless `invalidateOrder` triggering for expired EthFlow orders), becomes natural to ship once `ethflow.submit-from-log` lands. Out of scope for M2 but explicitly enabled by the same primitives. +- Guest modules consume `cowprotocol` types directly (gated on the wasm32 feature in item 3). The `shepherd-sdk` crate in M3 may add ergonomic wrappers on top, but those live on the guest side, not behind a WIT boundary. +- A follow-on Bleu module — the Rust-side equivalent of `cowprotocol/refunder` (permissionless `invalidateOrder` triggering for expired EthFlow orders) — becomes natural to ship once an ethflow-watcher module lands. Out of scope for M2 but explicitly enabled by the same primitives. +- TWAP polling logic (decode `ConditionalOrderCreated`, eth_call `getTradeableOrderWithSignature`, decode return, build `OrderCreation`) and EthFlow event decoding stay entirely in guest module code. The `cowprotocol` crate provides only the types and the orderbook client; the strategy is the module's. diff --git a/docs/adr/0008-factory-subscriptions-in-manifest.md b/docs/adr/0008-factory-subscriptions-in-manifest.md index fead3a9..5a23356 100644 --- a/docs/adr/0008-factory-subscriptions-in-manifest.md +++ b/docs/adr/0008-factory-subscriptions-in-manifest.md @@ -1,127 +1,56 @@ --- -status: proposed +status: deferred +deferred-to: 0.3 --- -# Dynamic address registration for log subscriptions +# Dynamic address registration for log subscriptions (deferred to 0.3) + +## Status + +**Deferred to 0.3.** Neither TWAP nor EthFlow (the M2 grant deliverables) needs this capability, and the design's complexity is not justified by current need. + +This ADR is preserved as a reference for the design space; the final shape will be revisited when the first module actually requiring dynamic address registration emerges. ## Context -Some module archetypes need to track contracts deployed dynamically by a factory, for example Uniswap V3 pools (deployed by `UniswapV3Factory`). Static `[[subscription]]` declarations in `nexum.toml` cannot express this: the child addresses are not known when the module's manifest is authored. - -Neither TWAP nor EthFlow (the M2 grant deliverables) needs this. Both subscribe to a single well-known contract per chain. This ADR is forward-looking, motivated by `docs/migration/0.1-to-0.2.md` §522 declaring 0.2 the breaking-change window; adding factory support after 0.2 would require another major version bump. - -Envio HyperIndex uses a hybrid pattern that fits Shepherd's design: topics are declared statically in the manifest, and the watched address set is mutated at runtime via a `register()` host call. The engine maintains a single aggregated log subscription per template; the address set grows as the module learns of new contracts. - -Whether the engine should also handle historical backfill on register (the module passes `from-block`, engine paginates `eth_getLogs` from there to head before going live) is a separate decision flagged for upstream review. This ADR keeps the engine surface minimal and defers historical replay to the existing module-driven catch-up pattern documented in `docs/02:260`. - -## Decision - -Two pieces: - -**1. Manifest schema gains `[[subscription.template]]`**, a topic-only log subscription whose address set is populated at runtime: - -```toml -[[subscription.template]] -chain_id = 1 -name = "uniswap_v3_pool" -event_topics = [ - "0xc42079f94a6350d7e6235f29174924f928cc2ac818eb64fed8004e115fbcca67", # Swap - "0x7a53080ba414158be7ec69b987b5fb7d07dee101fe85488f0853ae16239d0bde", # Mint -] -``` - -Existing `[[subscription]]` blocks with concrete `address` are unchanged. A module typically declares one static `[[subscription]]` for the factory event itself, plus one `[[subscription.template]]` per child contract type. - -**2. `nexum:host/chain` gains two host functions** for the module to manage the address set: - -```wit -interface chain { - // existing request, request-batch, subscribe-blocks, subscribe-logs ... - - /// Add an address to the watch set for `template-name` on `chain-id`. - /// Idempotent: calling twice with the same arguments is a no-op. - register-address: func( - chain-id: chain-id, - template-name: string, - address: list, // 20 bytes - ) -> result<_, host-error>; - - /// Remove an address from the watch set. Subsequent events on that - /// address are dropped. Idempotent. - unregister-address: func( - chain-id: chain-id, - template-name: string, - address: list, - ) -> result<_, host-error>; -} -``` - -**3. `log-source` variant in `nexum:host/event-module`** gains a `template` case so modules can route events: - -```wit -variant log-source { - static(u32), // existing: index into [[subscription]] - template(string), // new: name of the [[subscription.template]] -} -``` - -Module code (Rust, Uniswap V3 indexer): - -```rust -fn init(config: Vec<(String, String)>) -> Result<(), HostError> { - // Resume: re-register every pool we already discovered. - for key in local_store::list_keys("pool:")? { - let pool = parse_addr(&key); - chain::register_address(1, "uniswap_v3_pool", &pool)?; - } - Ok(()) -} - -fn on_event(event: Event) -> Result<(), HostError> { - match event { - // Factory event, declared as a static [[subscription]] for the factory. - Event::Log(LogEvent { log, source: LogSource::Static(0) }) => { - let pool = decode_pool_created(&log)?; - chain::register_address(1, "uniswap_v3_pool", &pool)?; - local_store::set(&format!("pool:{}", hex(&pool)), b"")?; - } - // Pool event, dispatched through the template. - Event::Log(LogEvent { log, source: LogSource::Template(name) }) - if name == "uniswap_v3_pool" => - { - process_pool_event(log)?; - } - _ => {} - } - Ok(()) -} -``` - -Engine internals: - -- **Boot**: read all `[[subscription.template]]` blocks. Initialise per-template address sets from the reserved key `__nexum:template:{name}:addresses` in the module's `local-store` namespace if present from a prior run. -- **Live**: one `eth_subscribe logs` per chain per template with filter `(topic in event_topics) AND (address in current_set)`. When `register-address` mutates the set, the engine re-subscribes. -- **Persistence**: engine writes `__nexum:template:{name}:addresses` whenever the set changes. Resume after restart is automatic if the module re-calls `register-address` in `init`. - -Historical backfill is the module's responsibility, consistent with the catch-up pattern documented in `docs/02:260`. The module calls `chain.request("eth_getLogs", ...)` during `init` to replay history before going live. The engine does not backfill on `register-address`. - -## Considered options - -- **Ponder full-declarative** (factory address, event, parameter declared in manifest; engine extracts child). Rejected: schema must express ABI-aware extraction (`child = { source = "topic", index = 1 }` or similar), and grows with every exotic factory shape (nested factories, multi-child events, address computed from multiple fields). The Envio model pushes that complexity into module Rust code, where it belongs given the module already decodes events with `alloy_sol_types`. -- **Pure imperative `chain.open-log-stream(filter) -> stream-handle`.** Rejected: each call opens a new subscription, so N pools means N WSS connections. Doesn't scale to indexers with 10k+ tracked addresses. The Envio model keeps one subscription per template and mutates its address set; engine batches naturally. -- **Engine-driven historical backfill on register** (with `from-block` parameter). Rejected after PR review flagged the added complexity. Module-driven catch-up via `init` + `eth_getLogs` already exists in mfw's design (`docs/02:260`) and covers the same use case without adding engine state (per-address cursor, paginated `eth_getLogs` orchestration). M3 SDK can ship a helper that wraps the pattern. -- **Wildcard manifest** (`address = "*"` with topic-only filter, module client-side filters). Rejected: mainnet has ~10k contracts emitting `Transfer` or `Swap` per day. The engine would deliver every matching event to every wildcard subscriber; modules pay fuel and bandwidth to discard 99% of them. -- **Defer factory pattern entirely to 0.3.** Rejected: 0.2 is the breaking-change window per migration:522. Adding either `[[subscription.template]]` or `register-address` after 0.2 requires another major bump. -- **Templates declared inside `[[subscription]]` with optional `address` (one block, two modes).** Rejected: conflates two semantically distinct cases. Modules looking at `[[subscription]]` would have to inspect for the presence of `address` to know whether they need to call `register-address`. Separate block name is clearer. - -## Consequences - -- `nexum.toml` schema gains `[[subscription.template]]` with `chain_id`, `name`, `event_topics`. Schema extension needs upstream approval. -- `nexum:host/chain` gains `register-address` and `unregister-address`; `nexum:host/event-module`'s `log-source` variant gains `template(string)`. WIT change needs upstream approval. -- Reserved key namespace `__nexum:template:*` in each module's `local-store` namespace. Modules MUST NOT write to keys with this prefix. -- Module boilerplate per factory is roughly 5 lines (decode the factory event, call `register-address`, persist for resume). The M3 SDK can ship a helper that wraps it. -- Register sources are not limited to factory events. A module can register addresses from any signal: HTTP API responses, governance votes, operator-supplied lists. Composability is a deliberate feature. -- Nested factories (a child contract that is itself a factory) work without schema changes. The child's event handler calls `register-address` on the grandchild template. -- Conditional registration ("only register pools with fee = 3000") works without schema changes. The module's factory-event handler decides. -- The address set per template is bounded only by `local-store` quota. The engine enforces a soft cap (default 50k addresses per template) configurable in `engine.toml`; exceeding the cap returns `host-error.denied` from `register-address`. -- Open follow-up: whether to support `from-block` historical backfill on register is left for upstream discussion. The minimal surface here can be extended additively if needed. +Some module archetypes need to track contracts deployed dynamically by a factory, for example Uniswap V3 pools (deployed by `UniswapV3Factory`). Static `[[subscription]]` declarations in `module.toml` cannot express this: the child addresses are not known when the module's manifest is authored. + +Neither TWAP nor EthFlow needs this; both subscribe to a single well-known contract per chain. This ADR was originally framed as forward-looking work to land in 0.2's breaking-change window. + +## Why deferred + +Two considerations motivate the deferral: + +1. **`eth_getLogs` already supports topic-only filtering.** The JSON-RPC method accepts a filter without an `address` field, so a module subscribing to a topic across all addresses can be served by the existing primitives if the operator's RPC endpoint cooperates. If topic-only filters at the JSON-RPC layer are good enough for the common case, the engine does not need a manifest-and-host-function mechanism on top. +2. **The schema and host-function surface add engine complexity that no M2 deliverable consumes.** The historical-backfill story is the largest contributor to that complexity and was already trimmed once; deferring the rest in the same spirit avoids paying for a mechanism nothing exercises yet. + +Combined: the dynamic-subscription design is not load-bearing for M2 deliverables, and the simplest path (topic-only `eth_subscribe` filters with module-side address filtering) may suffice for a wide range of indexer use cases. The dynamic-registration mechanism originally proposed (Envio-style `register-address`) addresses scaling concerns at high address counts but should land when a real consumer is on the table to validate the trade-off. + +## Reference design (not adopted in 0.2) + +The original proposal — kept here so future discussions have a starting point — was a hybrid of static topics and dynamic addresses: + +- `[[subscription.template]]` block in `module.toml` declaring `chain_id`, `name`, `event_topics` (no address). +- `chain.register-address(chain_id, template_name, address)` host function for the module to add addresses at runtime. +- `chain.unregister-address(chain_id, template_name, address)` mirror function. +- `log-source.template(string)` variant on the event dispatch so modules route by template name. +- Engine maintains a single aggregated `eth_subscribe logs` per chain per template, with filter `(topic ∈ event_topics) ∧ (address ∈ current_set)`. The address set is mutated as the module discovers new contracts. +- Historical backfill (`from-block` argument on register, paginated `eth_getLogs` orchestration) was contentious and was already trimmed before deferral. + +Envio HyperIndex's `context..register()` API is the closest existing pattern, validated in production for indexers tracking thousands of dynamically-discovered contracts. + +## Alternatives left open for 0.3 + +- **Topic-only `[[subscription]]`** (no address field; engine forwards `eth_subscribe logs` with topic-only filter; module client-side filters logs by address it cares about). Simplest, no new host functions. Trade-off: firehose volume for common topics like `Transfer`. +- **Dynamic register-address** (the original reference design above). +- **Engine-extracted factory child addresses** (Ponder-style declarative schema with ABI-aware extraction rules). Schema complexity grows with exotic factory shapes. +- **No factory pattern; modules wanting dynamic discovery use raw `chain.subscribe-logs` with topic-only filter and persist the discovered address set themselves**. + +The choice depends on what the first consumer actually needs. + +## Consequences of deferring + +- The `shepherd:cow` and `nexum:host` WIT surfaces remain unchanged in 0.2. +- `module.toml` schema does not gain `[[subscription.template]]` in 0.2. +- 0.2 is the breaking-change window; adding any of the above options in 0.3 may require a major version bump if the chosen shape extends `module.toml` or `nexum:host/chain` non-additively. This risk is accepted on the basis that the M2 grant deliverables do not require this surface. +- TWAP and EthFlow modules ship in 0.2 against the existing static `[[subscription]]` declarations (one address per subscription, known at manifest authorship time). This is consistent with how the autopilot ethflow indexer and watch-tower configure their subscriptions today. diff --git a/docs/diagrams/README.md b/docs/diagrams/README.md new file mode 100644 index 0000000..c9c509e --- /dev/null +++ b/docs/diagrams/README.md @@ -0,0 +1,31 @@ +# Diagrams + +Mermaid sources and rendered PNGs covering the engine architecture, the CoW workflows that the M2 modules implement (TWAP and EthFlow, both as guest modules using low-level host primitives), and the engine internals that new contributors most often need to reason about. + +## Architecture and CoW flows + +| File | Type | Shows | +|---|---|---| +| `architecture.png` / `.mmd` | Component | Static view: external infra, nexum-engine internals, WASM modules (twap-monitor, ethflow-watcher) consuming low-level host primitives, and the `cowprotocol` crate (consumed via `[patch.crates-io]` and the wasm32 feature). The `shepherd:cow` package contains only `cow-api`; no specialised TWAP or EthFlow interfaces. | +| `sequence-ethflow.png` / `.mmd` | Sequence | `OrderPlacement` on-chain event handled entirely in the `ethflow-watcher` guest module: `alloy_sol_types` decodes the event, the module builds an `OrderCreation` with the EIP-1271 signing scheme using `cowprotocol` types, and submits via `cow-api/submit-order`. The orderbook error path runs through `OrderPostError::try_from(host-error).retry_hint()`. | +| `sequence-twap.png` / `.mmd` | Sequence | `ConditionalOrderCreated` registration plus the per-block polling loop driven by the `twap-monitor` guest module: `alloy_sol_types` decodes registrations and `eth_call` returns, the module makes the `getTradeableOrderWithSignature` call via `chain.request`, builds `OrderCreation` via `cowprotocol` types, and submits via `cow-api/submit-order`. Orderbook errors flow through `OrderPostError::retry_hint`. | + +## Engine internals (for contributors) + +| File | Type | Shows | +|---|---|---| +| `module-lifecycle.png` / `.mmd` | State machine | Resolve → Load → Init → Run → Restart → Dead transitions and what triggers each. Documents the exponential-backoff restart policy and the implicit write transaction around `init`. | +| `engine-boot.png` / `.mmd` | Sequence | Boot order: engine.toml → tracing → ProviderPool → LocalStore → OrderBookPool → Supervisor (load each module) → open subscriptions → run event loop. | +| `wit-call-path.png` / `.mmd` | Sequence | One host call traced end-to-end: module Rust source → wit-bindgen stubs → WASM Component → wasmtime Linker → HostState trait impl → ProviderPool → alloy → Chain RPC, and back. Demystifies the WASM/Rust boundary. | +| `subscription-dispatch.png` / `.mmd` | Flow chart | How the supervisor aggregates `[[subscription]]` declarations across modules, opens shared block subscriptions (broadcast) and per-filter log subscriptions (routed), and dispatches events to the right `on_event` handlers. | + +## Regenerate + +```sh +cd docs/diagrams +for f in *.mmd; do + npx -y @mermaid-js/mermaid-cli@latest -i "$f" -o "${f%.mmd}.png" -b white --width 1800 +done +``` + +Mermaid sources are the source of truth; PNGs are committed for offline viewing and PR previews. diff --git a/docs/diagrams/architecture.mmd b/docs/diagrams/architecture.mmd new file mode 100644 index 0000000..f5b97f2 --- /dev/null +++ b/docs/diagrams/architecture.mmd @@ -0,0 +1,69 @@ +graph TB + subgraph external["External Infrastructure"] + OB["CoW Orderbook
api.cow.fi"] + RPC["Chain RPC
ws:// or https://"] + CC["ComposableCoW
(Solidity contract)"] + EF["CoWSwapEthFlow
(Solidity contract)"] + end + + subgraph engine["nexum-engine binary"] + ETOML["engine.toml
(operator config)"] + SUP["Supervisor
(boot + dispatch)"] + EL["Event Loop
futures::select_all"] + + subgraph host["HostState (per module)"] + HW["Host Backends
cow-api, chain,
local-store, logging, ..."] + CP["OrderBookPool
(BTreeMap of OrderBookApi)"] + PP["ProviderPool
(alloy DynProvider per chain)"] + LS["LocalStore
(redb, 32-byte hash prefix per module)"] + end + end + + subgraph modules["WASM Modules (Component Model)"] + MTOML["module.toml
(module manifest)"] + TM["twap-monitor
(decodes events, polls,
builds OrderCreation,
submits via cow-api)"] + EM["ethflow-watcher
(decodes OrderPlacement,
builds OrderCreation,
submits via cow-api)"] + end + + subgraph cowrs["cowprotocol crate (via [patch.crates-io] to PR #5)"] + OBA["OrderBookApi
(orderbook submission)"] + TYPES["Protocol types
(Order, OrderCreation,
OrderUid, signing schemes)"] + OPE["OrderPostError
+ retry_hint -> RetryHint"] + end + + ETOML --> SUP + MTOML -.declares.-> SUP + SUP --> EL + SUP -.loads via wasmtime.-> TM + SUP -.loads via wasmtime.-> EM + + EL -- "on_event(block | log)" --> TM + EL -- "on_event(block | log)" --> EM + + TM -- "WIT host call" --> HW + EM -- "WIT host call" --> HW + + TM -- "consumes types
(wasm32 feature)" --> TYPES + EM -- "consumes types
(wasm32 feature)" --> TYPES + TM -- "matches on" --> OPE + EM -- "matches on" --> OPE + + HW --> CP + HW --> PP + HW --> LS + + CP --> OBA + PP --> RPC + OBA --> OB + CC -. "ConditionalOrderCreated" .-> RPC + EF -. "OrderPlacement / OrderInvalidation" .-> RPC + + classDef external fill:#f0e6ff,stroke:#7e3ff2,color:#000 + classDef engineNode fill:#e6f3ff,stroke:#1e88e5,color:#000 + classDef moduleNode fill:#fff4e6,stroke:#ff9800,color:#000 + classDef cowrsNode fill:#e6ffe6,stroke:#2e7d32,color:#000 + + class OB,RPC,CC,EF external + class ETOML,SUP,EL,HW,CP,PP,LS engineNode + class MTOML,TM,EM moduleNode + class OBA,TYPES,OPE cowrsNode diff --git a/docs/diagrams/diagrams.md b/docs/diagrams/diagrams.md new file mode 100644 index 0000000..762e6db --- /dev/null +++ b/docs/diagrams/diagrams.md @@ -0,0 +1,472 @@ +# Shepherd — Architecture Diagrams + +Visual reference for the Shepherd engine, its interactions with Nexum, CoW Protocol, and the WASM module layer. Derived from ADRs 0001–0008 and the internal architecture document. + +> **Scope note** — diagrams 1–4 and 7–8 reflect the **M1 implemented state** plus the **M2 target design** as described by the ADRs. Diagrams 5–6 (TWAP, EthFlow) describe **guest-module-driven flows**: the modules do all the protocol work themselves using low-level host primitives, with no specialised `twap` or `ethflow` host interfaces. Where the current code differs from the target design, a note is included in the relevant block reference. + +--- + +## 1. System Architecture Overview + +High-level component map: what lives where, how repositories depend on each other. + +```mermaid +graph TD + ET["engine.toml · module.toml\n(operator config + module manifest)"] + SUP["Supervisor::boot"] + POOLS["ProviderPool · OrderBookPool · LocalStore"] + HS["HostState (per module)\nnexum:host@0.2.0 + shepherd:cow@0.2.0"] + EL["EventLoop — futures::stream::select_all\nfan-out block/log streams to subscribers"] + MODS["WASM Modules\ntwap.wasm · eth-flow.wasm\n(self-contained protocol logic in guest)"] + BC["Blockchain (Sepolia / Mainnet / …)\nComposableCoW · CowEthFlow · RPC Node"] + CR["bleu/cow-rs ← [patch.crates-io]\nOrder · OrderCreation · OrderUid · signing schemes\nOrderBookApi · OrderPostError + retry_hint\nOrderBookApi::with_base_url · wasm32 feature"] + OB["api.cow.fi (Orderbook REST)"] + + ET --> SUP + SUP --> POOLS + POOLS --> HS + HS --> EL + BC -->|"block/log events (eth_subscribe)"| EL + EL -->|"on_event(block/log)"| MODS + MODS -->|"WIT calls (chain · local-store · cow-api · …)"| HS + MODS -.->|"consumes types (wasm32 feature)"| CR + HS -->|"eth_call / subscribe"| BC + HS -->|"OrderBookApi.post_order"| OB + HS -->|"cow-api passthrough"| OB +``` + +### Block reference + +| Block | What it is | +|---|---| +| **engine.toml** | Written by the operator. Declares which chains to connect to (RPC URLs), where to store state on disk, and which WASM modules to load at boot. | +| **module.toml** | Written by the module developer and shipped inside the module bundle. Declares which capabilities the module needs (`required`), which on-chain events to subscribe to, and any module-specific config keys. Renamed from `nexum.toml` per ADR-0001 so the operator/module split is directly apparent. | +| **Supervisor::boot** | The boot orchestrator. Reads both config files, creates the shared resource pools, loads each `.wasm` component via wasmtime, and wires their subscriptions into the event streams. | +| **ProviderPool · OrderBookPool · LocalStore** | The three shared backends. `ProviderPool` holds one alloy RPC client per chain. `OrderBookPool` holds one CoW orderbook HTTP client per chain. `LocalStore` is a single redb key-value database shared by all modules (with per-module 32-byte hash namespacing — ADR-0003). | +| **HostState (per module)** | The per-module bridge between WASM guest code and Rust host code. When a module calls a WIT function (`local-store/set`, `cow-api/submit-order`, etc.), wasmtime routes that call to the corresponding method on that module's `HostState`. Checks capability permissions before dispatching. | +| **EventLoop** | The main async loop. Runs all block-header and log-event streams concurrently via `futures::stream::select_all`. When a stream fires, it routes the event to every module that subscribed to it in their `module.toml`. | +| **WASM Modules** | The guest programs. Each module exports `init(config)` (called once at boot) and `on_event(event)` (called on every relevant block or log). They contain the protocol logic themselves: TWAP polling, EthFlow event decoding, OrderCreation construction. They call back into the host through universal WIT interfaces only — no CoW-specific helper interfaces (ADR-0006). | +| **Blockchain** | The EVM chain being watched. Delivers new block headers and contract log events over a persistent WebSocket (`eth_subscribe`). Also handles `eth_call` for on-chain reads (e.g. checking whether a TWAP order is ready). | +| **bleu/cow-rs [patch.crates-io]** | The Rust crate containing CoW Protocol **primitives**: order types, signing schemes, the orderbook HTTP client, and the typed orderbook error model (`OrderPostError` + `retry_hint`). Pulled via `[patch.crates-io]` pointing at the head of upstream PR #5. Modules consume the types directly via the `wasm32` feature; the engine consumes the orderbook client via its `cow-api` host backend. No TWAP or EthFlow strategy logic lives here — that stays in module code (ADR-0007). | +| **api.cow.fi (Orderbook REST)** | The CoW Protocol orderbook service. Accepts `POST /orders` to register new orders. Trader-uploaded app-data documents are PUT to `/app_data/{hash}` separately by whoever signed the order (not by the relayer module). | + +--- + +## 2. Domain / Class Diagram + +Key types, their fields, and relationships across the engine codebase. + +```mermaid +classDiagram + class EngineConfig { + +state_dir: PathBuf + +chains: BTreeMap~u64, ChainConfig~ + +modules: Vec~ModuleEntry~ + } + class Manifest { + +name: String + +capabilities_required: Vec~String~ + +subscriptions: Vec~Subscription~ + } + class Subscription { + +kind: Block | Log + +chain_id: u64 + +address: Option~Address~ + +topics: Vec~B256~ + } + class Supervisor { + +dispatch_block(chain_id, block) + +dispatch_log(owner, log) + } + class ProviderPool { + +providers: BTreeMap~u64, DynProvider~ + } + class OrderBookPool { + +clients: BTreeMap~u64, OrderBookApi~ + } + class LocalStore { + +db: redb~Database~ + +get(key: String) Option~Vec~u8~~ + +set(key: String, value: Vec~u8~) + +delete(key: String) + +list_keys(prefix: String) Vec~String~ + } + class HostState { + +wasi: WasiCtx + +table: ResourceTable + +http_allowlist: Vec~String~ + +monotonic_baseline: Instant + %% M2 additions (ADR-0005): + %% +module_namespace: [u8; 32] (ENS namehash or keccak256) + %% +provider_pool: Arc~ProviderPool~ + %% +ob_pool: Arc~OrderBookPool~ + %% +local_store: Arc~LocalStore~ + } + class EventLoop { + +streams: SelectAll~Pin~Box~dyn Stream~~~ + } + class TwapModule { + <> + +on_event(log) persist watch via local-store + +on_event(block) poll each watch via chain.request(eth_call) + +decode return via alloy_sol_types + +build OrderCreation via cowprotocol types + +submit via cow-api.submit-order + +interpret errors via OrderPostError.retry_hint + } + class EthFlowModule { + <> + +on_event(log) decode OrderPlacement via alloy_sol_types + +build OrderCreation (EIP-1271 sig) via cowprotocol types + +submit via cow-api.submit-order + +interpret errors via OrderPostError.retry_hint + } + + EngineConfig --> Supervisor + Manifest --> Supervisor + Manifest "1" --> "*" Subscription + Supervisor --> ProviderPool + Supervisor --> OrderBookPool + Supervisor --> LocalStore + Supervisor "1" --> "*" HostState : per module + HostState --> ProviderPool + HostState --> OrderBookPool + HostState --> LocalStore + EventLoop --> Supervisor + TwapModule ..> HostState : WIT calls (universal) + EthFlowModule ..> HostState : WIT calls (universal) +``` + +### Class reference + +| Class | What it is | +|---|---| +| **EngineConfig** | Deserialized from `engine.toml`. Holds the database path (`state_dir`), one `ChainConfig` per chain (just an RPC URL), and the list of module paths to load. | +| **Manifest** | Deserialized from `module.toml`, which ships inside the module bundle. Declares what capabilities the module needs, which on-chain events to watch, and any module-level config values. | +| **Subscription** | One event declaration inside `module.toml`. `kind=Block` fires on every new block for a given chain. `kind=Log` fires when a specific contract emits an event matching the given address and topics. Factory-style dynamic subscriptions (`[[subscription.template]]` + `register-address`) are deferred to 0.3 — see ADR-0008. | +| **Supervisor** | Orchestrates boot and event dispatch. Creates one `HostState` per module. On each incoming block or log, calls `dispatch_block` / `dispatch_log` to fan the event out to subscribed modules. | +| **ProviderPool** | Holds one alloy `DynProvider` per chain. `wss://` chains get a pubsub provider that supports both subscriptions and requests. `https://` chains get HTTP-only (subscriptions unavailable, by design — ADR-0002). | +| **OrderBookPool** | Holds one `OrderBookApi` client per known CoW chain (Mainnet, Gnosis, Sepolia, ArbitrumOne, Base). Instantiated via `OrderBookPool::default()` at boot (ADR-0005). | +| **LocalStore** | A single redb embedded database at `state_dir`. All modules write into the same file. Keys are prefixed host-side as `[32-byte module namespace][raw_key]` so two modules never collide, and the namespace is unspoofable (ADR-0003). The namespace is `keccak256(module_name)` for locally-loaded modules and `ens_namehash(name)` for ENS-discovered modules. | +| **HostState** | The per-module runtime context. `wasmtime::component::bindgen!` generates one trait per WIT interface (e.g. `shepherd::cow::cow_api::Host`); `HostState` implements each trait. `Shepherd::add_to_linker` registers all trait implementations with the `Linker` once at boot. **Current fields** (M1): `wasi: WasiCtx`, `table: ResourceTable`, `http_allowlist: Vec`, `monotonic_baseline: Instant`. **M2 additions** will add `module_namespace: [u8; 32]`, `provider_pool: Arc`, `ob_pool: Arc`, `local_store: Arc`. | +| **EventLoop** | Runs `futures::stream::select_all` over a `Vec + Send>>>`. The loop never exits until SIGINT/SIGTERM. Each fired event is forwarded to `Supervisor` for fan-out. | +| **TwapModule** | The TWAP watcher WASM component. On a `Log` event (ConditionalOrderCreated): persists the registration in `local-store`. On a `Block` event: iterates all watches and, for each, makes an `eth_call` via `chain.request`, decodes the result via `alloy_sol_types` (in-module), builds an `OrderCreation` via `cowprotocol` types (consumed via wasm32 feature), and submits via `cow-api.submit-order`. Orderbook errors flow through `OrderPostError::retry_hint`. All polling logic lives in the module, not the host (ADR-0006). | +| **EthFlowModule** | The EthFlow watcher WASM component. On a `Log` event (OrderPlacement): decodes the event via `alloy_sol_types` in-module, builds the `OrderCreation` with the EIP-1271 signing scheme via `cowprotocol` types, and submits via `cow-api.submit-order`. No polling loop — one log equals one submission attempt. | + +--- + +## 3. WIT Interface Hierarchy + +Two WIT packages: the universal `nexum:host` and the CoW-specific `shepherd:cow`. + +```mermaid +graph TD + NH["nexum:host@0.2.0\n(universal — no CoW knowledge)"] + SC["shepherd:cow@0.2.0\n(CoW Protocol extensions)"] + + NH --> n1["chain ✅ implemented\nrequest(chain-id, method, params)\nrequest-batch(chain-id, requests)\n—\nsubscribe-blocks · subscribe-logs →\n engine-managed via module.toml subscriptions\nregister-address · unregister-address →\n 🕓 deferred to 0.3 (ADR-0008)"] + NH --> n2["local-store ✅ implemented\nget(key) · set(key, value)\ndelete(key) · list-keys(prefix)\nnamespacing: 32-byte hash prefix (ADR-0003)"] + NH --> n3["identity · messaging · http · remote-store\n✅ stubs (Unsupported) — full impl in 0.3"] + NH --> n4["logging · clock · random ✅ implemented"] + + SC -->|"use nexum:host/types"| NH + SC --> s1["cow-api ✅ implemented\nrequest(chain-id, method, path, body)\nsubmit-order(chain-id, order-data)\n→ result\n(only protocol-level interface in shepherd:cow)"] + + note1["No twap / ethflow host interfaces.\nTWAP and EthFlow logic lives in guest\nmodule code, using universal primitives\n(chain · local-store · cow-api).\nSee ADR-0006."] + SC -.-> note1 + + style note1 fill:#fff4e6,stroke:#ff9800,color:#000 +``` + +### Interface reference + +| Interface | What it does | +|---|---| +| **nexum:host@0.2.0** | The base WIT package. Any module running in the engine — CoW-aware or not — imports from here. Defines shared types (`chain-id`, `log`, `host-error`) used by both packages. | +| **chain** | Reads from the blockchain via JSON-RPC. `request` sends a single call; `request-batch` sends several in one round-trip. **Subscriptions are not callable WIT functions** — they are declared in `module.toml` and opened by the engine at boot. Dynamic `register-address` for factory patterns is deferred to 0.3 (ADR-0008). | +| **local-store** | Persistent key-value storage that survives restarts. Operations: `get(key)`, `set(key, value)`, `delete(key)`, `list-keys(prefix)`. The host prefixes every key with a 32-byte deterministic namespace (`keccak256(module_name)` locally, or `ens_namehash(name)` when ENS-loaded) so modules are fully isolated and the namespace cannot be spoofed (ADR-0003). | +| **identity · messaging · http · remote-store** | Capabilities stubbed at 0.2 — they return `Unsupported`. `identity` will provide keystore-backed signing. `messaging` will send Waku messages. `http` will allow direct outbound HTTP calls (subject to the manifest's allowlist). `remote-store` will read/write Swarm/IPFS. | +| **logging · clock · random** | Lightweight utilities. `logging` emits to the engine's `tracing` subscriber (inherits `RUST_LOG` filters). `clock` returns wall-clock time. `random` returns cryptographically-secure random bytes. | +| **shepherd:cow@0.2.0** | The CoW Protocol extension package. Imports `nexum:host/types` for shared types so modules don't re-define `chain-id` or `log`. Only CoW-aware modules need to import this package. Contains exactly **one** interface in 0.2: `cow-api`. | +| **cow-api** | Generic orderbook access. `request` is a raw REST passthrough (returns JSON string). `submit-order` takes raw order bytes and returns a `result` where the string is the order UID. Routes through the engine's `OrderBookPool`. This is the only protocol-level CoW interface in 0.2 — the boundary between "what CoW Protocol *is*" (orderbook submission, order types) and "what's implemented *on top* of CoW" (TWAP polling, EthFlow event handling). | +| **(no twap interface)** | Per ADR-0006, no specialised TWAP host interface exists. The TWAP module implements polling, decoding, and submission entirely in guest code, using `chain.request` for `eth_call`, `local-store` for state, `alloy_sol_types` (in-module) for ABI decoding, `cowprotocol` types for `OrderCreation`, and `cow-api.submit-order` for orderbook submission. Multiple TWAP strategies can coexist as separate modules with different polling policies and error tolerances. | +| **(no ethflow interface)** | Per ADR-0006, no specialised EthFlow host interface exists. The EthFlow module decodes `OrderPlacement` directly in guest code via `alloy_sol_types`, constructs the `OrderCreation` with the EIP-1271 signing scheme via `cowprotocol` types, and submits via `cow-api`. | + +--- + +## 4. Engine Boot Sequence + +```mermaid +flowchart TD + Start([nexum-engine starts]) --> ReadConfig + ReadConfig["1. Read engine.toml\n(EngineConfig::load)"] + ReadConfig --> InitTracing + InitTracing["2. Init tracing\n(RUST_LOG / log_level)"] + InitTracing --> ProvPool + ProvPool["3. ProviderPool::from_config\nFor each chain:\n wss:// → pubsub DynProvider\n https:// → http DynProvider\n(fatal on connection error — ADR-0002)"] + ProvPool --> OpenStore + OpenStore["4. LocalStore::open(state_dir)\nOpen/create redb DB\nnexum:local-store table\n(ADR-0003)"] + OpenStore --> OBPoolInit + OBPoolInit["5. OrderBookPool::default()\nBuild OrderBookApi for:\nMainnet, Gnosis, Sepolia, ArbitrumOne, Base\n(ADR-0005)"] + OBPoolInit --> SupervisorBoot + SupervisorBoot["6. Supervisor::boot\nFor each [[modules]] in engine.toml:"] + SupervisorBoot --> LoadManifest[" a. Load module.toml (Manifest)"] + LoadManifest --> LoadWasm[" b. Load .wasm Component (wasmtime)"] + LoadWasm --> Instantiate[" c. Instantiate with dedicated HostState\n (links nexum:host + shepherd:cow impls)"] + Instantiate --> CallInit[" d. Call module.init(config)"] + CallInit --> AnnotateSubs[" e. Annotate subscriptions from manifest"] + AnnotateSubs --> MoreModules{More modules?} + MoreModules -->|yes| LoadManifest + MoreModules -->|no| OpenStreams + OpenStreams["7. open_block_streams + open_log_streams\neth_subscribe newHeads per chain\neth_subscribe logs per (chain, address, topics)"] + OpenStreams --> RunLoop + RunLoop["8. run_event_loop\nfutures::stream::select_all over all streams\nfan-out: block → all block subscribers\nlog → owner module only"] + RunLoop --> Wait([Await SIGINT/SIGTERM]) +``` + +### Step reference + +| Step | What happens | +|---|---| +| **1. Read engine.toml** | Deserializes the operator config. If the file is missing, the engine falls back to defaults (no chains, default `state_dir`). Modules that need chains will receive `Unsupported` errors at runtime. | +| **2. Init tracing** | Sets up the `tracing` subscriber using `RUST_LOG` or the `log_level` field from `engine.toml`. All host log output flows through here, including per-capability trace events. | +| **3. ProviderPool** | Opens one alloy connection per chain declared in `[chains]`. WebSocket URLs get a full pubsub provider (the recommended setup for any chain a module subscribes to). HTTP URLs get a request-only provider. Any connection failure at this step is fatal — the engine refuses to start with a broken chain rather than silently degrading. Failover and retry are out of scope; they live in alloy middleware (ADR-0002). | +| **4. LocalStore** | Opens (or creates) the redb database at `state_dir`. Creates the `nexum:local-store` table if it doesn't exist. Per-module namespacing uses a 32-byte deterministic hash prefix. Module state from previous runs is immediately available. | +| **5. OrderBookPool** | Constructs one `OrderBookApi` HTTP client for each supported CoW chain via the `Default` implementation. Built upfront so config errors (unknown chain IDs) surface at boot, not on the first order submission. | +| **6. Supervisor::boot (per module)** | For each module listed in `engine.toml`: reads its `module.toml`, loads the `.wasm` component into wasmtime, creates a dedicated `HostState`, calls the module's `init(config)` export, and records which subscriptions the module declared. | +| **7. Open streams** | Aggregates all subscriptions declared across all modules. Opens one `eth_subscribe newHeads` per chain and one `eth_subscribe logs` per (chain, contract-address, topics) filter. | +| **8. Event loop** | The engine enters its steady-state loop. `futures::stream::select_all` waits for the next event on any stream. Block events are broadcast to all modules subscribed to that chain. Log events are delivered only to the module that owns that subscription. | + +--- + +## 5. TWAP Complete Flow (Registration → Submit) + +The TWAP module runs the entire flow in guest Rust code, using only universal host primitives. + +```mermaid +sequenceDiagram + actor User + participant CC as ComposableCoW
Contract + participant RPC as RPC Node
(wss://) + participant EL as EventLoop + participant TM as twap module
(WASM guest) + participant SD as alloy_sol_types
(in module) + participant CR as cowprotocol types
(in module, wasm32) + participant HS as HostState
(Rust) + participant OB as api.cow.fi
(Orderbook) + participant LS as LocalStore
(redb) + + Note over User,CC: Step 0 — On-chain registration (off-engine) + User->>CC: ComposableCoW.create(twapParams) + CC-->>RPC: emit ConditionalOrderCreated(owner, params, proof) + + Note over RPC,LS: Step 1 — Indexing (once per TWAP) + RPC->>EL: log batch (eth_subscribe logs) + EL->>TM: on_event(Event::Logs([registration_log])) + TM->>SD: decode ConditionalOrderCreated + SD-->>TM: (owner, params, salt) + TM->>HS: local-store.set("watch:{owner}:{hash}", params) + HS->>LS: write [module_namespace][watch:...] = params_bytes + + Note over RPC,LS: Step 2 — Poll loop (every block) + loop Every block on chain_id + RPC->>EL: block header (eth_subscribe newHeads) + EL->>TM: on_event(Event::Block(Block { number: N, ... })) + TM->>HS: local-store.list-keys("watch:") + HS-->>TM: registration entries + + loop For each watch where next_attempt <= N + TM->>HS: chain.request(chain_id, "eth_call", [...]) + HS->>RPC: eth_call ComposableCoW.getTradeableOrderWithSignature(owner, params, "", []) + RPC-->>HS: return value or revert + HS-->>TM: result (JSON string) + TM->>SD: decode return value (or interpret revert reason) + SD-->>TM: ready(GPv2OrderData, signature) OR not-ready(hint) + + alt Order ready + TM->>CR: build OrderCreation + CR-->>TM: OrderCreation + TM->>HS: cow-api.submit-order(chain_id, order_json) + HS->>OB: POST /api/v1/orders + alt Submit OK + OB-->>HS: 200 OK, OrderUid + HS-->>TM: Ok(OrderUid) + TM->>LS: set("submitted:{uid}", order_uid) + else Orderbook error + OB-->>HS: 4xx with error code + HS-->>TM: Err(host-error) + TM->>CR: OrderPostError::try_from(host-error).retry_hint() + CR-->>TM: TryNextBlock / BackoffSeconds(s) / Drop + TM->>LS: update next_attempt or remove watch + end + else Not yet ready (TryAtEpoch / TryOnBlock / TryNextBlock / Terminal) + TM->>LS: persist hint (next_attempt) or delete watch + end + end + end +``` + +### Participant reference + +| Participant | Role in this flow | +|---|---| +| **User** | The trader. Interacts with the blockchain directly — the engine never touches private keys. | +| **ComposableCoW Contract** | The on-chain conditional order registry. Accepts TWAP parameters via `create()` and emits `ConditionalOrderCreated`. Also exposes `getTradeableOrderWithSignature()`, which the engine polls to check whether the current TWAP part is ready to trade. | +| **RPC Node** | The WebSocket connection to the chain. Delivers log events (subscriptions) and handles `eth_call` (synchronous reads). Must be `wss://` for this flow since it uses subscriptions. | +| **EventLoop** | Receives raw events from the RPC node and routes them to the module that subscribed to them. Opaque to the flow — it just calls `on_event`. | +| **twap module (WASM guest)** | Contains the entire TWAP strategy: decoding registrations, deciding when to poll (using stored hints), reacting to revert reasons, building orders, interpreting orderbook errors. Calls into the host only through universal WIT primitives. | +| **alloy_sol_types (in module)** | The ABI-aware decoder. Compiled into the module's WASM. Decodes `ConditionalOrderCreated` from raw log bytes; decodes the `getTradeableOrderWithSignature` return; interprets revert reasons. No host involvement for decoding. | +| **cowprotocol types (in module)** | The protocol-level types from `bleu/cow-rs`, consumed by the module via the wasm32 feature (ADR-0007 item 3). Used to build `OrderCreation`, manipulate `OrderUid`, and pattern-match `OrderPostError`. The crate's HTTP client (`OrderBookApi`) is **not** used directly by the module — orderbook submission goes through the host's `cow-api`. | +| **HostState (Rust)** | Provides only the universal primitives (`chain.request`, `local-store.*`, `cow-api.submit-order`). Knows nothing about TWAP semantics. | +| **api.cow.fi (Orderbook)** | Receives the signed `OrderCreation`, validates it, and returns a 56-byte `OrderUid`. The order is now visible to CoW solvers. | +| **LocalStore (redb)** | Persistent state for the TWAP module. `watch:{owner}:{hash}` entries hold registrations. `submitted:{uid}` entries record completed submissions. `next_attempt` hints (epoch or block) let the module skip polling during the gap between TWAP parts. All entries survive engine restarts. | + +--- + +## 6. EthFlow Complete Flow (Event-Driven) + +```mermaid +sequenceDiagram + actor User + participant EFC as CoWSwapEthFlow
Contract + participant RPC as RPC Node
(wss://) + participant EL as EventLoop + participant EM as eth-flow module
(WASM guest) + participant SD as alloy_sol_types
(in module) + participant CR as cowprotocol types
(in module, wasm32) + participant HS as HostState
(Rust) + participant OB as api.cow.fi
(Orderbook) + participant LS as LocalStore
(redb) + + Note over User,EFC: Step 0 — User creates ETH order on-chain + User->>EFC: createOrder(order, msg.value=ETH) + EFC->>EFC: store orders[hash] = onchainData,
emit OrderPlacement(sender, order, EIP1271-sig, data) + EFC-->>RPC: log emitted on block N + + Note over RPC,LS: Step 1 — Log arrives via subscription + RPC->>EL: log batch matching CoWSwapEthFlow address + OrderPlacement topic + EL->>EM: on_event(Event::Logs([placement_log])) + + Note over EM,LS: Step 2 — Decode and submit (1 log = 1 submission) + EM->>SD: decode OrderPlacement(sender, order, sig, data) + SD-->>EM: (sender, GPv2OrderData, EIP-1271 sig, data) + + EM->>CR: build OrderCreation with EIP-1271 scheme
pointing at CoWSwapEthFlow contract + CR-->>EM: OrderCreation + OrderUid + + EM->>HS: cow-api.submit-order(chain_id, order_json) + HS->>OB: POST /api/v1/orders + OB-->>HS: result + + alt 200 OK with OrderUid + HS-->>EM: Ok(OrderUid) + EM->>LS: set("submitted:{uid}", order_uid) + else 4xx with error code + HS-->>EM: Err(host-error with code) + EM->>CR: OrderPostError::try_from(host-error).retry_hint() + CR-->>EM: TryNextBlock / BackoffSeconds(s) / Drop + + alt TryNextBlock + Note over EM: log and skip; next block retries + else BackoffSeconds(s) + EM->>LS: set("backoff:{uid}", now + s) + else Drop + EM->>LS: set("dropped:{uid}", reason) + end + end +``` + +### Participant reference + +| Participant | Role in this flow | +|---|---| +| **User** | The trader. Deposits native ETH into the `CoWSwapEthFlow` contract and specifies swap parameters. The contract is the EIP-1271 signer on behalf of the user. | +| **CoWSwapEthFlow Contract** | Custodies the ETH, stores the order metadata on-chain, and emits `OrderPlacement` so off-chain relayers (this module, plus CoW's own internal autopilot indexer) can pick up the order. | +| **RPC Node** | Delivers the `OrderPlacement` log via the persistent WebSocket subscription. No `eth_call` is needed in this flow — the log contains everything required to reconstruct the order. | +| **EventLoop** | Routes the log to the eth-flow module based on the `[[subscription]]` entry in its `module.toml` (matching the `CoWSwapEthFlow` contract address and the `OrderPlacement` topic). | +| **eth-flow module (WASM guest)** | Contains the entire EthFlow relay logic: decoding, OrderCreation construction, submission, error handling. No polling loop; one log equals one submission attempt. | +| **alloy_sol_types (in module)** | Decodes the `OrderPlacement` event in module-side Rust. The event payload carries the typed `GPv2OrderData`, the EIP-1271 signature blob, and the extra data field. | +| **cowprotocol types (in module)** | Used to construct the `OrderCreation` with the EIP-1271 signing scheme (the signature points at the `CoWSwapEthFlow` contract address, not at the user's key) and to compute the 56-byte `OrderUid`. `OrderPostError` from the same crate is used to interpret orderbook errors. | +| **HostState (Rust)** | Provides only the `cow-api.submit-order` primitive for this flow. Maps orderbook errors to `host-error` with the original error code preserved so the module can recover the typed `OrderPostError`. | +| **api.cow.fi (Orderbook)** | Receives the order. Returns `OrderUid` on success. Returns a typed error code on failure, which the module recovers and passes through `OrderPostError::retry_hint()` to decide what to do next. App-data documents are **not** fetched here; the trader uploads them via `PUT /api/v1/app_data/{hash}` separately. | +| **LocalStore (redb)** | `submitted:{uid}` records successful submissions. `backoff:{uid}` records pending retries with a deadline. `dropped:{uid}` records permanently-failed orders. All entries survive restarts so the module does not re-submit known orders. | + +--- + +## 7. Capability Dispatch (Generic Host Call Path) + +How any WIT function call from a WASM module reaches the host backend it targets. + +```mermaid +flowchart TD + Module["WASM Module\n(twap or eth-flow)"] + Module -->|"e.g. cow-api.submit-order(chain_id, order_json)"| Linker + Linker["wasmtime Linker\n(resolves import → host function)"] + Linker --> CapCheck["HostState\nmanifest.required check\n(returns denied if not declared)"] + CapCheck --> Trace["tracing::info!\n[capability] op chain=…"] + Trace --> HostFn["host backend Rust function"] + HostFn -->|"cow-api"| OBPool["OrderBookPool\n.get(chain_id)?.post_order(order)"] + HostFn -->|"chain (request)"| ProviderP["ProviderPool\n.get(chain_id).request(method, params)"] + HostFn -->|"chain (subscribe-*)"| EngineSubs["engine-managed streams\nopened at boot from module.toml"] + HostFn -->|"local-store"| StoreP["LocalStore\n.get/set/delete/list_keys\n(namespace-prefixed host-side)"] + HostFn -->|"logging · clock · random"| Misc["direct host impl"] + OBPool --> CowAPI["api.cow.fi\nPOST /api/v1/orders"] + ProviderP --> RPCNode["RPC Node\nJSON-RPC"] + CowAPI -->|"OrderUid or error"| Module + RPCNode -->|"result"| Module +``` + +### Node reference + +| Node | What it does | +|---|---| +| **WASM Module** | The guest program. It calls imported WIT functions exactly like regular function calls — it has no visibility into the host machinery behind them. | +| **wasmtime Linker** | `Linker` built once at startup. `wasmtime::component::bindgen!` generates a `Shepherd` world struct and one trait per WIT interface (e.g. `shepherd::cow::cow_api::Host`, `nexum::host::local_store::Host`). `Shepherd::add_to_linker(&mut linker, \|state\| state)` registers every trait method as a host function. After that, calls from WASM resolve with zero dynamic dispatch overhead — the vtable is built at link time, not per-call. | +| **HostState — manifest.required check** | Before dispatching, `HostState` checks that the called capability is listed under `[capabilities].required` in the module's `module.toml`. If not, it returns `host-error { kind: denied }` immediately. The 0.2 engine validates known capability names at boot via `KNOWN_CAPABILITIES`; per-call gating is the M2 target. | +| **tracing::info!** | Every host call emits a structured trace event (capability name, chain id, etc.). Operators use `RUST_LOG=shepherd=debug` to see every call a module makes. | +| **host backend Rust function** | `HostState` implements one generated trait per WIT interface. Each `async fn` in the trait receives `&mut self` (giving access to all host resources) and returns the WIT-mapped Rust type. There are no CoW-strategy-specific backends — only the universal ones plus `cow-api` (ADR-0006). | +| **OrderBookPool** | Looks up the `OrderBookApi` client for the requested chain and calls `post_order`. Returns a 56-byte `OrderUid` on success or an `OrderPostError`-bearing host error on failure. | +| **ProviderPool (chain.request)** | Looks up the alloy provider for the requested chain and dispatches the JSON-RPC call (`eth_call`, `eth_getLogs`, etc.). | +| **engine-managed streams (chain.subscribe-*)** | Subscriptions are not exposed as runtime-callable host functions in 0.2. They are opened by the engine at boot from each module's declared `[[subscription]]` entries; events flow into the module via `on_event`. Dynamic `register-address` for factory patterns is deferred (ADR-0008). | +| **LocalStore** | Reads or writes a key in the module's namespace. The module sees plain keys; the host silently prepends a 32-byte namespace prefix. | +| **logging · clock · random** | Lightweight stateless helpers; implemented directly on `HostState` without a separate pool. | + +--- + +## 8. Repository Dependency Map + +```mermaid +graph TD + upstream["cowdao-grants/cow-rs\n(alpha.3 on crates.io — PR #5 base)"] + bleu_cr["bleu/cow-rs\n(PR #5 head branch)"] + prims["Protocol primitives added to PR #5:\n• OrderPostError + retry_hint\n• OrderBookApi::with_base_url\n• wasm32 feature-gate"] + existing["Already in PR #5:\nOrder · OrderCreation · OrderUid\nsigning schemes · OrderBookApi"] + patch["[patch.crates-io]\ncowprotocol → bleu/cow-rs @ rev"] + engine["nexum-engine\n(WIT host, supervisor, event loop)"] + witCowApi["shepherd:cow/cow-api WIT"] + modules["WASM modules\n(twap · eth-flow)"] + + upstream -->|"is PR base"| bleu_cr + bleu_cr --> prims + bleu_cr --> existing + patch -->|"redirects cowprotocol to rev of"| bleu_cr + engine -->|"workspace Cargo.toml declares"| patch + engine --> witCowApi + witCowApi -->|"backed by OrderBookApi"| existing + modules -->|"imports WIT"| witCowApi + modules -.->|"consumes types (wasm32 feature)"| existing + modules -.->|"matches on errors"| prims +``` + +### Node reference + +| Node | What it is | +|---|---| +| **cowdao-grants/cow-rs** | The upstream CoW Protocol Rust SDK, maintained by the DAO. Version `alpha.3` is published to crates.io but predates 18 follow-up commits Bleu has been pushing through PR #5. This is the PR base — changes land here eventually. | +| **bleu/cow-rs** | Bleu's repository, which is simultaneously the head branch of the DAO's open PR #5. Every commit Bleu pushes here also advances PR #5 for upstream review. This is not a long-lived parallel fork — it is the active PR branch (ADR-0004). | +| **Protocol primitives added to PR #5** | The three additions Bleu is pushing into PR #5: `OrderPostError` rich variants + `retry_hint()` (critical for module error handling), `OrderBookApi::with_base_url` (barn / staging / forked deployments), and `wasm32` feature-gating (critical so guest modules can consume `cowprotocol` types). All three are protocol primitives — they describe what CoW Protocol *is*, not how a particular strategy uses it. TWAP polling and EthFlow event decoding are explicitly *not* added here; they stay in module code (ADR-0007). | +| **Already in PR #5** | The types and orderbook client Bleu's modules consume but did not add: `Order`, `OrderCreation`, `OrderUid`, signing-scheme enums, and `OrderBookApi`. These existed in PR #5 before the M2 work. | +| **[patch.crates-io]** | A single line in the workspace `Cargo.toml` that tells Cargo to use `bleu/cow-rs` at a specific git rev instead of the `alpha.3` release on crates.io. Bumping the rev is the only change needed to pick up a new primitive after it is pushed to `bleu/cow-rs` (ADR-0004). | +| **nexum-engine** | The engine binary. Contains the WIT host implementations, Supervisor, EventLoop, config loaders, and alloy/redb integration. Contains no CoW Protocol logic — protocol primitives live in `bleu/cow-rs`; strategy logic lives in guest modules. | +| **shepherd:cow/cow-api WIT** | The only CoW-specific WIT interface in 0.2. The engine implements it (host side); WASM modules import it (guest side). Backed by `OrderBookPool` (and through that, `OrderBookApi` from `cow-rs`). | +| **WASM modules (twap · eth-flow)** | The grant deliverables. Compiled to `.wasm` Component Model binaries. Import only universal WIT interfaces (`chain`, `local-store`, `logging`) plus `shepherd:cow/cow-api`. Consume `cowprotocol` types directly through the wasm32 feature for building `OrderCreation` and pattern-matching on `OrderPostError`. Contain all TWAP and EthFlow strategy logic themselves (ADR-0006). | diff --git a/docs/diagrams/engine-boot.mmd b/docs/diagrams/engine-boot.mmd new file mode 100644 index 0000000..85ff094 --- /dev/null +++ b/docs/diagrams/engine-boot.mmd @@ -0,0 +1,59 @@ +sequenceDiagram + autonumber + actor Op as Operator + participant Bin as nexum-engine binary + participant FS as Filesystem + participant Trc as tracing subscriber + participant PP as ProviderPool + participant LS as LocalStore (redb) + participant OBP as OrderBookPool + participant Sup as Supervisor + participant Mod as Module instance(s) + participant EL as Event Loop + + Op->>Bin: nexum-engine --engine-config engine.toml + Bin->>FS: read engine.toml + FS-->>Bin: EngineConfig { engine, chains, modules } + + Bin->>Trc: init_tracing(log_level) + Note over Trc: RUST_LOG overrides
engine.toml.log_level + + Bin->>PP: ProviderPool::from_config(&cfg) + loop For each chain in cfg.chains + alt URL is ws:// or wss:// + PP->>PP: ProviderBuilder.connect_ws(WsConnect) + else URL is http:// or https:// + PP->>PP: ProviderBuilder.connect_http(Url) + end + Note over PP: Connection failure = fatal,
engine refuses to start + end + PP-->>Bin: pool ready + + Bin->>LS: LocalStore::open(state_dir) + Note over LS: Creates redb file if missing,
materialises shared table. + LS-->>Bin: store ready + + Bin->>OBP: OrderBookPool::default() + Note over OBP: One OrderBookApi per
cowprotocol::Chain variant. + OBP-->>Bin: pool ready + + Bin->>Sup: Supervisor::boot(cfg, host_resources) + loop For each [[modules]] entry in cfg.modules + Sup->>FS: read module.toml + FS-->>Sup: Manifest + Sup->>FS: load .wasm + FS-->>Sup: wasm bytes + Sup->>Mod: wasmtime Component compile + instantiate
with dedicated HostState + Sup->>Mod: call init(config) inside write txn + Mod-->>Sup: Ok or Err + Sup->>Sup: record subscriptions declared in manifest + end + Sup-->>Bin: modules loaded + + Bin->>EL: open block + log subscriptions + EL->>PP: subscribe_blocks(chain_id) per unique chain + EL->>PP: subscribe_logs(chain_id, filter) per unique filter + PP-->>EL: streams ready + + Bin->>EL: run_event_loop(futures::select_all) + Note over EL: Loop until SIGINT or SIGTERM diff --git a/docs/diagrams/module-lifecycle.mmd b/docs/diagrams/module-lifecycle.mmd new file mode 100644 index 0000000..7a73bd1 --- /dev/null +++ b/docs/diagrams/module-lifecycle.mmd @@ -0,0 +1,39 @@ +stateDiagram-v2 + direction LR + + [*] --> Resolve + + Resolve --> Load: bundle fetched OK + Resolve --> Dead: resolution failed permanently + + Load --> Init: wasmtime compile and instantiate OK + Load --> Restart: compile or instantiate failed + + Init --> Run: init(config) returned Ok + Init --> Restart: init returned Err or trapped + + Run --> Run: on_event handled OK + Run --> Restart: on_event trapped or returned Err or fuel exhausted + + Restart --> Init: backoff expired (1s, 2s, 4s, up to 5min cap) + Restart --> Dead: max_consecutive_failures reached (default 10) + + Dead --> Init: operator action (nexum module restart or reload) + Dead --> [*]: operator removes module + + note right of Restart + Exponential backoff with jitter. + Memory zeroed, local-store survives. + InstancePre reused, no recompile. + end note + + note right of Dead + Module excluded from dispatch. + Engine continues running other modules. + Manual intervention required to resume. + end note + + note right of Init + Runs inside an implicit write txn. + Ok commits, Err rolls back. + end note diff --git a/docs/diagrams/sequence-ethflow.mmd b/docs/diagrams/sequence-ethflow.mmd new file mode 100644 index 0000000..7427779 --- /dev/null +++ b/docs/diagrams/sequence-ethflow.mmd @@ -0,0 +1,39 @@ +sequenceDiagram + autonumber + actor User as User
(wallet) + participant Contract as CoWSwapEthFlow
(on-chain) + participant RPC as Chain RPC
(WSS) + participant EL as nexum-engine
Event Loop + participant Mod as ethflow-watcher
(WASM module) + participant SolDec as alloy_sol_types
(in module) + participant Cow as cowprotocol crate
(in module, wasm32) + participant Host as HostState + participant OB as CoW Orderbook + + User->>Contract: createOrder(order, msg.value=ETH) + Contract->>Contract: store orders[hash] = onchainData,
emit OrderPlacement + Contract-->>RPC: log emitted on block N + + RPC-->>EL: eth_subscribe logs delivery + EL->>Mod: on_event(LogEvent) + + Mod->>SolDec: decode OrderPlacement(sender, order, sig, data) + SolDec-->>Mod: (sender, GPv2OrderData, EIP1271-sig, data) + + Mod->>Cow: build OrderCreation with EIP-1271 scheme
pointing at CoWSwapEthFlow contract + Cow-->>Mod: OrderCreation + OrderUid + + Mod->>Host: cow-api.submit-order(chain_id, order_json) + Host->>OB: POST /api/v1/orders + OB-->>Host: result + + alt 200 OK with OrderUid + Host-->>Mod: Ok(OrderUid) + Mod->>Host: local-store.set("submitted:{uid}", ...) + else 4xx with error code + Host-->>Mod: Err(host-error with code) + Mod->>Cow: OrderPostError::try_from(host-error).retry_hint() + Cow-->>Mod: RetryHint variant + end + + Note over Mod: Module applies RetryHint:
TryNextBlock - log + skip
BackoffSeconds(s) - persist next_attempt = now + s
Drop - permanent failure, do not retry diff --git a/docs/diagrams/sequence-twap.mmd b/docs/diagrams/sequence-twap.mmd new file mode 100644 index 0000000..5b5e75e --- /dev/null +++ b/docs/diagrams/sequence-twap.mmd @@ -0,0 +1,56 @@ +sequenceDiagram + autonumber + actor User as User
(wallet) + participant Contract as ComposableCoW
(on-chain) + participant RPC as Chain RPC
(WSS) + participant EL as nexum-engine
Event Loop + participant Mod as twap-monitor
(WASM module) + participant SolDec as alloy_sol_types
(in module) + participant Cow as cowprotocol crate
(in module, wasm32) + participant Host as HostState
(host backends) + participant OB as CoW Orderbook + + Note over User,Contract: Registration (one-time per TWAP) + User->>Contract: create(twapParams) + Contract-->>RPC: emit ConditionalOrderCreated(owner, params) + RPC-->>EL: log delivered + EL->>Mod: on_event(LogEvent) + Mod->>SolDec: decode ConditionalOrderCreated + SolDec-->>Mod: (owner, params, salt) + Mod->>Host: local-store.set("watch:{owner}:{hash}", params) + + Note over EL,OB: Per-block polling loop + loop For each block N + RPC-->>EL: eth_subscribe newHeads + EL->>Mod: on_event(BlockEvent { N }) + Mod->>Host: local-store.list_keys("watch:") + + loop For each watch where next_attempt <= N + Mod->>Host: chain.request(chain_id, "eth_call", [...]) + Host->>RPC: eth_call ComposableCoW.
getTradeableOrderWithSignature(owner, params) + RPC-->>Host: return value or revert + Host-->>Mod: result (JSON encoded) + Mod->>SolDec: decode return or interpret revert reason + SolDec-->>Mod: PollOutcome (module-defined enum) + + alt Ready (order, signature) + Mod->>Cow: build OrderCreation + Cow-->>Mod: OrderCreation + Mod->>Host: cow-api.submit-order(chain_id, order_json) + Host->>OB: POST /api/v1/orders + OB-->>Host: Ok(OrderUid) or Err(error_code) + Host-->>Mod: Result + alt Ok(uid) + Mod->>Host: local-store.set("submitted:{uid}", ...) + else Err + Mod->>Cow: OrderPostError::try_from(host-error)
.retry_hint() + Cow-->>Mod: TryNextBlock / BackoffSeconds(s) / Drop + Mod->>Host: local-store update
(next_attempt or remove watch) + end + else NotReady (try at epoch t) + Mod->>Host: local-store.set("watch:...next_attempt", t) + else Terminal (TWAP completed or cancelled) + Mod->>Host: local-store.delete("watch:...") + end + end + end diff --git a/docs/diagrams/subscription-dispatch.mmd b/docs/diagrams/subscription-dispatch.mmd new file mode 100644 index 0000000..6f11359 --- /dev/null +++ b/docs/diagrams/subscription-dispatch.mmd @@ -0,0 +1,61 @@ +graph TB + subgraph manifests["Module Manifests (module.toml per module)"] + M1S["module twap-monitor:
[[subscription]] kind=log
chain=1, address=ComposableCoW,
topics=[ConditionalOrderCreated]
[[subscription]] kind=block, chain=1"] + M2S["module ethflow-watcher:
[[subscription]] kind=log
chain=1, address=CowEthFlow,
topics=[OrderPlacement]"] + M3S["module other-module:
[[subscription]] kind=block, chain=1"] + end + + subgraph supervisor["Supervisor: aggregate at boot"] + BlockAgg["Block subscriptions
grouped by chain_id"] + LogAgg["Log subscriptions
grouped by (chain_id, filter_key)
where filter_key = address+topics hash"] + end + + subgraph subs["Aggregated WSS subscriptions"] + BSub["eth_subscribe newHeads
chain=1 (shared by all subscribers)"] + LSub1["eth_subscribe logs
chain=1, filter=ComposableCoW+ConditionalOrderCreated
(owner: twap-monitor)"] + LSub2["eth_subscribe logs
chain=1, filter=CowEthFlow+OrderPlacement
(owner: ethflow-watcher)"] + end + + subgraph dispatch["Event Loop dispatch"] + Decide{Event kind?} + Broadcast["Fan-out: dispatch to ALL
subscribers of that chain"] + Route["Route: dispatch to OWNER
of matching filter_key only"] + end + + subgraph delivery["Module on_event invocations"] + D1["twap-monitor.on_event(BlockEvent)"] + D2["ethflow-watcher.on_event(LogEvent)
or twap-monitor (LogEvent)"] + D3["other-module.on_event(BlockEvent)"] + end + + M1S --> BlockAgg + M1S --> LogAgg + M2S --> LogAgg + M3S --> BlockAgg + + BlockAgg --> BSub + LogAgg --> LSub1 + LogAgg --> LSub2 + + BSub --> Decide + LSub1 --> Decide + LSub2 --> Decide + + Decide -- "block" --> Broadcast + Decide -- "log" --> Route + + Broadcast --> D1 + Broadcast --> D3 + Route --> D2 + + classDef manifest fill:#fff4e6,stroke:#ff9800,color:#000 + classDef agg fill:#e6f3ff,stroke:#1e88e5,color:#000 + classDef wss fill:#f0e6ff,stroke:#7e3ff2,color:#000 + classDef decide fill:#fffde7,stroke:#fbc02d,color:#000 + classDef dispatch fill:#e6ffe6,stroke:#2e7d32,color:#000 + + class M1S,M2S,M3S manifest + class BlockAgg,LogAgg agg + class BSub,LSub1,LSub2 wss + class Decide,Broadcast,Route decide + class D1,D2,D3 dispatch diff --git a/docs/diagrams/wit-call-path.mmd b/docs/diagrams/wit-call-path.mmd new file mode 100644 index 0000000..5fe4159 --- /dev/null +++ b/docs/diagrams/wit-call-path.mmd @@ -0,0 +1,34 @@ +sequenceDiagram + autonumber + participant Src as Module Rust source
(twap-monitor/src/lib.rs) + participant Bindgen as wit-bindgen
(generated stubs) + participant Wasm as WASM Component
(twap.wasm) + participant Wt as wasmtime instance + participant Lk as wasmtime Linker + participant HS as HostState (Rust) + participant PP as ProviderPool + participant Alloy as alloy provider + participant RPC as Chain RPC + + Note over Src,Wasm: Build phase (cargo build) + Src->>Bindgen: chain::request(chain_id, method, params)
(plain Rust call) + Bindgen->>Wasm: compile into WASM Component
with "nexum:host/chain" import + + Note over Wasm,RPC: Runtime: module calls chain::request + Wasm->>Wt: WASM import call:
"nexum:host/chain"."request" + Wt->>Lk: lookup binding for import + Lk->>HS: invoke trait impl:
HostState::Chain::request(...) + Note over HS: tracing::info!("[chain] request
chain=... method=...") + HS->>PP: pool.get(chain_id) + PP-->>HS: &DynProvider + HS->>Alloy: provider.raw_request(method, params) + Alloy->>RPC: JSON-RPC over WSS/HTTP + RPC-->>Alloy: response bytes + Alloy-->>HS: serde_json::Value + HS-->>Lk: Ok(stringified JSON) + Lk-->>Wt: return value (marshaled) + Wt-->>Wasm: import call returns + Wasm-->>Bindgen: unmarshal canonical ABI
back to Rust types + Bindgen-->>Src: returns Result + + Note over Src,RPC: All host calls follow this path.
Only the trait impl on the right side
(HS → PP/OBP/LS/...) changes per capability.