Design proposal: provider-neutral optional x402 preflight hook before sign-tx

Obol Stack already has both sides of a useful agent safety loop:

• ethereum-local-wallet/scripts/signer.py::cmd_sign_tx constructs a complete EVM transaction before sending it to the remote signer.
• buy-x402/scripts/buy.py::cmd_pay can purchase an arbitrary x402 POST resource on Base with a cost cap.

Would maintainers be open to a provider-neutral, opt-in x402 preflight hook between transaction construction and remote signing?

Proposed minimal shape

• Add an optional --preflight-x402-url flag (or TX_PREFLIGHT_X402_URL configuration) to sign-tx / send-tx.
• After tx_req is complete and before _signer_post(.../transaction), call the existing x402 buyer with a configured maximum cost.
• Send a generic JSON transaction envelope: {chain, from, to, value, calldata}.
• Define a small response contract with outcome: PAY | REVIEW | REJECT and optional reason codes.
• PAY continues; REVIEW and REJECT stop by default, with a separate explicit override.
• Keep the feature disabled by default. Do not expose private keys or change the remote-signer trust boundary.

Jarvis is one concrete compatibility case for the hook:

POST https://jarvis-orderflow-router.yl124915300.workers.dev/v1/outcomes/tx-execution-preflight
cost cap: $0.008 USDC
network: Base mainnet
body: {chain:"base", from, to, value, calldata}

It performs point-in-time balance, allowance, nonce, contract classification, eth_call, and gas checks and returns PAY, REVIEW, or REJECT. This should be documented as a third-party paid provider, not hard-coded as a default or endorsed service.

Why this fits an actual Obol buyer path

The local-wallet flow can construct, sign, and broadcast arbitrary Base contract calls today. Its current preparation covers nonce/fees/gas estimation, but not token allowance/balance policy, target classification, nonce-gap analysis, or a stable decision/outcome hash. The same runtime already has a real x402 payer and a remote signer capable of the required authorization, so the hook is executable rather than a generic “supports x402” example.

I am opening a design issue before a PR because the main question is architectural: should this live inside signer.py, or should it be a separate orchestration skill that composes ethereum-local-wallet and buy-x402 without coupling the signer to HTTP policy providers? If maintainers prefer the latter, I can scope a follow-up to a small example/reference implementation.

Start with ethereum-local-wallet/scripts/signer.py, especially cmd_sign_tx and the point before _signer_post(.../transaction), then compare buy-x402/scripts/buy.py::cmd_pay. Resolve whether the hook belongs in signer.py or a separate orchestration skill, and define the provider-neutral request and outcome contract. Done means maintainers have chosen an architecture and a bounded implementation scope.