[Kewe63]

Summary

• reject mined transaction receipts whose execution status is failed
• keep successful receipts returning their transaction hash and block number
• add deterministic loopback JSON-RPC coverage through the real provider path

Problem

The shared transaction helper waited for a receipt but never checked its status. Reverted approvals and CTF operations could therefore print normal success output even though no state change occurred.

Approach

After obtaining the mined receipt, the shared proxy call helper checks its execution status before returning success. Existing callers already propagate helper errors, so they no longer reach their success output for reverted transactions.

Tests

• RED proof: a status-0 receipt was accepted by the previous implementation
• GREEN loopback regression covering status 0 and status 1
• full suite: 83 unit and 49 integration tests passed
• cargo +1.91.1 fmt --check
• cargo +1.91.1 clippy --locked --all-targets -- -D warnings
• git diff --check

Risk

Low. Successful transactions retain the existing return shape. Only receipts that explicitly report failed execution now return an error.

Fixes #95

---

Note

Low Risk
Behavior change only for failed on-chain execution; successful transactions are unchanged and errors already propagate to CLI callers.

Overview
proxy::send_call now treats mined receipts with failed execution (status 0) as errors instead of returning success with a tx hash and block number. Successful txs still return the same (B256, u64) pair after ensure!(receipt.status(), ...).

Callers that use this helper for approvals and CTF flows will surface revert failures instead of printing normal success when on-chain execution failed.

Adds a loopback mock JSON-RPC server and a tokio test that drives the real provider path via POLYMARKET_RPC_URL, covering both reverted and successful receipts.

^{Reviewed by Cursor Bugbot for commit f6073ef. Bugbot is set up for automated code reviews on this repo. Configure here.}