You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adopted from #638 / #645. The research recommendation was (c) hybrid — keep per-protocol prepare_* for flows that encode prepare-time invariants, route the long tail through prepare_custom_call. The cutoff rule needs a written home so future protocol-add decisions don't re-litigate the same question.
Otherwise route the agent to prepare_custom_call. The cutoff is structural, not popularity-based: a Uniswap V3 collect that doesn't take slippage args could legitimately go generic; a brand-new Layer-N farm that takes a min-out arg should not.
Why this is the right home
Project CLAUDE.md (/home/szhygulin/dev/recon-mcp/CLAUDE.md) already carries the project-specific gate rules (Pre-Sign Gate Surface Sweeps, Typed-Data Signing Discipline, Cross-Repo Scope Splits). The cutoff rule is the same shape: a structural decision that future contributors / agents need to apply when scoping new protocol coverage. ROADMAP.md tracks individual protocol adds; it isn't where structural meta-rules live.
Threat-model rationale (for the rule body)
assertTransactionSafe blocks 4 (catch-all unknown destination) and 5 (per-destination ABI-selector check) are bypassed for ack-stamped prepare_custom_call txs; only blocks 2 (approve spender allowlist) and 3 (transfer on unknown token) still fire. Per-protocol tools concentrate prepare-time invariants the generic path cannot enforce — picking prepare_custom_call for a new protocol that meets criteria 1–5 silently drops those invariants behind a single ack.
Scope
Add a "Per-protocol vs. generic-call cutoff" section to project CLAUDE.md with the 5-criterion rule and the threat-model one-liner.
Adopted from #638 / #645. The research recommendation was (c) hybrid — keep per-protocol
prepare_*for flows that encode prepare-time invariants, route the long tail throughprepare_custom_call. The cutoff rule needs a written home so future protocol-add decisions don't re-litigate the same question.Cutoff rule (verbatim from #645's research note)
Keep a per-protocol
prepare_*when the tool encodes any of:Otherwise route the agent to
prepare_custom_call. The cutoff is structural, not popularity-based: a Uniswap V3 collect that doesn't take slippage args could legitimately go generic; a brand-new Layer-N farm that takes a min-out arg should not.Why this is the right home
Project CLAUDE.md (
/home/szhygulin/dev/recon-mcp/CLAUDE.md) already carries the project-specific gate rules (Pre-Sign Gate Surface Sweeps, Typed-Data Signing Discipline, Cross-Repo Scope Splits). The cutoff rule is the same shape: a structural decision that future contributors / agents need to apply when scoping new protocol coverage. ROADMAP.md tracks individual protocol adds; it isn't where structural meta-rules live.Threat-model rationale (for the rule body)
assertTransactionSafeblocks 4 (catch-all unknown destination) and 5 (per-destination ABI-selector check) are bypassed for ack-stampedprepare_custom_calltxs; only blocks 2 (approve spender allowlist) and 3 (transfer on unknown token) still fire. Per-protocol tools concentrate prepare-time invariants the generic path cannot enforce — pickingprepare_custom_callfor a new protocol that meets criteria 1–5 silently drops those invariants behind a single ack.Scope
Related
prepare_custom_calland ack gate)VAULTPILOT_PROTOCOLS— the catalog-growth lever, complementary)