Problem. shepherd-sdk::cow::resolve_app_data fetches the appData JSON via GET /api/v1/app_data/{hash} before every twap-monitor submission, and the twap-monitor strategy depends on it. ADR-0007 already verified this is unnecessary: watch-tower never fetches app-data; it submits the hash and classifies INVALID_APP_DATA (backoff) / APPDATA_FROM_MISMATCH (drop). The orderbook accepts OrderCreation appData as the raw hash and joins the pre-registered document on its side.
Current. The GET is provably redundant: it queries the same orderbook database that validates the submission, so both branches (registered / not registered) end in the same outcome as a hash-only submit, one round-trip later, plus a 404 dead-end failure mode watch-tower does not have. The likely shaping force is that the vendored cow-rs OrderCreation::from_signed_order_data only models the full-JSON appData variant.
Proposed. Expose the hash-only appData variant (OrderCreationAppData::Hash shape) in cow-rs's order-creation constructor first, per the ADR-0007 upstream-first rule; bump the patched rev; switch twap-monitor to submit the on-chain hash verbatim; delete shepherd-sdk/src/cow/app_data.rs and its module docs.
Notes. The INVALID_APP_DATA / APPDATA_FROM_MISMATCH arms already exist in classify_api_error; behaviour then matches watch-tower exactly. Also removes one cow-api GET dependency from the module's capability footprint, which matters for the intent-architecture port (docs PR #132) where twap-monitor's venue surface shrinks to submit-only.
Problem.
shepherd-sdk::cow::resolve_app_datafetches the appData JSON viaGET /api/v1/app_data/{hash}before every twap-monitor submission, and the twap-monitor strategy depends on it. ADR-0007 already verified this is unnecessary: watch-tower never fetches app-data; it submits the hash and classifiesINVALID_APP_DATA(backoff) /APPDATA_FROM_MISMATCH(drop). The orderbook acceptsOrderCreationappData as the raw hash and joins the pre-registered document on its side.Current. The GET is provably redundant: it queries the same orderbook database that validates the submission, so both branches (registered / not registered) end in the same outcome as a hash-only submit, one round-trip later, plus a 404 dead-end failure mode watch-tower does not have. The likely shaping force is that the vendored cow-rs
OrderCreation::from_signed_order_dataonly models the full-JSON appData variant.Proposed. Expose the hash-only appData variant (
OrderCreationAppData::Hashshape) in cow-rs's order-creation constructor first, per the ADR-0007 upstream-first rule; bump the patched rev; switch twap-monitor to submit the on-chain hash verbatim; deleteshepherd-sdk/src/cow/app_data.rsand its module docs.Notes. The
INVALID_APP_DATA/APPDATA_FROM_MISMATCHarms already exist inclassify_api_error; behaviour then matches watch-tower exactly. Also removes onecow-apiGET dependency from the module's capability footprint, which matters for the intent-architecture port (docs PR #132) where twap-monitor's venue surface shrinks to submit-only.