[Builder Grant Proposal] OP Security Proxy: Local Pre-Execution & Revert Interception for the Superchain

Hi everyone. I am a solo systems developer building OP Security Proxy (GitHub - Ishant5436/op-sec-proxy · GitHub), which is an open-source JSON-RPC middleware written in Rust that intercepts and simulates transactions before broadcasting to OP Stack nodes. On EVM rollups, end users and automated agents pay gas fees even when transactions revert on chain due to stale oracle states, localized slippage, or sandwich attacks. For retail users, burning gas on a failed execution creates frustration, and for wallet teams it leads to avoidable support tickets.

The proxy sits between standard wallets or clients and public Optimism RPC nodes. When a client issues an eth_sendRawTransaction request, the proxy intercepts the raw payload and simulates it in process using revm against current chain state. If the simulation executes successfully, the transaction is forwarded upstream to the sequencer over an existing hyper connection pool. If the simulation reverts, the proxy aborts the broadcast completely so zero gas is burned on chain, and immediately returns a standard JSON-RPC error containing decoded Solidity custom errors or panic codes along with an estimated gas saved metric.

The core implementation is open-source under the MIT license with 40 automated tests passing across the Rust core and TypeScript client SDK. In empirical benchmarks against mainnet.optimism.io, the proxy introduces a minimal 11.8 millisecond processing overhead on fair keep-alive connections with session reuse. For clients that make cold requests without connection reuse, the proxy internal connection pool eliminates repetitive TLS 1.3 handshakes to remote endpoints, amortizing roundtrip latency by roughly 97 milliseconds. The full reproduction methodology and raw telemetry logs are recorded in BENCHMARK_RESULTS.md (https://github.com/Ishant5436/op-sec-proxy/blob/main/BENCHMARK_RESULTS.md).

Uncached transaction simulation over public internet RPC currently averages approximately 2.7 seconds because the execution engine must fetch contract state slots across the network during execution. I am requesting 10,000 OP for an initial builder grant to fund three engineering milestones over the next three months. The initial phase tackles state caching, replacing network RPC state queries with a local in-memory LRU trie cache for warm contract bytecode and storage slots to drive simulation latency down toward a sub-65 millisecond target. Following that, work shifts to developer adoption with a TypeScript provider wrapper and standardized error decoding for wallet integrations. The final phase expands routing across OP Mainnet, Base, Mode, Zora, and Fraxtal alongside reproducible Docker containers and systemd service packaging for node operators.

As an individual engineer, I rely on Rust memory safety guarantees, cargo-audit automated dependency scanning, and reproducible GitHub Actions workflows rather than corporate support infrastructure. All code is public and modular. I previously shared an introductory post in the general discussion section of the governance forum under thread 10810 (OP Security Proxy: A local RPC middleware to prevent paying for failed L2 executions), and this grant application will allow me to build and package the middleware as a permanent, zero-cost public good for the Superchain ecosystem.

From a user-support perspective, how will the proxy handle cases where the local simulation is based on slightly stale state but the transaction might still succeed on-chain? It would be useful to understand whether the default behavior is to fail open, and how the wallet communicates simulation uncertainty versus a definite revert.

Regarding stale state and transient boundaries, the proxy strictly defaults to fail-open whenever there is execution ambiguity or when a simulation fails due to state retrieval timeouts or RPC sync lags. If the proxy cannot deterministically prove a failure against the current block header, it logs the warning and forwards the raw transaction directly upstream to the sequencer so user submissions are never blocked by middleware latency or momentary node lag.

For transaction categorization, the proxy distinguishes between invariant contract panics and state-dependent reverts. Static reverts such as invalid signatures, nonce mismatches, unauthorized access, or insufficient balance are deterministic and will fail regardless of whether the head moved by a block. In those cases, the proxy returns a standard -32000 error with the decoded reason and flags the simulation as definite.

State-dependent reverts, such as slippage limits on decentralized exchanges or time-sensitive oracle feeds, are where stale state matters most. When revm returns a revert from a condition that depends on volatile storage slots, the proxy includes an uncertainty flag in the JSON-RPC error payload under data.confidence set to uncertain alongside the block number used for simulation. In the TypeScript provider wrapper, wallets can inspect this field to decide how to treat the result. For instance, a wallet can show a clear distinction between a transaction that is guaranteed to revert versus one that failed due to potential slippage drift at the head, or choose to pass uncertain transactions upstream automatically with a warning notice in the user interface.

1 Like

A quick update for the review team following up on the discussion above. The simulation confidence classification and fail-open behavior discussed here are now fully implemented and passing in the public repository under commit 8376212.

When revm encounters transient database or RPC connection timeouts, the proxy classifies the execution as uncertain and automatically forwards the raw transaction directly upstream to the sequencer when fail-open is enabled, ensuring zero user drop-offs. If a wallet wishes to inspect or handle the simulation result, the JSON-RPC error payload returns the confidence rating along with decoded contract reverts. The TypeScript client library at @op-sec/client has also been updated with these types, and all unit, integration, and linter checks pass with zero warnings across 32 tests.

1 Like

A quick procedural update for the review team: project metadata and repository ownership verification have now also been completed and published onchain via OP Atlas at https://atlas.optimism.io/project/0x6ab1a8cbf07a602a09c6e754b34361f336ba8e62c1a4792659d7b5ac4a27663b.

1 Like