TL;DR: Openfort now takes advantage of EIP-7966 (eth_sendRawTransactionSync) on endpoints that support it. When available, your send becomes a single call that returns a receipt, a typed timeout (pending), or a real error—no DIY polling loops. That means faster perceived UX and fewer edge cases for wallets, games, agents, and paymasters. If the endpoint doesn’t support 7966, Openfort automatically falls back to the classic send + receipt flow.
What 7966 is (and why it helps Openfort users)
Traditionally, apps submit a tx with eth_sendRawTransaction, then poll eth_getTransactionReceipt until confirmation. EIP-7966 introduces eth_sendRawTransactionSync—a single RPC that submits the signed tx and waits briefly (node-configured; the EIP recommends a small default, e.g. ~2s) to return the receipt, a timeout (meaning “not included yet”), or a clear error. This collapses round-trips and reduces submission-to-confirmation latency on low-latency chains.
Key point: 7966 is an Interface EIP in Draft and optional. Support varies by provider/chain; that’s why Openfort negotiates it per connection and falls back seamlessly.
How Openfort implements it
-
Auto-detect + route: If the connected RPC exposes
eth_sendRawTransactionSync, Openfort uses it; otherwise we use our hardened send-and-receipt path. No code changes needed in your app. -
Three explicit outcomes your UI can trust:
confirmed→ standard receipt object (same shape aseth_getTransactionReceipt)pending_timeout→ clearly “not yet included,” not a failureerror→ meaningful error (e.g., nonce/underpriced/revert)
-
Safer UX defaults: Treat
pending_timeoutas pending (no double-submit). Openfort will continue background tracking as usual if you choose.
What you should expect (performance & claims)
- Latency/throughput: The EIP’s goal is to reduce end-to-end latency by ~50% on suitable networks by removing the extra RPC round-trip. Real-world gains depend on the chain, sequencer, and your RPC’s implementation.
- Timeouts: The spec recommends a small node-configured default (≈2s); providers may choose different windows (some expose longer caps). Openfort forwards these semantics while letting you keep your own UI timers.
Why this matters for wallet UX, not just infra
- Instant, trustworthy feedback: Users see “confirmed” faster, “pending” when appropriate, and useful errors instead of ambiguity.
- Fewer “did it go through?” tickets: Cleaner states cut support load.
- Less glue code: Remove custom polling/retry utilities and race-condition bandaids—one code path across chains.
FAQs
Is 7966 replacing normal sends? No. It’s additive and optional. Nodes without it return “method not found,” and Openfort falls back to the standard flow automatically.
What timeout should I show users? Treat node timeouts as “still pending”, not a failure. Keep your UX timer small (e.g., spinner + “pending” badge) and let Openfort follow up in the background if you choose.
Which chains/providers support it?
Support is expanding. Some providers already expose eth_sendRawTransactionSync (often branded as “synchronous send”) on major L2s; Openfort will use it automatically when your endpoint has it.