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.
Obol Stack already has both sides of a useful agent safety loop:
ethereum-local-wallet/scripts/signer.py::cmd_sign_txconstructs a complete EVM transaction before sending it to the remote signer.buy-x402/scripts/buy.py::cmd_paycan 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
--preflight-x402-urlflag (orTX_PREFLIGHT_X402_URLconfiguration) tosign-tx/send-tx.tx_reqis complete and before_signer_post(.../transaction), call the existing x402 buyer with a configured maximum cost.{chain, from, to, value, calldata}.outcome: PAY | REVIEW | REJECTand optional reason codes.PAYcontinues;REVIEWandREJECTstop by default, with a separate explicit override.Jarvis is one concrete compatibility case for the hook:
It performs point-in-time balance, allowance, nonce, contract classification,
eth_call, and gas checks and returnsPAY,REVIEW, orREJECT. 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 composesethereum-local-walletandbuy-x402without coupling the signer to HTTP policy providers? If maintainers prefer the latter, I can scope a follow-up to a small example/reference implementation.